Thesis Tuvaaq

8/8/2019 Thesis Tuvaaq

1/169

Development of an Autonomous Underwater Vehicle for

Sub-Ice Environmental Monitoring in Prudhoe Bay, Alaska

by

Charles Lee Frey

Bachelor of ScienceOcean Engineering

Florida Institute of Technology1999

A thesis submitted to theFlorida Institute of Technology

In partial fulfillment of the requirements

for the degree of

Master of Sciencein

Ocean Engineering

Melbourne, FloridaDecember, 2002


2/169

2002 Charles Lee FreyAll Rights Reserved

The author grants permission to make single copies _______________________


3/169

The undersigned committee hereby recommends that the attached documentbe accepted as fulfilling in part the requirements for the degree of

Master of Science in Ocean Engineering

Development of an Autonomous Underwater Vehicle forSub-Ice Environmental Monitoring in Prudhoe Bay, Alaska

byCharles 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


4/169

iii

Abstract

Development of an Autonomous Underwater Vehicle forSub-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 Bayregion of the Beaufort Sea, along Alaskas 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.


5/169

iv

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

and simulation of the system is performed. Then, the design of the AUVs various

subsystems is presented, including propulsion, navigation, environmental sensor

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

prototype development are presented.


6/169

v

Table of Contents

List of Keywords vii

List of Figures viiiList of Tables xiList of Abbreviations xiiList of Symbols xiiiAcknowledgements xvDedication xvi

1. Introduction 1

1.1 The ANIMIDA Project 11.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 173.2.1 AUV Dynamics 183.2.2 Navigation System 223.2.3 Mission Planner 23

3.2.4 Low Level Controllers (Depth & Heading) 253.2.5 Simulation Results 30

3.3 Prototype Design & Construction Tuvaaq 373.3.1 Mechanical Assembly 373.3.2 Propulsion 423.3.3 Navigation 543.3.4 Environmental Sensor Payload 713.3.5 Main Computer 74

3.3.5.1 Internal Communications 763.3.5.2 External Communications 77

3.3.6 Power 813.3.7 High-Level Software 84

4. Results & Conclusions 94


7/169

vi

5. Recommended Future Work 96

References 99

Appendices 101

A. MATLAB Simulation Source Code 101 B. Mechanical Drawings 114C. BLDC Motor Controller Board 123

(Schematics, PCB Layout, PIC Source Code)D. SSBL Acoustic Navigator Board 139

(Schematics, PCB Layout, PIC Source Code)


8/169


9/169

viii

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 Engineerings nuclear inspection ROV Firefly 13

3.1.4 Prototype Prudhoe Class AUV design 143.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 383.3.1.2 AUV pressure vessel (1 of 4) 39

3.3.1.3 Underside of AUV, with PVC spacer plate shown 40


10/169

ix

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 fans3.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 743.3.5.2 Main PC/104 CPU Board 75

3.3.5.3 PC/104 serial expansion module 77


11/169

x

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 883.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


12/169


13/169

xii

List of Abbreviations

ADCP Acoustic Doppler Current Profiler

ANIMIDA Arctic Nearshore Impact Monitoring in the Development AreaAUV 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 ModulationROV 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


14/169


15/169

xiv

h(1,2) Sliding-Mode controller gain constants

H Altitude above seafloor

Z,d AUV depth

R Range to beacon

K s 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


16/169

xv

Acknowledgements

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

Dr. Stephen WoodDr. 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 BattinNagahiko Shinjo

Marc Damon

Carmen Serrano

Applied Microsystems, Inc.

Fumunda Marine, Inc.

Sensor, Inc.

Impulse, Inc.

Family & Friends


17/169

xvi

Dedication

This work is dedicated to my parents, who have helped me in lifemore 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.


18/169

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


19/169

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


20/169

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.


21/169

4

1. Overall vehicle concept and mission plan

2. Modeling and simulation

3. Prototype design and construction, including:

a. General mechanical assemblyb. Propulsion systemc. Navigation systemd. Environmental sensor payloade. On-board computing and communicationsf. Power systemg. 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 YesAutonomous Depth Following YesMinimum Operating Temperature (in water) -1.8 CMinimum Storage Temperature (in air) -20 CMaximum Water Current 0.05 m/sMaximum Operating Depth 50 mMaximum Speed 1 m/sMaximum Entry / Exit Hole Diameter 0.6 mMaximum Ice Thickness at Hole 2 mMaximum Distance Between Entry/Exit Holes 500 mMaximum Number of crew required 2 persons


22/169

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.


23/169

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 ships 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


24/169

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 UTLs 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.


25/169

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.


26/169

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 Masters

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.


27/169

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 vehicles 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


28/169

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.


29/169

12

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

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.

Beacon

Failed exit, vehicle entersturnaround maneuver

A roach ath


30/169

13

Fig. 3.1.3: Deep Ocean Engineerings Nuclear Inspection ROV Firefly

(from: www.deepocean.com)


31/169

14

Figure 3.1.4: Prototype Prudhoe Class AUV Design

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).

SSBL Transducer

Syntactic Foam

Thruster Tunnel

Protection Cage

Spacer Plate

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

Connector Rod


32/169

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.


33/169

16

Figure 3.1.5: Visual representation of AUV mission plan


34/169

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


35/169

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 axisz (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 thrusterT2 Thrust force from the starboard-side thrusterT3 Thrust force from the vertical thrusterFext(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***

20V AC F pd d = (3.2.1)

where:Cd = coefficient of drag = density of seawaterAp = projected drag areaV0 = velocity of drag surface

(*Note: rotational skin friction is considered nominal)


36/169

19

Other relevant parameters:

m vehicle mass (approx. 200lbs = 6.2 slugs)D separation between horizontal thrusters T 1 & 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 slugin 4)

Figure 3.2.1.1: AUV Body-Fixed Coordinate Reference Frame

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 T 1, T2, and T 3

x

y

z


37/169

20

act at the vehicles 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 vehicles center of buoyancy (C b) and center of gravity (C g), 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:

&&&& ym

F F T T x ext xdx ++++= )( 21 (3.2.2)

&&&& xm

F F y ext

ydy ++

= (3.2.3)

m

F W F T z ext zauvdz

++= 3&& (3.2.4)

where:

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

Fxext = F yext = F zext = 0 (assume no external currents or disturbances)


38/169

21

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

( )

z

ext z

I

M DT T + = 212

&& (3.2.5)

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:

==

&&&&

z

y x

z

y

x

x

x

x x

x

x

x

x

X

8

7

6

5

4

3

2

1

( )

+

==

3

12

21

2T

DT T

T T

F

M

F

u

z

z

x

(3.2.6)

where u is a function of T 1, T2, and T 3, 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.


39/169

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:

=

CosSin

SinCos X

BG (3.2.7)

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:

==

H

Z

R

x

x

x x

x

X nav

5

4

3

2

1

(3.2.8)


40/169

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.


41/169

24

Figure 3.2.3.1: AUV Mission Planner decision algorithm

Vehicle InWater Column?

STARTMISSION

MissionFile

Proceed withMission

Listen forBeacon

TimeoutExpired?

Abort Mission(Return to

Origin)

ReachedTarget?

Ascend toSurface

STOPMISSION

Vehicle Out ofWater Column?Descend to

Mission Depth 1

Standby

Yes

No

BeaconAcquired?

Yes

No

Yes

No

Load

No

Yes

Yes

No


42/169

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 (T 3). From equation (3), it can be seen that the relationship

between depth and thrust T 3 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

where:

Zdesired = depth command from mission plannere = depth errorT3 = vertical thruster outputK p = proportional gain

eK eK eK d i p &++ AUV ModelZdesired Zactual

INPUT CONTROLLER PLANT OUTPUT

T3 e


43/169

26

K i = integral gainK d = 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:

ehsT

= (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


44/169

27

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

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

Sliding Trajectory

e

Sliding Line

Boundary Layer

e&


45/169

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

where:

desired = heading command from mission plannerK s = +/- bounds on controller output (thruster limits)h1= error gainh2 = error rate gainT1 & 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]).

( )ehehK s &21sgn* + AUV Model desired out

INPUT CONTROLLER PLANT OUTPUTT1 , T2 e


46/169

29

Figure 3.2.4.4: PID speed controller block diagram

desired X & actual X

&

where:

desired X & = speed command from mission planner

e = speed errorT1, T2 = horizontal thruster outputsK p = proportional gainK i = integral gainK d = 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 vehicles 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 (T 1 & T2).

eK eK eK d i p &++ AUV Model

INPUT CONTROLLER PLANT OUTPUT

T1 ,T2 e


47/169

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.


48/169

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.


49/169


50/169

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.


51/169

34

Figure 3.2.5.5: AUV Course plot for moving beacon simulation


52/169

35

Figure 3.2.5.6: AUV Depth plot for moving beacon simulation

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

Vehicle ascends and descends inresponse to beacon movement


53/169

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 T 1 and T 2 should provide smoother control, with far less chattering and

loss in forward momentum.


54/169

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 Engineerings 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.


55/169

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


56/169

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)


57/169

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.


58/169

41

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


59/169

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.


60/169

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).


61/169

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.


62/169

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 AUVs 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 K t 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


63/169

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 wasremoved from the fixture and faced on an end-mill to ensure a perfectly toroidal

shape.


64/169

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-coatedrotor 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 6diameter trolling propeller.


65/169

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


66/169

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-woundCommutation Hall-effect# of Motors per board 2Reversing YesMotor Voltage Range 12-24 VDCMaximum Motor Current 20 AMPS (per motor)Velocity Feedback Yes, PID loop

Communications RS-232 Serial @ 9600,8,1,NCircuit supply 12 VDC @ 200mA


67/169

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:

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.


68/169


69/169


70/169

53

Figure 3.3.2.9: Motor Controller Housing Internals

Figure 3.3.2.10: Sealed Motor Controller Housing


71/169

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


72/169

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.


73/169

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 vehicles 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


74/169

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

t12

t23

123

Beacon

t13


75/169


76/169

59

Figure 3.3.3.3: Propagation of hydroacoustic waves across a

triangular SSBL transducer array

Zone 1(0-60)

Zone 2(60-120)

Zone 3(120-180)

Zone 4(180-240)

Zone 5(240-300)

Zone 6(300-360)

t

ab

tbc

1

23

BeaconTOP VIEW

tac


77/169

60

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)

SIDE VIEW

tac

123

Beacon

tac max


78/169

61

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

X t t

ac

bc +

= 60 for odd-numbered zones (1,3,5) (3.3.1)

X t t

ac

ab +

= 60 for even-numbered zones (2,4,6) (3.3.2)

where,

t ab = time difference between the first and second transducers todetect the signal.

t bc = time difference between the second and last transducers todetect the signal.

t ac = time difference between the first and last transducers to detectthe signal.

X = lower angle limit of each zone (e.g. for Zone 5, X = 240)

3. Determine the vertical bearing angle ( ).

=

max

1

ac

ac

t t

Cos (3.3.3)

where,

t ac = time difference between the first and last transducers to detectthe signal.

t ac max = Maximum time difference between the first and lasttransducers to detect the signal, based on the flat-linedistance between them and an approximate speed of sound,C s = 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


79/169

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.

Tand R = (3.3.4)

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


80/169

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: 50log20log20 == r TL sph = 34.0 dB

450m Cylindrical spreading: 450log10log10 == r TLcyl = 26.5 dB

Absorption:12

21 log10log10r r

I I

= in this case, we can use Fig

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

kHz in seawater of approximately:

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


81/169

64

Summing these losses, we get a total of:

34.0 + 26.5 + 3.5 = 64 dB

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


82/169

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.


83/169


84/169

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


85/169

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


86/169

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 (t 1,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.


87/169

70

Figure 3.3.3.9: SSBL Firmware block diagram


88/169

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


89/169

72

Table 3.3.4.1: AUV Environmental Sensor Payload Specifications

CTD Conductivity SensorRange 0-7 S/mResolution 0.003 S/mAccuracy +/- 0.001 S/m

CTD Temperature SensorRange -2-32 CResolution 0.001 CAccuracy +/- 0.005 C

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

LSS Turbidity SensorRange 0-25 NTUResolution +/- 0.03 % full scale (0.0075 NTU)

System Power Requirements 12VDC @ 75mASystem Communications RS-232 Serial @ 9600,8,N,1System Data Output Format ASCII TextSystem Data Sample / OutputRate

15Hz

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.


90/169

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


91/169

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


92/169

75

The heart of the AUVs 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


93/169

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 CPUs 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.


94/169

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 Alaskas 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


95/169

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


96/169

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)


97/169

80

Figure 3.3.5.5: CPU Housing Internals with PC/104 Stack

Figure 3.3.5.6: Sealed CPU Housing


98/169

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 -10C).

Without losses, the vehicles 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.


99/169

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)


100/169

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 V in is at

least 6V).

Figure 3.3.6.2: PC/104 Power Supply Board


101/169

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 AUVs 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, Tuvaaqs 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).


102/169

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


103/169

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


104/169

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.


105/169

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

StopDescriptions of these menus options is given below.


106/169

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


107/169

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


108/169

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).


109/169

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


110/169

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 aut

Thesis Tuvaaq

Documents

Transcript of Thesis Tuvaaq