Release Notes for Version 19.8 (Aug 6th, 2019)

  • Release 19.8 contains a MOOS Release posted by P.Newman/Oxford July 5th, 2019.

New Applications

pObstacleMgr (new MOOS App)

  • The pObstacleMgr manages incoming sensor data about obstacles and posts alerts suitable for spawning obstacle avoidance behaviors. This application is still considered to be in Beta mode as further in-water testing with LIDAR data is still ongoing.

uMemWatch (new MOOS App)

  • The uMemWatch application is used for measuring the current memory used by a set of MOOS apps. To measure an app, the app must publish the MYAPP_PID variable with its own PID. This app will use that PID and the command line utility "ps" to measure the current memory usage. This app can be configured to selectively watch items on a watch list, or watch all apps but selectively ignore apps on an ignore list. The primary output is through both AppCasting, and the publication to MYAPP_MEM each time a new measurement is made.

alogtest

  • Scan an alog file, apply test criteria and return a pass/fail result. Used for automated mission testing.

alogcat

  • Create a new MOOS .alog file from two or more given .alog files. Given files are meant to be non-overlapping in time, presumably made by starting and stopping a single MOOS community.

pickpos

  • pick_pos is a utility for generating starting points for simulated vehicles. It can generate points from a set of pts given in a file, or by picking random points from within one or more convex polygons. The starting heading position can also be chosen, in a random range, or relative to a given position. Vehicle names and group names may also be chosen randomly.

manifest_test

  • manifest_test is a utility for checking the correctness of one or more manifest (.mfs) files, and one or more lines of code (.loc) files.

New Behaviors

Convoy

  • New behavior to enable multi-vehicle linear formations based on following vehicles traversing over bread-crumb points of a leader vehicle. Further support for following vehicles to control their speed to maintain a safe range interval to the leader vehicle.

Modifications to Existing Applications

pHelmIvP

  • Behaviors now have overloadable onSpawn() function available to behavior code developers.
  • Behaviors have spawnflags available for use in any templated/spawnable behaviors.
  • New configuration parameter, hold_on_apps, takes a comma-separated list of MOOS Apps. The helm will wait for these apps to be seen in DB_CLIENTS before posting helm startup messages (postings made by behaviors in their onHelmStart() function call. Not all apps need to be on the DB_CLIENTS list simultaneously. Once each hold_on app has appeared, it is noted, even if it disappears from the DB_CLIENTS list.
  • behaviors can now get contact type information from info_buffer by querying VNAME_NAV_TYPE

pBasicContactMgr (new features)

  • Added the ability to have alerts based on a polygon regions, so missions can be configured to trigger action if a contact of interest enters a given region. Region criteria can be used in conjunction with range criteria, or simply on its own.
  • Added an optional publication of the range to the closest contact. Posting turned on with the post_closest_range=true paramater, and will publish to CONTACT_RANGE an integer value of the range. Value will be published only when the range changes.
  • Customized contact lists can now be configured based on range, vehicle type or group. A client app can register for a customized contact list with "BCM_REPORT_REQUEST" with a value something like: "var=BCM_CONTACTS_85, range=85". This will result in the contact manager posting a list of all contacts within a range of 85 meters. This report request must be continuously refresh and the contact manager will cease making reports after some period of time if the request is not refreshed.
  • The list of retired contacts is limited to N contacts with the contacts_retired_hist = N, and N defaults to 5 and max 100.
  • Added the contact_max_age_history parameter to guard against unbounded memory growth if the system is producing many unique contact IDs over a long period of time.

pBasicContactMgr (bug fixes)

  • The contacts_recap_interval parameter now defaults to 1 second. Previously it default to 0 seconds, and the documentation said 5. It is now set to 1, and the documentation is properly updated. It may also be set to "off" which would cease all pubs.
  • Fixed a bug where defaults were not applied to an alert configuration that ommitted the alert_range or cpa_range. In this case these values should default to the values specified in the parameters default_alert_range and default_alert_range_cpa. Now they do.

pMarineViewer

  • Added functionality to the Commander pop-up window including auto-adjusting button widths, and the ability to add color to a button to make it easier for an operator to find and hit an emergency button.
  • Updated the pMarineViewer documentation to describe commander pop-up window functionality. The commander pop-up window feature was part of the 17.7 release but was not documented at all.
  • The m2_berta mission has been updated to include a non-trivial example of the commander pop-up window, to control deploying, returning, station-keeping, vehicle speed, and loiter direction for both vehicles.
  • Improved the drawing efficiency of hash marks (grid lines). New version reduces overall CPU load by more than half.
  • Added functionality to selectively display comms pulses coming from node reports vs those coming from node messages.

pEchoVar

  • Added Boolean Switching. For a configuration "Echo = FOO !-> BAR", if a string representing a Boolean value is published to FOO, a string representing the opposite Boolean value is published to BAR. The case of the strings is matched.

uTimerScript

  • Fixed a bug that would prevent the pause_var from being used in timer conditions

uFldCollisionDetect

  • Added full documentation

uFldNodeComms (bug fix)

  • Fixed a bug where some messages were occasionally being dropped despite meeting all the communications criteria.

alogview (bug fix)

  • Fixed a bug in alogview affecting the construction of the collective objective function to be rendered. Previously it was not properly applying the weights of each function.

alogscan (bug fix)

  • Fixed a bug in alogscan that would result in a segfault just prior to early exit on detected invalid input file. For example an empty alog file.

Modifications to Existing Behaviors

BHV_Waypoint

  • Added lead_condition to allow the user to specify a logic condition that must be met in order for the trackline following to be enabled. This allows for coordination with any collision avoidance behavior temporarily turn off trackline following during an avoidance encounter. See m2_track_condition mission.

BHV_AvoidObstacle

  • Tighter coordination with the new pObstacleMgr application to support dynamically detected obstacles. Support for statically configured obstacles at known locations, e.g., buoys etc, is unchanged. The new functionality addresses obstacles fed from external apps or derived from LIDAR data. The latter feature is still in Beta mode as on-water testing is ongoing at the time of Release 19.8.

BHV_AvoidCollision

  • This behavior now can be configured to use the new CPA refinery to substantially reduce the number of pieces used in generating objective functions, with no loss of precision. This is enabled by setting use_refinery=true. The motivation for this is the substantial speed up allowing simulations in higher time warps, and lower logging footprint which also facilities large automated mission testing.
  • The parameter contact_type_required has been deprecated. This parameter was introduced in Release 17.7, and is generalized in this release with the match_type parameter now supported for all contact behaviors at the IvPContactBehavior superclass level. Use of this parameter is still supported for now, but will be treated as if it were the match_type parameter. See the release notes discussions for the IvPContactBehavior superclass for more details.

BHV_AvdColregs

  • Like the AvoidCollision behavior, this behavior now can be configured to use the new CPA refinery to substantially reduce the number of pieces used in generating objective functions, with no loss of precision. This is enabled by setting use_refinery=true. The motivation for this is the substantial speed up allowing simulations in higher time warps, and lower logging footprint which also facilities large automated mission testing.
  • This behavior now supports the giveway_bow_dist parameter to provide the user more control in setting the threshold for when ownship crossing in front of contact (from the contact's port side) does not represent a risk of collision. This range can now be set to any value between min_util_cpa_dist and max_util_cpa_dist. Further experimentation with different methods to determine this safe distance is ongoing, including methods that account for the contact speed. Exposing this parameter in this release was considered to be a short-term improvement.
  • In release 19.8, the "COLREGS" behavior is named explicitly AvdColregsV19, keeping the AvdColregsV17 as an option available to the user. For the COLREGS behavior, the plan is to proceed with co-existing versions in successive releases.

Modifications to Libraries/Utilities

RefineryCPA (lib_bhvutil)(new utility)

The CPA refinery is a specialized tool for finding/building plateaus found in CPA based objective functions. The identification of plateaus is coupled with the new IvPBuild pipeline discussed below to support contact behaviors that reason about CPA. This includes at least for now, the AvoidCollision behavior as well as the AvdColregs behavior. The refinery is an optional opt-in parameter that will substantially reduce the number of pieces used in building an objective function for a behavior. Depending on the relative vehicle geometry, this can mean a reduction up to 90% of the pieces, and the corresponding savings on CPU time and log file size. This is accomplished with no loss of precision in the objective function.

IvP Build Toolbox (lib_ivpbuild)(bug fix)

  • ZAIC_LEQ. In cases where the summit is 0 (or lowest possible value in the domain), and the base width was also zero, the zaic should return a max value in summit, and min value elsewhere. Prior to the bug fix, it would produce NO piece covering the summit value and a min value for the remainder of the domain.

IvP Build Toolbox (lib_ivpbuild)(new capability)

The below modifications are essentially well under the hood for behavior users, but they provide additional optional power for behavior developers to produce objective functions more efficiently, saving both CPU cycles and memory/log file size. These changes enable the CPA Refinery which is a new optional parameter for both the AvoidCollision and AvdColregs behaviors. The CPA refinery and other specialized refineries will continue to be introduced in upcoming releases.

Modifications to the OF_Reflector tool for creating multi-variableIvP functions. The motivation for mods to the reflector are to make directed refinement more efficient. The previous pipeline for creation was:

(1) uniform function (initial evaluation of interior functions)
(2) direct refinement
(3) smart refinement
(4) auto-peak

In prior releases, the pieces' linear interior function was evaluated during the uniform function stage. And a priority queue was built to prepare for the smart refinement stage. This could be very inefficient if direct refinement is employed. Direct refinement will identify regions of the decision space that have known utility. These are known as plateaus. If large plateaus are known and used, then the creation of uniform pieces in those regions during phase (1) is a waste. Even more of a waste is the evaluation of those pieces.

To enhance the efficiency and benefit of behaviors that are able to generate and pass plateaus to the reflector, the pipeline has been changed to:

(1) uniform function (NO evaluation of interior functions)
(2) direct refinement
(3) piece evaluation (except plateau pieces used in direct refinement)
(3) smart refinement
(4) auto-peak

To implement this, the RT_Uniform utility was replaced with the RT_UniformX utility. This is the utility used in phase (1). It no longer performs any evaluation of linear interior functions. And it does not create pieces internal to the plateau regions. Pieces that would be partially in/out of a plateau region are instead created with smaller pieces where each smaller piece is distinctly outside the plateau region.

Phase (2) directed refine was also modified to *not* do any evaluation of linear interior functions, saving this for the following phase (3)

Phase (3) is a new phase, implemented in the class RT_Evaluator. It takes all the pieces built so far (in the form of a PDMap) and evaluates all their interior functions. For now, it even evaluates the interior functions for pieces that originated as plateaus, even though presumably their utility was already known and linear with zero slope. But this minor inefficiency remains for now, because presumably the number of plateau pieces is very small compared to the number of "regular" uniformly generated pieces.

Most Recent Previous Release Notes (17.7.2)