Nested Autonomy for Distributed Ocean Sensing 20.3 Autonomy 465
Part B | 20.3
sensing, modeling, processing, and control. MOOS ensures a process executes its iterate method at a specified
frequency and handles new mail on each iteration in
a publish-and-subscribe manner. The autonomy (IvP)
helm runs as the MOOS process pHelmIvP.
The fundamental architecture of the IvP-Helm autonomy configuration at the core of the nested autonomy paradigm is illustrated in Fig. 20.8. Because of
the inherent latency and intermittency of the underwater communication environment, the mission-dependent
autonomy configuration defines a finite set of autonomy
modes in which the autonomy will remain perpetually
until specifically reassigned through a high-level transition command, either from the topside command and
control or an onboard mission control process. The autonomy mode structure is configured in a hierarchical
tree structure, with the mode transitions achieved by
a simple change in a MOOS control variable, thus requiring very limited communication from the operators.
Note that this paradigm is in distinct contrast to traditional scripted autonomy, where mode transitions are in
general predefined.
Another fundamental architectural principle illustrated in Fig. 20.8 is that each mode has a preconfigured
set of behaviors, each of which defines a set of objective
functions for speed, heading, and depth, representing
the utility of all allowed values for these variables.
As in the case of the modes, the behaviors are perpetual, which means that they are running throughout
the mission whenever the mode is active, although they
may not contribute an objective function unless certain
conditions are met. For example, the vehicles will continuously run a collision avoidance behavior, but it will
not be active unless the node to avoid is within a configurable spatial envelope. The central IvP algorithm (the
captain) will then continuously calculate and publish
an objective compromise, which will be passed on to
the MVC via the MOOSDB and the interface process
(the Helmsman).
The nested autonomy paradigm in general allows
the mode transitions to be entirely arbitrary, which
makes it inherently suited to sensor-adaptive mission
execution. Thus, for example, an underwater vehicle
operating in a deploy mode such as a hexagonal loiter
will use its onboard sensor processing to detect and subsequently classify an episodic event to which the node
must respond. Once the processing is confident in assessing the desired nature of the event, it will simply
change a MOOS variable which will trigger a mode
transition in the Helm to a prosecute mode, which will
activate a set of behaviors that allows the vehicle to map
and track the event.
Mode transitions may alternatively be triggered by
a simple command from the operators, received via the
MOOSDB
MOOS application
MOOS application
MOOS application
MOOS application
IvP-Helm
Fig. 20.7 Modular software architecture based on the MOOS middleware
IvP solver
IvP-Helm
MOOSDB
Mission
modes
IvP function
IvP function
IvP function
Information
Variable-value pairs
Variable-value pairs
IvP behavior
IvP behavior
IvP behavior
IvP behavior
IvP behavior
IvP behavior
IvP behavior
Decision
Fig. 20.8 IvP-Helm autonomy architecture
communication infrastructure. Also, depending on the
configuration, transitions may be initiated by an event
report issued by a collaborating fixed or mobile node or
the operators. The fact that mode transitions can be initiated through various channels is a key feature ensuring
robustness. Thus, for example, a node which has not itself been able to detect an event can be alerted through
one of the other channels and consequently participate
fully in the event prosecution.
An example autonomy mode hierarchy for vehicles
in a network deployed for capturing episodic oceanographic events is shown in Fig. 20.9. During a mission,
a vehicle will always reside in one of the modes at the
end of a branch, and it will as a fundamental principle
remain in that mode until it is commanded, internally
or externally, to transition to another mode. Each mode
defines a set of behaviors, most of which are generally
available off-the-shelf. A typical behavior set is shown
in the table in Fig. 20.9.
The perpetual mode/behavior architecture provides
an extremely effective basis for executing field missions. Thus, except for configuration variables such
Part B | 20.3
sensing, modeling, processing, and control. MOOS ensures a process executes its iterate method at a specified
frequency and handles new mail on each iteration in
a publish-and-subscribe manner. The autonomy (IvP)
helm runs as the MOOS process pHelmIvP.
The fundamental architecture of the IvP-Helm autonomy configuration at the core of the nested autonomy paradigm is illustrated in Fig. 20.8. Because of
the inherent latency and intermittency of the underwater communication environment, the mission-dependent
autonomy configuration defines a finite set of autonomy
modes in which the autonomy will remain perpetually
until specifically reassigned through a high-level transition command, either from the topside command and
control or an onboard mission control process. The autonomy mode structure is configured in a hierarchical
tree structure, with the mode transitions achieved by
a simple change in a MOOS control variable, thus requiring very limited communication from the operators.
Note that this paradigm is in distinct contrast to traditional scripted autonomy, where mode transitions are in
general predefined.
Another fundamental architectural principle illustrated in Fig. 20.8 is that each mode has a preconfigured
set of behaviors, each of which defines a set of objective
functions for speed, heading, and depth, representing
the utility of all allowed values for these variables.
As in the case of the modes, the behaviors are perpetual, which means that they are running throughout
the mission whenever the mode is active, although they
may not contribute an objective function unless certain
conditions are met. For example, the vehicles will continuously run a collision avoidance behavior, but it will
not be active unless the node to avoid is within a configurable spatial envelope. The central IvP algorithm (the
captain) will then continuously calculate and publish
an objective compromise, which will be passed on to
the MVC via the MOOSDB and the interface process
(the Helmsman).
The nested autonomy paradigm in general allows
the mode transitions to be entirely arbitrary, which
makes it inherently suited to sensor-adaptive mission
execution. Thus, for example, an underwater vehicle
operating in a deploy mode such as a hexagonal loiter
will use its onboard sensor processing to detect and subsequently classify an episodic event to which the node
must respond. Once the processing is confident in assessing the desired nature of the event, it will simply
change a MOOS variable which will trigger a mode
transition in the Helm to a prosecute mode, which will
activate a set of behaviors that allows the vehicle to map
and track the event.
Mode transitions may alternatively be triggered by
a simple command from the operators, received via the
MOOSDB
MOOS application
MOOS application
MOOS application
MOOS application
IvP-Helm
Fig. 20.7 Modular software architecture based on the MOOS middleware
IvP solver
IvP-Helm
MOOSDB
Mission
modes
IvP function
IvP function
IvP function
Information
Variable-value pairs
Variable-value pairs
IvP behavior
IvP behavior
IvP behavior
IvP behavior
IvP behavior
IvP behavior
IvP behavior
Decision
Fig. 20.8 IvP-Helm autonomy architecture
communication infrastructure. Also, depending on the
configuration, transitions may be initiated by an event
report issued by a collaborating fixed or mobile node or
the operators. The fact that mode transitions can be initiated through various channels is a key feature ensuring
robustness. Thus, for example, a node which has not itself been able to detect an event can be alerted through
one of the other channels and consequently participate
fully in the event prosecution.
An example autonomy mode hierarchy for vehicles
in a network deployed for capturing episodic oceanographic events is shown in Fig. 20.9. During a mission,
a vehicle will always reside in one of the modes at the
end of a branch, and it will as a fundamental principle
remain in that mode until it is commanded, internally
or externally, to transition to another mode. Each mode
defines a set of behaviors, most of which are generally
available off-the-shelf. A typical behavior set is shown
in the table in Fig. 20.9.
The perpetual mode/behavior architecture provides
an extremely effective basis for executing field missions. Thus, except for configuration variables such