Nested Autonomy for Distributed Ocean Sensing 20.3 Autonomy 463
Part B | 20.3
Thermocline
Temperature
Depth
Fig. 20.5 Concept of operations for an AUV detecting, classifying, and tracking a coastal thermocline (after [20.4], courtesy of Petillo et al.)
DCLT a shallow water thermocline. The node level,
CONOPS are described here for the tracking of a thermocline, but they can be directly mapped onto any
other episodic event in the ocean environment, for
example, the tracking of a plume, where the collaborative, adaptive cluster autonomy is even more important
by providing simultaneously the resolution and coverage required for accurately localizing, classifying, and
tracking the event. Thus, the network must first detect and localize the plume, and then adaptively track
its boundaries, a mission which obviously requires the
vehicles to collaborate to cover the expanding spatial
extent of the plume.
20.3 Autonomy
20.3.1 MOOS-IvP Autonomy
Architecture and System
The core of the nested autonomy paradigm is MOOSIvP (the mission-oriented operating suite, with interval
programming (IvP)): the autonomous, integrated sensing, modeling, and command and control framework on
each individual platform. In combination with the collaborative cluster autonomy, the integrated node autonomy enables the adaptation which may compensate for
the reduced physical sensor apertures of the unmanned
underwater vehicles. The design of the autonomy system is based on three basic architectural components,
extending the nesting into each individual sensor node:
Payload/Backseat vehicle architecture: Low-level
vehicle control is separated from the platform autonomy software, with the latter operating on a separate payload computer. This allows the same payload software and payload hardware to be integrated
in vehicles of different size and different vehicle
manufacturers.
Publish and subscribe software application architecture: The payload software system is comprised of several distinct applications. The decisionmaking, sensor processing, communications handling, data logging, and many other applications are coordinated by the MOOS publish–
subscribe middleware. The core MOOS middleware
is lightweight, having no external dependencies and
less than 1 Mb compiled size. The 2012 release,
MOOS V10, allows for improved high-bandwidth
and low-latency communications, suitable for use
on the Oxford autonomous car project. Hundreds of
MOOS applications have been written for use on
at least 20 different marine vehicle platform types.
Applications are largely independent, defined only
by their interface. Any application is easily replaceable with an improved version with a matching
interface. Core MOOS and many common applications are publicly available along with source code
under an open source LGPL license (GNU Lesser
General Public License).
Behavior-based decision-making architecture: The
IvP-Helm is a single MOOS application containing its own architecture of modular components –
behaviors. The mission mode determines which behaviors are active, and competing behaviors are
coordinated using multiobjective optimization using interval programming [20.5]. Several common
and powerful behaviors are available at www.moosivp.org, but users may augment this core capability with their own public or proprietary behaviors to
suit new mission objectives.
20.3.2 The Payload Autonomy Paradigm
To allow the MOOS-IvP network control to be applied
on a variety of fixed and moving nodes with different control software, a payload autonomy paradigm
was adopted and integrated with the MOOS-IvP control software infrastructure, and has subsequently been
integrated into a wide variety of autonomous underwater vehicles and surface craft. This is achieved by
adopting a hardware and software architecture that
physically separates the sensing, communication, data
processing, and associated adaptive autonomy from
the basic platform control, illustrated schematically in
Fig. 20.6. The idea is that all high-level control including the adaptation to measured and estimated parameters, is performed on a payload computer (PLC) running
MOOS middleware, and including the IvP-Helm autonomous decision-making engine. The payload will
also handle all communication with the network, ei-
Part B | 20.3
Thermocline
Temperature
Depth
Fig. 20.5 Concept of operations for an AUV detecting, classifying, and tracking a coastal thermocline (after [20.4], courtesy of Petillo et al.)
DCLT a shallow water thermocline. The node level,
CONOPS are described here for the tracking of a thermocline, but they can be directly mapped onto any
other episodic event in the ocean environment, for
example, the tracking of a plume, where the collaborative, adaptive cluster autonomy is even more important
by providing simultaneously the resolution and coverage required for accurately localizing, classifying, and
tracking the event. Thus, the network must first detect and localize the plume, and then adaptively track
its boundaries, a mission which obviously requires the
vehicles to collaborate to cover the expanding spatial
extent of the plume.
20.3 Autonomy
20.3.1 MOOS-IvP Autonomy
Architecture and System
The core of the nested autonomy paradigm is MOOSIvP (the mission-oriented operating suite, with interval
programming (IvP)): the autonomous, integrated sensing, modeling, and command and control framework on
each individual platform. In combination with the collaborative cluster autonomy, the integrated node autonomy enables the adaptation which may compensate for
the reduced physical sensor apertures of the unmanned
underwater vehicles. The design of the autonomy system is based on three basic architectural components,
extending the nesting into each individual sensor node:
Payload/Backseat vehicle architecture: Low-level
vehicle control is separated from the platform autonomy software, with the latter operating on a separate payload computer. This allows the same payload software and payload hardware to be integrated
in vehicles of different size and different vehicle
manufacturers.
Publish and subscribe software application architecture: The payload software system is comprised of several distinct applications. The decisionmaking, sensor processing, communications handling, data logging, and many other applications are coordinated by the MOOS publish–
subscribe middleware. The core MOOS middleware
is lightweight, having no external dependencies and
less than 1 Mb compiled size. The 2012 release,
MOOS V10, allows for improved high-bandwidth
and low-latency communications, suitable for use
on the Oxford autonomous car project. Hundreds of
MOOS applications have been written for use on
at least 20 different marine vehicle platform types.
Applications are largely independent, defined only
by their interface. Any application is easily replaceable with an improved version with a matching
interface. Core MOOS and many common applications are publicly available along with source code
under an open source LGPL license (GNU Lesser
General Public License).
Behavior-based decision-making architecture: The
IvP-Helm is a single MOOS application containing its own architecture of modular components –
behaviors. The mission mode determines which behaviors are active, and competing behaviors are
coordinated using multiobjective optimization using interval programming [20.5]. Several common
and powerful behaviors are available at www.moosivp.org, but users may augment this core capability with their own public or proprietary behaviors to
suit new mission objectives.
20.3.2 The Payload Autonomy Paradigm
To allow the MOOS-IvP network control to be applied
on a variety of fixed and moving nodes with different control software, a payload autonomy paradigm
was adopted and integrated with the MOOS-IvP control software infrastructure, and has subsequently been
integrated into a wide variety of autonomous underwater vehicles and surface craft. This is achieved by
adopting a hardware and software architecture that
physically separates the sensing, communication, data
processing, and associated adaptive autonomy from
the basic platform control, illustrated schematically in
Fig. 20.6. The idea is that all high-level control including the adaptation to measured and estimated parameters, is performed on a payload computer (PLC) running
MOOS middleware, and including the IvP-Helm autonomous decision-making engine. The payload will
also handle all communication with the network, ei-