Author/Y Type

ear
Websi
te

Citation

Topic

http://oc
eanai.m
it.edu/iv
pman/p
mwiki/p
mwiki.p
hp?
n=Helm
.HelmD
esignInt
ro

The
BehaviorBased
Control
Design
Philosophy
and IvP Helm

Quote

In the IvP Helm, the objective

functions are of a certain type piecewise linearly defined - and
are called IvP Functions. The
solver algorithms exploit this
construct to find a rapid solution
to the optimization problem
comprised of the weighted sum
of contributing functions.
Action Selection
o Subsumption Architecture
to prioritize
behaviors in a way
that the highest
priority behavior
locks out all others
o Potential fields or vector
summation approach
which considers the
average action
between multiple
behaviors to be a
reasonable
compromise.
reasonable
effectiveness on a
variety of
platforms, including
indoor robots
o Both method above have
short coming , describe at
Paolo Pirjanian, Multiple
Objective Action
Selection and Behavior
Fusion, Aalborg
University, 1998.

authors advocated
for the use of multiobjective
optimization as a
more suitable,
although more
computationally

http://oc
eanai.m
it.edu/iv
pman/p
mwiki/p
mwiki.p
hp?
n=Helm
.MOOSO
verview

http://oc
eanai.m
it.edu/iv
pman/p
mwiki/p
mwiki.p
hp?
n=Helm
.MOOSO
verview

MOOS Modul
es from Oxfo
rd

Mission Simul
ation Modules

expensive, method
for action selection.
The IvP model is a
method for
implementing
multi-objective
function based
action-selection
that is
computationally
viable in the IvP
Helm
implementation.
uMVS: A multi-vehicle AUV
simulator, capable of simulating
any number of vehicles and
acoustic ranging between them
and acoustic transponders. The
vehicle simulation incorporates a
full 6 D.O.F vehicle model
replete with vehicle dynamics,
center of buoyancy / center of
gravity geometry, and velocity
dependent drag. The acoustic
simulation is also fairly smart. It
simulates acoustic packets
propagating as spherical shells
through the water column
Mission simulation modules are
used only in simulation. Many of
the applications in the uField
Toolbox may also be considered
simulation modules, but they
also have a use case involving
simulated sensors on actual
physical vehicles. The two
modules below are purely for
simulated vehicles.
uSimMarine: A simple 3D
vehicle simulator that updates
vehicle state, position and
trajectory, based on the present
actuator values and prior vehicle

state. Typical usage scenario has

a single instance of uSimMarine
associated with each simulated
vehicle. See [9].

http://oc
eanai.m
it.edu/iv
pman/p
mwiki/p
mwiki.p
hp?
n=Helm
.MOOSO
verview

The uField
Toolbox

Two Layers of
Building
Autonomy in
the IvP Helm

Mission Be

uSimCurrent: A simple
application for simulating the
effects of water current. Based
on local current information from
a given file, it repeately reads
the vehicle's present position
and publishes a drift vector,
presumably consumed by
uSimMarine. See [9].
The uField Toolbox contains a
number of tools for
supporting multi-vehicle
missions where each vehicle is
connected to a shoreside
community. This includes both
simulation and real field
experiments. It also contains a
number of simulated sensors
that run on offboard the vehicle
on the shoreside.

The autonomy in play on a

vehicle during a particular
mission is the product of two
distinct efforts - (1) the
development of vehicle
behaviors and their algorithms,
and (2) mission planning via the
configuration of behaviors and
mode declarations. The former
involves the writing of new
source code, and the latter
involves the editing of mission
behavior files, such as the
simple example for the Alpha
example mission in Listing 5.1 .
The helm is configured for a

havior Files
-Configuring
behavior

The IvP
Build
Toolbox

particular mission primarily

through one or more mission
behavior files, typically with a
*.bhv suffix. Behavior files have
three types of entries, usually
but not necessarily kept in three
distinct parts - (1) variable
initializations, (2) behavior
configurations, and (3)
hierarchical mode declarations.
These three parts are discussed
below. The example alpha.bhv
file in Listing 5.1 did not contain
hierarchical mode declarations,
but does contain examples of
variable initializations and
behavior configurations.
Many, if not all of the behaviors in this
document make use of this toolbox,
and authors of new behaviors have this
at their disposal. A primary component
of writing a new behavior is the
development of the "underlying
function", the function approximated
by an IvP function with the help of the
toolbox. The underlying function
represents the relationship between a
candidate helm decision and the
expected utility with respect to the
behavior's objectives. The IvP Toolbox
is not covered in detail in this
document, but an overview is given
below.