Release Notes for Version 13.2 (Feb 4th, 2013)

  • Release 13.2 contains a major new release of MOOS, Version 10.0-rc2, from Oxford.
  • The modifications to MOOS are recapped below, and detailed in the PDF from Oxford. The new release of MOOS is backward compatible to older MOOS applications. However, the build system and library structure of MOOS V10 has been modified. Older MOOS applications should still build against MOOS V10, but we recommend adopting the build conventions described in the MOOS V10 documentation.
  • As with previous MOOS-IvP releases, Oxford MOOS is bundled as part of the MOOS-IvP release. (see nested repositories)

The majority of the changes between release of 12.11Beta and 13.2 comes in the form of additional and improved documentation. Namely the following three documents:

  • An Overview of MOOS-IvP and a Users Guide to the IvP Helm - Release 13.5 (May 10th, 2013)
  • MOOS-IvP Autonomy Tools Users Manual Release 13.5 (May 10th, 2013)
  • A Guide to Using MOOS-V10 Communications, pdf

MOOS Headlines:

  • See MOOS V10 Release Notes for a full description.
  • Reduced Latency: Aysnchronous communications are now supported via an upgraded MOOSDB and a new kind of communications client object MOOSAsyncCommClient. This allows data to be pushed to clients by the MOOSDB rather than clients having to fetch messages which match their subscriptions when the call into the MOOSDB. This affords a drastically decreased latency between data being published and clients receiving it.
  • Multithreaded Design: The MOOSDB now offers improved resiliance when working with clients which reside at the end of a high latency or low bandwidth link. Each client is now furnished with its own thread within the DB which allows each client to take as long as it needs to complete and read or write without holding up the interactions of other clients. This behaviour can be disabled from the command line in which case the behaviour of the DB reverts to pre V10 behaviour.
  • Wildcard Subscriptions: The MOOS communications API now supports wildcard subscriptions whereby clients can subscribe to variable which match variable name patterns and also source name patterns. For example a client could register for *:* meaning all variables from all sources or J*:*K meaning any variable beginning with J from a process ending in K.
  • MOOS Core under LGPL License: The Core MOOS libraries have been moved to an LGPL license, to permit commercial development of MOOS Applications. The middleware itself remains under a GPL license.

MOOS-IvP Headlines:

  • AppCasting: AppCasting is a means for an application to regularly generate a single common data structure containing a rich status report, configuration and run-time alerts, and significant events. These reports are in addition to whatever else the application may otherwise publish to the MOOSDB. They are designed primary with debugging and alert generation in mind. They are also designed to work in an on-demand fashion so as to minimize CPU load, comms traffic, and log file size. See AppCasting In MOOS for a full description.
    The primary motivations are (1) to increase the ability of a single operator to manage complex information across larger sets of fielded vehicles, and (2) to improve the ability to automatically detect configuration and run time problems and generate alerts, thereby improving the robustness of missions.
  • uMAC Tools: The uMAC tools are applications for Monitoring AppCasts. There are two new tools, uMAC (a terminal appcast viewer), and uMACView (a GUI appcast viewer). The pMarineViewer has also been augmented to monitor appcasts.
  • Broad Application Support for AppCasting: Nearly all MOOS applications in the MOOS-IvP tree have been augmented to support appcasting. This includes improved configuration error checking and reporting, run-time error checking and reporting, and improved application status reports for debugging.

All GUI Apps (pMarineViewer, alogview etc):

  • We are no longer re-packaging FLTK as part of the MOOS-IvP tree. MOOS-IvP GUI apps are using FLTK 1.3 stable release which is pretty reliably available with GNU/Linux and OSX package managers now.
  • In Ubuntu: apt-get install libfltk1.3-dev
    In Macports: sudo port install fltk-devel
  • The fltk1.3 source code is also directly available from the FLTK site.


  • A new helm state has been added. The helm will enter the MALCONFIG state when launched with an ill-formed behavior configuration parameter. In prior releases, if the helm detected a configuration error, it would note the error and exit. This would be hard to detect until the helm was re-launched with a terminal window open. With this change the helm process will not quit, it will clearly report the MALCONFIG state in pMarineViewer, and IVPHELM_STATE will be set to MALCONFIG. Checking the terminal output or the appcast output will show which line(s) in the configuration file caused the problem.
  • Fix to the behavior file parser to accept behavior configuration lines such as:

with no whitespace after the first token.

  • Change to BHV_Waypoint to allow a third kind of waypoint capture criteria. When setting capture_line=true, waypoint capture is achieved by crossing the line perpendicular to the current track line, at the waypoint. This criteria is an "alternative" criteria, meaning that if capture_radius and slip_radius are also set, the waypoint arrival will be declared as soon as one of the criteria are met. To enable the capture_line criteria alone, one must either (a) set capture_radius and slip_radius to zero, or equivalently (b) set capture_line to "absolute" instead of "true".
  • Change to policy posting behavior flags. Prior to this change a behavior posting a runflag of RSTAT=true would see this flag posted only once, due to the helm's duplication filter. This was true even if the behavior exited the running state (e.g., to idle) and returned to the running state. With this change, flags are always (re)posted upon a behavior state change. r4397.
  • Added support for AppCasting.

pMOOSBridge vs. pShare

  • We are no longer using pMOOSBridge in the MOOS-IvP tree. We are using pShare from Oxford instead. pShare supports dynamic registrations and pMOOSBridge does not. Dynamic registrations are used extensively in the uField Toolbox, to facilitate inter-MOOSDB connections. See the ivp/missions/m2_berta example mission for demonstration of pShare with the uField Toolbox. The best documentation for pShare presently is with :
    pShare --help


  • Added the display of the MOOSDB community name to the top of the printed report. Can be toggled off with the 'm' key.
  • Modified to support appcasting. Missions may be launched with multiple special-purpose uXMS clients, each selectable via an appcast viewer.


  • Added this MOOS module for automatically accepting HAZARDSET_REPORT messages submitted by a given vehicle for a hazard field.


  • Several modifications to the code and uField Toolbox documenation regarding this module.
  • Added support for AppCasting.


  • Added support for AppCasting.
  • Added the ability to have contacts be defined in terms of earth coordinates vs. local coordinates.


  • Modified to work with pShare instead of pMOOSBridge
  • Added support for AppCasting.


  • A new app: the uFldHazardMgr is a strawman MOOS app for managing hazard sensor information and generation of a hazard report over the course of an autonomous search mission.


  • pSearchGrid is a new app for storing a history of vehicle positions in a 2D grid defined over a region of operation.


  • pSafetyRetreat is a new application that posts a safe loiter position upon a user-defined cue. Presumably this works in coordination with the IvP Helm, and also could have been implemented as a helm behavior.


  • A new command-line utility: the gen_hazards tool may be used to generate a simulated hazard lay-down file.


  • Added support for AppCasting.


  • Modified to work with pShare instead of pMOOSBridge
  • Much improved status reports.
  • Added support for AppCasting.


  • Modified to work with pShare instead of pMOOSBridge
  • Added support for AppCasting.


  • Added support for AppCasting.


  • Native support for AppCast monitoring. Toggle off/on with the 'a' key.
  • Support for "full-screen" mode. Toggle with the 'f' key.
  • Modified pull-down menus to reflect all legal MOOS file configuration parameters, an each parameter's present value with a radio-button setting.
  • Suport for RangePulses.
  • Bug fixes to improve stability and crashes reported upon startup for some users.
  • Heuristic window sizing upon startup based on detected screen size, useful in demo modes connected to a lower resolution projector.


  • Added support for AppCasting.
  • Added support for Gaussian random variables.
  • Revised status report structure.

Build system

  • Modified build system to reflect build changes in Oxord MOOS build system, e.g., all references to MOOSGenLib removed.


  • Provides a warning with file and line number when a macro has been re-defined with a #define statement.
  • Ignores undefined macros if they are in a line commented out.
  • If a target file already exists, the user will be prompted for overwrite with the default being no.
  • Fixed a bug affecting nested #ifdef statements. r4397
  • Added conjunction support for #ifdef statemtents. r4397
    #ifdef A && B
    #ifdef A 23 && B 2