Embed Size (px)
Citation preview
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
iii
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.
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 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.
v
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
vi
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)
vii
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
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 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
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 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
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 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
xi
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
xii
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
xiii
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
xiv
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 …
xv
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…
xvi
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.
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 2 m 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”
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 enters turnaround maneuver
Approach path
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
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
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***
20V
ACF pdd ρ= (3.2.1)
…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
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
x
y
z
φ
θ
ψ
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:
ψ&&&& ym
FFTTx extxdx +
+++=
)( 21 (3.2.2)
ψ&&&& xm
FFy extydy +
+= (3.2.3)
m
FWFTz extzauvdz +−+
= 3&& (3.2.4)
… 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:
( )
z
extz
I
MD
TT +
−
= 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:
=
=
ψ
ψ
&&&&
zyx
zyx
xxxxxxx
x
X
8
7
6
5
4
3
2
1
( )
−
+
=
=
3
12
21
2T
DTT
TT
FMF
u
z
z
x
(3.2.6)
… 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:
−=
ψψψψ
CosSinSinCos
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:
=
=
HZR
xxxx
x
X nav
ψα
5
4
3
2
1
(3.2.8)
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
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
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
…where:
Zdesired = depth command from mission planner e = depth error T3 = vertical thruster output Kp = proportional gain
eKeKeK dip &++ ∫ AUV Model Zdesired Zactual
INPUT CONTROLLER PLANT OUTPUT
T3 e
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:
ehs T= (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
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&
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 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]).
( )ehehK s &21sgn* + AUV Model ψdesired ψout
INPUT CONTROLLER PLANT OUTPUT T1 , T2
e
29
Figure 3.2.4.4: PID speed controller block diagram
desiredX& actualX&
…where:
desiredX& = 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).
eKeKeK dip &++ ∫ AUV Model
INPUT CONTROLLER PLANT OUTPUT
T1 ,T2 e
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
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 in response to beacon movement
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 (Kt=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
α
∆t12
∆t23
1 2 3
Beacon
∆t13
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
Zone 1 (0º-60º)
Zone 2 (60º-120º)
Zone 3 (120º-180º)
Zone 4 (180º-240º)
Zone 5 (240º-300º)
Zone 6 (300º-360º)
α
∆tab
∆tbc
1
2 3
Beacon TOP VIEW
∆tac
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
1 2 3
Beacon
∆tac max
61
2. Determine the horizontal bearing angle (α) within the appropriate zone through time-of-arrival ratios:
Xtt
ac
bc +
∆∆
= º60α … for odd-numbered zones (1,3,5) (3.3.1)
Xtt
ac
ab +
∆∆
= º60α … for even-numbered zones (2,4,6) (3.3.2)
…where,
∆tab = time difference between the first and second transducers to detect the signal.
∆tbc = time difference between the second and last transducers to detect the signal.
∆tac = 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 (β).
∆
∆= −
max
1
ac
ac
tt
Cosβ (3.3.3)
… where, ∆tac = time difference between the first and last transducers to detect
the signal. ∆tac 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.
βTan
dR
∆= (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
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 == rTL sph = 34.0 dB
450m Cylindrical spreading: 450log10log10 == rTLcyl = 26.5 dB
Absorption: 12
21 log10log10rr
II−−
=α … 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)
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 Rate
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.
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; }
![arXiv:1710.00961v1 [physics.flu-dyn] 3 Oct 2017web.stanford.edu/group/prakash-lab/cgi-bin/labsite/wp-content/... · bacteria [Schuler and Frankel(1999),Zborowski et al.(2003)Zborowski,](https://img.pdfslide.us/doc/110x75/5c775ef009d3f229578bc3ef/arxiv171000961v1-3-oct-2017webstanfordedugroupprakash-labcgi-binlabsitewp-content.jpg)
