Development Plans: (posted Oct 20th, 2011)(Updated Dec 29th 2011)

The following features are being targeted for the next release of moos-ivp, planned for January 2012.

  • Standby Helm - The ability to have a second helm instantiated during a mission in a "stand-by" mode. This helm would engage when or if the primary helm ceases to produce a heartbeat message (publishing the variable IVPHELM_STATE). The motivation for this is to mitigate risk associated with a helm instantiated with a configuration or set of behaviors with relatively less confirmation of functionality. Status: completed and available for beta testing.
  • uField Toolbox - The uField Toolbox is a collection of new MOOS applications to facilitate operation of multiple vehicles in the field, and facilitate the simulation of multiple vehicles. It currently consists of six new applications. (1) uFldNodeBroker runs on a vehicle and aims to broker a connection to a shoreside command and control community. It does this by gathering its own host information (IP address, port # etc) and reaching out to a shoreside community at a number of possible locations. (2) uFldShoreBroker is the complement of the former. It resides on a shoreside computer and accepts incoming node connections and arranges for bridging of key command and control messages between the shore and the nodes. (3) uFldNodeComms runs on the shoreside computer and acts as a middleman for node reports between fielded vehicles. It may apply range dependency and latency between nodes. (4) uFldPathCheck runs on the shoreside and evaluates key information on incoming vehicle node reports, keeping track of avg speed, top speed, odometry etc. (5) uFldScope runs on the shoreside and may be configured to pull user-defined key information from various data sources on all fielded vehicles, providing a convenient table for command and control information. (6) pHostInfo runs in both the vehicle and the shoreside community. It provides host information on the IP address, community name and UDP Listening port. Critical info needed by other uField applications. Status: completed and available for beta testing.
  • uMAT Toolbox - The alogview tool is being split into a set of comparable "Mission Analysis Tools". These tools will still operate primarily on a set of .alog files from one or more vehicles, but will run as separate apps connected by the MOOSDB. The primary info communicated between apps is a playback timestamp. This is motivated by the need to greatly expand the types of information currently accessible by the alogview tool to include (a) a sonar image viewer, (b) BTR viewer, (c) and generic scope on string-type MOOS variables. It is also motivated by the prospect of making some of the post-mission-analysis tools double as runtime mission analysis tools. We are further motivated by increasing the ability for third-party developers to develop add-ons to the mission-analysis tools without a compile dependency on existing tools. Status: under development.
  • Multi-Function Behaviors - Behaviors will be allowed to generate multiple objective functions submitted to the helm on any given iteration. A significant development hurdle is to update the various mission analysis tools to consider this usage mode. The primary motivation is to (a) leave objectives over decoupled decision variables decoupled, and (b) allow for behaviors based on particle filters to associate a lightweight objective function with each particle. Status: under development.
  • IPF Recycle - Behavior authors will have the ability to design a behavior that chooses to re-use an objective function generated on a previous iteration. In effect the helm caches objective functions, informs a behavior of the cache status and leaves the option to the behavior on any given iteration to simply regard the currently cached function as the behavior's current output. In many cases the objective function produced by a behavior between iterations does not change substantially if the world situation hasn't changed. This is motivated by (a) reduction of CPU usage as we focus more on low-powered vehicles such as gliders, (b) support for behaviors designed to produced larges clusters of objective functions to allow only portions of the function cluster to be replaced on any iteration, and (c) simple reduction of unnecessary logfile bloat. Status: under development.
  • Elimination of IVPHELM_POSTINGS - The aim here is to simply turn off the publication of this variable by the helm. It contains a summary of MOOS variable postings by all behaviors for the current iteration. Solely for debugging and post-mission analysis. This was previously needed because all variables posted by the helm where simply logged as being produced by the helm without any information regarding which behavior produced it. Now that MOOS supports an auxiliary source field in a MOOS message, this field is used to indicate the behavior source. The only remaining thing(s) to do to turn off this posting is to modify the mission analysis tools to handle the auxiliary source field. The primary motivation is simply to reduce log file bloat and to simplify further development of mission analysis tools. Status: under development.