Tortuga III

Autonomous Underwater Vehicle

robotics @ MARYLAND

http://ram.umd.edu/

The University of Maryland, College Park

Tom Capon Chris Carlsen Nathan Davidge Joseph Galante Paul Goldin
Alex Janas Nicholas Limparis Joseph Lisee John Martin Jaymit Patel Kit Sczudlo
Neil Sikka Leo Singer Jonathan Sternberg

Faculty advisor: Dr. Nuno Martins, Ph.D.

Abstract
Tortuga III is a fully autonomous underwater vehicle designed to defend its first
place title in the 2009 International AUVSI Competition. Every system of the vehicle
has been streamlined and upgraded for peak performance. The third generation in the
Tortuga series of autonomous underwater vehicles, Tortuga III features a smaller and
lighter pressure hull, new thrusters with integrated motor controllers, as well as new
hardware for tasks new to the 2009 competition. The addition of a second inertial
measurement unit allows the robot to utilize an improved control system. Increased
sonar functionality and a more robust vision system ensures that Tortuga III is ready
to compete with the world’s top universities.
1 Introduction system, sold by 80/20 Inc., which allows for
easy design and modification. Everything on
Tortuga III is an AUV designed and built the vehicle bolt to the 80/20 rails and can be
by Robotics@Maryland, a student-run non- reconfigured when necessary. The batteries
profit (501C3) organization at the University and core electronics reside in a single 16-inch
of Maryland, College Park. The original Tor- long, eight-inch diameter acrylic tube (pres-
tuga was created in 2006 to compete in the sure hull) supported within the aluminum frame.
Tenth Annual International Autonomous Un- The rear section of the chassis attaches with
derwater Vehicle Competition hosted by AU- heavy-duty latches to allow for battery changes
VSI and ONR. The purpose of the compe- or removal of the pressure hull for mainte-
tition is to develop AUV technology by chal- nance. Forward and downward-facing cam-
lenging students to construct submersibles ca- eras are housed in a modified Ikelite enclosure
pable of completing underwater tasks simu- at the front of the vehicle.
lating realistic missions. For the 2009 Inter-
national AUV Competition, the Robotics@Mary-
land team has made significant improvements
to both the hardware and software of Tor-
tuga II . Throughout the year, Robotics@Mary-
land has showcased the AUV at several demon-
strations and recruiting events for the Univer-
sity and participated in several graduate re-
search projects. Participation in AUVSI and
ONR’s annual AUV competition will provide
Robotics@Maryland with knowledge that can
be used to further their studies and aid in fu-
ture research.

2 Mechanical System
The AUVSI Autonomous Underwater Vehi-
cle course and competition mandate maneu-
verability, rather than speed, as the primary
requirement of our vehicle. High maneuver-
ability can be accomplished with the proper
thruster and mass placement, with little con-
cern for hydrodynamics. Simplicity, cost, and
reliability are also important design factors
driving the chassis configuration.
2.1 Chassis
The vehicle chassis is designed to be as simple
and versatile as possible. The chassis frame
is built using a modular aluminum framing
Figure 1: CAD rendering of Tortuga III
2.2 Pressure Hull
The pressure hull is the central component
of the vehicle. A single electronics enclosure
was chosen to reduce the number of wet in-
terconnects and leak points. This reduces
the probability of a hull breach and simpli-
fies construction.
The pressure hull consists of an eight-inch
diameter acrylic tube whose ends are sealed
by two aluminum end caps. The inner sur-
faces of the tube are turned and chamfered

Robotics@Maryland 1
to precisely mate with piston seals on the end Each launcher is triggered by a waterproofed
caps. The piston O-ring seal has proven to be servo. The launchers are constructed from
both simple and very reliable. The end caps rapid prototyped ABS plastic and fire five-
themselves are CNC-milled from aluminum inch-long projectiles.
slabs and provide mounting surfaces for the
many watertight SubConn connectors. Be-
cause most of the electronics are inside the 3 Electronics
pressure hull, only the components that re-
quire contact with the water use wet connec- 3.1 Backplane
tors. The electrical systems for Tortuga III use the
The rear endcap of Tortuga III is designed same modular design found on its predeces-
with a corrugated shape and acts as a high- sor. A central backplane links the several
efficiency flat-wall heat exchanger. Fans cir- plug-in cards that carry out various electronic
culate the air inside the hull over the heat tasks. The modular design was chosen for its
exchanger, dumping over 60 watts of power logical separation of functions, expandability,
into the surrounding water while keeping the and ease of servicing and repair. Our elec-
electronics at a safe operating temperature. tronics stack consists of a backplane board
Tortuga III features new thrusters with that holds six other modules: the power reg-
integrated motor controllers and encoders. Thisulator board, battery load balancing board,
allows the pressure hull to be shorter and power distribution board, telemetry board,
eliminates the need for internal motor con- sensor board, and sonar processing board.
trollers, saving valuable space. The backplane provides nearly all of the
required interconnections between boards, in-
2.3 Payload Actuators cluding power and data signals. The only
exception is a single high-current connection
The marker droppers use a unique magnetic
that supplies power to the motors.
circuit design to perform the hold and release
operations. Flux paths are constructed such
that with the coil de-energized, a permanent 3.2 Sensor Board
magnet holds the marker in place. When The sensor board is the central module in the
the coil energizes, it forces the flux out of backplane. It contains four Microchip dsPIC
the marker into an alternate path, allowing microcontrollers, one of which masters the
the marker to fall. This mechanism requires control bus and has a USB link to the ve-
very little power to operate when compared hicle computer. The remaining three chips
to other electromagnetic systems. operate in slave mode and are responsible for
To retrieve the “briefcase” from the bot- reading temperatures, digitizing and filtering
tom of the pool, an array of spring-loaded the depth reading, and controlling an LCD
flaps latch onto the PVC pipes when the robot readout. These chips also provide spare out-
descends. There are 18 flaps arranged such puts for future upgrades and modifications.
that the vehicle can drift up to eight inches In addition to interface code, the master
off-target and still retrieve the payload. chip on the sensor board contains a diagnostic
A new task for the 2009 AUVSI competi- program which displays status and telemetry
tion is to fire torpedoes through an underwa- information on the vehicle’s LCD. This di-
ter target. Two torpedo launchers are mounted agnostic program can be used to verify the
on the front of Tortuga III on opposite sides.

Robotics@Maryland 2
operation of the electronics stack and dive- with Linear Technology’s LTC4412HV Pow-
critical sensors without starting the vehicle erPath Controller chips and several P-channel
computer. MOSFETs. The onboard dsPIC controller
monitors the voltage and current measure-
3.2.1 Control Bus ments for each battery channel and the board
temperature. The microcontroller also has
The control bus carries information such as the ability to enable and disable individual in-
motor commands, sensor values, power read- put channels, which allows for hot-swapping
ings, safety commands as well as various other of the batteries.
status messages and updates. The bus it- The balancer board contains the vehicle’s
self is an 8-bit-wide, fully asynchronous, bi- power-on and power-off circuitry. The On
directional bus consisting of one master and and Off switch signals are connected both
seven slave microcontrollers, some of which to push-buttons on the board and to reed
are located on other boards in the backplane. switches mounted on the edge of the electron-
It enables multiple microcontrollers to per- ics tray. The reed switches can be magneti-
form data acquisition and processing in par- cally activated while the hull is sealed.
allel, pausing only to report the latest value
when requested.
3.3.2 Distribution Board

3.3 Power The main function of the power distribution

board is to provide high current outputs for
The vehicle is powered by five 25.9V, 5200mAh the motor controllers. Each motor can be in-
lithium-ion battery packs. These are suffi- dividually enabled or disabled through com-
cient for over two and a half hours of under- mands on the control bus. The board also
water operations, or over eight hours of sta- provides high current outputs for the marker
tionary development time. droppers and the onboard computer’s power
Power management and distribution is han- converter.
dled by the three backplane modules described The external kill switch is connected to
below. Tortuga III features a new power ar- the distribution board. When activated, power
chitecture with isolated switch-mode power to the motors is shut off by hardware logic
converters for the most critical components. and cannot be enabled by software.
This system will eliminate ground loops and Like the balancer board, the distribution
limit cascading failure caused by short cir- board contains a dsPIC microcontroller to per-
cuits. The addition of fast-blow automotive form the monitoring and control tasks. It
fuses on the battery and motor power lines provides current measurements for all of its
add another measure of protection. output channels, motors, and board temper-
ature.
3.3.1 Balancer Board
3.3.3 Regulator Board
The balancer board is responsible for man-
aging the vehicle’s incoming power. It arbi- The regulator board provides clean, regulated
trates between internal and external power power for various components of the vehi-
sources, and ensures that the battery packs cle. The outputs include 5V and 12V rails
are discharged evenly. This is accomplished for logic power, two isolated 9V outputs for
the IMU sensors, and a 20V analog supply to

Robotics@Maryland 3
bias the hydrophone amplifiers.
The 5V rail powers most of the microcon-
trollers and logic chips in the vehicle. The
12V rail powers peripherals like ethernet and
FireWire hubs, and it powers point-of-load
regulators used for analog reference signals.
The 5V and 12V potentials are produced
by two PTN78020-series switching regulators
from Texas Instruments. Each output can
source currents of up to 6A. The isolated out-
puts are produced by two DCP0205xx-series
modules, also from Texas Instruments. The
20V output is produced by an LM317 linear
regulator. The 26V, 12V, 5V, and 20V rails
are all routed onto the backplane.
3.3.4 UVQ Board
The onboard computer is powered by a Mu-
rata 100W isolating DC-DC converter mod-
ule. This module, the UVQ-18/5.6-D24PBC,
bolts directly to the front end cap so heatsink-
ing is not an issue. It mounts with a small
circuit board that contains the necessary ex-
ternal components to operate the converter,
along with a dsPIC30F3012 microcontroller
to read voltage and current. The dsPIC com-
municates with the sensor board over opto-
isolated serial lines so that power isolation is
maintained.
4 Sensors
Tortuga III uses a variety of sensors and con-
trol algorithms that enable it to complete its
objectives. Inertial guidance sensors are cou-
pled with low level control algorithms to sta-
bilize the vehicle and allow it to execute basic
motions in the water. Sonar and vision sen-
sors are used to determine the relative loca-
tion of various competition objectives. The
locations are used by the AI in higher level
control algorithms to carry out specific tasks
such as object recovery.
Robotics@Maryland
4.1 Inertial guidance
Inertial guidance is primarily accomplished
using two sensors. The first sensor is an ab-
solute pressure transducer. Since the sur-
face of the water is considered to be an in-
ertial translational reference point, the pres-
sure transducer provides a direct measure of
the vehicle’s depth. The sensor is absolute
and thermally compensated, so it gives a re-
liable depth reading despite temperature and
pressure fluctuations inside the hull.
The second sensor is a pair of IMUs (in-
ertial measurement units) manufactured by
MEMSense called nIMUs. These devices each
contain a three axis magnetometer, a three
axis accelerometer, and three angular rate gy-
ros. Assuming small accelerations, the mag-
netometer and accelerometer readings can be
used in a TRIAD algorithm [1] to provide a
direct measurement of angular position (i.e.
absolute orientation). The angular rate gy-
ros provides a direct measurement of angular
velocity. Tortuga III is equipped with two
IMUs, one at the vehicle’s CG (center of grav-
ity) and one on a boom at the top of the vehi-
cle. The IMU at the CG of the vehicle is used
to obtain acceleration and angular rate read-
ings which would suffer from dilution of pre-
cision were they located anywhere else, but is
subjected to magnetic interference from the
electronics in and around the pressure hull.
A second IMU located in a boom above the
main pressure hull is far enough away from
other electronics to provide an accurate mea-
surement of the local magnetic field near the
vehicle.
4.2 Sonar
Multilateration is used to determine Tortuga III ’s
relative bearing from the pinger. The relative
position of an acoustic source is estimated by
comparing the time delay on arrival (TDOA)
of a pulse received by an array of hydrophones
4
 Figure 2: A block diagram of Tortuga III ’s passive sonar system

at known positions. fin BF537 DSP, from Analog Devices, which

The design uses TDOAs from a four-sensor handles data analysis.
array to determine the direction of the pinger To facilitate development and ease debug-
in a 2-D plane, but the multilateration tech- ging, uClinux was chosen as the operating
nique can be extended to three dimensions system for the DSP. uClinux provides numer-
[2]. Tortuga III uses bearings alone, because ous features that enable rapid development
of the extremely fine tolerances on the place- such as file system drivers, Flash card drivers,
ment of the hydrophones that passive ranging and a TCP/IP stack. The sonar software
demands. runs entirely in userspace.
Fortunately, the FIFO buffers inside the
4.2.1 Signal processing FPGA are deep enough to handle any in-
terruptions to data collection resulting from
The sonar board consists of signal condition- context-switching. These FIFOs eliminate the
ing circuitry, analog to digital converters, a need for a real-time OS on the Blackfin, greatly
field programmable gate array (FPGA), and simplifying the DSP software.
a digital signal processor (DSP).
The signal conditioning circuitry for each
channel consists of an amplifier and a first- 5 Vision System
order bandpass filter with corner frequencies
of 20 kHz and 30 kHz. The vision system input uses two Unibrain
Signals are digitized by two four-channel Fire-i cameras which stream video over FireWire
ADCs, sampling at a rate of 500 kHz with to the Mac Mini. The two cameras are stored
a depth of 16 bits. The FPGA collects and in a separate housing from the rest of the ve-
buffers data from the ADCs and carries out hicle’s electronics, giving the ability to swap
other control tasks. The system can sample housings. The external housing provides a
continuously on all four channels at a full rate flat optical viewing surface for the cameras.
for up to 2.6 seconds. One camera faces forward and the other faces
The FPGA communicates with a Black- downward, as relative to the vehicle’s orien-

Robotics@Maryland 5
tation. be estimated. This allows for more precise
The vision processing software is written maneuvering and odometry.
in C++ and makes use of the OpenCV im-
age processing library. The vision system is
split into a series of detectors, corresponding 6 Control
closely with the set of vision objectives: the
Tortuga III is designed to be extremely mo-
flare, path, barbed wire, bombing run, and
bile. Its sophisticated suite of sensors allows
the machine gun nest. All the vision detec-
it to locate objectives quickly and accurately.
tors utilize the CIELUV color space, which
Six SeaBotix SBT153 thrusters are positioned
provides improved color segmentation perfor-
such that the vehicle can translate or rotate
mance over traditional color spaces.
along any of its three axes simultaneously.
The orange-path detector uses color mask-
It can translate in any direction (up/down,
ing to locate the orange pixels of the image.
port/starboard, fore/aft), hold any orienta-
It then uses a custom blob detection method
tion, and even change orientation while trans-
to find the ends of the pipe with which it
lating. The thrusters are also equipped with
calculates the pipe’s orientation. The vehicle
integrated motor controllers and encoders. The
then hovers over the centroid of the pipe at
encoders allow control algorithms to directly
the desired orientation.
control the output force of the thrusters, which
The barbed wire detector works in a sim-
provides more precise movement and maneu-
ilar manner, except it filters for green instead
vering. This high level of maneuverability
of orange pixels. It then uses connected com-
also simplifies the task-specific control algo-
ponents analysis to separate the pixels into
rithms and provides excellent motion stabil-
groups. The centroids of the two largest pipe-
ity for vision and sonar sensors.
like pixel groups are used to determine the
Control software for Tortuga III is placed
barbed wire’s orientation relative to the vehi-
in two different locations in the onboard ve-
cle.
hicle code. Low level control, which handles
The flare and machine gun nest detec-
depth and rotation, exists in the compiled
tors also utilize the same type of blob detec-
C code and is maintained by a high priority
tion and color masking. They mask the image
thread that is called at 40 Hz. This ensures
for the applicable color, and then separate
that safety-critical code is run often enough
the pixels into connected groups. After that
to keep the vehicle stable. Low level control
the detectors return the relative position and
algorithms have direct authority over the on-
range of the objective based on the largest
board thrusters.
pixel group.
High level control which handles tasks such
The bombing run detector looks for a large
as flare seeking, path following, bin and brief-
black cluster contained within an appropriate
case hovering, and search pattern control is
white group. The clusters are found using
located in the python code. This code must
the same color masking and connected pixel
be executed by a lower priority thread as the
group algorithms described earlier. Once a
code often has to wait for sensors that cannot
target bin is found, a symbol detector runs
report measurements as often as 40 Hz (such
to identify the specific target image.
as cameras). High level control does not di-
Optical flow velocity detection has also
rectly communicate with actuators. Instead,
been implemented on Tortuga III . Optical
the high level control outputs are typically in
flow tracks the movement of pixels from frame
the form of desired states for the low level
to frame. Using this information, velocity can

Robotics@Maryland 6
controllers like a desired depth or a desired Unfortunately, preliminary testing with this
orientation. controller indicates a strong sensitivity to sen-
sor noise.
6.1 Depth control
6.3 Objectives
Since Tortuga III primarily holds a fixed depth,
the depth control is implemented as a reg- High level control algorithms utilize the low
ulator (as opposed to a tracking controller). level algorithms to make Tortuga III com-
The non-linearity stemming from a positively plete competition objectives. Flare seeking
buoyant vehicle can be treated as a constant is done by maintaining forward motion at a
disturbance. This allows the use of any linear desired depth while adjusting orientation to
controller as long as it is augmented with an point in the desired direction specified by the
integrator for constant disturbance rejection. vision system. Orange path following uses
Numerous depth controllers have been im- three independent proportional controllers run-
plemented on the vehicle. P, PI, PID, LQG, ning at the same time to simultaneously drive
and model based observer controllers [3] are the vehicle over the path segment and orient
currently implemented on Tortuga III . All the vehicle in the same direction as the path.
depth controllers are available to be selected Once properly aligned, the vehicle drives in
at runtime. Since the vehicle’s buoyancy and the direction of the path segment indicated.
trim characteristics are often altered for new The bombing run task uses the same algo-
actuators or adjustment of ballast, the ro- rithms as path following, but hovers over a
bustness of the control algorithms is as impor- target instead of the path. Once the vehi-
tant as controller performance. After com- cle is hovering over the correct bin, the depth
paring the various depth control algorithms controller dives the vehicle closer to the bin
on the vehicle, a PID implementation was to allow for a more accurate drop. Finally,
chosen. the briefcase hovering is broken up into sev-
eral simple tasks: approach the pinger using
6.2 Rotational control sonar to adjust desired orientation; hover over
the briefcase using the downward facing cam-
The rotational control algorithm is based off era; diving onto the briefcase, then surfacing
[4], a full three axis non-linear PD controller. using sonar.
The controller uses quaternions, making it As an addition to the tasks, the vehicle
singularity free (i.e. immune to ”gimbal lock” has been programmed with a SLAM (simul-
problems). Since the controller is a tracking taneous localization and mapping) algorithm.
controller, the vehicle can be commanded to Since there will be two active pingers at differ-
rotate in any direction by simply telling the ent frequencies at different locations, an ex-
controller to hold at a given desired orienta- tended Kalman filter (EKF) performs SLAM
tion or by specifying a desired angular rate by using an initial estimate of the pinger lo-
and integrating the desired orientation. A cations and vehicle position. The EKF then
more advanced rotational control algorithm uses successive pinger direction measurements
based off [5] has also been implemented. As (from the SONAR system) and a model of the
an adaptive controller, it can “learn” Tor- vehicle’s in plane dynamics to refine the ve-
tuga III ’s inertia, drag, and buoyant moment hicle and pinger position estimates over time.
properties online to provide a significant im- It is also planned to use vehicle translational
provement to the vehicle’s attitude control. velocity measurements using optical flow to

Robotics@Maryland 7
provide more data for the EKF.
7 Software
7.1 Overview
Tortuga III ’s software is written in Python,
C++, and C. It has been designed and de-
veloped with portability in mind and runs on
the GNU/ Linux, Mac, and Windows operat-
ing systems to allow the widest possible au-
dience. It is developed using subversion for
source control, Trac for issue tracking, and
SCons for the build system. The overall de-
velopment philosophy focuses on developing
a flexible system combined with software val-
idation through unit and simulation testing.
It is a medium-sized and maturing codebase
with roughly 102,000 source lines of code and
three years of development.
Core
Auxilary
Vehicle
Network
Control Vision
AI
Support
Event Scheduler Configuration
Figure 3: A Diagram of Tortuga III ’s soft-
ware subsystem
Tortuga III ’s software is divided into three
main sections. The core section contains the
subsystems which complete the mission and
AUV-specific tasks. The auxiliary section pro-
vides tools that enable faster development and 7.4 Auxiliary Subsystems
easier use of the software. The support sec-
tion provides the services needed for the other Main Tortuga III dive operations are done
two subsystems to function efficiently.
Robotics@Maryland
7.2 AI Subsystem
The AI subsystem is based on a concurrent,
event-based, finite state machine. It is coded
in Python using a custom state machine frame-
work. Python was chosen because the state
machines can be modified without having to
recompile the core software. The events it
is driven by originate from Tortuga III ’s sen-
sor subsystem. Its event-driven nature allows
for parallel state machines to run without the
need for multiple threads. For the 2009 com-
petition the state machines themselves have
been updated to handle errors caused by poor
vision data or vehicle control.
7.3 Support Subsystems
In order to reduce the coupling between soft-
ware components the support section provides
a publish-subscribe event system based on the
Boost.Signals library. It allows for messages
to be passed asynchronously and synchronously
between components, threads, and languages.
GUI
In order to facilitate easy post-dive debug-
Simulation ging and vehicle performance analysis, two
logging systems are used. The important data
feeds are logged with Log4cpp and another
system uses Boost.Serialization to write all
Logging
events generated during a dive to disk.
The configuration subsystem allows virtu-
ally every facet of Tortuga III ’s software to
be tweaked with a simple YAML based con-
figuration file. The configuration system is
used along with an inversion of control-based
start up sequence to allow for complete re-
configuration of the software without any re-
compilation.
through the use of a reconfigurable wxPython-
based GUI composed of panels for each soft-
ware subsystem. The layout of these panels
8
can be reconfigured by the user and is then and the Departments of Computer & Electri-
saved or loaded on demand. Individual panels cal Engineering, Aerospace Engineering, and
also reconfigure themselves based upon the Computer Science. Industry sponsors include
number and types of devices present on the Advanced Circuits, BAE Systems, Kato Ma-
vehicle. rine, Lockheed Martin, MEMSense, the NSF
The GUI also leverages the PyCrust Python ECCS division, Northrop Grumman, and Sub-
interpreter which allows the user to call func- Conn.
tions and methods on all objects in the sys-
tem while the vehicle software is executing.
This allows for a very deep interface to Tor-
References
tuga III ’s software without extensive user in- [1] M.D. Shuster and S.D. Oh. Three-axis attitude
terface development work. determination from vector observations. Journal
The GUI can also be run concurrently with of Guidance, Control, and Dynamics (ISSN 0731-
5090), 4(1):70–77, 1981.
the Robotics@Maryland Python Ogre-based
simulator. This simulates Tortuga III ’s hard- [2] K. C. Ho and Wenwei Xu. An accurate alge-
braic solution for moving source location using
ware, low level sensors, and the competition
TDOA and FDOA measurements. Signal Pro-
environment. With its ability to simulate the cessing, IEEE Transactions on [see also Acous-
output of the onboard cameras, the simula- tics, Speech, and Signal Processing, IEEE Trans-
tor enables integration testing of the vision actions on], 52(9):2453–2463, 2004.
system, control algorithms, and AI without [3] S. Skogestad and I. Postlethwaite. Multivari-
time-consuming physical dive operations. able feedback control: analysis and design. Wiley,
Chichester, 1996.
[4] B. Wie and P.M. Barba. Quaternion feedback
for spacecraft large angle maneuvers. Journal of
Guidance, Control, and Dynamics, 8(3):360–365,
1985.
[5] O. Egeland and J.M. Godhavn. Passivity-
based adaptive attitude control of a rigid space-
craft. IEEE Transactions on Automatic Control,
39(4):842–846, 1994.

Figure 4: GUI and Simulator

8 Acknowledgements
Robotics@Maryland would like to thank its
sponsors, without whom Tortuga III would
of never left the drawing board. Within the
University of Maryland are the Institute for
Systems Research, the Space Systems Labo-
ratory, the Student Government Association,

Robotics@Maryland 9