Scripting Language for State Configured Layered Control of the Tethys Long Range Autonomous Underwater Vehicle

vroomhuhΛογισμικό & κατασκευή λογ/κού

4 Νοε 2013 (πριν από 3 χρόνια και 11 μήνες)

80 εμφανίσεις

Scripting Language for State Configured Layered
Control of the Tethys Long Range Autonomous
Underwater Vehicle

M. A. Godin, J. G. Bellingham, B. Kieft, R. McEwen
Monterey Bay Aquarium Research Institute (MBARI)
7700 Sandholdt Road
Moss Landing, CA 95039 USA


Abstract- A scripting language for state configured layered
control of a long range autonomous underwater vehicle (AUV) is
introduced. The XML-based language has been designed to meet
the complex requirements for long-term autonomous operation.
It does not require that mission planners be programmers, yet
allows them to have a high degree of certainty at deployment that
the robot will do what they want it to do. The script is simple to
execute on the vehicle, both to minimize CPU power usage and to
minimize the chance of failure due to complexity. Users do not
need a high-fidelity model of the AUV to plan a mission, as the
robot may change in unexpected ways over the course of the
mission. Those who wish to do more advanced programming of
mission commands and behaviors can do so in the script and are
not able to crash the vehicle's operating system. To address these
needs, the “Tethys script” state-configured layered control
language has been developed.
I. I
NTRODUCTION

The layered control paradigm, originally described by
Rodney Brooks [1], has proven a robust methodology for
specifying mobile robot missions and controlling mobile
robots in the real world. Nevertheless, a common complaint
about layered control is that mission planners tend to think in
terms of a procedure they would like the robot to execute, not
in terms of how to achieve their goals through behavior that
might in fact be emergent. Also for long-duration missions
with multiple goals, each goal needs to be achieved by an
individual behavior, resulting in behaviors that can approach
the complexity of complete control systems. State configured
layered control, described by James Bellingham [2], extends
layered control by having a higher level of control that enables
only the behaviors appropriate to the specific phase of the
mission, which means that several behaviors can work
together to meet each goal, reducing the complexity of
individual behaviors. A sequence of mission phases and a set
of phase transition rules allow state configured layered control
to leverage the strengths of both layered control and more
traditional procedural control systems. However,
implementations of state configured layered control in AUVs
have been rare.
The scripting language and architecture described here,
developed for the Tethys long-range AUV [3] adds two
concepts to the layered control paradigm: sequential behaviors
and aggregate behaviors. A sequential behavior can reach a
state of being "satisfied." Each sequential behaviors is
inserted into the layered control stack and is active until it its
goal is satisfied. Subsequently, it is withdrawn and replaced
with the next sequential behavior. Adding flow operators
(when/while/until, repeat loops, etc.), results in sequences that
resemble an imperative programming language. Aggregate
behaviors are defined in the script, and allow one to combine
other behaviors together (in sequence and/or parallel,
including other aggregate behaviors) to allow bottom-up
programming structures reminiscent of a structured
programming language.
Stack execution occurs within a hierarchy that allows higher
priority behaviors to remain active as lower priority behaviors
change from mission state to mission state. Stacks may also be
specified as reactive, entering or exiting the behavior
hierarchy in response to environmental and robot conditions
that warrant their execution or termination. Such reactive
commands allow the vehicle to reach a safe state during
system failures and risky circumstances (such as a low battery
charge or flight too close to the bottom), or can help the AUV
conserve power. For example, the AUV can conserve power
by favoring a transit to the surface for satellite transmissions
when it is already heading towards the surface rather than
during a dive.
The scripting language is built using XML to take
advantage of off-the-shelf validation tools and concise syntax
descriptions. Advanced mission planners can embed code for
new mission behaviors in the mission script itself (or in
auxiliary files) using the Lua scripting language. Running
such scripted behaviors in the "protected sandbox" of the
scripting language insulates the main vehicle code from
failures that could propagate from code complied directly into
the robot's core application software.
II. T
ETHYS
V
EHICLE

The Tethys long range AUV under development at MBARI
represents the next step in the evolution of AUVs, an
evolution that started with un-tethered vehicles that could be
trusted to return to their starting point, followed by vehicles
that could be deployed from a ship that would eagerly await
the return of the vehicles, through today's vehicles that can be
deployed by a ship, left on their own for a day or two, and
then retrieved on a later cruise. Along the way, docking AUVs
that return to an unmanned dock for recharging and
maintenance were developed, along with simple "glider"
AUVs that could remain in the water for months at a time, but
had to be contacted regularly to carry out a mission. Tethys
combines the capability for long-term deployments of glider
AUVs with the speed capabilities and fully autonomous nature
of existing high-power AUVs, resulting in a vehicle that will
be deployed for months at a time without requiring frequent
human intervention. Tethys cost and size will be closer to
those of gliders than to large vehicles, making it economically
and logistically feasible to operate the vehicle in large
numbers and from small platforms.
Over operational deployments of weeks to months, Tethys
vehicles can be infrequently monitored and controlled from
shore via a satellite communication link. Tethys will be able to
travel thousands of kilometers -- far beyond the capability (or
economic feasibility) of rescue vehicles to retrieve the AUV if
it encounters trouble. Such a capability means that several
failure modes that must be detected and tolerated in the
hardware and software architecture, such as failure of any
single actuator or sensor, earlier than expected battery
depletion, lock-up of the main vehicle computer, loss or
corruption of a data storage unit, or computational failure (i.e.,
taking too much time or segmentation fault) in a code
component.
III. T
ETHYS
S
OFTWARE
A
RCHITECTURE

The software executable files use a modular architecture,
which aids in isolating failures and failure recovery. However,
all data from all modules is captured in a single slate that
represents the complete state of the vehicle and is logged to a
single logging stream. All data values have associated units
and read and writes of these values must specify the units used
in the read or write; when necessary, unit conversions are
performed on the fly. To simplify debugging yet enhance the
capability to trap faults, a sequential nested threading model
wraps execution of module code.
In some cases, there will be multiple sources of information
for a given measurement. For example, there is a primary
pressure sensor, but also auxiliary pressure sensors on other
instrumentation, as well as a dead-reckoned pressure estimate.
The Tethys software gracefully handles failures of one or
more of these pressure sources by associating a universal
concept, “sea_water_pressure” with each of these sources, and
an accuracy estimate for each source. A computational
component that needs pressure can then just request the
universal “sea_water_pressure” and know that it will get the
best available pressure at the time of request.
A. Tethys Mission Structure
Figure 1 is a tabular depiction of a Tethys script mission. As
shown in the table, a mission may contain DefineArg elements,
an optional Timeout element, and any number of Behavior,
Call, Insert, Syslog, and Assign elements in any order.

Figure 1, Mission elements
# of Occurrences
Element (or Attribute)
1 Id
0 to N DefineArg
1 optional Timeout
0 to N in any order Behavior
Call
Insert
Syslog
Assign

The Id attribute is a unique identifier for the mission, and is
necessary for addressing the mission while it is running.
The DefineArg elements declare arguments for use in the
mission, along with default values. If the vehicle operator
wants to specify these arguments, they may be individually
specified at the start of the mission or any time during mission
execution.
The optional Timeout element applies to missions, but can
also be applied to any behavior within the mission. By default
if the duration specified along with the Timeout passes, the
mission (or behavior) completes. However, an optional
behavior can be specified within the Timeout element, which
will execute when the specified duration has elapsed. In the
case of a Tethys mission, after completion of a selected
mission, a default mission kicks off to maintain the vehicle in
a safe state and maintain lines of communications.
Behavior elements encapsulate an aspect of the robot’s
interaction with the world, and can be as simple as timed wait,
or as complex as a multi-waypoint, multi-speed survey with
satellite communications.
The Call element allows one to re-use identical behaviors in
the mission without having to describe them over and over,
while the Insert element allows one to import mission code
from an external file.
Syslog elements allow one the opportunity to generate a
textual log of mission status as the mission evolves.
Finally, the Assign element allows one to assign values to
defined arguments or to any slate variable. The values can be
constants, or may come from any other argument or slate
variable.
B. Tethys Behavior Structure
As with any layered control system, the fundamental unit of
execution is the behavior, which drives the system to interact
with the world in a defined way. Of course, layered control
also introduces behavior priority and allows higher priority
behaviors to subsume the interactions of lower priority
behaviors. State-configured layered control further adds state
transitions that cause the prioritized behavior stack to change
as mission objectives are achieved or environmental
conditions warrant changes.
Figure 2 is a tabular depiction of the schema for a Tethys
script Behavior. Like Tethys missions, behaviors can have Id
attributes and Timeout elements. However, other attributes
and elements related to state transitions are also available.

Figure 2, Basic Behavior elements and attributes
# of Occurrences
Element (or Attribute)
1 optional Id
1 RunIn
1 optional Repeat
1 optional Timeout
1 optional Preemptive
1 optional While
1 optional When
1 optional Until

The RunIn attribute can have one of three values: “Parallel”,
“Sequence”, or “Progression”, and controls when the behavior
exists in the stack. A parallel behavior is always in the stack
(unless it is part of a sequential aggregate behavior that is not
on the stack). Conversely, a behavior running in sequence is
loaded onto the stack after any sequential behaviors that
precede it are satisfied, and is unloaded from the stack when
its goal becomes satisfied. A behavior running in progression
is similar to a sequential behavior, except that it stays on the
stack, even after its goal is satisfied, ensuring that its goal is
maintained.
For behaviors running in sequence, the Repeat attribute can
be used to ensure that the behavior’s goal is achieved N times
before it is considered satisfied.
The Preemptive element is a Boolean clause that affects
other behaviors with less priority in the layered control stack.
If Preemptive evaluates to true, then other lower priority
behaviors are completely removed from the stack rather than
having their outputs subsumed while the behavior with the
Preemptive clause is active.
Another Boolean clause is the While element, which causes
the behavior to be active only while the clause evaluates to
true. The When element is similar to the While element, but
causes behaviors that are specified to run in sequence to start
when the Boolean clause is true, and run until the behavior’s
goal is satisfied.
If the Until Boolean clause is specified, the behavior ceases
to be active when the clause is true, similar to the concept of
Timeout, but allows for the testing of any parameter, and
allows for the generalization of the requirements of meeting
the behavior’s goal.
As described above, basic Behavior elements are still a bit
abstract, and to write an actual mission, the more concrete
forms of Behavior must be used. Two are defined:
Component behaviors, which are coded routines, and
Aggregate behaviors which are combinations of other
behaviors.
C. Tethys Component Behaviors
As implemented for Tethys, most Component behaviors are
compiled into binary modules that are made available through
the core Tethys software system. The modularity allows users
to develop their own modules using the C++ Component
behavior API to implement new behaviors without touching
the core Tethys software system. Also, special Custom
behaviors can be embedded directly into the mission using
Lua scripting language routines that follow the Custom
behavior API. As shown in Figure 3, Component behaviors
have additional elements that are typically specified.

Figure 3, Additional elements of Component behaviors
# of Occurrences
Element
0 to N Setting
1 optional Satisfied

The Setting element allows the mission script to set
parameters for the coded behavior. For example a Waypoint
behavior would need a Setting for desired latitude and a
Setting for desired longitude, both of which are used to
influence the behavior’s effect on the robot and to determine
when the behavior has been satisfied.
The Satisfied element is an Aggregate behavior that is
launched when the Component behavior becomes satisfied. As
an example, one may imagine an event detection behavior that
is looking for a peak in chlorophyll concentration. Once that
peak has been found in the water column, the detection
behavior becomes satisfied, and the Satisfied Aggregate
behavior is started, which could, for example, drive back to
the place of peak chlorophyll concentration and take a sample.
D. Tethys Aggregate Behaviors
Aggregate behaviors can be thought of as containers for
other Component and Aggregate behaviors. Typically, the
goal that an Aggregate behavior tries to accomplish is meeting
the goals of all its contained behaviors, each of which may run
in sequence or parallel. However, by using Until clauses, other
criteria for Aggregate behavior completion can be defined.
As containers, Aggregate behaviors can contain many of the
same elements as missions, as shown in Figure 4. The
Behavior, Call, Insert, Syslog, and Assign elements defined for
Aggregate behaviors have the same meaning and function as
corresponding elements at the mission level.

Figure 4, Additional elements of Aggregate behaviors
# of Occurrences
Element
0 to N in any order Behavior
Call
Insert
Syslog
Assign

IV. E
XAMPLE
M
ISSIONS

Traditionally, when introducing a new programming
paradigm, the simplest possible code that produces the words
“Hello, world!” is demonstrated. For the Tethys script, such a
code follows:

<Mission Id=”Hello”>
<Syslog>Hello, world!</Syslog>
</Mission>

As one may imagine, the output is quite simple:

[MissionManager](IMPORTANT): Started Mission Hello
[Hello: 0](INFO): Hello, world!
[Hello](INFO): Completed Hello

A more complex “Hello world” mission that includes
defined arguments, aggregate behaviors, an assignment, a
component behavior with a setting and a timeout, and a call
follows:

<Mission Id="Hello">
<DefineArg Name="Str"><String/></DefineArg>
<Aggregate Id="SyslogStr" RunIn="Sequence">
<When><Called></When>
<Syslog><Arg Name="Str"/><Units:none/></Syslog>
</Aggregate>
<Assign>
<Arg Name="Str"/><String>Hello, world!</String>
</Assign>
<Guidance:Wait RunIn="Sequence">
<Timeout Duration="P4S">
<Call RefId="SyslogStr"/>
</Timeout>
<Setting><Guidance:Wait.duration/>
<Units:second/><Value>5</Value>
</Setting>
</Guidance:Wait>
</Mission>

When this mission runs, the argument “Str” is initially set to
an empty string. The aggregate behavior “SyslogStr” is
initially not run because it has a When clause which is only
satisfied when a Call is made to it. So the Assign element
assigns the value “Hello, world!” to the variable “Str” and the
“Wait” behavior from the “Guidance” module is run, with
duration setting of 5 seconds, and a timeout set for 4 seconds,
at which time the “SyslogStr” behavior will be called.

Output from the more complex HelloWorld mission:

[MissionManager](IMPORTANT): Started Mission Hello
[Hello:1.Wait](INFO): Timed out.
[Hello:SyslogStr:0](INFO): Hello, world!
[Hello](INFO): Completed Hello

While entertaining, these “Hello world” scripts fail to
convey the types of scripts that are useful for a real robot, so
an actual mission used by the Tethys vehicle will be illustrated.
The mission file, called WaypointYoYo.xml will attempt
to steer the vehicle to four waypoints, repeating the first
waypoint at the end of the mission, completing a square circuit,
while simultaneously driving up and down in the water
column (yo-yoing) and stopping at the surface every half hour
for GPS updates and satellite communications. While the
vehicle is not communicating with shore, it will collect
science sensor data, and at all times, the vehicle will avoid
going too deep, will avoid the sea floor, and will avoid the
coastline.
Since some parts of the mission are commonly repeated in
other missions, these parts have been put into their own files
and are referred to via Insert elements. The first chunk of code
imported into the mission contains the highest priority, safety-
critical component behaviors that prevent loss of the vehicle.
These are contained in their own aggregate behavior file
named Safety.xml, will be referred to by an Insert statement
near the top of the main mission file. The content of
Safety.xml follows:

<Aggregate Id="Safety" RunIn="Parallel">
<Guidance:AltitudeEnvelope RunIn="Parallel">
<Setting><Guidance:AltitudeEnvelope.minAltitude/>
<Units:meter/><Value>5</Value>
</Setting>
</Guidance:AltitudeEnvelope>
<Guidance:DepthEnvelope RunIn="Parallel">
<Setting><Guidance:DepthEnvelope.maxDepth/>
<Units:meter/><Value>300</Value>
</Setting>
</Guidance:DepthEnvelope>
<Guidance:OffshoreEnvelope RunIn="Parallel">
<Setting><Guidance:OffshoreEnvelope.minOffshore/>
<Units:kilometer/><Value>1.0</Value>
</Setting>
</Guidance:OffshoreEnvelope>
</Aggregate>


Safety.xml contains three behaviors from the Guidance
module: AltitudeEnvelope (which in this case keeps the robot
off the sea floor), DepthEnvelope (which in this case keeps the
robot above its crush depth), and OffshoreEnvelope (which in
this case keeps the vehicle off the shore). Each of the
behaviors has a setting element, each of which contains three
further elements: a setting name (defined in the module
schema file), a unit (defined in the unit schema file), and a
numerical value. Also, each behavior is specified to run in
parallel. The behavior that appears at the top
(AltitudeEnvelope) has the highest priority and the behavior
that appears at the bottom has the lowest priority. In this case,
the priorities are arbitrary, since the first two behaviors both
tend to force the vehicle upwards in the vertical direction,
while the third acts on the horizontal plane of motion.
The second part of the mission achieves the goal of surface
satellite communications to shore, and is called by the main
mission whenever satellite communications are desirable.
Unlike the safety-critical functions, which are always running
in parallel, surface communications can be thought of as
having a beginning, a set of activities, and an endpoint at
which time the goal of surface communications is satisfied.
This, it will be a sequence aggregate behavior that contains
other sequence behaviors. The content of Surface.xml follows:

<Aggregate Id="Surface" RunIn="Sequence">
<Guidance:GoToSurface RunIn="Progression"/>
<Aggregate Id=”AtSufaceOps”>
<Preemptive><True/></Preemptive>
<Guidance:ReadSensor RunIn="Sequence">
<Timeout Duration="P5M"/>
<Setting><Guidance:ReadSensor.uri/>
<Universal:time_fix/>
</Setting>
</Guidance:ReadSensor>
<Guidance:ReadSensor RunIn="Sequence">
<Timeout Duration="P5M">
<Assign>
<Universal:platform_communications/>
</Assign>
</Timeout>
<Setting><Guidance:ReadSensor.uri/>
<Universal:platform_communications/>
</Setting>
</Guidance:ReadSensor>
<Guidance:ReadSensor RunIn="Sequence">
<Timeout Duration="P5M"/>
<Setting><Guidance:ReadSensor.uri/>
<Universal:time_fix/>
</Setting>
</Guidance:ReadSensor>
</Aggregate>
</Aggregate>

The first sequential behavior is the GoToSurface component
behavior from the Guidance module. It is run in Progression
because it is desirable to achieve the goal (at which time other
sequential behaviors can commence), but also to maintain the
goal while subsequent behaviors occur (i.e., the vehicle needs
to return to the surface if it finds itself submerged).
The second sequential behavior is an aggregate behavior
with the id “AtSurfaceOps”. This behavior has a Preemptive
element set to true, which means that while surface operations
are occurring, lower priority behaviors are shut off. If the
vehicle is progressing towards a waypoint, for example when
the GoToSurface behavior becomes active, it will continue
towards the waypoint as the behavior attempts to achieve its
goal. However, once that goal is reached and surface
operations commence, the vehicle needs to stop all other
operations (such as heading towards a waypoint) until surface
operations complete.
Within the “AtSurfaceOps” aggregate behavior, there are
three sequential ReadSensor behaviors, which read from the
GPS, read interact with an Iridium satellite, and read from the
GPS again. Each ReadSensor behavior has a Timeout element
set to a period of 5 minutes and a Setting element that sets the
ReadSensor’s uri setting to the name of the variable that is
intended to be read. For the GPS, a request to read any of
time_fix, latitude_fix, or longitude_fix results in a read of all
three parameters, while the Iridium driver initiates a two-way
communication session when one attempts to read
platform_communications.
Note that the second ReadSensor behavior’s timeout
element includes an Assign element with the
platform_communications target and no value. This simply
updates the timestamp of platform_communications so that it
appears that it has been recently written. Doing so allows the
mission (see later) to continue even though more than 30
minutes has passed since the last platform_communications.
The third import into the mission, Science.xml causes
the science sensors to be read. Like Safety.xml, it is an
Aggregate behavior that runs in parallel, and contains parallel
behaviors. Like Surface.xml, it contains ReadSensor
behaviors, but they all run in parallel, not in sequence:

<Aggregate Id="Science" RunIn="Parallel">
<Guidance:ReadSensor RunIn="Parallel">
<Setting><Guidance:ReadSensor.uri/>
<Universal:sea_water_temperature/>
</Setting>
</Guidance:ReadSensor>
<Guidance:ReadSensor RunIn="Parallel">
<Setting><Guidance:ReadSensor.uri/>
<Universal:sea_water_salinity/>
</Setting>
</Guidance:ReadSensor>
<Guidance:ReadSensor RunIn="Parallel">
<Setting><Guidance:ReadSensor.uri/>
<Universal:mass_concentration_of_chlorophyll />
</Setting>
</Guidance:ReadSensor>
<Guidance:ReadSensor RunIn="Parallel">
<Setting><Guidance:ReadSensor.uri/>
<Universal:mass_concentration_of_oxygen />
</Setting>
</Guidance:ReadSensor>
</Aggregate>

The actual mission file, WaypointYoYo.xml, starts with
several DefineArg statements. Each sets a variable that can be
used later in the mission in place of constant expressions.
They can also be overridden when the mission is launched, or
even while the mission is running, to change the intended
waypoints without having to modify the mission file. This can
be useful, for example if a scientist is monitoring data being
sent to shore from the vehicle in near-real-time and decides
that a change of trajectory is warranted to either re-sample and
interesting area, or to extend the mission out into a more
interesting region. The content of WaypointYoYo.xml,
follows:

<Mission Id="WaypointYoYo">
<DefineArg Name="Wp1Lat"><Units:degree/>
<Value>36.80732</Value></DefineArg>
<DefineArg Name="Wp1Lon"><Units:degree/>
<Value>-121.827194</Value></DefineArg>
<DefineArg Name="Wp2Lat"><Units:degree/>
<Value>36.809602</Value></DefineArg>
<DefineArg Name="Wp2Lon"><Units:degree/>
<Value>-121.830099</Value></DefineArg>
<DefineArg Name="Wp3Lat"><Units:degree/>
<Value>36.812076</Value></DefineArg>
<DefineArg Name="Wp3Lon"><Units:degree/>
<Value>-121.827194</Value></DefineArg>
<DefineArg Name="Wp4Lat"><Units:degree/>
<Value>36.809602</Value></DefineArg>
<DefineArg Name="Wp4Lon"><Units:degree/>
<Value>-121.824506</Value></DefineArg>
<Timeout Duration="P240M"/>
<Insert Filename="Missions/Safety.xml"/>
<Insert Filename="Missions/Surface.xml"/>
<!-- GPS & Iridium Update every 30 minutes -->
<Aggregate Id="NeedComms" RunIn="Sequence">
<When><Universal:platform_pitch_angle/>
<Elapsed><Universal:time_fix/></Elapsed>
<Gt/><Units:minute/><Value>30</Value>
<Or>
<Elapsed><Universal:platform_communications/>
</Elapsed>
<Gt/><Units:minute/><Value>30</Value>
</Or>
</When>
<Call RefId="Surface"/>
</Aggregate>
<Guidance:Buoyancy RunIn="Progression">
<Setting><Guidance:Buoyancy.position/>
<Units:cubic_centimeter/><Value>100</Value>
</Setting>
</Guidance:Buoyancy>
<Aggregate Id="GoToWaypoints" RunIn="Sequence">
<Insert Filename="Missions/Science.xml"/>
<Guidance:SetSpeed RunIn="Parallel">
<Setting><Guidance:SetSpeed.speed/>
<Units:meter_per_second/><Value>1</Value>
</Setting>
</Guidance:SetSpeed>
<Guidance:DepthEnvelope RunIn="Parallel">
<Setting><Guidance:DepthEnvelope.minDepth/>
<Units:meter/><Value>5</Value>
</Setting>
</Guidance:DepthEnvelope>
<Guidance:YoYo RunIn="Parallel"/>
<Guidance:Waypoint Id="Wp1" RunIn="Sequence">
<Setting><Guidance:Waypoint.latitude/>
<Arg Name="Wp1Lat"/></Setting>
<Setting><Guidance:Waypoint.longitude/>
<Arg Name="Wp1Lon"/></Setting>
</Guidance:Waypoint>
<Guidance:Waypoint Id="Wp2" RunIn="Sequence">
<Setting><Guidance:Waypoint.latitude/>
<Arg Name="Wp2Lat"/></Setting>
<Setting><Guidance:Waypoint.longitude/>
<Arg Name="Wp2Lon"/></Setting>
</Guidance:Waypoint>
<Guidance:Waypoint Id="Wp3" unIn="Sequence">
<Setting><Guidance:Waypoint.latitude/>
<Arg Name="Wp3Lat"/></Setting>
<Setting><Guidance:Waypoint.longitude/>
<Arg Name="Wp3Lon"/></Setting>
</Guidance:Waypoint>
<Guidance:Waypoint Id="Wp4" RunIn="Sequence">
<Setting><Guidance:Waypoint.latitude/>
<Arg Name="Wp4Lat"/></Setting>
<Setting><Guidance:Waypoint.longitude/>
<Arg Name="Wp4Lon"/></Setting>
</Guidance:Waypoint>
<Call Id="Wp5" RefId="Wp1"/>
<Call RefId="Surface"/>
</Aggregate>
</Mission>

The argument definitions are followed by a Timeout
element, then two Insert elements. The first insert refers to
Safety.xml, ensuring that the safety-critical behaviors are
always in the highest priority position in the layered control
stack, while the second insert refers to Surface.xml,
ensuring that the first sequential operation in the mission will
consist of surface communications. These are followed by an
Aggregate behavior with a When clause. The When clause
evaluates to true when the elapsed time since the last time_fix
exceeds 30 minutes or when the elapsed time since the last
platform_communications exceeds 30 minutes. At that time,
the contained Call element will cause the “Surface” behavior
(in Surface.xml) to run.
After surface communications, the next sequential step in
the mission is to pump the vehicle’s adjustable buoyancy
system to a specific value, 100 cm
3
, and keep it there for the
remainder of the mission.
After the buoyancy is pumped, the “GoToWaypoints” phase
of the mission begins by making several parallel behaviors
active: all the behaviors in Science.xml, a SetSpeed
behavior that ensures the vehicle moves at 1 m/s, a
DepthEnvelope behavior that will keep the vehicle deeper than
5 meters, and a YoYo behavior that will ensure the vehicle
travels up and down as it traverses.
Five sequential Waypoint behaviors achieve the primary
objective of the mission (the fifth one is just a call to the first),
and are followed by a Call element that refers to the “Surface”
Aggregate behavior in Surface.xml. Note that the Call
element calls the “Surface” behavior at its existing location in
the behavior stack, which is important since the “Surface”
element must subsume and eventually preempt the
DepthEnvelope (minDepth=5m) behavior that exists at a
higher priority than the Call element. For cases where this is
not the intended effect, the Call element has an optional
attribute, PriorityHere, which can be set to true to shift the
priority of called behaviors to where the Call statement exists.

V. NEXT

STEPS
In both simulation and ocean tests, Tethys AUV missions
continue to successfully leverage features of the scripting
language and provide a rich oceanographic data collection.
The use of XML in the Tethys script facilitates machine-based
code generation, which will be the next phase of Tethys
development: an easy to use GUI for developing Tethys
missions.
A
CKNOWLEDGMENT

This work was supported by the David and Lucile Packard
Foundation.
R
EFERENCES

[1] R. A. Brooks, “A robust layered control system for a mobile robot,” in
IEEE Journal of Robotics and Automation, vol. RA-2, no. 1, pp. 14-23,
March 1986.
[2] J. G. Bellingham, T. R. Consi, “State configured layered control.” in
Proceedings of the IARP 1st Workshop on Mobile Robots for Subsea
Environments, pp. 75-80, Monterey CA, October 1990.
[3] J. G. Bellingham, B. Hobson, M. A. Godin, B. Kieft, J. Erikson, R.
McEwen, C. Kecy, Y. Zhang, T. Hoover, and E. Mellinger, “A small,
long-range AUV with flexible speed and payload,” in Ocean Sciences
Meeting, Abstract MT15A-14, Portland, OR, February 2010.