Part B | 20.3
464 Part B Autonomous Ocean Vehicles, Subsystems and Control
Payload autonomy system
Main vehicle stack
Tracking
Localization
Classification
Frontseat driver
low-level control
navigation
Backseat driver
autonomous
communication, command
and control
pHelmlvp
autonomous decision
making
Detection
Acquisition
pAcommsHandler
Communication
Sensors
HBW
data bus
MOOS
LBW data bus
Expanded
CCL
NMEA
Signal
processing
ReCon/Huxley
interface
ReCon/Huxley
Actuators
Sensors
Fig. 20.6 Schematic representation
of the payload autonomy paradigm,
where higher level adaptive control
and network communication are
handled by MOOS-IvP on the payload
computer, while lower level control,
navigation, and vehicle safety are
handled by the main vehicle computer
using the native control software
ther through a radio link while surfaced, or an acoustic
modem when submerged. All lower level control, and
basic navigation and platform safety tasks are handled by the native vehicle control software running on
the main vehicle computer (MVC), for example, Huxley on Bluefin vehicles and Recon on Remus vehicles.
The communication between the PLC and the MVC
is performed over a manufacturer-specific NMEA-type
interface (National Marine Electronics Association),
operated by a dedicated MOOS process. The commands
passed from the PLC to the MVC are simply continuous
updates of desired heading, speed, and depth, which the
MVC then translates to desired rudder, thrust and elevator signals to the tail cone. The MVC will provide
the PLC with a data stream containing all relevant navigation data. Thus, in a traditional ship analogy, the PLC
represents the bridge, the radio room and the sensing infrastructure, while the MVC represents the engine room
and the navigation resources of the ship. In the same
analogy, the Helm represents the Captain, while the interface MOOS module represents the Helmsman.
The MVC will also perform a series of basic safety
tasks, including mission aborts due to bottom altitude
limit violations, lack of commands from the PLC within
a specified time, or an overall mission timeout. Higher
level safety tasks such as exceeding the specified operational area, and individual behavior timeouts or failures,
are handled by the PLC.
20.3.3 The MOOS-IvP Autonomy Architecture
The nested autonomy paradigm for distributed undersea
sensing inherently involves reaction to situations and
events that are deterministically unpredictable. Thus,
the autonomy architecture cannot be based on the availability of a world model that can form the basis for
the autonomous decision making. Instead, it requires
a capability of fully autonomously adapting to the environmental and tactical situation associated with the
phenomenon it is intended to measure. As such, it forms
a clear example of the type of robotic system for which
the IvP model for multiobjective behavior coordination
was intended and developed. Thus, for example, an underwater vehicle tasked with detecting and tracking an
acoustic source is faced with several, often conflicting
objectives. It will likely have been assigned a station
point, from which it should not move too far, while at
the same time having to get close to the source to develop a reliable tracking solution. Also, depending on
its sensing capability it may have a preferred heading
for achieving tracking resolution. Also, if other vehicles in the vicinity are already tracking the target event,
it may not be desirable for it to pursue the same source
aggressively, but instead preserve power for future sensing tasks. MOOS-IvP provides exactly the flexibility
and inherent multiobjective capability for implementing
such high-level autonomy with adaptive and collaborative capabilities.
The MIT-LAMSS group’s implementation of the
nested autonomy concept of operations is using the
MOOS middleware, supporting the modular star software architecture illustrated in Fig. 20.7. As in all
MOOS communities, the MOOS Database (MOOSDB)
process is the core of the MOOS architecture and handles all communication between the processes (applications) using a publish-and-subscribe architecture. The
various MOOS processes include all necessary control
functions as well as sensing and processing modules,
with the MOOSDB providing the unified interface standard that enables the fully autonomous integration of
464 Part B Autonomous Ocean Vehicles, Subsystems and Control
Payload autonomy system
Main vehicle stack
Tracking
Localization
Classification
Frontseat driver
low-level control
navigation
Backseat driver
autonomous
communication, command
and control
pHelmlvp
autonomous decision
making
Detection
Acquisition
pAcommsHandler
Communication
Sensors
HBW
data bus
MOOS
LBW data bus
Expanded
CCL
NMEA
Signal
processing
ReCon/Huxley
interface
ReCon/Huxley
Actuators
Sensors
Fig. 20.6 Schematic representation
of the payload autonomy paradigm,
where higher level adaptive control
and network communication are
handled by MOOS-IvP on the payload
computer, while lower level control,
navigation, and vehicle safety are
handled by the main vehicle computer
using the native control software
ther through a radio link while surfaced, or an acoustic
modem when submerged. All lower level control, and
basic navigation and platform safety tasks are handled by the native vehicle control software running on
the main vehicle computer (MVC), for example, Huxley on Bluefin vehicles and Recon on Remus vehicles.
The communication between the PLC and the MVC
is performed over a manufacturer-specific NMEA-type
interface (National Marine Electronics Association),
operated by a dedicated MOOS process. The commands
passed from the PLC to the MVC are simply continuous
updates of desired heading, speed, and depth, which the
MVC then translates to desired rudder, thrust and elevator signals to the tail cone. The MVC will provide
the PLC with a data stream containing all relevant navigation data. Thus, in a traditional ship analogy, the PLC
represents the bridge, the radio room and the sensing infrastructure, while the MVC represents the engine room
and the navigation resources of the ship. In the same
analogy, the Helm represents the Captain, while the interface MOOS module represents the Helmsman.
The MVC will also perform a series of basic safety
tasks, including mission aborts due to bottom altitude
limit violations, lack of commands from the PLC within
a specified time, or an overall mission timeout. Higher
level safety tasks such as exceeding the specified operational area, and individual behavior timeouts or failures,
are handled by the PLC.
20.3.3 The MOOS-IvP Autonomy Architecture
The nested autonomy paradigm for distributed undersea
sensing inherently involves reaction to situations and
events that are deterministically unpredictable. Thus,
the autonomy architecture cannot be based on the availability of a world model that can form the basis for
the autonomous decision making. Instead, it requires
a capability of fully autonomously adapting to the environmental and tactical situation associated with the
phenomenon it is intended to measure. As such, it forms
a clear example of the type of robotic system for which
the IvP model for multiobjective behavior coordination
was intended and developed. Thus, for example, an underwater vehicle tasked with detecting and tracking an
acoustic source is faced with several, often conflicting
objectives. It will likely have been assigned a station
point, from which it should not move too far, while at
the same time having to get close to the source to develop a reliable tracking solution. Also, depending on
its sensing capability it may have a preferred heading
for achieving tracking resolution. Also, if other vehicles in the vicinity are already tracking the target event,
it may not be desirable for it to pursue the same source
aggressively, but instead preserve power for future sensing tasks. MOOS-IvP provides exactly the flexibility
and inherent multiobjective capability for implementing
such high-level autonomy with adaptive and collaborative capabilities.
The MIT-LAMSS group’s implementation of the
nested autonomy concept of operations is using the
MOOS middleware, supporting the modular star software architecture illustrated in Fig. 20.7. As in all
MOOS communities, the MOOS Database (MOOSDB)
process is the core of the MOOS architecture and handles all communication between the processes (applications) using a publish-and-subscribe architecture. The
various MOOS processes include all necessary control
functions as well as sensing and processing modules,
with the MOOSDB providing the unified interface standard that enables the fully autonomous integration of