Development of an Autonomous Underwater Vehicle for

Sub-Ice Environmental Monitoring in Prudhoe Bay, Alaska

by
Charles Lee Frey

Bachelor of Science
Ocean Engineering
Florida Institute of Technology
1999

A thesis submitted to the

Florida Institute of Technology
In partial fulfillment of the requirements
for the degree of

Master of Science
in
Ocean Engineering

Melbourne, Florida
December, 2002
 © 2002 Charles Lee Frey
All Rights Reserved

The author grants permission to make single copies _______________________

 The undersigned committee hereby recommends that the attached document
be accepted as fulfilling in part the requirements for the degree of
Master of Science in Ocean Engineering

Development of an Autonomous Underwater Vehicle for

Sub-Ice Environmental Monitoring in Prudhoe Bay, Alaska

by
Charles Lee Frey

Andrew Zborowski, Ph.D.

Program Chair, Ocean Engineering

Stephen Wood, Ph.D., P.E.

Assistant Professor, Ocean Engineering

Eric Thosteson, Ph.D., P.E.

Assistant Professor, Ocean Engineering

Hector Gutierrez, Ph.D., P.E.

Assistant Professor, Mechanical Engineering
 Abstract

Development of an Autonomous Underwater Vehicle for

Sub-Ice Environmental Monitoring in Prudhoe Bay, Alaska

Author:
Charles Lee Frey

Advisor:
Stephen Wood, Ph.D., P.E.

Currently, research is underway at the Florida Institute of Technology, to

investigate the environmental impacts of oil development in the Prudhoe Bay

region of the Beaufort Sea, along Alaska’s northern coast. Of particular interest are

the impacts of construction of offshore gravel islands used for oil drilling and

production. Construction of these islands may contribute to increased suspended

sediment concentrations in the waters of Prudhoe Bay, which may have adverse

affects on the health of local marine ecosystems.

To aid in this research, a unique Autonomous Underwater Vehicle (AUV)

has been developed by the Underwater Technologies Laboratory (UTL) at Florida

Tech. The purpose of this AUV is to perform automated point-to-point data

collection missions underneath the thick winter ice sheet.

This paper discusses the design and construction of the AUV prototype,

known as “Tuvaaq”. Also included is a brief description of a small Remotely

Operated Vehicle (ROV) and Towed Instrument Array (Towfish) used in Alaska

during a summer field deployment.

iii
 First, the overall design concept for the AUV is discussed. Next, modeling

and simulation of the system is performed. Then, the design of the AUV’s various

subsystems is presented, including propulsion, navigation, environmental sensor

payload, CPU, power, and software. Finally, results of the simulation and

prototype development are presented.

iv
 Table of Contents

List of Keywords vii

List of Figures viii
List of Tables xi
List of Abbreviations xii
List of Symbols xiii
Acknowledgements xv
Dedication xvi

1. Introduction 1

1.1 The ANIMIDA Project 1

1.2 Scope of Work & Design Criteria 3

2. Phase I : ROV & Towfish Development 5

3. Phase II: AUV Development 9

3.1 Overall Design Concept 9

3.2 Modeling & Simulation 17

3.2.1 AUV Dynamics 18
3.2.2 Navigation System 22
3.2.3 Mission Planner 23
3.2.4 Low Level Controllers (Depth & Heading) 25
3.2.5 Simulation Results 30

3.3 Prototype Design & Construction – “Tuvaaq” 37

3.3.1 Mechanical Assembly 37
3.3.2 Propulsion 42
3.3.3 Navigation 54
3.3.4 Environmental Sensor Payload 71
3.3.5 Main Computer 74
3.3.5.1 Internal Communications 76
3.3.5.2 External Communications 77
3.3.6 Power 81
3.3.7 High-Level Software 84

4. Results & Conclusions 94

v
5. Recommended Future Work 96

References 99

Appendices 101

A. MATLAB Simulation Source Code 101

B. Mechanical Drawings 114
C. BLDC Motor Controller Board 123
(Schematics, PCB Layout, PIC Source Code)
D. SSBL Acoustic Navigator Board 139
(Schematics, PCB Layout, PIC Source Code)

vi
 List of Keywords

Acoustic Navigation
Alaska
ANIMIDA
Arctic
Autonomous Underwater Vehicle (AUV)
AUV Control
Beaufort Sea
Brushless DC (BLDC) Motor
Department of the Interior (DOI)
Department of Marine and Environmental Systems (DMES)
Dynamic Modeling
Florida Institute of Technology
LabVIEW®
MATLAB®
Mineral Management Service (MMS)
North Slope
PC/104
Prudhoe Bay
Simulation
Simulink®
Sliding-Mode Control
Super-Short Baseline (SSBL)
Tuvaaq
Under-Ice
Underwater Robotics
Underwater Technologies Laboratory (UTL)
Underwater Thruster
Underwater Vehicles

vii
 List of Figures

1.1.1 Map of the ANIMIDA study area 1

1.1.2 “Drilling for data” in Prudhoe Bay, near Northstar Island 2
2.1 Deploying the Hornet ROV in Prudhoe Bay, Summer 2001 6
2.2 Towfish deployment in Prudhoe Bay, Summer 2001 8
3.1.1 A typical AUV design, the Autosub-1 10
3.1.2 Flight path of torpedo-shaped AUV for a failed 12
“exit catch”
3.1.3 Deep Ocean Engineering’s nuclear inspection ROV “Firefly” 13
3.1.4 Prototype Prudhoe Class AUV design 14
3.1.5 Visual representation of AUV mission plan 16
® ®
3.2.1 MATLAB Simulink block diagram for AUV simulation 17
3.2.1.1 AUV body-fixed coordinate reference frame 19
3.2.3.1 AUV Mission Planner decision algorithm 24
3.2.4.1 PID depth controller block diagram 25
3.2.4.2 Sliding-Mode controller behavior in the error plane 27
3.2.4.3 Sliding-Mode heading controller block diagram 28
3.2.4.4 PID speed controller block diagram 29
3.2.5.1 AUV mission simulation - course plot 30
3.2.5.2 PID depth controller performance 31
3.2.5.3 Sliding-mode heading controller performance 32
3.2.5.4 PID speed controller performance 33
3.2.5.5 AUV course plot for moving beacon simulation 34
3.2.5.6 AUV depth plot for moving beacon simulation 35
3.3.1.1 Tuvaaq AUV mechanical assembly 38
3.3.1.2 AUV pressure vessel (1 of 4) 39
3.3.1.3 Underside of AUV, with PVC spacer plate shown 40

viii
3.3.1.4 Assembled AUV (acoustic transducer array not shown) 41
3.3.2.1 Typical Brushed DC motor construction 43
3.3.2.2 Typical Brushless DC motor construction 44
3.3.2.3 Motor fixture with coil, cable, and Hall-Effect sensors 46
3.3.2.4 Finished potted motor coil 47
3.3.2.5 Finished BLDC seal-less underwater thruster 48
3.3.2.6 Block diagram of BLDC Motor Controller circuit 49
3.3.2.7 Block diagram of BLDC Motor Controller PIC firmware 51
3.3.2.8 Final printed BLDC Motor Controller circuit board 52
3.3.2.9 Motor controller housing internals with 2-board stack 53
and cooling fans
3.3.2.10 Sealed motor controller housing 53
3.3.3.1 EZ-Compass 3 digital compass module 56
3.3.3.2 Propagation of hydroacoustic waves across a 57
straight-line transducer array
3.3.3.3 Propagation of hydroacoustic waves across a 59
triangular SSBL transducer array
3.3.3.4 ULB-350 Underwater Beacon 64
3.3.3.5 SX-38 38kHz omnidirectional transducer 65
3.3.3.6 SSBL transducer array mounted on test plate 66
3.3.3.7 Block diagram of SSBL Acoustic Navigator circuit 67
3.3.3.8 Block diagram of SSBL Acoustic Navigator PIC firmware 68
3.3.3.9 Final printed SSBL Acoustic Navigator circuit board 70
3.3.4.1 CTD & LSS instrument package 71
3.3.4.2 CTD sensor mounted on the AUV 73
3.3.5.1 AUV high-level system architecture block diagram 74
3.3.5.2 Main PC/104 CPU Board 75
3.3.5.3 PC/104 serial expansion module 77

ix
3.3.5.4 Linksys WUSB11 802.11b Wireless Ethernet Module 78
3.3.5.5 CPU housing internals with PC/104 stack 80
3.3.5.6: Sealed CPU Housing 80
3.3.6.1 Battery Pod internals with two SLA batteries 82
(parallel wiring)
3.3.6.2 Sealed Battery Pod (1 of 2) 82
3.3.6.3 PC/104 power supply board 83
3.3.7.1 The Tuvaaq AUV desktop, visible on a PC 85
running VNC Client
3.3.7.2 TUVAAQ software architecture block diagram 86
3.3.7.3 TUVVAQ main user interface panel 88
3.3.7.4 Configure Serial Devices panel 89
3.3.7.5 Offsets & Multipliers panel 90
3.3.7.6 Controller Gains panel 91
3.3.7.7 ROV Mode panel 92

x
 List of Tables

1.2.1 AUV design criteria 4

3.3.2.1 Motor controller specifications 49
3.3.4.1 AUV environmental sensor payload specifications 72

xi
 List of Abbreviations

ADCP Acoustic Doppler Current Profiler

ANIMIDA Arctic Nearshore Impact Monitoring in the Development Area
AUV Autonomous Underwater Vehicle
BLDC Brushless DC
CTD Conductivity, Temperature, Depth (sensor)
DGPS Differential GPS (Global Positioning System)
DMES Department of Marine & Environmental Systems (at Florida Tech)
DOE Deep Ocean Engineering
DOF Degree of Freedom
DOI Department of the Interior
DVL Doppler Velocity Log
LBL Long Base-Line
LSS Light Scattering Sensor (for measuring turbidity)
MMS Mineral Management Service
PCB Printed Circuit Board
PID Proportional, Integral, Derivative
PWM Pulse-Width Modulation
ROV Remotely Operated Vehicle
RTOS Real-Time Operating System
SLA Sealed Lead-Acid
SSBL Super Short Base-Line
USB Universal Serial Bus
USBL Ultra Short Base-Line
UTL Underwater Technologies Laboratory (part of the DMES)
VNC Virtual Network Computing
WLAN Wireless Local Area Network

xii
 List of Symbols

x Surge
y Sway
z Heave
φ Roll angle
θ Pitch angle
ψ Yaw angle (also magnetic bearing angle)
α Horizontal acoustic bearing angle (also acoustic absorption factor)
β Vertical acoustic bearing angle
T1 Thrust force from the port-side thruster
T2 Thrust force from the starboard-side thruster
T3 Thrust force from the vertical thruster
F(x,y,z) Force in the (x,y,z) direction
M(x,y,z,) Moment about the (x,y,z) axis
Fext(x,y,z,ψ) External disturbance force in the (x,y,z,ψ) direction
Fd (x,y,z) Linear hydrodynamic drag force in the (x,y,z) direction
Cd Coefficient of drag
ρ Density of seawater
Wauv Weight of the AUV in water
r Radius
Ap Projected drag area
V0 Velocity of drag surface
m Vehicle mass
I(x,y,z) Moment of inertia about the (x,y,z) axis
D Separation between horizontal thrusters
Kt Motor torque constant
K(p,i,d) Proportional, Integral, and Derivative gain constants

xiii
h(1,2) Sliding-Mode controller gain constants
H Altitude above seafloor
Z,d AUV depth
R Range to beacon
Ks Sliding-mode controller maximum signal output
e Error
t(1,2,3) SSBL Transducer detection times
TL(sph,cyl) Transmission loss from (spherical, cylindrical) spreading
∆… Difference in …

xiv
 Acknowledgements

My sincerest thanks to those who have helped me along the way…

Dr. Stephen Wood

Dr. John Trefry
Dr. Eric Thosteson
Dr. Hector Gutierrez
Dr. Pierre LaRochelle
Dr. Andrew Zborowski
Mineral Management Service
Department of the Interior
Florida Atlantic University
Harbor Branch Oceanographic Institution
Leslie Popp
Adam Kay
Larry Buist
Dan Simpson
John Lee
Bill Battin
Nagahiko Shinjo
Marc Damon
Carmen Serrano
Applied Microsystems, Inc.
Fumunda Marine, Inc.
Sensor, Inc.
Impulse, Inc.

Family & Friends…

xv
 Dedication

This work is dedicated to my parents, who have helped me in life

more than words can express.

To my Mother, for giving me the creativity and passion to pursue my dreams,

whatever they may be.

and…

To my Father, for giving me the intellect and work ethic to achieve them.

xvi
 1

1. Introduction:
1.1. The ANIMIDA Project

In the Prudhoe Bay region of the Alaskan Beaufort Sea, oil drilling and

exploration efforts are underway and expanding. Currently, the Mineral

Management Service (MMS), under the Department of the Interior (DOI), has been

tasked with the responsibility of studying the effects of offshore gravel-island based

oil development on the marine environment.

Dr. John Trefry, a professor of Oceanography at Florida Tech, is an active

participant in a large research effort in this region, known as the Arctic Nearshore

Impact Monitoring in the Development Area (ANIMIDA) Project.

As a part of this research effort, studies are being conducted on the currently-

operational Northstar Island, as well as another site slated for gravel-island

construction, known as the Liberty Prospect (see Fig. 1.1.1).

Figure 1.1.1: Map of the ANIMIDA Study Area

 2

One primary interest in this area is increase in suspended sediment

concentrations in Prudhoe Bay, due to gravel-island construction and erosion. Such

increases may have deleterious effects on marine plantlife, due to decreased light

transmission through the water column. To study this problem, conductivity,

temperature, depth, (CTD) and turbidity data are collected by Dr. Trefry and his

graduate students, using a series of field instruments.

During the summer months, these instruments can be deployed directly

from a small boat. However, to collect winter data, several holes must be drilled in

the ice, in order to perform sensor casts. This activity is shown below.

Fig. 1.1.2: “Drilling for data” in Prudhoe Bay, near Northstar Island
 3

This method is highly inefficient and time consuming. Furthermore, it

offers poor spatial resolution, confining data collection to a few discreet points over

the entire field of study. To automate and improve this process, Dr. Trefry

recruited the Underwater Technologies Laboratory (UTL) within the Florida Tech

Department of Marine and Environmental Systems (DMES), to help design and

construct equipment for use in under-ice data collection.

1.2 Scope of Work & Design Criteria

The scope of work for this thesis undertaking is split into two phases. Phase

I consists of the design and development of a small, low-cost Remotely Operated

Vehicle (ROV) and towed sensor array (Towfish) which were used during a data

collection trip in Prudhoe Bay in the summer of 2001. Although this work is not

the primary focus of this thesis, a brief description of these devices is presented in

section 2, for informational purposes.

Phase II involves the design and construction of an Autonomous

Underwater Vehicle (AUV), which is capable of performing point-to-point data

collection missions under the winter ice sheet that covers Prudhoe Bay. This phase

is the primary focus of this paper, and will be discussed in depth in the following

sections. The list below defines the scope of work that will be addressed in this

thesis.
 4

1. Overall vehicle concept and mission plan

2. Modeling and simulation
3. Prototype design and construction, including:
a. General mechanical assembly
b. Propulsion system
c. Navigation system
d. Environmental sensor payload
e. On-board computing and communications
f. Power system
g. High-level software design

Within this scope of work, the AUV has been designed specifically for use

in the Prudhoe Bay area, though its potential applications far exceed this single site.

The specifications listed in Table 1.2.1 have been used as a basis for design

decisions throughout this project.

Table 1.2.1: AUV Design Criteria

Autonomous Data Collection Parameters Salinity, Temp,

Depth, Turbidity
Autonomous Sub-Ice Navigation Yes
Autonomous Depth Following Yes
Minimum Operating Temperature (in water) -1.8 °C
Minimum Storage Temperature (in air) -20 °C
Maximum Water Current 0.05 m/s
Maximum Operating Depth 50 m
Maximum Speed 1 m/s
Maximum Entry / Exit Hole Diameter 0.6 m
Maximum Ice Thickness at Hole 2m
Maximum Distance Between Entry/Exit Holes 500 m
Maximum Number of crew required 2 persons
 5

2. Phase I: ROV & Towfish Development

As mentioned before, the first phase of the project was to design and build a

small ROV and Towfish. These devices were to be used during an ANIMIDA

sampling trip in Prudhoe Bay in the Summer of 2001, after the spring ice break-up.

Since the purpose of this thesis is the development of an AUV, the details of the

design and construction of the ROV and Towfish will not be presented here.

However, a brief discussion will be provided for background purposes.

The development of the ROV, nicknamed “The Hornet”, was a re-design of

a previous Florida Tech project, the “Stella” ROV. The goal was to quickly create

a small, low-cost ROV for capturing video of the kelp beds in the Boulder-Patch

area near the Liberty Island construction site (Liberty Prospect - See Fig. 1.1.1).

Future uses of the ROV may also include location and recovery of the AUV in the

case of a mission failure or bottom collision. A picture of the Hornet ROV is

shown below in figure 2.1.

 6

Figure 2.1: Deploying The Hornet ROV in Prudhoe Bay, Summer 2001

The Hornet consists of two horizontal thrusters, one vertical thruster, a color

CCD camera, and halogen dive-light, mounted to a tubular PVC frame. The video

signal and control voltages for the brushed DC thrusters are fed through an

umbilical via shielded twisted copper wire pairs (STPs). The topside controller

features reversible Pulse-Width Modulated (PWM) speed controllers for each

thruster and a line-out video feed to a small monitor. The ROV is powered from a

24VDC, 10-AMP power supply supplied with 110 VAC from the ship’s inverter.

This low-cost ROV served mainly as a controllable underwater video camera for

documenting the boulder-patch, but continues to be developed at the UTL.

The second item developed for this expedition was a Towfish, intended to

house the Aanderaa 3231 CTD and 3712 Infrared Light-Scattering Turbidity
 7

sensors, used in previous ANIMIDA sampling trips. The goal was to be able to

collect horizontal constant-depth data profiles in open-water during the summer,

with the same equipment used for vertical casts in both the winter and summer

months.

The Towfish consists of a torpedo-shaped PVC housing, based on a scaled-

down version of the JW Fishers Proton 1 Marine Magnetometer. The sensors are

mounted inside the hull, and connected to power and serial communications via a

tether borrowed from the UTL’s Proton 1. Data is sampled topside using the

Aanderaa Reader, which scans the sensors via a proprietary serial format. The

reader then converts the data to a standard ASCII text string, transmitted over an

RS-232 serial line. This serial line is then connected to a Microsoft® Windows-

based PC via an RS-232 serial port. The data is viewed and stored in a text file

using the Hilgraeve HyperTerminal communications program.

 8

Figure 2.2: Towfish Deployment in Prudhoe Bay, Summer 2001

Overall, both the ROV and Towfish performed well during the ANIMIDA data

sampling expedition in the Summer of 2001. Over a dozen casts and tows were

made with the towfish, and the data collected is being used in future publications

by Dr. Trefry. The ROV was deployed four times, and collected video of the kelp

beds in the Boulder Patch area on three of these deployments. On the fourth

deployment, the ROV was sent underneath floating sea-ice fragments, to collect

video of the shape and texture of the submerged portion of the ice.
 9

3. Phase II: Prudhoe Class AUV Development

3.1: Overall Design Concept

Early-on, it was realized that the most difficult problems to overcome in the

development of this AUV would be navigation, control, and launch & recovery.

The navigational problem presents itself in several forms. First, the use of

Differential GPS is unavailable due to the fact that the vehicle is operating both

underwater and under ice, preventing even periodic surfacing for GPS position

fixes. A reliable DGPS signal simply cannot be assured under these conditions.

Secondly, inertial navigation systems progressively accumulate error due to

approximations in integration and limitations in sensor resolution. Therefore,

navigating to a 1m-diameter target, over a 500m mission would be extremely

difficult for even the most advanced inertial navigation system. Only with periodic

absolute position fixes (i.e. GPS or Acoustic) and fast Kalman Filtering to bound

the accumulated error, could this be achieved [6]. Based on the timeframe and

budget for this project, such a system is well beyond the scope of a single Master’s

Thesis.

Thirdly, although dead-reckoning with a digital compass is a necessary

ingredient in any AUV, the accuracy of such a system is extremely poor and should

only be used when precise navigation is not important (i.e. when following

compass headings in open water), or as a last-resort navigation system when others

have failed.
 10

These design restrictions therefore necessitated the development of a more

accurate, yet simple, acoustic homing system. This system, discussed further in

section 3.3.3, allows the vehicle to navigate with respect to a fixed acoustic beacon,

located at the vehicle’s intended exit hole.

Now that the navigational problem had been addressed, it was time to

examine the control, launch, and recovery issues, which are intimately tied

together. Typically, modern AUVs are designed with a torpedo-shaped form,

providing the advantages of low hydrodynamic drag, ease of maneuverability over

long distances, and low power consumption.

Figure 3.1.1: A typical AUV design, the Autosub-1

(from: www.soc.soton.ac.uk/OTD/asub/cotdasub.html)

While this basic design offers some payoffs in open water survey and data

collection missions, it lacks the precise positioning and stationkeeping abilities of a

 11

multi-thruster work-class ROV design. Due to the nature of the deployment

environment for this project, it was determined that such maneuvering and control

characteristics were of utmost importance. This is mainly due to the fact that the

vehicle must be able to be launched and recovered through a 2ft.-diameter hole, in a

6ft-thick sheet of ice, and may have to navigate around random, closely-spaced ice-

spikes (although collision avoidance is beyond the scope of this thesis). This

requires the ability to precisely position the vehicle at low speeds underneath the

exit hole, assuming that the position of that hole is accurately known by the

navigation system.

Such fine control and stationkeeping tasks are virtually impossible for a

conventional torpedo-shaped vehicle, steered by control surfaces such as rudders

and dive planes, as the turning radii for such systems are usually very large and

constant forward motion is required in order to generate lift on the control surfaces.

Since the positioning tolerance for recovery of the Prudhoe Class AUV is so tight,

failing to “catch” a torpedo-shaped vehicle during its first pass to exit would mean

a complete wide turn-around in a decreasing spiral path (see Fig. 3.1.2), rather than

a simple small position correction. Additionally, the horizontal flight

characteristics of a torpedo-shaped vehicle further complicate the recovery effort,

as the vehicle must be turned vertical before it can be lifted from the exit hole.
 12

Figure 3.1.2: Flight path of torpedo-shaped AUV for a failed “exit catch”

Failed exit, vehicle enters

turnaround maneuver

Beacon

Approach path

It was also determined that the benefits of low hydrodynamic were of little

consequence since this particular AUV would be moving at such low speeds (< 1

m/s).

The result of these design restrictions lead to a rather unconventional

vehicle shape, intended to simplify control strategies, enhance maneuverability, and

ease the launch and recovery effort (see Fig. 3.4). This shape was based on the

design of a series of nuclear-inspection ROVs manufactured by Deep Ocean

Engineering (DOE, www.deepocean.com) and will be discussed in more detail in

section 3.3.1. The DOE ROVs work at slow speeds in tubular environments and

what they lack in hydrodynamics, they make up for in maneuverability,

stationkeeping, and ease of control.

 13

Fig. 3.1.3: Deep Ocean Engineering’s Nuclear Inspection ROV “Firefly”

(from: www.deepocean.com)
 14

Figure 3.1.4: Prototype Prudhoe Class AUV Design

SSBL Transducer

Syntactic Foam

Thruster Tunnel

Pressure Housing
(2 for electronics)
(2 for batteries)

Connector Rod

Spacer Plate

Protection Cage

Taking all of these design issues into account, the Prudhoe Class AUV mission

concept can be outlined as follows (a visual representation of this plan is shown in

Fig. 3.1.5):

1. Drill a single 2ft. diameter entry hole and one or more exit holes in the

ice sheet at the data collection site.

2. Deploy a simple acoustic beacon (a marking pinger) in the desired exit

hole, approximately 1ft. below the bottom of the ice (7ft. water depth).
 15

3. Deploy the AUV into the entry hole using a simple hand-operated rope

winch. The mission is in a standby mode, and begins when the vehicle

senses 1ft. of water depth.

4. The AUV executes its mission by homing-in on the beacon and

navigating simple paths with respect to the beacon, a digital compass,

and depth sensor. Data from the on-board CTD & Turbidity sensors is

logged along the way, as the vehicle heads for the homing beacon,

which is also at its intended exit hole.

5. Once at the exit hole, the vehicle ascends, positioning itself slightly to

remain underneath the hole.

6. The vehicle is retrieved with the use of a simple hook and rope and

concludes its mission once it senses less than 1” of water depth (i.e. it

has been extracted from the water).

7. These point-to point missions can be repeated as necessary to map the

whole field of interest.

 16

Figure 3.1.5: Visual representation of AUV mission plan

 17

3.2 Modeling & Simulation

Upon completing the preliminary design, a MATLAB® Simulink simulation

(Fig. 3.2.1) was created to model plant dynamics, refine controller designs, and

examine the feasibility of the overall design through execution of test missions.

The source code for this simulation can be found in Appendix D.

Figure 3.2.1: MATLAB ® Simulink Block Diagram for AUV Simulation

 18

3.2.1 AUV Dynamics

The first step in developing an accurate simulation is modeling the dynamic

equations of the AUV. In this case, a body-fixed coordinate reference frame will

be used which is described by the following six degrees-of freedom (DOFs) and

their respective derivatives:

x (surge) – linear motion with respect to the longitudinal axis

y (sway) – linear motion with respect to the transverse axis
z (heave) – linear motion with respect to the vertical axis
φ (roll) – rotational motion about the X-axis
θ (pitch) – rotational motion about the Y-axis
ψ (yaw) – rotational motion about the Z-axis

Inputs to the system are defined as follows:

T1 – Thrust force from the port-side thruster

T2 – Thrust force from the starboard-side thruster
T3 – Thrust force from the vertical thruster
Fext(x,y,z,ψ) – External disturbance forces (water currents, etc)
Fd (x,y,z) – linear hydrodynamic drag forces due to vehicle motion
defined by the equation (see [1]):
2
V
Fd = Cd * ρ * A p * 0 (3.2.1)
2
…where:
Cd = coefficient of drag
ρ = density of seawater
Ap = projected drag area
V0 = velocity of drag surface

(*Note: rotational skin friction is considered nominal)

 19

Other relevant parameters:

m – vehicle mass (approx. 200lbs = 6.2 slugs)

D – separation between horizontal thrusters T1 & T2 (11” = 0.91667ft.)
Wauv – weight of the vehicle in water (assume neutral buoyancy, = 0)
Iz – moment of inertia about the (vertical) z-axis (6.009 slug·in4 )

Figure 3.2.1.1: AUV Body-Fixed Coordinate Reference Frame

φ
x

Before beginning derivation of the equations of motion, it should be noted

that y, φ, & θ are all uncontrollable DOFs, based on our thruster configuration.

Furthermore, φ, & θ are of no concern due to their linear, decoupled nature. This

is in fact one of the primary advantages of this design, in that roll and pitch can be

removed from the equations of motion. This of course assumes that T1 , T2 , and T3
 20

act at the vehicle’s centroid. In fact this is not the case. However, due to a heavy

keel weight, coupled with a large buoyancy module, and large separation between

the vehicle’s center of buoyancy (Cb) and center of gravity (Cg), we can assume

that the vehicle will possess a high righting moment (GZ), allowing it to remain

sufficiently stable in roll & pitch, so as to incur nominal disturbances in the other

vehicle DOFs. Therefore, we need only be concerned with the 4 DOFs required to

position the vehicle in space: x,y,z,ψ … three of which are controllable: x,z,ψ.

As shown in [8], the dynamic equations of motion can be derived in the

following manner:

Taking the sum of forces in the X, Y, and Z-directions, and solving for acceleration

yields:

(T1 + T2 ) + Fdx + Fx ext

&x& = + y& ψ& (3.2.2)
m

Fdy + Fy ext
&y& = + x& ψ& (3.2.3)
m

T3 + Fdz − Wauv + Fz ext

&z& = (3.2.4)
m

… where:

Fd(x,y,z) are defined by Eqn. 3.2.1

Fxext = Fyext = Fzext = 0 (assume no external currents or disturbances)

 21

Taking the sum of moments about the Z-axis yields:

(T2 − T1 ) D  + M z ext

2
ψ&& = (3.2.5)
Iz

…where:

Mz ext = 0 (assume no external disturbances about the Z-axis)

For the purposes of the simulation, these equations of motion yield eight

state variables and three independently controllable system inputs:

 x1   x 
x   y 
 2  
x3   z  T1 + T2 
     Fx  
ψ   D 
X =  4 =    
x
u =  M z  =  (T2 − T1 )   (3.2.6)
 x5   x&   2 
     Fz  
 x6   y&   T3 
 x   z& 
 7  
 x8  ψ& 

… where u is a function of T1 , T2 , and T3 , the inputs to the plant model from the

three thruster controllers.

These equations of motion were then implemented in an S-Function block

in the Simulink model, “auv_plant”.

 22

3.2.2: Navigation System

Two blocks in the Simulink model comprise the navigation system. The

“coord_xform” block transforms body-fixed state outputs from the plant model

onto a geographical reference frame. In the horizontal plane, the following

transformation matrix is used:

Cosψ − Sinψ 
X BG = 
Cosψ 
(3.2.7)
 Sin ψ

Whereas, in the vertical plane, coordinate reference frames can be directly

superimposed upon one another.

The “nav_system” block simulates the navigation system by resolving the

position of the vehicle with respect to the location of the acoustic beacon (set by the

user). Navigational “noise” can also be added to simulate errors in calculation of

the bearing to the beacon. From this block, the following simulated system states

are output to the mission planner and controller modules:

 x1   α 
 x  ψ 
 2  
X nav =  x3  =  R  (3.2.8)
   
x4   Z 
 x5   H 
 23

… where:

α = bearing angle to beacon (from acoustic navigation system)

ψ = magnetic bearing of vehicle (from digital compass)
R = range to beacon (from acoustic navigation system)
Z = depth (from depth sensor in CTD)
H = altitude (from altimeter)

3.2.3: Mission Planner

The mission planner block is the high-level decision maker on-board the

AUV. It monitors all system states and issues commands to the low-level thruster

controllers. In the case of this simulation, the mission planner observes the states

in Xnav, as well as flags from simulated emergency events, such as collision

avoidance system commands and leak detection. Mainly, the mission planner

decides how fast to go, what depth to descend to, what heading to follow, etc.

During simulation trials, the mission planner was set to command the vehicle to go

directly to the beacon (α = 0), dive to two different depths depending on the range

to the beacon, and when close to the beacon, surface and slow down. The mission

planner also issues a flag, which stops the simulation when the vehicle is within 1ft

of the beacon, and at 1ft. depth (below the ice), which is assumed to be within

sufficient capture range of the exit hole.

 24

Figure 3.2.3.1: AUV Mission Planner decision algorithm

Mission START
File Load
MISSION

Ascend to
Surface
Vehicle In
No Standby
Water Column?

No
Yes

Vehicle Out of
Descend to Water Column?
Mission Depth 1

Yes

Listen for No
Beacon STOP
MISSION
Yes

Beacon No
Timeout
Acquired? Expired?

Yes Yes

Abort Mission
No Proceed with (Return to
Mission Origin)

Reached
Target?
 25

3.2.4: Low-Level Controllers

The low-level controller set consists of three controllers, depth, speed and

heading, which are dedicated to receiving commands from the mission planner and

generating thruster outputs based on error between commanded and actual depth

and heading.

The simplest of the three, the depth controller, receives depth commands

from the mission planner, vehicle depth (z) from the navigation system, and issues

a thruster output (T3 ). From equation (3), it can be seen that the relationship

between depth and thrust T3 is simple and linear. Therefore, it was decided that a

conventional Proportional-Integral-Derivative (PID) controller with negative unity

feedback would be more than sufficient (see [3]).

Figure 3.2.4.1: PID depth controller block diagram

INPUT CONTROLLER PLANT OUTPUT

Zdesired e T3 Zactual
K p e + K i ∫ e + K d e& AUV Model

…where:

Zdesired = depth command from mission planner

e = depth error
T3 = vertical thruster output
Kp = proportional gain
 26

Ki = integral gain
Kd = derivative gain

The speed and heading controllers are a bit more complex, due to their non-

linear, coupled nature. As a result, the two tasks have been combined into a single

hybrid switching controller which functions as both a heading-correction controller

when heading error is present and a PID speed controller when the vehicle is on-

course.

Heading correction is achieved by a sliding-mode controller (see [11]),

which is activated if heading error exceeds the limits of the sliding boundary layer

(+/- 3 degrees). A sliding-mode controller works by driving error (e) and error rate

( e& ) to zero, along a “sliding-function” defined by the line:

s = hT e (3.2.9)

… where:

h = a two-dimensional vector of controller gains (changes slope of sliding line)

e = a two-dimensional vector containing error & error rate
 27

Figure 3.2.4.2: Sliding-Mode controller behavior in the error plane

e&

Sliding Trajectory

Boundary Layer

Sliding Line

As can be seen from the Fig. 3.2.4.2, when e and e& fall outside the sliding

line, the controller moves back towards this line by making the control signal

maximally positive (“reaching”). This allows the controller to compensate for

unknown system nonlinearities, by forcing the system into a range where it

becomes linear and can begin “sliding” towards the origin (along the sliding line).

This is especially useful if little or nothing is known about the non-linear aspects of

the system model. Once on the line, the controller continues to reduce e and e& ,

behaving like a linear P-D controller.

Additionally, as shown in Fig. 3.2.4.2, a boundary layer can be added to

reduce chattering, by “thickening” the sliding line. In the case of our hybrid
 28

controller, the sliding-mode heading controller disengages inside of the +/- 3

degree boundary layer, allowing the PID speed controller to take-over and move

the vehicle forward, based on commands from the mission planner. Thus, heading

control is only initiated when the vehicle is off-course. These two controllers are

shown below in Figs. 3.2.4.3 and 3.2.4.4.

Figure 3.2.4.3: Sliding-Mode heading controller block diagram

INPUT CONTROLLER PLANT OUTPUT

T1 , T2
ψ desired e ψ out
K s * sgn (h1e + h2e& ) AUV Model

… where:

ψ desired = heading command from mission planner

Ks = +/- bounds on controller output (thruster limits)
h1 = error gain
h2 = error rate gain
T1 & T2 = horizontal thruster outputs

Note that the sliding mode controller in Fig. 3.2.4.3 contains no estimate of non-

linear dynamics in the system, and therefore behaves like a bang-bang controller,

which settles as it drives error (e) and error rate ( e& ) to zero (see [8]).
 29

Figure 3.2.4.4: PID speed controller block diagram

INPUT CONTROLLER PLANT OUTPUT

e
X& desired T1 ,T2 X& actual
K p e + K i ∫ e + K d e& AUV Model

…where:

X& desired = speed command from mission planner

e = speed error
T1 , T2 = horizontal thruster outputs
Kp = proportional gain
Ki = integral gain
Kd = derivative gain

It should be noted that since determination of vehicle speed is based on the

rate of change in range (R) to the acoustic beacon, the vehicle’s speed cannot

always be determined accurately, and cannot be determined at all in dead-reckoning

mode. In this case, the PID speed controller is “bypassed” by feeding it a desired

thrust instead of a desired speed. In this mode, there is no settling time and no need

for a feedback loop, as vehicle speed is assumed to be linearly proportional to the

combined commanded thrust of the two horizontal motors (T1 & T2 ).

 30

3.2.5: Simulation Results

The simulation was run many times, changing the location of the beacon,

adjusting controller gains, etc. Figure 3.2.5.1 shows an overhead view of the

vehicle moving from its starting location (0,0) to the beacon, located approximately

140ft (43m) away.

Figure 3.2.5.1: AUV Mission Simulation – Course Plot

In this simulation, the vehicle adequately navigates to its target location. During

this mission, the vehicle was commanded to descend to two different depths, 20 ft.
 31

and 15 ft, respectively, and then surface to 1ft. when within 10 ft. of the target. The

PID depth controller performed exceptionally well as a P-D controller with Kp =

10, Ki = 0, & Kd = 5. As can be seen in Fig. 3.2.5.2, overshoot was minimal, rise

& setting times are relatively short, and there is virtually zero steady-state error.

Figure 3.2.5.2: PID Depth Controller Performance

Although the hybrid heading/speed controller was able to get the vehicle to its

target, it showed poor settling time, and caused the vehicle to oscillate fairly

significantly at first (+/- 45º), eventually smoothing out to a low +/- 5º.
 32

Figure 3.2.5.3: Sliding-Mode Heading Controller Performance

Additionally, the PID speed controller had difficulty maintaining speed, because it

was constantly being switched-off in favor of heading correction. Despite this, it

continued to move forward at an acceptable rate. Again, speed is not a priority for

this AUV.
 33

Fig. 3.2.5.4: PID Speed Controller Performance

As a test for robustness, the simulation was re-run, and the location of the beacon

was moved during the simulation to see if the vehicle could easily “chase” the

beacon, making turn-around maneuvers without any problems or instabilities. The

tests were successful, and the resulting course and depth plots are shown below.
 34

Figure 3.2.5.5: AUV Course plot for moving beacon simulation

 35

Figure 3.2.5.6: AUV Depth plot for moving beacon simulation

Vehicle ascends and descends in

response to beacon movement

It should be noted that the performance of the depth controller was unaffected.

Since the range of the vehicle to the beacon changed as it was moved around, the

mission planner changed its depth command to the controller, resulting in the

ascent/descent spike in the depth profile.

Overall, the simulation proved successful, and shows the ability of the

vehicle to adequately navigate to its intended target. The depth controller

performed excellently, and as a result of the simulation, was implemented on the

AUV. The hybrid sliding-mode/PID heading controller also performed well, and
 36

was implemented on the prototype. However, a re-design of this controller in the

future may be beneficial to reduce chattering and increase robustness. Currently,

the sliding-mode controller alters heading by reversing the thrusters to rotate the

AUV. In the case of large heading errors this is acceptable, in order to make quick

corrections. However, for small heading corrections, a simple imbalance in thrust

between T1 and T2 should provide smoother control, with far less chattering and

loss in forward momentum.

 37

3.3 Prototype Design & Construction – “Tuvaaq”

After evaluating the performance of the preliminary design through use of

the MATLAB® simulation, work on production of a prototype vehicle began. The

first in the “Prudhoe Class” of AUVs at Florida Tech, the vehicle has been dubbed

“Tuvaaq”, an Inupiat Eskimo word meaning “hunter”, based on its characteristic

“beacon hunting” behavior. The following sections discuss in detail all of the

subsystems developed for the Tuvaaq AUV.

3.3.1: Mechanical Layout

As stated previously, the mechanical design of the Tuvaaq AUV is based on

research into ROVs used in tight-quarter working environments, such as Deep

Ocean Engineering’s “Firefly” (www.deepocean.com). The basic layout of the

vehicle is shown in Figs. 3.1.4 & 3.3.1.1, and consists of four vertically-mounted

pressure vessels (two for electronics, two for batteries), two parallel horizontal

thrusters, one vertical thruster, externally mounted CTD, turbidity sensor, and

acoustic transducers, and upper & lower protection cages. Detailed drawings can

be found in Appendix A.
 38

Figure 3.3.1.1: Tuvaaq AUV Mechanical Assembly

This design allows the vehicle to fit vertically into a 2ft. diameter hole, simplifying

launch and recovery through the thick ice on the Beaufort Sea. Also, the use and

placement of the thrusters simplifies control by decoupling vehicle motions in the

vertical and horizontal planes and allowing small position corrections at low speed.

This low speed positioning, plus the advantage of being able to make a complete

360° turn within its own body diameter, makes the vehicle extremely maneuverable

in tight quarters and gives it stationkeeping ability.

The vertical separation of the buoyancy foam and ballast weight (batteries

and additional lead keel weights) enhance roll and pitch stability, allowing the
 39

vehicle to move in an upright position. The upper protection cage also serves as a

recovery target, which can be “hooked” in order to catch the vehicle and lift it out

of the exit hole.

Each pressure vessel consists of a 15”-long, 6” diameter 6061-T6 aluminum

pipe with a welded flat endplate. This sizing was chosen to accommodate the

PC/104 electronics stacks and batteries discussed in later sections, with ample room

for future electronics add-ons. The open end of each housing is then sealed with a

single face-seal o-ring, which is embedded in a flat connector plate. The connector

plate is mated to the sealing flange on the housing by six stainless-steel cap bolts.

The housings have been black anodized for corrosion protection and aesthetics.

Figure 3.3.1.2: AUV pressure vessel (1 of 4)

 40

The pressure vessels are held in place by three Type-I PVC spacer plates,

which also contain a center hole for a flow tube, used to maintain output from the

vertical thruster. The CTD is mounted between the second and third spacer plates.

Figure 3.3.1.3: Underside of AUV, with PVC spacer plate shown

The thruster assembly consists of three thrusters mounted into a syntactic

foam buoyancy module. The entire vehicle is held together by 4 pieces of

threaded-rod, which compress the housings, thruster/buoyancy module, acoustic

transducer array, environmental sensors, and protection cages together into a single

unit, shown below.

 41

Figure 3.3.1.4: Assembled AUV (acoustic transducer array not shown)

 42

3.3.2: Propulsion

The propulsion system for the Tuvaaq AUV is based around two parallel

horizontal thrusters and one vertical thruster. As shown in section 3.2, this

arrangement simplifies control of the vehicle by decoupling motions in the

horizontal and vertical planes. Furthermore, fine control and maneuverability at

low speeds is possible because the thrusters, unlike fin-shaped control surfaces,

require no forward motion to generate turning moment. This allows the vehicle to

hold position underneath the exit hole, making small position corrections as it

attempts to move as close as possible to the acoustic beacon.

Early on, it was recognized that one major problem in the design of

underwater thrusters, especially in cold environments is the presence of rotary shaft

seals which often leak and can put significant frictional drag on the motor drive

shaft, causing excess power consumption and accelerated seal wear. Unfortunately,

conventional brushed-DC motors must be kept dry since their commutation is

mechanical and requires open-air electrical contacts.

 43

Figure 3.3.2.1: Typical brushed-DC motor construction

In contrast, brushless-DC (BLDC) motors achieve their commutation

through electronics, which charge the appropriate coil at the appropriate time in the

rotation cycle, thus creating the necessary rotating magnetic field. Furthermore,

since most BLDC motors utilize a permanent-magnet rotor, coupling between the

rotor and stator is strictly magnetic, with no open-air electrical contacts (brushes).
 44

Figure 3.3.2.2: Typical Brushless-DC Motor construction

The advantage of this inductive coupling is that it allows the outer motor coils

(stator) to be coated completely in epoxy without affecting the performance of the

motor. It was hoped that potting such a motor would negate the need for shaft

seals, allowing the motor to run completely submerged, with water flowing through

it. This technique is frequently used with AC motors in commercially available

aquarium pumps and sump pumps, with much success. The goal was to duplicate

these results using a BLDC motor.

First, a commutation method had to be selected. Since BLDC motors

require electronic commutation, the position of the rotor must be known so that the

commutator can energize each coil with the proper polarity at the proper time.
 45

Several different commutation methods were examined. Initially, sensorless

commutation was pursued, to avoid the need for extra conductors in the motor

connectors and eliminate the need for potting the sensors with the motor coil

assembly. This sensorless commutation technique uses back-EMF generated on the

non-energized coil in a 3-phase motor to determine rotor position (see [2]).

Unfortunately, after prototyping many designs, it was found that sensorless

commutation performed poorly at low-RPM and could not adequately handle the

fast direction switching, required by the AUV’s thrusters.

Finally, it was decided that the hall-effect commutation method would be

used. This widely used commutation scheme involves three small hall-effect

sensors, which act as magnetically-driven TTL transistor switches. This method is

proven and reliable, and can function at very low RPM (see [2]).

After some searching, the Elcom ST N2312 motor was selected from the

Pittman Motor Company (see Appendix F). This motor was selected based on its

size, construction (for ease of potting), coil-type (3-phase wye-wound), low speed,

operating voltage, and high torque constant (K t =5.30). A high Kt is desirable to

maximize torque output, while minimizing power consumption.

Once the motor was chosen, it was disassembled, and a fixture was made

for epoxy-coating the stator and hall-effect sensors. The fixture was then coated

with a synthetic mold release compound, “HMP 4-18B”, from Fluid Polymers, Inc.,

and the coil/cable/sensor assembly placed inside. The fixture, with coil, cable, and
 46

hall-effect sensors was then potted using “HMP85-1 Black Slow” 2-part epoxy,

also from Fluid Polymers, Inc. This epoxy was chosen for its workability,

moderately high durometer (hardness), and color. Information on these substances

can be found in Appendix F. During initial cure, each motor was run through

approximately 5-10 vacuum cycles to remove air bubbles and fill any small voids

in the assembly.

Figure 3.3.2.3: Motor fixture with coil, cable, and hall-effect sensors

After the epoxy had fully cured and cross-linked (approx. 48 hours), it was

removed from the fixture and faced on an end-mill to ensure a perfectly toroidal

shape.
 47

Figure 3.3.2.4: Finished potted motor coil

To complete the final motor assembly, the original steel ball-bearings were

replaced with nylon/glass-ball bearings, and endplates were machined from

UHMW Polyethylene plate. These pieces, coupled with a factory epoxy-coated

rotor magnet and stainless-steel drive shaft, offer corrosion resistance and the added

advantage of water lubrication. The final motor assembly was then outfitted with a

mounting bracket and 6”diameter trolling propeller.

 48

Figure 3.3.2.5: Finished BLDC seal-less underwater thruster

To drive the thrusters, a computer-interfaceable motor controller was

needed. Since a suitable motor controller was not commercially available, it was

designed by the author and Larry Buist, at the Technical Support Lab in the College

of Engineering. The motor controller was designed to support two motors per

board and allow control from a host PC via a standard RS-232 serial port.

The controller board was based around the Motorola MC33035 BLDC

Commutator IC, which provides hall-effect commutation, direction control, and on-

board Pulse-Width Modulated (PWM) speed control (see [2]). The interface

between this IC and the host PC is a PIC16F876 Microcontroller, programmed in C

 49

with the Hi-Tech® ANSI C Compiler and MPLAB Software. A block diagram of

the motor controller circuit is shown below. Detailed schematics can be found in

Appendix B.

Figure 3.3.2.6: Block Diagram of BLDC Motor Controller Circuit

Table 3.3.2.1: Motor Controller Specifications

Motor Drive Type 3-Phase BLDC Wye-wound

Commutation Hall-effect
# of Motors per board 2
Reversing Yes
Motor Voltage Range 12-24 VDC
Maximum Motor Current 20 AMPS (per motor)
Velocity Feedback Yes, PID loop
Communications RS-232 Serial @ 9600,8,1,N
Circuit supply 12 VDC @ 200mA
 50

The PIC microcontroller receives commands via the RS-232 serial port in

the form of ASCII text strings with the following syntax:

1. Motor speed & direction command: “<spdA,dirA,spdB,dirB>”

… where spdA & spdB are speed commands ranging from 0-255 (0-

100% PWM Duty Cycle), and dirA & dirB are direction commands,

either 1 (fwd) or 0 (rev).

2. Request motor status information: “?”

Upon receipt of the “?” character, the PIC replies with a text string

containing current motor speeds and directions, in the form

“[spdA,dirA,spdB,dirB]”.

3. Request firmware version information: “v”

Upon receipt of the “v” character, the PIC replies with a text string

containing the firmware version and date. (e.g. “BLDC v1.2.0 –

10/29/2002”)

A block diagram of the PIC Microcontroller firmware program is shown below in

Fig. 3.3.2.7. Full C source code is contained in Appendix B.

 51

Figure 3.3.2.7: PIC BLDC Motor Controller Firmware Block Diagram

The final board design was manufactured into a printed circuit board (PCB) using

ExpressPCB (www.expresspcb.com). These boards were sized to fit the PC/104-

Plus form factor. In the motor controller housing, two boards were used, one for the
 52

horizontal thrusters, and one for the vertical thruster and one redundant spare.

Board layout diagrams are contained in Appendix B.

Figure 3.3.2.8: Final Printed Motor Controller Circuit Board

 53

Figure 3.3.2.9: Motor Controller Housing Internals

Figure 3.3.2.10: Sealed Motor Controller Housing

 54

3.3.3 Navigation

As stated earlier, there are many inherent problems in sub-ice autonomous

navigation. Given the nature of the AUV mission plan and operating environment,

several navigation systems were considered and eliminated.

Most AUV navigation breaks down into five major categories: GPS,

inertial, visual, acoustic and dead reckoning. As stated previously, GPS was not an

option for the Tuvaaq AUV because of its sub-ice operation.

Inertial navigation involves the use of three orthogonally-mounted

accelerometers and three corresponding gyros. This allows the system to measure

linear and rotational accelerations in 3-dimessions, thereby characterizing vehicle

motion in all 6-DOF (see [6]). However, as stated previously, integration of these

accelerations to determine velocity and displacement over time results in

accumulated error. This error can be reduced through state-estimation methods

such as Kalman Filtering, and/or completely bounded by periodic absolute position

fixes, through the use of Differential GPS (DGPS). Such systems are very

complex, and often prohibitively expensive where high accuracy is required, as in

this case. Therefore, inertial navigation was ruled-out for use on the Tuvaaq

vehicle.

Visual navigation systems are also available, but due to light attenuation

underwater, are only useful at close range, and are mainly used for object

identification, following, and collision avoidance. Therefore, visual navigation was

 55

not chosen due to its unsuitability for long-range navigation, as well as its long

development time.

This leaves two options, acoustic navigation and dead-reckoning, both of

which will be used on the Tuvaaq AUV. The simplest of the two, dead-reckoning,

involves simple measurements such as magnetic heading from a compass, depth

from a pressure sensor, ground velocity measurement through the use of a Doppler

Velocity Log (DVL), and distance estimation based on propeller revolutions. This

method is simple, but has the most potential for large errors. Nevertheless, a dead-

reckoning system is a basic requirement for any AUV. Since a DVL was

unavailable and prohibitively expensive for this project, the Tuvaaq vehicle was

outfitted with a depth sensor (contained within the onboard CTD, discussed in

section 3.3.4), and digital compass, which also serves as a roll/pitch sensor. The

roll/pitch sensor is primarily used to correct for vehicle motions in the calculation

of magnetic bearing, and also allows us to examine the true vertical stability of the

vehicle during a mission.

 56

Figure 3.3.3.1: EZ-Compass 3 Digital Compass module

In dead-reckoning mode, the AUV uses the compass for bearing and

calculates velocity and displacement based on thruster commands, assuming certain

linear characteristics about the relationship between propeller RPM and forward

vehicle speed. Again, this method is highly error-prone, especially in the Arctic,

where close proximity to the North Pole can cause magnetic compasses to give

erroneous readings. However, it can be used if no other navigational data is

available or to test simple mission plans, such as following a compass heading at a

specified depth. Furthermore, this system is useful for field testing of the AUV in

Florida, to prove the performance of the vehicle’s mission planning and control

software.

Acoustic navigation systems offer the ability to determine precise location

over long distances, due to the high speed of sound underwater (avg. 1500 m/s in

seawater). Several types of acoustic systems are available for AUVs, including
 57

Long-Base-Line (LBL), Ultra-Short-Base-Line (USBL), Sound Navigation And

Ranging (SONAR), and Acoustic Doppler (ADCPs & DVLs) technologies (see

[4]). Review of these technologies lead to the decision to develop a simple homing

system, which would allow the AUV to find its exit hole by targeting a continually

repeating acoustic beacon.

The system developed for this purpose is based on the Super-Short-Baseline

method, or SSBL. The theory behind this technique is as follows. Sound in water

propagates as a pressure wave, oriented orthogonally to its direction of motion as in

Fig. 3.3.3.2.

Figure 3.3.3.2: Propagation of hydroacoustic waves across a

straight-line transducer array

Beacon

∆t13
∆t12
α
∆t23

3 2 1
 58

As the pressure waves meet a line of transducers oriented at an angle to their

direction of travel, the incoming waves arrive at each transducer at different times.

These time differences can be used to trigonometrically calculate the bearing angle

to the acoustic source. In the case of an Ultra-Short-Base-Line (USBL) system,

these transducer elements are placed very close together (on the order of

millimeters), such that the time-of-arrival differences present themselves as phase-

shifts in the incoming acoustic signal.

For our purposes, a similar, larger scale method was chosen … the Super-

Short-Base-Line (SSBL) technique. This technique works identically to USBL,

except that the transducer elements are placed further apart (on the order of inches),

allowing the time-of-arrival differences to be measured in time, rather than phase-

shift. Furthermore, since it is necessary to discern which direction the acoustic

signal is coming from in the full 360-degree horizontal and vertical planes, a

single-line array would be unsuitable. Therefore, a triangular transducer “triplet”

array was designed, so as to allow this determination (see Fig 3.3.3.3 and [4]).
 59

Figure 3.3.3.3: Propagation of hydroacoustic waves across a

triangular SSBL transducer array

TOP VIEW Beacon

α
Zone 6
(300º-360º)
Zone 1
(0º-60º)

∆tac ∆tab
1

∆tbc
Zone 5 Zone 2
(240º-300º) (60º-120º)

3 2

Zone 4 Zone 3
(180º-240º) (120º-180º)
 60
SIDE VIEW
Beacon

∆tac β

3 2 1

∆tac max

As shown in Figure 3.3.3.3, the angle α gives the horizontal bearing to the beacon

and the angle β gives the vertical bearing. These angles are calculated in the

following manner:

1. Logically resolve which 60º zone the beacon is in based on the order in

which the transducers received the signal:

1,2,3 = Zone 1 (0º-60º)

2,1,3 = Zone 2 (60º-120º)
2,3,1 = Zone 3 (120º-180º)
3,2,1 = Zone 4 (180º-240º)
3,1,2 = Zone 5 (240º-300º)
1,3,2 = Zone 6 (300º-360º)
 61

2. Determine the horizontal bearing angle (α) within the appropriate zone
through time-of-arrival ratios:

 ∆t 
α =  bc  60º + X … for odd-numbered zones (1,3,5) (3.3.1)
 ∆t ac 

 ∆t 
α =  ab 60º + X … for even-numbered zones (2,4,6) (3.3.2)
 ∆t ac 

…where,

∆t ab = time difference between the first and second transducers to

detect the signal.
∆t bc = time difference between the second and last transducers to
detect the signal.
∆t ac = time difference between the first and last transducers to detect
the signal.
X = lower angle limit of each zone (e.g. for Zone 5, X = 240)

3. Determine the vertical bearing angle (β).

 ∆t ac 
β = Cos −1   (3.3.3)
 ∆t ac max 

… where,

∆t ac = time difference between the first and last transducers to detect

the signal.
∆t ac max = Maximum time difference between the first and last
transducers to detect the signal, based on the flat-line
distance between them and an approximate speed of sound,
Cs = 1500 m/s = 59055.118 in/s.

The horizontal bearing angle (α) functions like an acoustic compass

heading, guiding the vehicle towards the beacon. Note that knowing the speed of
 62

sound is not necessary when calculating α, because it is based on relative time

differences between the transducers. This allows high accuracy in determining this

angle, despite changes in the speed of sound between the beacon and the vehicle.

Of course, it must be assumed that there is no change in the speed of sound

between the transducers. This assumption is reasonable since the transducers are

only 12” apart.

The vertical bearing angle (β) is useful for two reasons. If the vehicle depth

and beacon depth are known, the two can be subtracted, giving a vertical offset

(∆d). This vertical offset and the vertical bearing angle can then be used to

triangulate the position of the beacon, thereby allowing approximate determination

of horizontal range (R), as shown below.

∆d
R= (3.3.4)
Tanβ

Secondly, as the vehicle approaches the beacon from below, β approaches zero,

allowing the vehicle to determine when it is directly under the beacon. The vehicle

can then make a simple vertical ascent to the exit hole. In fact this is the most

important feature of knowing β. Since the microcontroller assumes a constant for

the speed of sound (1500 m/s), precise determination of β is difficult. However, by

monitoring this angle as it approaches 90º, the mission planner knows that it is
 63

moving towards the beacon. Thus, the mission planner can find the beacon by

driving β towards 90º, and begin making its ascent when β is sufficiently steep.

The desired frequency for the beacon and receiving transducers is a

relatively low-frequency, to increase range, while at the same time offering good

resolution and ease of detection. These design criteria, coupled with a review of

industry standard equipment and operating frequencies, lead to the choice of 37

kHz. In order to confirm that this frequency would result in a reasonable power

output requirement from our acoustic beacon, the following calculations were made

to determine signal attenuation.

Maximum distance from beacon = 500m

Maximum water depth = 50m

Primary sources of attenuation = Transmission Loss (spherical & cylindrical

spreading) and absorption.

50m Spherical spreading: TL sph = 20 log r = 20 log 50 = 34.0 dB

450m Cylindrical spreading: TLcyl = 10 log r = 10 log 450 = 26.5 dB

10 log I 1 − 10 log I 2
Absorption: α= … in this case, we can use Fig
r 2 −r1

5.2 on p.104 of [5], which gives an absorption coefficient for sound waves at 37

kHz in seawater of approximately:

α = 7.0 dB/kyd = 7.0 dB/km = 3.5 dB total absorption (over 500m path)
 64

Summing these losses, we get a total of:

34.0 + 26.5 + 3.5 = 64dB

Therefore, our beacon must be able to output enough power to be detectable, with

64dB of loss. The beacon selected for this task is the ULB-350, manufactured by

RJE International. This pinger is often used as a marker beacon for subsea

equipment, and can last on a single 9V battery for up to 40 days. Its output is a

10ms pulse every 1sec at 37kHz, with a power output of 163dB, which is more than

sufficient for our needs.

Figure 3.3.3.4: ULB-350 Underwater Beacon

 65

The counterpart to the beacon, the receiving transducers from Sensor Technologies,

Ltd., were chosen based on omni-directional response, a 38kHz center-frequency,

and relatively low cost.

Figure 3.3.3.5: SX-38 38kHz Omnidirectional Transducer

These transducers were placed in a triangular array to form the receiving-end of the

SSBL system. Spacing of the transducers is 11.955” on each side (12” nominal),

based on a multiple of the half-wavelength (0.797”) and the widest possible

configuration suitable for placement on the top of the Tuvaaq AUV.

 66

Figure 3.3.3.6: SSBL Transducer array mounted on test fixture

Development of the receiver electronics is based on a 5-part process,

outlined below and shown in Fig. 3.3.3.7. The boards were also manufactured by

ExpressPCB, and fit the PC/104 form factor. Detailed schematics and PCB layout

drawings can be found in Appendix C.

1. First, the transducer signal is amplified to a useable voltage level (gain

is set manually by a potentiometer).

2. A bandpass filter is applied to remove noise on either side of the

frequency of interest (37kHz).

 67

3. The amplified, filtered signal is fed through a tone detector, which

“listens” for the frequency of interest (set manually by a potentiometer).

4. Simultaneously, the signal is fed through a fixed threshold detector,

which determines if the signal is “loud” enough to be the pinger, and not

just simply 37 kHz background noise (set manually by a potentiometer).

5. The result of the tone detector and threshold detector are combined in a

“Boolean AND” fashion and fed to a PIC microcontroller.

6. The PIC microcontroller records the difference in arrival time of the

signal at each of the three transducers and computes the horizontal and

vertical bearing angles. The result is then sent to the host PC via an RS-

232 serial port.

Figure 3.3.3.7: Block diagram of SSBL Acoustic Navigator circuit

 68

Figure 3.3.3.8: Final printed SSBL Acoustic Navigator circuit board

It should be noted that multi-path reverberation errors are of no concern to

this system, because the firmware in the PIC microcontroller triggers on the first

detection of the signal by the circuit. As a result, any successive detections due to

multi-pathing will arrive at each transducer after the straight-line signal is received,

and will be ignored. Furthermore, the delay associated with computation of the

bearing angles far exceeds the dissipation time of the acoustic pulse, and can be

increased as necessary by adding additional delay timers in the firmware.

The firmware running on the PIC microcontroller (PIC16F876-20) records

the differences in time-of-arrival between the three transducers by polling their

three corresponding signal detection pins. In order to ensure adequate resolution

 69

for measuring bearing angle, it was determined that based on the geometry of the

SSBL array, the maximum time delay would occur at 60º multiples of bearing

angle offset, and the minimum desired measurable bearing angle offset is 1º. Based

on these limits, it was calculated that time delays between transducers can range

from approximately 3-203µs. Therefore, a faster 20MHz PIC was chosen, which

has a minimum timer increment of 0.4µs (2 instruction cycles), and a maximum of

26,214.4 µs (for the 16-bit timer). Once the bearing angles are calculated, the data

is sent via RS-232 serial port at 9600-8-N-1, in the form of an ASCII text string

which appears as “[α,β,t1 ,t2 ,t3 ]”, where α ranges from 0-360º, β ranges from 0-90º,

and the three transducer detection times (t1 ,t2 ,t3 ) are measured in number of

instruction cycles (0.2µs per count for a 20MHz PIC). The inclusion of the

transducer detection times allows for error checking, as well as re-computation of β

by the main computer, if the speed of sound is known. A block diagram of the

firmware is shown below in Fig. 3.3.3.9. Detailed source code can be found in

Appendix C.
 70

Figure 3.3.3.9: SSBL Firmware block diagram

 71

3.3.4: Environmental Sensors

As the purpose of the Tuvaaq AUV is to monitor environmental data,

selection of the sensor payload is critical. Ultimately, the vehicle is nothing more

than an autonomous platform, and can be adapted for other data collection missions

simply by changing the sensor payload. Originally, it was thought that the

Aanderaa CTD and Turbidity sensors used in the towfish would be used on the

AUV. However, after some testing, it was determined that these sensors require a

great deal of settling time at start-up (several minutes), and much too low of a

sampling rate (0.25 Hz), to be useable on the vehicle.

As a result, a new sensor package was researched, and lead to the Smart

CTD, manufactured by Applied Microsystems, Ltd., with an add-on Infrared Light-

Scattering Turbidity Sensor (LSS) from WetLabs, Inc.

Figure 3.3.4.1: CTD and LSS Instrument package

 72

Table 3.3.4.1: AUV Environmental Sensor Payload Specifications

CTD Conductivity Sensor

Range 0-7 S/m
Resolution 0.003 S/m
Accuracy +/- 0.001 S/m

CTD Temperature Sensor

Range -2-32 ºC
Resolution 0.001 ºC
Accuracy +/- 0.005 ºC

CTD Depth Sensor

Range 0-100 dBar (0-100m)
Resolution +/- 0.01 dBar (1cm)
Accuracy +/- 0.05 % full scale (5cm)

LSS Turbidity Sensor

Range 0-25 NTU
Resolution +/- 0.03 % full scale (0.0075 NTU)

System Power Requirements 12VDC @ 75mA

System Communications RS-232 Serial @ 9600,8,N,1
System Data Output Format ASCII Text
System Data Sample / Output 15Hz
Rate

As a result of the fast sample rate of the sensor package and high resolution of its

depth sensor, it was determined that the CTD could be used to navigate the vehicle

in the water column without the need for a separate pressure transducer. Therefore

the depth reading from the CTD is also fed to the PID depth controller on board the

vehicle as a feedback term.

 73

The CTD sensor is mounted on the vehicle as shown in Fig. 3.3.4.2, and the

LSS (not shown) is attached on the underside of the vehicle such that it has a clear

visual path into the water column.

Figure 3.3.4.2: CTD Sensor mounted on the AUV

 74

3.3.5: Main Computer

The Central Processing Unit (CPU) Housing is the “brain” of the AUV,

running all control, mission planning, and data-logging software. This “command

central” ties all of the vehicle subsystems together. For the Tuvaaq vehicle, the

PC/104 Computer format was chosen. PC/104 and PC/104-Plus are industry-

standard formats for small, embedded computer systems. These standards have the

added advantages of a small form factor, ease of expansion through stackable

PC/104 modules, and a wide array of manufacturers and add-ons. Figure 3.3.5.1

shows a high-level diagram of how all of the vehicle subsystems are tied together

through the CPU.

Figure 3.3.5.1: Tuvaaq high-level system architecture block diagram

 75

The heart of the AUV’s PC/104 stack is the Lippert Cool Road Runner II

Single-Board Computer (SBC). This board, shown in Fig. 3.3.5.1, is a complete,

stand-alone 300 MHz Pentium II PC in a PC/104-Plus form factor, with extended

operating temperature to –20 ºC. It has all of the functionality of a typical

computer, including: on-board video, sound, 10/100 Base-T Ethernet, mouse,

keyboard, 2 serial ports, 1 parallel port, 2 USB ports, watchdog timers, 64MB

SDRAM, PC/104 ISA connector, PC/104-Plus PCI connector, IDE connector,

floppy drive connector, and IBM MicroDrive connector. Detailed specifications

for this board can be found in Appendix F.

Figure 3.3.5.2: Main PC/104 CPU Board

 76

3.3.5.3: Internal Communications

Internal communications with sensors, navigation systems, motor drivers,

etc., is achieved through an RS-232 serial network. Given the amount of I/O in the

Tuvaaq vehicle, it was felt that standard RS-232 serial protocol offers the simplest,

most cost-effective means of intra-vehicle communication and expandability,

without the need for complex industrial control networks or protocols. The main

hub of the RS-232 network is the Xtreme 8-104 PC/104 serial expansion module,

which offers 8 standard RS-232 serial ports (also configurable as RS-485 or RS-

422). This expansion board, shown in Fig. 3.3.5.3, coupled with the CPU’s 2

native ports, offers 10 total serial ports, 5 of which are still unused. Some

advantages of this system include the ability to add additional serial expansion

cards to the PC/104 stack, and ease of interfacing with PIC Microcontrollers (as in

the case of the BLDC Motor Controller Board and SSBL Acoustic Navigation

Board), which in itself opens virtually infinite data acquisition and control

possibilities. This, combined with the use of only standard ASCII text strings for

data transfer, simplifies software and hardware development, and adds to the

overall robustness of the system. Furthermore, commercial devices such as the EZ-

Compass 3 and Advanced Microsystems CTD readily offer RS-232

communications, simplifying future instrument additions.

 77

Figure 3.3.5.3: PC/104 Serial Expansion Module

3.3.5.3: External Communications

In order to set mission parameters, execute on-board software, and

download data, a means of external communication with the AUV is necessary.

When the PC/104 stack is exposed, the CPU has the ability to directly connect to a

standard keyboard, monitor, and mouse, as well as floppy and CD-ROM drives.

This is the simplest means of communication for making major changes and

debugging problems.

However, when the stack is sealed in the CPU housing, access is limited,

and it is desirable in a harsh environment such as Alaska’s North Slope, to

eliminate the need for hard-wire communications and expensive multi-pin

waterproof bulkhead connectors. Therefore, it was decided that a low-cost 802.11b

Wireless Ethernet (WLAN) card would be used for communications between the
 78

AUV and a host PC. This module, shown in Figure 3.3.5.4, can be configured for

one-to-one communications with another WLAN card installed in a field laptop, for

instance, or with a Wireless Network Access Point (WAP), giving the AUV the

ability to join a Local Area Network (LAN) and gain access to Internet resources.

One of these modules was removed from its casing and mounted in the CPU stack

on the AUV. It is interfaced to the main CPU board via a USB connection. Its

antenna was then routed via coaxial cable to the metal shell on one of the bulkhead

connectors on the endplate of the CPU housing. This transforms the entire housing

into a WLAN antenna, which allows wireless communications with the AUV while

at the surface.

Figure 3.3.5.4: Linksys WUSB11 802.11b Wireless Ethernet Module

 79

In total, the CPU stack is comprised of the following items, which if not PC/104

compliant, are mounted on to perforated fiberglass boards which have hole patterns

that mount into the PC/104 stack. The components of this housing are shown in

Figs. 3.3.5.5 & 3.3.5.6.

1. PC/104+ CPU (Pentium II 300MHz, 64 MB SDRAM)

2. PC/104 8-Port Serial Expansion Module

3. PC/104 Vehicle Power Supply Module

4. 2GB Laptop Hard-Drive (may be upgraded to solid-state in the future, due

to temperature concerns)

5. Linksys 802.11b Wireless Ethernet USB card (removed from casing)

6. CPU Cooling Fan

7. EZ-Compass 3 Digital Compass

8. SSBL Acoustic Navigation Board (to be added)

 80

Figure 3.3.5.5: CPU Housing Internals with PC/104 Stack

Figure 3.3.5.6: Sealed CPU Housing

 81

3.3.6: Power

Ultimately, the ability of an AUV to perform its mission is dependent on its

power supply. The lack of an umbilical means that selection of batteries or fuel-

cells is critical.

For this project, the power system is relatively simple. It consists of four

12V, 12 AH Sealed-Lead-Acid (SLA) batteries, held in two housings, and a PC/104

power supply board.

It was estimated that the power requirements of the vehicle are as follows

(note the low power consumption of the Brushless Thrusters):

3 BLDC Thrusters, running constantly at 75% thrust 1.5 A

Electronics (CPU, Motor Controllers, Navigation, Fans, etc) 1.0 A
Mission time at 50% speed (0.5 m/s) over 500m 17 min
---------
Conservative power estimate per 1hr mission (FOS = 2.0) 5 AH

As a result of this estimate, it was decided that SLA batteries would be the most

cost-effective solution, despite their propensity to lose power density in cold

weather (up to 50% loss at -10ºC).

Without losses, the vehicle’s total power capacity is 48 AH @ 12 VDC.

Assuming this worst-case scenario for power loss due to cold, the vehicle still

retains 24 AH of battery time, allowing approximately 8-10 30-minute missions or

4-5 1-hour missions.

 82

Figure 3.3.6.1: AUV Battery Pod internals, with two SLA Batteries

(parallel wiring)

Figure 3.3.6.3: Sealed Battery Pod (1 of 2)

 83

The other component of the power system is a PC/104-based regulated

power supply board. Since there are two battery pods on the AUV, one is used

exclusively for thruster power, and the other is used for electronics. In order to

isolate noise and provide the varied, regulated voltages required by the electronics

(+5V, -5V, +12V, -12V @ 50W), the second battery pod is connected to the power

supply board, which in-turn handles power to all of the electronics and the PC/104

bus. Since the power supply is regulated, this also ensures that as the batteries’

output voltage drops below 12V, all electronics will continue to receive their

required voltages, preventing premature low-voltage shutdown (provided Vin is at

least 6V).

Figure 3.3.6.2: PC/104 Power Supply Board

 84

3.3.7: High-Level Software

Ultimately, all datalogging, navigation, motor control, and mission planning

functions take place on the main CPU. In the case of the Tuvaaq AUV, the

Windows 98 Operating System was chosen, for ease of use, availablilty, and size

requirements. This choice allowed quick software development time and a familiar

user interface. In the future, the AUV’s software may be ported to a UNIX-type

RTOS (Real-Time Operating System), such as QNX or MicroLinux, for increased

robustness and real-time compliance.

Communication with the CPU is achieved as mentioned earlier, through the

use of a Wireless Ethernet LAN card whose antenna is electrically connected to the

CPU housing. Using a simple freeware program called Virtual Network

Computing (VNC), created by AT&T Bell Labs, Tuvaaq’s Windows Desktop can

be viewed and controlled remotely from a laptop or field computer. To achieve

this, the VNC Server is configured to run as a service under Windows on the AUV.

The VNC Client is run on the field PC, which is connected to the AUV via the

WLAN card. Once the AUV is booted-up, the VNC client can connect to it and

render the logon screen and desktop in a window on the field PC. From this

window, the user can manipulate the AUV as if it were connected directly to a

monitor, keyboard and mouse. The AUV software can then be run and configured,

data files can be transferred, or the vehicle can be operated in ROV Mode

(discussed later).
 85

Figure 3.3.7.1: The Tuvaaq desktop, visible on a PC running VNC Client

The high-level AUV software program, known as simply “TUVAAQ”, was

written in National Instruments’ LabVIEW® 6.1, again used for its short

development time and ease of use. Furthermore, LabVIEW offers easy debugging

and a graphical programming environment that should be simple to pick-up for

those who continue the Tuvaaq AUV project.

The basic architecture for the TUVAAQ program is based on the

MATLAB® Simulation described in section 3.2. It is implemented as a single

multi-threaded application, which uses a shared-memory block to pass data

between its many concurrent Virtual Instrument (VI) threads. A block diagram of
 86

this architecture is shown in Fig. 3.3.7.1. These VIs are then compiled into a

stand-alone executable (TUVAAQ.exe), using the LabVIEW® Application Builder,

eliminating the need to have a licensed copy of LabVIEW® installed on the AUV.

All that is required are installations of the LabVIEW® and NI-VISA® Runtime

Engines, available for free from the National Instruments website (www.ni.com).

Due to its graphical nature, LabVIEW source code (VI block diagrams) consumes

far too many pages when printed. Therefore, source code for this program will not

be included in this document, however it is available from the UTL.

Figure 3.3.7.2: TUVAAQ Software Architecture Block Diagram

 87

This design allows all of the individual threads, implemented as separate

simultaneously-running VIs, to remain active during the entire execution time,

eliminating lags as threads are spawned and terminated. This also allows each VI

(CTD reader, motor controller, datalogger, etc.) to run at its own speed,

independent of the others (asynchronous operation). For instance, the CTD sensor

is sampled at 15Hz, and the compass is sampled at 4Hz. Generally, the overall

vehicle control loop runs at 4Hz (from raw sensor read to low-level motor

command).

Flags to read sensors and send motor commands, along with mission data

variables, are passed through the shared-memory block, implemented as a

LabVIEW® global variable VI (Tuvaaq_global.vi). This VI allows a seamless

interface between all of the separate processes as they each simply read and write to

variables in the memory block. LabVIEW® automatically handles the semaphores

necessary to prevent memory allocation errors when using this VI.

The main VI (Tuvaaq_main.vi) handles the graphical user interface (GUI)

and menu selection. This VI also serves as a simple mission planner, which

orchestrates commands to the depth, heading, and speed controllers during the

mission. As shown in Fig 3.3.7.3, the user can select either dead-reckoning mode,

which uses the digital compass, or “Go To Beacon” which uses the acoustic

navigation system. Also, there are settings for depth or altitude following (can be

implemented with the addition of an altimeter) and end-of-mission behavior.

 88

Figure 3.3.7.3: TUVAAQ Main User Interface Panel

From the main VI, the user can then start the mission or select from several

menu options, including:

1. File
• Quit
2. Configure
• Serial Devices
• Offsets & Multipliers
• Controller Gains
• ROV Mode
3. Data Logging
• Start
• Stop

Descriptions of these menus options is given below.

 89

File | Quit: Ends program

Configure | Serial Devices: Allows user to change COM Port mapping for sensors

and motor controllers as well as enable/disable each device individually

Figure 3.3.7.4: Configure Serial Devices Panel

 90

Configure | Offsets & Multipliers: Allows user to change gain & offset factors for

all devices. This panel can be used to compensate for linear scale factors and error

constants in the instruments and motor controllers, or to convert raw data to

engineering units.

Figure 3.3.7.5: Offsets & Multipliers Panel

 91

Configure | Controller Gains: Allows user to set gains for depth, heading, and

speed control algorithms

Figure 3.3.7.6: Controller Gains Panel

Configure | ROV Mode: Displays a panel, which allows user to control the vehicle

in a Remotely-Operated mode. This panel is especially useful for doing open-loop

field tests via the Wireless Ethernet connection (this can be extended through the

use of a single wire umbilical attached to the CPU housing as an antenna for testing

purposes).
 92

Figure 3.3.7.7: ROV Mode Panel

Datalogging | Start / Stop: These selections start or stop datalogging on the AUV.

When datalogging is started, the user will be prompted for a location and filename

(default is “date_time.tuv”). The datafiles, saved with a “.tuv” extension, are in

tab-delimited spreadsheet format, and can be opened with a spreadsheet application

such as Microsoft Excel. Data contained with these files includes both sensor and
 93

mission parameters, such as salinity, depth, temperature, motor speed, etc. The

files are written at a rate of 2Hz, to minimize data bloating (this can be changed

within the software if necessary). Upon retrieval of the AUV, the mission planner

will stop the mission, which automatically halts datalogging. The data files can

then be downloaded using VNC via the Wireless Ethernet connection.

 94

4. Results & Conclusions

This paper has described the simulation, design, and construction of an

Autonomous Underwater Vehicle (AUV) for use in under-ice data collection in

Prudhoe Bay, Alaska. Throughout this work, much has been accomplished. These

results are listed below:

1. Built and deployed a small ROV and Towfish in Prudhoe Bay

2. Designed a new type of AUV, which swims vertically and can navigate
under uninterrupted Arctic sea-ice.
3. Created a computer simulation of the AUV and used the simulation to
model vehicle dynamics, design its controllers, and test its mission
planner.
4. Built a prototype vehicle named “Tuvaaq”, including design and
construction of the following:
a. Vehicle chassis, pressure vessels, and buoyancy system.
b. Seal-less Brushless DC thrusters
c. PIC-Based BLDC Motor Controller Board
d. PIC-Based SSBL Acoustic Navigation Board
e. SSBL transducer array test fixture
f. Two Sealed Lead-Acid battery pods
g. Main PC/104 computer stack, including CPU, serial expansion
module, power supply, wireless Ethernet card, hard-drive, and
digital compass.
h. Wireless external communications system (using VNC)
i. High-Level AUV Software (using LabVIEW®)
 95

In conclusion, the scope of work set forth for this endeavor has been

fulfilled. The Tuvaaq AUV shows genuine promise as a viable under-ice data

collection system. The design of the Tuvaaq vehicle also allows for the electronics,

software, and pressure vessel technologies to be used in other vehicle shapes,

thereby extending its applications to open-water and higher-speeds. Furthermore,

the large body of work contained in this thesis, has not only created a new AUV for

use in the Arctic, but has also developed a base technology which can be used for

future AUV development in the Underwater Technologies Laboratory at Florida

Tech.
 96

5. Recommended Future Work

Design and construction of an Autonomous Underwater Vehicle from

scratch is an enormous undertaking. This thesis represents significant progress, but

there is always room for future improvements. Since the majority of the design and

construction effort has been completed, mostly what needs to be done is testing.

This includes hardware-in-the-loop mission simulations, pool testing, and field

testing, both in open water and under ice. Additionally, there are some refinements

and improvements that could be useful in the future. The following are a list of

suggestions that the author feels would greatly improve the functionality and

reliability of the AUV.

1. Testing, refinement and implementation of the SSBL Acoustic

Navigation system:
Currently, this system is undergoing testing, and may need some
debugging, including PIC firmware refinements and possibly additional,
higher-order noise filtering in the amplifier circuit. Once completed,
the system needs to be mounted to the vehicle and implemented in the
TUVAAQ LabVIEW ® program, as it currently only allows for use of
dead-reckoning when operating autonomously.
2. Re-design of the heading & speed controller algorithm:
This controller can follow a commanded heading, but shows a lot of
chattering and slow settling time in simulation. Based on the results of
field testing, this may need to be refined, possibly through the
development of a Fuzzy-Logic or Fuzzy Sliding-Mode controller.
 97

3. Further development of the Tuvaaq Mission Planner:

Currently, the mission planner implemented in the TUVAAQ program
is very simplistic, and could to be improved to allow for more complex
mission plans, perhaps using an XML-based mission plan file.
4. Change of Operating Systems:
In the interest of reliability, porting the AUV software to another
operating system such as QNX or MicroLinux may be advantageous.
5. Addition of Leak detectors:
The addition of leak detectors in each housing is recommended,
especially in the case where short-circuiting the SLA batteries could
have potentially dangerous consequences (i.e. release of hydrogen gas).
The addition of an over-pressure relief valve on the battery housings
may also be a useful safety feature.
6. Connector retrofit:
Due to limited budget, SealCon constrictive pressure connectors were
installed on the battery and motor controller housings. These
connectors are the limiting factor in the vehicle’s rated depth (150 ft.).
For deeper operation, and better reliability, these should be replaced
with ones similar to those used on the CPU housing (by Impulse), for
increased reliability and ease of disassembly.
7. Addition of Collision Avoidance System & Altimeter:
To protect against impact with potential random ice spikes, an acoustic
collision avoidance system should be developed and implemented on
the AUV. This starts with the development of a simple acoustic
altimeter, which would then also add altitude-following capability.
8. Revision of Motor Controller PIC Firmware:
The BLDC Motor Controller boards currently operate in an open-loop
mode, as there have been problems noticed with determining motor
 98

RPM, a necessary component in the PID velocity-feedback loop. This

needs to be investigated and fixed, so that a precise RPM can be
maintained. At the moment, the work-around for this problem is to
adjust the low-level motor command gains & offsets so that all motors
operate equally for a given control signal.
9. Re-selection of Thruster Motors:
Overall, the thruster motors work well, but were fairly difficult to pot,
due to tight tolerance between the stator and rotor. In the future, other
motor coil designs with larger stator-rotor spacing may be desirable.
Also, the possibility of magnetic coupling through a housing should be
investigated. This way, the propeller would be magnetically coupled to
the motor shaft through the wall of a pressure housing, eliminating the
need for motor disassembly, potting, and rotary shaft seals.
 99

References

[1] Roberson, John A. and Crowe, Clayton T. Engineering Fluid Mechanics.

Sixth Edition. New York: John Wiley & Sons, 1997.

[2] Gottlieb, Irving M. Electric Motors and Control Techniques. Second Edition.
New York: McGraw Hill, 1994.

[3] Ogata, Katsuhiko. Modern Control Engineering. Third Edition. New Jersey:
Prentice Hall, 1997.

[4] Waite, A.D. SONAR for Practising Engineers. Third Edition. West Sussex,
England: John Wiley & Sons, 2002.

[5] Urick, Robert J. Principles of Underwater Sound. Third Edition. California:

McGraw-Hill, 1983.

[6] Everett, H.R. Sensors for Mobile Robots: Theory and Application.
Massachusetts: A.K. Peters, 1995.

[7] Keogh, Jim. The C++ Programmer’s Notebook: An Illustrated Quick

Reference. New Jersey: Prentice Hall, 1998.

[8] Olgac, N., Platin, B.E., and Chang, J.-M. “Sliding Mode Control of Remotely
Operated Vehicles for Horizontal Plane Motions.” IEE Proceedings-D.
Vol. 138, No. 5, 1991.
 100

[9] Cristi, Roberto, Papoulis, Fotis A., and Healey, Anthony J. “Adaptive Sliding
Mode Control of Autonomous Underwater Vehicles in the Dive Plane.”
IEEE Journal of Oceanic Engineering. Vol. 15, No. 3, 1990.

[10] Yoerger, Dana R. and Slotine, Jean-Jaques E. “Robust Trajectory Control of

Underwater Vehicles.” IEEE Journal of Oceanic Engineering. Vol. OE-10,
No. 4, 1985.

[11] DeCarlo, R.A., Hak, S.H., and Drakunov, S.V. “Variable Structure, Sliding-
Mode Controller Design.” In The Control Handbook, edited by William S.
Levine. Florida: CRC Press, 1996.

[12] Conte, G.and Orlando, G. “A Variable Structure Control of a Remotely

Operated Vehicle.” IEEE Journal of Oceanic Engineering. 1994.
 Appendix A:
MATLAB ® Simulation Source Code
102
 103

%///////////////////////////////////////////////////////
%Filename: auv_model.m
%
%Description: This file implements
% the dynamics of a 6-DOF
% Autonomous Underwater Vehicle (AUV)
%
%Author: Lee Frey
%///////////////////////////////////////////////////////

function [sys, x0] = prnl(t,x,u,flag)

%Return vector of sizes and initial conditions

if flag == 0

% SYS Definitions
% 1-Number of continuous states
% 2-Number of discrete states
% 3-Number of outputs
% 4-Number of inputs
% 5-Flag for direct feedthrough
% 6-Number of sample times

sys = [8, 0, 8, 7, 0, 1];

x0 = [0, 0, 0, 0, 0, 0, 0, 0]; %initial conditions for each state
end

% Define constants used and return state derivatives

if flag == 1

%Define vehicle in-water weight

W = 0; %assume neutrally buoyant

%Define Vehicle mass (slugs) and moment of inertia about vertical-

axis
m = 3.1; %approx 100 lbs.
Iz = 0.5*m*1.969^2; %Iz = 0.5*m*A^2

%Define horizontal thruster separation distance (ft)

d = 0.91667; %approx. 11" between centers of thrusters

% Definition of inputs
T1 = u(1);
T2 = u(2);
T3 = u(3);
Fxext = u(4);
Fyext = u(5);
Fzext = u(6);
Mzext = u(7);
 104

% Definition of states
Xx = x(1);
Yy = x(2);
Zz = x(3);
psi = x(4); %radians
xdot = x(5);
ydot = x(6);
zdot = x(7);
psidot = x(8);

%Restrict thrust force to actual motor limits (assume 10 lbf),

%in case the controllers give us some outrageous control signal to
meet
if T1 > 10
T1 = 10;
elseif T1 < -10
T1 = -10;
end

if T2 > 10
T2 = 10;
elseif T2 < -10
T2 = -10;
end

if T3 > 10
T3 = 10;
elseif T3 < -10
T3 = -10;
end

%Calculate hydrodynamic drag forces

%from the equation Fd = Cd*Ap*rho*(Vo^2/2)
%ASSUME: AUV is 28" tall, 21" dia. cylinder 24/19
%rho (seawater) = 1.99
%Cd = 1.0
%Ap = 4.083 sq.ft.

Fdx = 1.0*4.083*1.99*(xdot^2/2);
if xdot > 0
Fdx = -Fdx;
end

%Cd = 1.0
%Ap = 4.083 sq.ft.
Fdy = 1.0*4.083*1.99*(ydot^2/2);
if ydot > 0
Fdy = -Fdy;
end
 105

%Cd = 0.9 for cylinder moving parallel to flow with L/D = 1

%Ap = 2.405 sq.ft.
Fdz = 0.87*2.405*1.99*(zdot^2/2);
if zdot > 0
Fdz = -Fdz;
end

%Calculate state derivatives

sys(1)= xdot + (Yy*psidot);
sys(2)= ydot - (Xx*psidot);
sys(3)= x(7);
sys(4)= x(8);
sys(5)= ((T1 + T2 + Fdx + Fxext)/m) + (ydot*psidot);
sys(6)= ((Fdy + Fyext)/m) - (xdot*psidot);
sys(7)= (T3 + Fdz + Fzext - W)/m;
sys(8)= (((T2-T1)*(d/2)) + Mzext)/Iz;

end

% Return output states

if flag == 3
sys = [x(1),x(2),x(3),x(4),x(5),x(6),x(7),x(8)];
end
 106

function[output] = coord_xform(input)
%///////////////////////////////////////////////////////
%Filename: coord_xform.m
%
%Description: This function converts the body-fixed
% coordinates generated by AUV_model to
% geographical (global) coordinates
%
%Author: Lee Frey
%///////////////////////////////////////////////////////

%Inputs from AUV_Model

Xx = input(1);
Yy = input(2);
Zz = input(3);
psi = input(4);
xdot = input(5);
ydot = input(6);
zdot = input(7);
psidot = input(8);

%Convert radians to degrees

Psi = mod(psi*(180/pi),360);
Psidot = psidot*(180/pi);

%Define coordinate transformation matrix

BGxform = [cos(psi) -sin(psi);...
sin(psi) cos(psi)];

%Convert body-fixed coords. to geographical coords.

geoXY = BGxform*[Xx;Yy];
geoXYdot = BGxform*[xdot;ydot];
X = geoXY(1);
Y = geoXY(2);
Xdot = geoXYdot(1);
Ydot = geoXYdot(2);

%Depth coords. remain the same

Z = Zz;
Zdot = zdot;

%Create output vector

output = [X,Y,Z,Psi,Xdot,Ydot,Zdot,Psidot];
 107

function [output] = nav_system(input)

%///////////////////////////////////////////////////////
%Filename: nav_system.m
%Author: Lee Frey
%
%Description:
%This function converts the x-y, psi location of
%the auv given by the system model to the heading, range,
%magnetic heading, depth and altitude given by the
%acoustic nav system, compass, depth sensor, and
%altimeter
%
%INPUT VECTOR [14]:
%Beacon_X, Beacon_Y = distance from origin to beacon
%Beacon_Z = depth of eacon
%X, Y = distance of vehicle from origin
% (this is what auv_model outputs)
%Z = depth of vehicle
%Psi = absolute heading angle of vehicle
%Xdot,Ydot,Zdot,Psidot = velocities of above
% parameters
%alpha_noise, beta_noise = random noise can be
% introduced into the acoustic nav system
% with these two inputs
%D = overall water depth
%
%OUTPUT VECTOR [6]:
%Alpha = heading angle to beacon (0 -> 360 deg)
%Psi = absolute heading angle (0 -> 360 deg)
%R = range to beacon in the horizontal plane
%Z = vehicle depth
%H = vehicle height from bottom (altitude)
%//////////////////////////////////////////////////////////

%Define input parameters

Beacon_X = input(1);
Beacon_Y = input(2);
Beacon_Z = input(3);
X = input(4);
Y = input(5);
Z = input(6);
Psi = input(7); %degrees
Xdot = input(8);
Ydot = input(9);
Zdot = input(10);
Psidot = input(11);
Alpha_noise = input(12);
Beta_noise = input(13);
D = input(14);
 108

%Define separation distances

X_sep = Beacon_X - X;
Y_sep = Beacon_Y - Y;
Z_sep = Beacon_Z - Z;

%Calculate altitude
H = D-abs(Z);

%Calculate theoretical range to beacon with no noise

R = sqrt(Y_sep^2 + X_sep^2);

%Re-Calculate range to beacon with random acoustic noise

%This is done by calculating the elevation angle that the
%acoustic nav system would see, then adding noise to that
%angle (Beta), then re-calculating "R" from the noisy "Beta"
%NOTE: MATLAB Trig functions use radians!
%Beta = mod(atan(abs(Z_sep)/R)*(180/pi),360) + Beta_noise;
%R = abs(Z_sep)/tan(Beta*(pi/180));

%-------------------------------------------
%Calculate heading angle to beacon (in degrees) with random
acoustic noise
%-------------------------------------------
Delta = atan(abs(Y_sep)/abs(X_sep))*(180/pi);

%This if/else statement determines what quadrant the beacon is in

if X_sep >= 0
if Y_sep < 0
Delta = (90-Delta) + 270;
end
else
if Y_sep < 0
Delta = Delta + 180;
else
Delta = (90-Delta) + 90;
end
end

Alpha = (Delta - Psi);

if Alpha < 0
Alpha = 360 + Alpha;
end

%----------------------------------------------------------------
%Convert Alpha & Psi from 0->360deg angles to -180->180deg angles
%----------------------------------------------------------------
if Alpha > 180
Alpha = Alpha - 360;
end

if Psi > 180

Psi = Psi - 360;
 109

end

%Create output vector

output = [Alpha, Psi, R, Z, H, Xdot];
 110

function [output] = mission_planner(input)

%///////////////////////////////////////////////////////
%Filename: mission_planner.m
%
%Description: This function implements the high-level
% AUV mission planner
%
%Author: Lee Frey
%///////////////////////////////////////////////////////

%Define input parameters

Alpha = input(1);
Psi = input(2);
R = input(3);
Z = input(4);
H = input(5);
Xdot = input(6);
collision_flag = input(7);
emergency_flag = input(8);

stop = 0;

%Stop when AUV has arrived at target

if R < 0.3
stop = 1;
end

%Heading decision (go to beacon)

heading_command = 0;

%Speed decision (ft/s)

if R < 10; %Slow-down
speed_command = 0.25;
else %Cruise
speed_command = 1.0;
end

%Depth decision
if R < 10 %Surface
depth_command = -1;
elseif R < 25 %Dive to 15ft.
depth_command = -15;
else %Dive to 20ft.
depth_command = -20;
end

depth_error = depth_command - Z;
heading_error = Alpha - heading_command;
speed_error = speed_command - Xdot;

output = [heading_error, speed_error, depth_error, stop];

 111

function [output] = sliding_heading_controller(input)

%///////////////////////////////////////////////////////
%Filename: sliding_heading_controller.m
%
%Description: This function acts as a hybrid sliding-mode
% heading controller and PID speed controller
%
%Author: Lee Frey
%///////////////////////////////////////////////////////

PSIe = input(1); %Heading Error

PSIedot = input(2); %Heading Error Rate

%Adjust Ks (maximum control signal ... 1 lbf)

Ks = 1;

%Adjust Sliding-Mode Heading Controller Gains (Ht = [h1 h2])

h1 = 0.5;
h2 = 0.1;

%Implement the sign function for the sliding mode controller ...
[sgn(s)]
%where the boundary layer = +/- 3 degrees
if (h1*PSIe + h2*PSIedot) <= -3
sgn_s = 1;
flag = 1;
elseif (h1*PSIe + h2*PSIedot) >= 3
sgn_s = -1;
flag = 1;
else
sgn_s = 0;
flag = 2;
end

%Calculate the control signal

if flag == 1 %Use sliding-mode to make a heading
correction
u1 = Ks*sgn_s;
u2 = -Ks*sgn_s;
else %Use PID to move vehicle forward
(Simulink Block)
u1 = 0;
u2 = 0;
end

T1 = u1;
T2 = u2;

output = [flag, T1, T2];

 112

function [output] = fuzzy_heading_controller(input)

%///////////////////////////////////////////////////////
%Filename: fuzzy_heading_controller.m
%
%Description: This function acts as a fuzzy-logic
% AUV heading controller
%
%Author: Lee Frey
%///////////////////////////////////////////////////////

e = (input(1) - input(2));

%port_thrust_ratio = .50;
%stbd_thrust_ratio = .50;

%Behavior Rule Base Lengths

b1 = 3; %straight
b2 = 17; %swooping
b3 = 70; %tank turn
b4 = 90; %full turn

%Behavior Rule Heights

h1 = 50; %straight
h2 = 50; %swooping
h3 = 50; %tank
h4 = 50; %full turn

%Behavior Rule Slopes

m1 = 0;
m2 = (50/b2);
m3 = (50/b3);
m4 = 0;

%-------------------
%Fuzzy Control Logic
%-------------------
if e < 180
if e < b4
if e > (b1+b2)
%LEFT FUZZY TANK TURN
stbd = (m3*(e-(b1+b2))); %y = m*x
port = -stbd;
elseif e > b1
%LEFT FUZZY SWOOPING TURN
stbd = (50 + m2*(e-b1));
port = (50 - m2*(e-b1));
else
%GO STRAIGHT
stbd = h1;
port = h1;
end
else
 113

%FULL LEFT TANK TURN

stbd = h4;
port = -h4;
end
%---------------------------------------------------
else
if e > (360-b4)
if e < (360-(b1+b2))
%RIGHT FUZZY TANK TURN
port = (m3*((360-(b1+b2))-e));
stbd = -port;
elseif e < (360-b1)
%RIGHT FUZZY SWOOPING TURN
port = (50 - m2*((360-b1)-e));
stbd = (50 + m2*((360-b1)-e));
else
%GO STRAIGHT
port = h1;
stbd = h1;
end
else
%FULL RIGHT TANK TURN
port = h4;
stbd = -h4;
end
end

%DETERMINE THRUST RATIOS

port_thrust_ratio = port/100;
stbd_thrust_ratio = stbd/100;

output = [port_thrust_ratio, stbd_thrust_ratio];

 Appendix B:
Mechanical Drawings
115
116
117
118
119
120
121
122
 Appendix C:
BLDC Motor Controller Board
(patent pending)
124
 125

PCB Layout – Pads & Silkscreen Layer

 126

PCB Layout – Top Copper Layer

 127

PCB Layout – Bottom Copper Layer

 128

//BLDC.C Header File

#ifndef _BLDC_H
#define _BLDC_H
#endif

//Function prototypes
void getCommand(); //parses incoming
//commands
void getStatus(); //gets current motor
//states (RPM, direction)
void runPID(int Kp, int Ki, int Kd); //computes PID control
//action and outputs it
//to motors
void sendStatus(); //sends motor status info
//to user via serial port
void sendVersion(); //sends firmware version
//information
int initPort(int baud); //initializes PIC serial
//port USARTs
void writeByte(char byte); //sends a character to
//PIC serial port
char readByte(); //reads a character from
//PIC serial port
void interrupt ccpInterrupt(); //CCP capture interrupt
//handler
 129

/* ///////////////////////////////////////////////////////
// FILENAME: BLDC.C
// DATE: 11/06/2002
// VERSION: 1.3.0
// AUTHOR: LEE FREY
// DESCRIPTION:
// This file implements a
// Dual Brushless-DC Motor Control
// Scheme on the PIC 16F876 series
// microcontroller, for use with the
// MC33035 motor control IC and
// the TLC7528 DAC.
//
// Communication with the PIC
// is performed via an RS-232 serial
// interface at 9600 baud, 8-data bits,
// 1-stop bit, no parity, no flow control.
//
// Motor speed control is achieved
// through the use of a digital
// PID-loop with hall-sensor
// velocity feedback.
//
// COMMENTS:
// [04/30/2002, v1.0.0, L.Frey] - Creation
// [10/10/2002, v1.1.0, L.Frey] - Removed character echos
// [10/29/2002, v1.2.0, L.Frey] - Modified sendStatus()
// function and added
// sendVersion() function
// [11/06/2002, v1.3.0, L.Frey] - Added digital PID
// control lines for
// future use (commented-
// out)
//
//
// COPYRIGHT:
// This program is the property
// of the Florida Insitute of
// Technology and was developed
// by the Underwater Technologies
// Laboratory (UTL) of the Department
// of Marine & Environmental
// Systems (DMES). Reproduction
// or use of this program outside
// of Florida Tech is allowed for
// academic purposes only, provided
// credit is given to the author and
// the Florida Tech UTL. Commercial
// use is prohibited without permission
// from the UTL.
//
/////////////////////////////////////////////////////// */
 130

#include <pic.h>
#include <bldc.h>
#include <delay.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

#define PORTBIT(adr, bit) ((unsigned)(&adr)*8+(bit))

#define bitset(var, bitno) ((var) |= 1 << (bitno))
#define bitclr(var, bitno) ((var) &= ~(1 << (bitno)))
#define FOSC (4000000L)

// Pin definitions
static bit brakeA @ PORTBIT(PORTA, 0); //0 = run, 1 = brake
static bit brakeB @ PORTBIT(PORTA, 1); //0 = run, 1 = brake
static bit dirA @ PORTBIT(PORTA, 2); //0 = rev, 1 = fwd
static bit dirB @ PORTBIT(PORTA, 3); //0 = rev, 1 = fwd
static bit DACwrite @ PORTBIT(PORTA, 5); //0 = write, 1 = hold,
static bit DACselect @ PORTBIT(PORTC, 3); //0 = DAC-A, 1 = DAC-B
static bit speedfbA @ PORTBIT(PORTC, 1); //2 pulses = 1 revolution
static bit speedfbB @ PORTBIT(PORTC, 2); //2 pulses = 1 revolution

//Global motor variables (alot of globals are used in this

program, but the PIC doesn't care)
unsigned int spdA_desired = 0;
unsigned int spdB_desired = 0;
unsigned int spdA_actual = 0;
unsigned int spdB_actual = 0;
unsigned char dirA_desired = 1;
unsigned char dirB_desired = 1;

/*
//These are used to clock motor RPM
unsigned int timeA = 0;
unsigned int timeB = 0;
char interruptA = 0;
char interruptB = 0;

//Speed error terms

int eA = 0; //Motor A speed error at time=t
int eA1 = 0; //Motor A speed error at time=t-1
int eA2 = 0; //Motor A speed error at time=t-2
int eB = 0; //Motor B speed error at time=t
int eB1 = 0; //Motor B speed error at time=t-1
int eB2 = 0; //Motor B speed error at time=t-2

//Speed controller outputs

int uA = 0;
int uA1 = 0;
 131

int uB = 0;
int uB1 = 0;
*/

void main()
{
//setup initial conditions
int init = initPort(9600); //initialize on-board
//serial port USARTs
//to 9600 baud,8,N,1

ADCON1 = 0x07; //Set PORTA to digital I/O

TRISA = 0x00; //Set PORTA as all outputs
TRISB = 0x00; //Set PORTB as all outputs
TRISC = 0xf7; //Set RC3 as an output, all
//others as inputs
PORTB = 0x00; //Motor Speeds = 0
PORTA = 0x2c; //Brakes off, Dirs = fwd, DAC =
hold

if(init==0) //serial communications are

open
{
for(;;) //start infinite loop
{
char start;
do //poll serial port for incoming
commands
{
runPID(1,0,0); //run PID controller
//while waiting
//(Kp = 1,Ki = 0,Kd = 0)
}while(!RCIF);

start = RCREG; //something came in, so

//let's see what it is

if(start == '<') //user is sending a motor

//command
{
getCommand();
}
else if(start == 'v') //user is requesting
//software version info
{
sendVersion();
}

else if(start == '?') //user is requesting

//motor status info
 132

{
//getStatus();
sendStatus();
}
else //must have been garbage, so ignore
{
RCIF = 0;
}
}
}
else
{
init = initPort(9600); //try again
}
}

void getCommand()
{
//-----------------------------------------------------------------
//NOTE: The command string must be ASCII text, sent in the
//following form:
// <rpmA,dirA,rpmB,dirB>
//Where rpmA/rpmB are the desired motor speeds, and dirA/dirB = 1
//or 0 (fwd/rev)
//The commands must be comma-delimited, and enclosed with "< >"
//-----------------------------------------------------------------

char incoming[20]; //variable declarations

must be done first for some reason
char *substring;
int i;
int cmd;

for(i=0;incoming[i-1]!='>';i++) //get the incoming

command string
{
incoming[i] = readByte();
}
incoming[i-1] = '\0'; //null-terminate the string
//(erases the last '>')

//-----------------------------------------------------------------
//Parse the commands from the string, convert them to integer
//values, and store them in the appropriate variables if they are
//valid commands
//This way, if invalid commands are sent, the motors will stay the
//same
//-----------------------------------------------------------------
 133

substring = strtok(incoming,",");
cmd = atoi(substring);
if((cmd <= 255) && (cmd >= 0)) //speed boundaries (%)
{
spdA_desired = cmd;
}
substring = strtok(NULL,",");
cmd = atoi(substring);
if((cmd == 1) || (cmd == 0))
{
dirA_desired = cmd;
}
substring = strtok(NULL,",");
cmd = atoi(substring);
if((cmd <= 255) && (cmd >= 0)) //speed boundaries (%)
{
spdB_desired = cmd;
}
substring = strtok(NULL,",");
cmd = atoi(substring);
if((cmd == 1) || (cmd == 0))
{
dirB_desired = cmd;
}
}

void runPID(int Kp, int Ki, int Kd)

{
/*
int K0 = Kp+Kd; //Modified PID controller gains
//for digital implementation
int K1 = Ki - 2*Kd - Kp;
int K2 = Kd;
int delta_uA; //control signal change
//variables
int delta_uB;
getStatus(); //make sure all motor state
//info (RPM & Dir) is current

//----------------------------------------------------
//This is the digital PID speed controller for motor A
//----------------------------------------------------
eA = spdA_desired - spdA_actual; //calculate current
//speed error

delta_uA = (K0*eA + K1*eA1 + K2*eA2); //calculate control

//signal change

uA = uA1 + delta_uA; //calculate new

//control signal
 134

eA2 = eA1; //shift error and

//control terms in
//time
eA1 = eA;
uA1 = uA;

if(uA > 255) //control signal upper bound

{
uA = 255;
}
else if(uA < 0) //control signal lower bound
{
uA = 0;
}

PORTB = uA; //Output speed command to DAC-A

*/

PORTB = spdA_desired;
DACselect = 0; //Select DAC-A
DACwrite = 0; //Enable writing data to DAC-A
DACwrite = 1; //Hold data at DAC-A

//--------------------------------------------
//This is the direction controller for motor A
//--------------------------------------------
if(dirA != dirA_desired) //Switch direction of motor A
if necessary
{
brakeA = 1; //set brake A
dirA = dirA_desired; //set Direction A
DelayMs(100); //wait a bit to avoid jerking
//on direction change
brakeA = 0; //release brake A
}

/*
//----------------------------------------------------
//This is the digital PID speed controller for motor B
//----------------------------------------------------
eB = spdB_desired - spdB_actual; //calculate current speed
//error
delta_uB = (K0*eB + K1*eB1 + K2*eB2); //calculate control
//signal change
uB = uB1 + delta_uB; //calculate new
//control signal
eB2 = eB1; //shift error and
//control terms in
//time
eB1 = eB;
uB1 = uB;
 135

if(uB > 255) //control signal upper bound

{
uB = 255;
}
else if(uB < 0) //control signal lower bound
{
uB = 0;
}

PORTB = uB; //Output speed command to DAC-B

*/

PORTB = spdB_desired; //!!!!delete this line when the

//PID controller works
DACselect = 1; //Select DAC-B
DACwrite = 0; //Enable writing data to DAC-B
DACwrite = 1; //Hold data at DAC-B

//--------------------------------------------
//This is the direction controller for motor B
//--------------------------------------------
if(dirB != dirB_desired) //Switch direction of motor B
//if necessary
{
brakeB = 1; //set brake B
dirB = dirB_desired; //set direction B
DelayMs(100); //wait a bit to avoid
//jerking on direction
//change
brakeB = 0; //release brake B

}
}

/*
void getStatus()
{
//!!!! NOTE: due to the limitations of the timer1 module,
//motor speed cannot be accurately determined under 240 RPM!

GIE = 1; //enable all interrupts

interruptA = 0; //clear interrupt flags
//interruptB = 0;

//Get speed of motor A

CCP2IE = 1; //enable CCP2 interrupt
CCP2CON = 0b00000110; //initialize CCP2 module to
//capture on 4th rising
//edge (2 revs)
 136

TMR1H = 0; //clear timer 1

TMR1L = 0;
T1CON = 0b0011001; //prescaler = 8, sync on
//Fosc/4, start timer
while(interruptA == 0){} //wait for a CCP interrupt
T1CON = 0b0011000; //stop timer 1
CCP2CON = 0b00000000; //stop CCP2 capture
CCP2IE = 0; //disable CCP2 interrupt
spdA_actual = (timeA / 250000)*60; //calculate speed (RPM)
//of motor A

//Get Speed of motor B

CCP1IE = 1; //enable CCP1 interrupt
CCP1CON = 0b00000110; //initialize CCP1 module to
//capture on 4th rising
//edge (2 revs)
TMR1H = 0; //clear timer 1
TMR1L = 0;
T1CON = 0b0011001; //prescaler = 8, sync on
//Fosc/4, start timer
while(interruptB == 0){} //wait for a CCP interrupt
T1CON = 0b0011000; //stop timer 1
CCP1CON = 0b00000000; //stop CCP1 capture
CCP1IE = 0; //disable CCP1 interrupt
spdB_actual = (timeB / 250000)*60; //calculate speed (RPM)
of motor B

GIE = 0; //disable all interrupts

}
*/

/*
void interrupt ccpInterrupt()
{
if(CCP1IF) //motor B
{
timeB = CCPR1H + CCPR1L;
CCP1IF = 0;
interruptB = 1;
}

if(CCP2IF) //motor A
{
timeA = CCPR2H + CCPR2L;
CCP2IF = 0;
interruptA = 1;
}
}
*/
 137

void sendStatus()
{
//send motor speeds and directions (just sends desired speeds
//for now, until getStatus() works)

int j = 0;
char message[15];
sprintf(message, "[%3d,%1d,%3d,%1d]", spdA_desired, dirA,
spdB_desired, dirB);

for(j=0;j<sizeof(message);j++)
{
writeByte(message[j]);
}
writeByte('\r');
writeByte('\n');
}

void sendVersion()
{
//send firmware version information

int j = 0;
char message[24];
sprintf(message, "BLDC v1.3.0 - 11/06/2002");

for(j=0;j<sizeof(message);j++)
{
writeByte(message[j]);
}
writeByte('\r');
writeByte('\n');
}

int initPort(int baud)

{
int X; // calculate and set baud rate
register
unsigned long tmp; // for asynchronous mode
tmp = 16UL * baud;
X = (int)(FOSC/tmp) - 1;
if((X>255) || (X<0))
{
tmp = 64UL * baud;
X = (int)(FOSC/tmp) - 1;
if((X>255) || (X<0))
{
return 1; // panic - baud rate unobtainable
}
 138

else
{
BRGH = 0; // low baud rate
}
}
else
{
BRGH = 1; // high baud rate
}

SPBRG = X; // set the baud rate

SYNC = 0; // asynchronous
SPEN = 1; // enable serial port
TXEN = 1; // enable the transmitter
CREN = 1; // enable the receiver
SREN = 0; // no effect
TXIE = 0; // disable tx interrupts
RCIE = 0; // disable rx interrupts
TX9 = 0; // 8-bit transmission
RX9 = 0; // 8-bit reception

return 0;
}

void writeByte(char byte)

{
while(!TXIF) // this flag is set when the TXREG
register is empty
continue;
TXREG = byte;

return;
}

char readByte()
{
while(!RCIF) //this flag is set when the RCREG
register is not empty
continue;

return RCREG;
}
 Appendix D:
SSBL Acoustic Navigation Board
(patent pending)
140
 141

PCB Layout – Pads & Silkscreen Layer

 142

PCB Layout – Top Copper Layer

 143

PCB Layout – Bottom Copper Layer

 144

//ANAV.C Header File

#ifndef _ANAV_H
#define _ANAV_H
#endif

//Function prototypes
void sendVersion(); //sends firmware version information
//via serial port
int initPort(int baud); //initializes PIC serial port USARTs
void writeByte(char byte); //sends a character to PIC serial
//port
char readByte(); //reads a character from PIC serial
//port
void listenForBeacon(); //polls detection pins for beacon
//signal arrival
void calculateBearings(); //calculates alpha & beta based on
//time-of-arrival delays
void sendResult(); //sends alpha, beta, and arrival
//times (t1, t2, t3) over serial port
 145

/* ///////////////////////////////////////////////////////
// FILENAME: ANAV.C
// DATE: 10/30/2002
// VERSION: 1.0.0
// AUTHOR: LEE FREY
// DESCRIPTION:
// This file implements a Super-Short
// Baseline (SSBL) Acoustic Navigation
// System for an Autonomous Underwater Vehicle
// (AUV).
//
// It times the difference between arrivals
// of a SONAR ping at three transducers and
// uses these time differences
// to compute bearing angles to the beacon
// in the horizontal and vertical
// planes.
//
// The result of the computation is then output
// to a host PC via RS-232 serial port
// at 9600-8-N-1, in the form of an ASCII text string
// which looks like "[alpha,beta]", where alpha is
// the horizontal bearing angle (degrees) and beta
// is the vertical bearing angle (degrees).
//
// COMMENTS:
// [10/30/2002, v1.0.0, L.Frey] – Creation (test mode)
//
// COPYRIGHT:
// This program is the property
// of the Florida Insitute of
// Technology and was developed
// by the Underwater Technologies
// Laboratory (UTL) of the Department
// of Marine & Environmental
// Systems (DMES). Reproduction
// or use of this program outside
// of Florida Tech is allowed for
// academic purposes only, provided
// credit is given to the author and
// the Florida Tech UTL. Commercial
// use is prohibited without permission
// from the UTL.
//
/////////////////////////////////////////////////////// */

#include <pic.h>
#include <anav.h>
#include <delay.h>
#include <stdio.h>
#include <math.h>
 146

#include <stdlib.h>
#include <string.h>

#define PORTBIT(adr, bit) ((unsigned)(&adr)*8+(bit))

#define bitset(var, bitno) ((var) |= 1 << (bitno))
#define bitclr(var, bitno) ((var) &= ~(1 << (bitno)))
#define FOSC (20000000L)

// Pin definitions
static bit T1 @ PORTBIT(PORTB, 0); //Forward
//Transducer (1)
static bit T2 @ PORTBIT(PORTB, 1); //Starboard
//Transducer (2)
static bit T3 @ PORTBIT(PORTB, 2); //Port
//Transducer (3)
static bit LED1 @ PORTBIT(PORTC, 0);
static bit LED2 @ PORTBIT(PORTC, 1);
static bit LED3 @ PORTBIT(PORTC, 2);

//global variables
#define XDCR_SPACING 12 //length of side of transducer array
//triangle, (inches)
#define XDCR_TIMEOUT 65000 //maximum timer count while waiting
//for transducer detection
int time1 = 0;
int time2 = 0;
int time3 = 0;
int alpha = 0;
int beta = 0;
char gotBeacon = 0;
char gotT1 = 0;
char gotT2 = 0;
char gotT3 = 0;

void main()
{
int init = initPort(9600); //initialize on-board
//serial port USARTs
//to 9600 baud, 8-N-1

//Setup initial conditions

TRISB = 0xff; //Set RB0,1,2 as inputs
TRISC = 0xf8; //Set RC0,1,2 as outputs,
//all others as inputs

if(init==0)
{
sendVersion(); //send version info on startup
DelayMs(250); //wait a bit...
 147

T1CON = 0x00; //setup Timer1 (1:1 Prescaler,

//Timer mode, Timer OFF)
TMR1IF = 0; //reset overflow flag
TMR1IE = 0; //disable TMR1 interrupt

for(;;) //start infinite loop

{
listenForBeacon();
calculateBearings();
sendResult();
}
}
else
{
init = initPort(9600); //try again
}
}

void listenForBeacon()
{
gotBeacon = 0;
gotT1 = 0;
gotT2 = 0;
gotT3 = 0;
TMR1L = 0;
TMR1H = 0;

do //poll the detection pins

{
if((gotT1 == 0) && (T1 == 1))
{
gotT1 = 1; //we received a signal at T1
time1 = 0; //it was the first one
TMR1ON = 1; //start the timer

//keep listening until timeout is reached or

//we receive the signal at all 3 transducers
do{
if((gotT2 == 0) && (T2 == 1))
{
time2 = (TMR1L + TMR1H<<8);
gotT2 = 1;
}
if((gotT3 == 0) && (T3 == 1))
{
time3 = (TMR1L + TMR1H<<8);
gotT3 = 1;
}
if((gotT1 == 1) && (gotT2 == 1) && (gotT3
== 1))
{
gotBeacon = 1;
 148

}while(((TMR1L + TMR1H<<8) < XDCR_TIMEOUT) &&

(gotBeacon == 0));

TMR1ON = 0; //stop the timer

TMR1L = 0; //reset the timer
TMR1H = 0;
}

else if((gotT2 == 0) && (T2 == 1))

{
gotT2 = 1; //we received a signal at T2
time2 = 0; //it was the first one
TMR1ON = 1; //start the timer

//keep listening until timeout is reached or

//we receive the signal at all 3 transducers
do{
if((gotT1 == 0) && (T1 == 1))
{
time1 = (TMR1L + TMR1H<<8);
gotT1 = 1;
}
if((gotT3 == 0) && (T3 == 1))
{
time3 = (TMR1L + TMR1H<<8);
gotT3 = 1;
}
if((gotT1 == 1) && (gotT2 == 1) && (gotT3
== 1))
{
gotBeacon = 1;
}

}while(((TMR1L + TMR1H<<8) < XDCR_TIMEOUT) &&

(gotBeacon == 0));

TMR1ON = 0; //stop the timer

TMR1L = 0; //reset the timer
TMR1H = 0;
}

else if((gotT3 == 0) && (T3 == 1))

{
gotT3 = 1; //we received a signal at T3
time3 = 0; //it was the first one
TMR1ON = 1; //start the timer
 149

//keep listening until timeout is reached or

//we receive the signal at all 3 transducers
do{
if((gotT1 == 0) && (T1 == 1))
{
time1 = (TMR1L + TMR1H<<8);
gotT1 = 1;
}
if((gotT2 == 0) && (T2 == 1))
{
time2 = (TMR1L + TMR1H<<8);
gotT2 = 1;
}
if((gotT1 == 1) && (gotT2 == 1) && (gotT3
== 1))
{
gotBeacon = 1;
}

}while(((TMR1L + TMR1H<<8) < XDCR_TIMEOUT) &&

(gotBeacon == 0));

TMR1ON = 0; //stop the timer

TMR1L = 0; //reset the timer
TMR1H = 0;
}

}while(gotBeacon == 0);
}

void calculateBearings()
{
//determine which 60-degree zone the beacon came from
//and calculate its alpha value.

//NOTE: For testing, the alpha value is just set to the zone
//number.
//the trigonometric calculations to resolve alpha to 1-degree
//resolution will be added later

if(time1 < time2)

{
if(time3 < time1) //3,1,2 (240-300, Zone 5)
{
alpha = 5;
}
else
{
if(time3 < time2) //1,3,2 (300-360, Zone 6)
{
 150

alpha = 6;
}
else //1,2,3 (0-60, Zone 1)
{
alpha = 1;
}
}
}

else if(time2 < time1)

{
if(time1 < time3) //2,1,3 (60-120, Zone 2)
{
alpha = 2;
}
else
{
if(time2 < time3) //2,3,1 (120-180, Zone 3)
{
alpha = 3;
}
else //3,2,1 (180-240, Zone 4)
{
alpha = 4;
}
}
}

//Need to calculate beta, the vertical bearing angle ... will

//work on that later.
beta = 0;
}

void sendResult()
{
int j = 0;

//For testing, send out the timer values as well, so we can

//check the results
char message[21];
sprintf(message, "[%3d,%3d,%3d,%3d,%3d]", alpha, beta, time1,
time2, time3);

for(j=0;j<sizeof(message);j++)
{
writeByte(message[j]);
}
writeByte('\r');
writeByte('\n');
}
 151

void sendVersion()
{
//send firmware version information

int j = 0;
char message[24];
sprintf(message, "ANAV v1.0.0 - 10/30/2002");

for(j=0;j<sizeof(message);j++)
{
writeByte(message[j]);
}
writeByte('\r');
writeByte('\n');
}

int initPort(int baud)

{
int X; // calculate and set baud rate
register
unsigned long tmp; // for asynchronous mode
tmp = 16UL * baud;
X = (int)(FOSC/tmp) - 1;
if((X>255) || (X<0))
{
tmp = 64UL * baud;
X = (int)(FOSC/tmp) - 1;
if((X>255) || (X<0))
{
return 1; // panic - baud rate unobtainable
}
else
{
BRGH = 0; // low baud rate
}
}
else
{
BRGH = 1; // high baud rate
}

SPBRG = X; // set the baud rate

SYNC = 0; // asynchronous
SPEN = 1; // enable serial port
TXEN = 1; // enable the transmitter
CREN = 1; // enable the receiver
SREN = 0; // no effect
TXIE = 0; // disable tx interrupts
RCIE = 0; // disable rx interrupts
TX9 = 0; // 8-bit transmission
 152

RX9 = 0; // 8-bit reception

return 0;
}

void writeByte(char byte)

{
while(!TXIF) // this flag is set when the TXREG
register is empty
continue;
TXREG = byte;

return;
}

char readByte()
{
while(!RCIF) //this flag is set when the RCREG
register is not empty
continue;

return RCREG;
}