Release Notes for Version 24.8 (Aug 6th, 2024)

Core Helm (pHelmIvP mods)

  • Major new feature: Helm now accepts a platform model description which can be holonomic by default, or Dubins, or any model the user wishes to provide. Dubins is currently only supported. The PlatModel is a data structure containing a piecewise linear approximation (Seglr) of a vehicle turn, given say a turn radius, and instructions on how many pieces to use for the approximation. This PlatModel is updated on each iteration to local coordinates and passed to each behavior. A behavior may decide to use it or not. Currently only the AvoidObstacle behavior utilizes it, but collision avoiadance and other behaviors are being modified/upgraded to use this information.
  • If a platform model is enabled, the helm will now calculate and post TURN_RATE. This value is calculated from observed NAV_HEADING values and stored in the PlatModel data structure, and thus is available to all behaviors in this manner. However it is also published by the Helm on every iteration as well, after the PlatModel has been updated.
  • Major addition to SuperUtility class ObShipModel. Extensive modifications and improvements to support the AvoidObstacle behavior and the engineering test GUIs that support testing and development of the behavior.
  • Almost a complete re-write of the RefineryObAvoid class, implementing the refinery used by the the AvoidObstacle behavior.
  • IvPDomain can accept spec such as: "speed:0:$(MAX_SPD):delta=0.1". This allows top speed to be altered mid-mission without affecting the discretization of the decision space.

Mods to IvPBehavior Superclass

  • Added ability to regulate offboard messaging rates. For any message (MOOS Var) sent offboard with one of the postOffboardMessage() functions, the message rate can be regulated with regulateOffboardMessage() function. This function names a MOOS variable and a minimum time gap between offboard postings. A behavior is then free to post as often as it likes, without needing to implement its own functionality to regulate the offboard rate. An additional function resetRegulatedMessage() can be called at any time to reset the timestamp associated with the last posting. In this way, the behavior author can regulate the rate generally, but when something important needs to be sent now, the reset can be used to ensure the next message will go out. A further function, isRegulatedMessageNow(MOOSVar) returns a Boolean value indicating whether the message would be sent at the current time. This allows the behavior author to check before executing potentially cpu-intensive code to generate the message content.
  • Added more MACROS available for all behaviors, e.g, NOW.
  • Added spawnx_flag, executed after first iteration. The spawn_flag is posted prior to the first iteration.

New Applications

pMissionHash (new MOOS App)

  • The pMissionHash application is used for generating a MISSION_HASH posting. Normally this is produced by pMarineViewer. In headless mission not running pMarineViewer, this app can be used instead. They should not be both run unless the mission feature is configured to be disabled in pMarineViewer.

pMapMarkers (new MOOS App)

  • The pMapMarkers app is configured with a number of markers each with a name and location, and will post a VIEW_MARKER notification for consumption of a GUI like pMarineViewer. Typically the set of markers is a local coordinate frame, e.g, a playing field, where markers are possible coordinates for boundaries, goals, mid-field lines and so on.

uFldDelve (new MOOS App)

  • The uFldDelve app monitors traffic to/from the shoreside via the pShare application. It tallies the total messages and chars and the message and character RATES. The list of messages to monitor is derived from a message from uFldNodeBroker and uFldShoreBroker.

projfield (new command-line App)

  • Calculates a field of coordinates with key vals By default a 26x26 field with AA at the root and ZZ at the far corner. Used in mission preparation.

app_mhash_gen (new command-line App)

  • This tool is simple wrapper around the utility for making the default format MOOS-IvP mission hash. It was created solely to give the user a feel for example mission hashes.

app_nzero (new command-line App)

  • Convert a heading given with the Zero-North origin and convert it to a heading in Zero-East origin. Used in some launch scripts.

Mods To Existing Apps

nsplug

  • Accepts new command line arg, --macros=<file> specifying a file of macros to be used. Previously nsplug accepted macros only on the command-line. This provides another option, useful when the set of macros is large in an a file format anyway. Multiple macro files can be provided. Order matters. Macros specified in earlier args, will be expanded when ingesting later macro files.
  • Added support for default values

uMAC

  • Will now display the MISSION_HASH if it is known.

uSimMarineV22

  • Added ability to configure the degree to which a vehicle loses speed during a turn. This is a parameter "turn_spd_loss" in the range of [0,1], with a default of 0.85. This number was hard-coded previously. A value of 0 means no speed loss even at 100 percent rudder. A value of 1 will result in a total speed loss at 100 percent rudder.
  • Added a max_speed parameter. Sometimes, in high thrust value situations, the peak burst speed was beyond intuition. This allows for a hard cap. Presumably this speed will be used for the pHelmIvP speed domain max speed. The common launch script uses the $(MAX_SPD) macro for both uSimMarine* and pHelmIvP

pContactMgrV20

  • Added optional Boolean parameter "hold_alerts_for_helm" which is false by default. When true, the contact manager will not post alerts for the helm until it has received IVHHELM_STATE=DRIVE at least once. This prevents the CM from sending alert messages and the helm later processing the alert but throwing a "skew" warning. This may happen in a mission when vehicles start close to one another and the CM immediately posts alerts, before the helm has been deployed.

uPokeDB

  • Added ability to add a set of pokes from a configuration block. These lines are the "poke cache". This allows auto-starts, e.g., xlaunch script, to a mission by just generically invoking a poke of whatever is configured to be in the cache.

pMarineViewer

  • pMarineViewer now generates a "mission hash" upon startup, that is posted to the variable MISSION_HASH. This is sent to all vehicles and logged. It is now the primary way of correlating log files from single mission. A full hash may look like: 
    MISSION_HASH=mhash=230711-1929C-PRIM-HAYS,utc=1689118197.62

It contains the shorthand "PRIM_HAYS" as well as the date and time, and exact time of start in UTC seconds.

  • With the mission_hash_display=true setting, the shorthand version of the mission hash will be displayed in the titlebar of pMarineViewer.

New IvP Helm Behaviors

BHV_ZigZag

The ZigZag behavior will affect a zigzag maneuver for a configurable amount of times. It will conduct the zigzag relative to the current ownship heading when the zigzag behavior became active. The target zig angle can be achieved by requesting a target heading, or a relative heading change. It will zig until the target heading has been achieved.

BHV_LegRun

The LegRun behavior is enables a vehicle to repeatedly traverse back and forth over a legrun trackline prescribed by two vertices. After reaching the end of the trackline, the vehicle switches into a Williamson turn mode to ensure the vehicle aligns with the trackline when starting in the other direction. The behavior may be configured with a single vehicle speed, or a schedule of speeds, changing on each legrun. As with any other helm behavior, configuration parameters may be changed dynamically through its updates variable. As such, this behavior support several configuration parameters for changing the length and orientation of the legrun trackline while the behavior is running. Dynamic in-mission modifications to the turn characteristics are also supported. The support for in-mission adjustments is to allow an operator to gauge a mission for safety or other metrics during a mission and adjust as needed without needing to halt and restart the vehicle mission, thereby saving valuable test range time.

BHV_FixTurn

The FixedTurn behavior allows a vehicle to execute a turn with parameters for configuring the duration of the turn (in degrees), and the commanded changes in desired heading during the turn. The behavior is primarily motivated by supporting surface vehicle shake-out tests, but may be used in any mission where this pattern is desired. The behavior can be configured with varying number of turns, order of turns, and the number of degrees for each turn, and the manner in which the turn is requested. Turns in a FixedTurn behavior are accomplished by continuously requesting a heading change of a configured fixed value, monitoring the number of degrees in a turn, until the turn completion 1 criteria is reached. Completion criteria is in number of degrees, e.g, a 180 degree turn, or a 270 degree turn.

BHV_OpRegionV24

The OpRegionV24 behavior was created to combine and replace the OpRegion and OpRegionRecover behaviors. The former was simply a pass-fail check to ensure operating constraints are not exceeded, resulting in an all-stop if they were. No attempt was made in the OpRegion behavior to influence the vehicle to avoid exceeding the operating constraints. On the other hand, in the OpRegionRecover behavior, the goal is indeed to influence the vehicle to return to a the operation area once it has exited. The OpRegionV24 behavior can perform both functions of the older behaviors. It works with the notion of three polygons, the core, save and halt polygons.

BHV_FullStop

The FullStop behavior is designed to execute a full-stop, but also monitor the time and distance the vehicle needs to come to a near zero speed.

BHV_PModelView

The PModelView behavior solely produce a visual of the expected vehicle trajectory given (a) the vehicle platform model, and (b) the most recent or current value for DESIRED_HEADING.

Mods to Existing IvP Helm Behaviors

BHV_AvoidObstacleV24

The V24 version is now the best performing and officially supported version of this behavior. The AvoidObstacleV24 uses the new PlatModel optional feature of the helm. If the helm is configured with a turn radius or other platform model designation, it will be used in this behavior.

BHV_Waypoint

Added reset_on_idle parameter. By default false. If set to true, the waypoint index is set to zero upon entering the idle state.

Post-Mission Pipeline

alogview

  • Improved the efficiency of loading, rendering AppLog content by restricting the GUI to show only the last +/- 50 app iterations. For substantial AppLog content, this had been slowing alogview to a crawl or crash.
  • Updated the implementation of drawing hashes and auto-setting reasonable hash_delta values based on image size.
  • Major enhancements improving efficiency in loading large alog files. Loading of renderable objects, e.g., VIEW_POINT etc, improved by (a) not loading image data from vehicle logs when a shoreside alog file is detected to be present, and (b) auto-reducing the time-series bin sizes when loading visual objects. In smaller files, a new bin is created for each unique timestamp. For larger alog files, bins are created with ever larger timestamp ranges. This can create some perhaps noticeable choppiness when binning is larger, but even very small increases to bin sizes will vastly reduce load time. This technique also greatly reduces the memory usage of alogview. The user can override the bin sizing policy with the --vqual param. This defaults to --vqual=med, which should be more than adequate for the vast majority of situation.
  • Augmented to support rendering of logged XYSelglr data types