===================================================================== Post 4.0.1 Pre 4.1 ===================================================================== Merge of dynamic behaviors branch ---------------------- o The IvP Helm now strictly enforces the rule that behaviors must have unique names - due to the way that dynamic behavior spawning was implemented in this release. o Dynamic behavior spawning has been implemented. Behaviors specified in the .bhv files may be used as templates for spawning new behaviors based on incoming messages through the UPDATES parameter. Templating is enabled via "templating=clone" or "templating=spawn" configurations for the behavior. o As part of the dynamic behavior spawning implementation, the .bhv file "populator" methods were nearly completely re-written. o The helm no longer publishes UH_*, PC_*, PWT_*, STATE_* MOOS variables for each behavior. A single BHV_STATUS publication is made for each behavior automatically, with the name of the behavior specified in in one of the fields. o IvPBehavior *flags parameters: all flags posted by a helm behavior, activeflag, inactiveflag, idleflag, endflag, runflag, may now contain one of four macros in postings of strings. $[OWNSHIP] will expand to the name of ownship (the name of the MOOS community), $[BHVNAME] will expand to the behavior name, $[BHVTYPE] will expand to the behavior type, and $[CONTACT] will expand to the contact name for contact-related behaviors. o The s5_echo mission was added to ivp/missions/ to demonstrate the dynamic spawning of behaviors. o The m2_berta mission was added to ivp/missions/ to demonstrate the dynamic spawning of behaviors, collision avoidance behavior, and the pBasicContactMgr application. o The pBasicContactMgr application was added to the repository. It works with the new helm feature for dynamic behavior spawning. o IvPBehavior::onComplete() is implemented as a virtual function to be overloaded by behavior authors. It is called once, only when the behavior enters the complete state, prior to being deleted from the helm. o Bug fix: when behaviors complete due to a timeout, via the duration parameter, they would enter the idle state for one last iteration, and invoke the onIdleState() functions before completing. It now goes directly into the complete state on the very iteration its duration times-out. o LifeEvents are defined in lib_behaviors, to mean the spawning, or death of a behavior. Or when a behavior spawning is aborted. The helm publishes a new variable IVPHELM_LIFE_EVENT whenever a life event occurs. o The uHelmScope application registers for IVPHELM_LIFE_EVENT posts from pHelmIvP and may generate a "life event" report by toggling the 'L' key. o The aloghelm utility was added to generate a life-event report for a given alog file, based on the IVPHELM_LIFE_EVENT posts logged. ---------------------- o Jan 23rd: Minor enhancement: pMarineViewer now accepts BEARING_LINE artifacts to render a bearing line for a given vehicle, presumably to render directional sensor information. o Jan 22nd: Minor bug fix: Modified HelmIvP to update the info_buffer timestamp only once on each iteration. This fixes a bug where calls to getBufferTimeValue(varname) were returning nonzero time durations even if a variable was updated on the current iteration. o Jan 9th: Minor enhancement: uTimerScript scripts may be designated as atomic (script_atomic = true). o Jan 9th: Minor enhancement: iMarinesim accepts a IMS_DECELERATION parameter for adjusting how the vehicle decelerates through the water. o Jan 9th: Interface change iMarineSim: The default prefix to variables published changed from MARINESIM_ to IMS_. For example MARINESIM_X would now be published as IMS_X. When iMarineSim is used as a proxy for navigation generating NAV_* data, it is still recommended to explicitly set the iMarineSim prefix to NAV_ in the config block. o Jan 9th: Signficant enhancement: iMarineSim accepts IMS_FORCE_VECTOR and IMS_FORCE_VECTOR_ADD for accepting outside influence in generating simulated force vectors simulating for example wind gusts. See documentation for uTimerScript. o Jan 9th: Minor enhancement: Added slip_radius as an alternative parameter designation in place of nm_radius in the BHV_Waypoint behavior. o Jan 9th: Significant enhancement: Augmented pMarineViewer to allow for configuration of left and right mouse clicks with macro expansion. See the helm documentation looking for the MOOS variable MVIEWER_LCLICK in the index. Also see for example the s4_delta example mission: left_context[survey-point] = SURVEY_UPDATES = points = vname=$(VNAME), \ x=$(XPOS), y=$(YPOS), format=lawnmower, label=delta, width=70, \ height=30, lane_width=8, rows=north-south, degs=80 left_context[survey-point] = SURVEY = true o Jan 9th: Minor Enhancement: Added "stale_report_thresh" parameter to pMarineViewer to allow for configuration greater than the default 5 seconds before "STALE-REPORT" message is displayed. o Dec 31st: Minor enhancement: Augmented .bhv file syntax to accept multiple initializations on a single line, e.g. "initialize FOO=true, BAR=false". The file lib_helmivp/PopulatorBehaviorSet.cpp was edited. o Dec 17th: Minor bug fix: The WaypointEngine, used by BHV_Waypoint, should have been resetting its cycle_count member variable to zero on each resetting of the waypoint pattern. The count is really only relevant to a given pattern. o Dec 13th: Minor enhancement: Altered pMarineViewer handling of left and right mouse click context handling. Much more flexible in the way MOOS variables are poked on the event of a left/right click. See example mission s3_charlie. o Dec 12th: Moved the InfoBuffer class to lib_logic from lib_behaviors so other applications using logic utilities will have access to the InfoBuffer class (which facilitates the use of the logic utilities in an application that uses logic utilities). o Dec 11th: Minor Enhancement: Allowed BHV_Loiter to accept a visual hint defining what polygon label displayed. If no label, it defaults to the vehicle_name+_+behavior_name. o Dec 10th: Minor Enhancement: augmented iMarineSim to accept startpos configuration strings in the form of "x=val, y=val, hdg=val, spd=val, dep=val" in addition to the prior allowed formats. ===================================================================== Post 4.0 Nov 17th 2009 Pre 4.0.1 Dec 3rd 2009 MOOS r.2300, MOOS-IvP r.2406 ===================================================================== o Dec 2nd: Pulled in a new version of MOOS (r.2300) that contains an additional function, MissionReader::EnableVerbatimQuoting(bool). Calling this prior to MissionReader::GetConfiguration() allows the double-quotes to be retained in the incoming string, as was done by default in MOOS r.2292, but changed in MOOS r.2295 o Dec 2nd: Changed all MOOS-IvP applications to invoke MissionReader::EnableVerbatimQuoting(false) prior to reading MOOS file configuration lines, to retain the double-quotes. In Release 4.0 the applications uTimerScript and pMarineViewer, at least, would not operate as advertised due to the dropping of double-quotes in mission configuration lines. o Dec 2nd: Changed many of the MOOS-IvP main.cpp implementations to check for .moos++ files as well as .moos files. The .moos++ files are generated when using MOOSTimeWarp. o Nov1709: IvPBehavior::postWMessage() modified to NOT post a warning when passed an empty string. o Nov1709: Modified uTimerScript to support --help, and report a Usage message when no .moos file is provided (standard practice across apps). MINOR FIX o Nov1709: Modified BHV_ConstantSpeed to accept a summit_delta parameter specification. MINOR IMPROVEMENT o Nov1709: Modified BHV_ConstantSpeed to return BHV_ERROR in the case where an IvP function generation fails, and post warnings in the case where the ZAIC produces warnings. MINOR FIX o Nov1709: Modified BHV_ConstantDepth to return BHV_ERROR in the case where an IvP function generation fails, and post warnings in the case where the ZAIC produces warnings. MINOR FIX o Nov1709: Modified BHV_ConstantHeading to accept a summit_delta parameter specification. MINOR IMPROVEMENT o Nov1709: Modified BHV_ConstantHeading to return BHV_ERROR in the case where an IvP function generation fails, and post warnings in the case where the ZAIC produces warnings. MINOR FIX o Nov1709: Modified ZAIC_PEAK to be more gracious in accepting parameters. For example, basewidth, peakwidth < 0 is clipped to zero and a warning is generated, rather than declaring the ZAIC to be in a broken state and unable to produce an function. This issue was biting folks in the field where a basewidth was inadvertantly set to