Tech. The purpose of this AUV is to perform automated point-to-point data collection missions ... 3.1.4 Prototype Prudhoe Class AUV design. 14. 3.1.5 Visual ...
Development of an Autonomous Underwater Vehicle for Sub-Ice Environmental Monitoring in Prudhoe Bay, Alaska
by Charles Lee Frey Bachelor of Science Ocean Engineering Florida Institute of Technology 1999
A thesis submitted to the Florida Institute of Technology In partial fulfillment of the requirements for the degree of
Master of Science in Ocean Engineering
Melbourne, Florida December, 2002
© 2002 Charles Lee Frey All Rights Reserved
The author grants permission to make single copies _______________________
The undersigned committee hereby recommends that the attached document be accepted as fulfilling in part the requirements for the degree of Master of Science in Ocean Engineering Development of an Autonomous Underwater Vehicle for Sub-Ice Environmental Monitoring in Prudhoe Bay, Alaska by Charles Lee Frey
Andrew Zborowski, Ph.D. Program Chair, Ocean Engineering
Stephen Wood, Ph.D., P.E. Assistant Professor, Ocean Engineering
Eric Thosteson, Ph.D., P.E. Assistant Professor, Ocean Engineering
Hector Gutierrez, Ph.D., P.E. Assistant Professor, Mechanical Engineering
Abstract Development of an Autonomous Underwater Vehicle for Sub-Ice Environmental Monitoring in Prudhoe Bay, Alaska Author: Charles Lee Frey Advisor: Stephen Wood, Ph.D., P.E.
Currently, research is underway at the Florida Institute of Technology, to investigate the environmental impacts of oil development in the Prudhoe Bay region of the Beaufort Sea, along Alaska’s northern coast. Of particular interest are the impacts of construction of offshore gravel islands used for oil drilling and production. Construction of these islands may contribute to increased suspended sediment concentrations in the waters of Prudhoe Bay, which may have adverse affects on the health of local marine ecosystems. To aid in this research, a unique Autonomous Underwater Vehicle (AUV) has been developed by the Underwater Technologies Laboratory (UTL) at Florida Tech. The purpose of this AUV is to perform automated point-to-point data collection missions underneath the thick winter ice sheet. This paper discusses the design and construction of the AUV prototype, known as “Tuvaaq”. Also included is a brief description of a small Remotely Operated Vehicle (ROV) and Towed Instrument Array (Towfish) used in Alaska during a summer field deployment.
iii
First, the overall design concept for the AUV is discussed. Next, modeling and simulation of the system is performed. Then, the design of the AUV’s various subsystems is presented, including propulsion, navigation, environmental sensor payload, CPU, power, and software. Finally, results of the simulation and prototype development are presented.
iv
Table of Contents
List of Keywords List of Figures List of Tables List of Abbreviations List of Symbols Acknowledgements Dedication
vii viii xi xii xiii xv xvi
1. Introduction
1
1.1 The ANIMIDA Project 1.2 Scope of Work & Design Criteria
1 3
2. Phase I : ROV & Towfish Development
5
3. Phase II: AUV Development
9
3.1
Overall Design Concept
9
3.2
Modeling & Simulation 3.2.1 AUV Dynamics 3.2.2 Navigation System 3.2.3 Mission Planner 3.2.4 Low Level Controllers (Depth & Heading) 3.2.5 Simulation Results
17 18 22 23 25 30
3.3
Prototype Design & Construction – “Tuvaaq” 3.3.1 Mechanical Assembly 3.3.2 Propulsion 3.3.3 Navigation 3.3.4 Environmental Sensor Payload 3.3.5 Main Computer 3.3.5.1 Internal Communications 3.3.5.2 External Communications 3.3.6 Power 3.3.7 High-Level Software
37 37 42 54 71 74 76 77 81 84
4. Results & Conclusions
94
v
5. Recommended Future Work
96
References
99
Appendices
101
A. MATLAB Simulation Source Code B. Mechanical Drawings C. BLDC Motor Controller Board (Schematics, PCB Layout, PIC Source Code) D. SSBL Acoustic Navigator Board (Schematics, PCB Layout, PIC Source Code)
vi
101 114 123 139
List of Keywords
Acoustic Navigation Alaska ANIMIDA Arctic Autonomous Underwater Vehicle (AUV) AUV Control Beaufort Sea Brushless DC (BLDC) Motor Department of the Interior (DOI) Department of Marine and Environmental Systems (DMES) Dynamic Modeling Florida Institute of Technology LabVIEW® MATLAB® Mineral Management Service (MMS) North Slope PC/104 Prudhoe Bay Simulation Simulink® Sliding-Mode Control Super-Short Baseline (SSBL) Tuvaaq Under-Ice Underwater Robotics Underwater Technologies Laboratory (UTL) Underwater Thruster Underwater Vehicles
vii
List of Figures
1.1.1
Map of the ANIMIDA study area
1
1.1.2
“Drilling for data” in Prudhoe Bay, near Northstar Island
2
2.1
Deploying the Hornet ROV in Prudhoe Bay, Summer 2001
6
2.2
Towfish deployment in Prudhoe Bay, Summer 2001
8
3.1.1
A typical AUV design, the Autosub-1
10
3.1.2
Flight path of torpedo-shaped AUV for a failed
12
“exit catch” 3.1.3
Deep Ocean Engineering’s nuclear inspection ROV “Firefly”
13
3.1.4
Prototype Prudhoe Class AUV design
14
3.1.5
Visual representation of AUV mission plan
16
3.2.1
®
®
MATLAB Simulink block diagram for AUV simulation
17
3.2.1.1 AUV body-fixed coordinate reference frame
19
3.2.3.1 AUV Mission Planner decision algorithm
24
3.2.4.1 PID depth controller block diagram
25
3.2.4.2 Sliding-Mode controller behavior in the error plane
27
3.2.4.3 Sliding-Mode heading controller block diagram
28
3.2.4.4 PID speed controller block diagram
29
3.2.5.1 AUV mission simulation - course plot
30
3.2.5.2 PID depth controller performance
31
3.2.5.3 Sliding-mode heading controller performance
32
3.2.5.4 PID speed controller performance
33
3.2.5.5 AUV course plot for moving beacon simulation
34
3.2.5.6 AUV depth plot for moving beacon simulation
35
3.3.1.1 Tuvaaq AUV mechanical assembly
38
3.3.1.2 AUV pressure vessel (1 of 4)
39
3.3.1.3 Underside of AUV, with PVC spacer plate shown
40
viii
3.3.1.4 Assembled AUV (acoustic transducer array not shown)
41
3.3.2.1 Typical Brushed DC motor construction
43
3.3.2.2 Typical Brushless DC motor construction
44
3.3.2.3 Motor fixture with coil, cable, and Hall-Effect sensors
46
3.3.2.4 Finished potted motor coil
47
3.3.2.5 Finished BLDC seal-less underwater thruster
48
3.3.2.6 Block diagram of BLDC Motor Controller circuit
49
3.3.2.7 Block diagram of BLDC Motor Controller PIC firmware
51
3.3.2.8 Final printed BLDC Motor Controller circuit board
52
3.3.2.9 Motor controller housing internals with 2-board stack
53
and cooling fans 3.3.2.10 Sealed motor controller housing
53
3.3.3.1 EZ-Compass 3 digital compass module
56
3.3.3.2 Propagation of hydroacoustic waves across a
57
straight-line transducer array 3.3.3.3 Propagation of hydroacoustic waves across a
59
triangular SSBL transducer array 3.3.3.4 ULB-350 Underwater Beacon
64
3.3.3.5 SX-38 38kHz omnidirectional transducer
65
3.3.3.6 SSBL transducer array mounted on test plate
66
3.3.3.7 Block diagram of SSBL Acoustic Navigator circuit
67
3.3.3.8 Block diagram of SSBL Acoustic Navigator PIC firmware
68
3.3.3.9 Final printed SSBL Acoustic Navigator circuit board
70
3.3.4.1 CTD & LSS instrument package
71
3.3.4.2 CTD sensor mounted on the AUV
73
3.3.5.1 AUV high-level system architecture block diagram
74
3.3.5.2 Main PC/104 CPU Board
75
3.3.5.3 PC/104 serial expansion module
77
ix
3.3.5.4 Linksys WUSB11 802.11b Wireless Ethernet Module
78
3.3.5.5 CPU housing internals with PC/104 stack
80
3.3.5.6: Sealed CPU Housing
80
3.3.6.1 Battery Pod internals with two SLA batteries
82
(parallel wiring) 3.3.6.2 Sealed Battery Pod (1 of 2)
82
3.3.6.3 PC/104 power supply board
83
3.3.7.1 The Tuvaaq AUV desktop, visible on a PC
85
running VNC Client 3.3.7.2 TUVAAQ software architecture block diagram
86
3.3.7.3 TUVVAQ main user interface panel
88
3.3.7.4 Configure Serial Devices panel
89
3.3.7.5 Offsets & Multipliers panel
90
3.3.7.6 Controller Gains panel
91
3.3.7.7 ROV Mode panel
92
x
List of Tables
1.2.1
AUV design criteria
4
3.3.2.1 Motor controller specifications
49
3.3.4.1 AUV environmental sensor payload specifications
72
xi
List of Abbreviations ADCP
Acoustic Doppler Current Profiler
ANIMIDA
Arctic Nearshore Impact Monitoring in the Development Area
AUV
Autonomous Underwater Vehicle
BLDC
Brushless DC
CTD
Conductivity, Temperature, Depth (sensor)
DGPS
Differential GPS (Global Positioning System)
DMES
Department of Marine & Environmental Systems (at Florida Tech)
DOE
Deep Ocean Engineering
DOF
Degree of Freedom
DOI
Department of the Interior
DVL
Doppler Velocity Log
LBL
Long Base-Line
LSS
Light Scattering Sensor (for measuring turbidity)
MMS
Mineral Management Service
PCB
Printed Circuit Board
PID
Proportional, Integral, Derivative
PWM
Pulse-Width Modulation
ROV
Remotely Operated Vehicle
RTOS
Real-Time Operating System
SLA
Sealed Lead-Acid
SSBL
Super Short Base-Line
USB
Universal Serial Bus
USBL
Ultra Short Base-Line
UTL
Underwater Technologies Laboratory (part of the DMES)
VNC
Virtual Network Computing
WLAN
Wireless Local Area Network
xii
List of Symbols
x
Surge
y
Sway
z
Heave
φ
Roll angle
θ
Pitch angle
ψ
Yaw angle (also magnetic bearing angle)
α
Horizontal acoustic bearing angle (also acoustic absorption factor)
β
Vertical acoustic bearing angle
T1
Thrust force from the port-side thruster
T2
Thrust force from the starboard-side thruster
T3
Thrust force from the vertical thruster
F(x,y,z)
Force in the (x,y,z) direction
M(x,y,z,)
Moment about the (x,y,z) axis
Fext(x,y,z,ψ)
External disturbance force in the (x,y,z,ψ) direction
Fd (x,y,z)
Linear hydrodynamic drag force in the (x,y,z) direction
Cd
Coefficient of drag
ρ
Density of seawater
Wauv
Weight of the AUV in water
r
Radius
Ap
Projected drag area
V0
Velocity of drag surface
m
Vehicle mass
I(x,y,z)
Moment of inertia about the (x,y,z) axis
D
Separation between horizontal thrusters
Kt
Motor torque constant
K(p,i,d)
Proportional, Integral, and Derivative gain constants
xiii
h(1,2)
Sliding-Mode controller gain constants
H
Altitude above seafloor
Z,d
AUV depth
R
Range to beacon
Ks
Sliding-mode controller maximum signal output
e
Error
t(1,2,3)
SSBL Transducer detection times
TL(sph,cyl)
Transmission loss from (spherical, cylindrical) spreading
∆…
Difference in …
xiv
Acknowledgements My sincerest thanks to those who have helped me along the way… Dr. Stephen Wood Dr. John Trefry Dr. Eric Thosteson Dr. Hector Gutierrez Dr. Pierre LaRochelle Dr. Andrew Zborowski Mineral Management Service Department of the Interior Florida Atlantic University Harbor Branch Oceanographic Institution Leslie Popp Adam Kay Larry Buist Dan Simpson John Lee Bill Battin Nagahiko Shinjo Marc Damon Carmen Serrano Applied Microsystems, Inc. Fumunda Marine, Inc. Sensor, Inc. Impulse, Inc.
Family & Friends…
xv
Dedication
This work is dedicated to my parents, who have helped me in life more than words can express.
To my Mother, for giving me the creativity and passion to pursue my dreams, whatever they may be. and… To my Father, for giving me the intellect and work ethic to achieve them.
xvi
1
1. Introduction: 1.1. The ANIMIDA Project In the Prudhoe Bay region of the Alaskan Beaufort Sea, oil drilling and exploration efforts are underway and expanding. Currently, the Mineral Management Service (MMS), under the Department of the Interior (DOI), has been tasked with the responsibility of studying the effects of offshore gravel-island based oil development on the marine environment. Dr. John Trefry, a professor of Oceanography at Florida Tech, is an active participant in a large research effort in this region, known as the Arctic Nearshore Impact Monitoring in the Development Area (ANIMIDA) Project. As a part of this research effort, studies are being conducted on the currentlyoperational 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. b. c. d. e. f. g.
General mechanical assembly Propulsion system Navigation system Environmental sensor payload On-board computing and communications Power system 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 Autonomous Sub-Ice Navigation Autonomous Depth Following Minimum Operating Temperature (in water) Minimum Storage Temperature (in air) Maximum Water Current Maximum Operating Depth Maximum Speed Maximum Entry / Exit Hole Diameter Maximum Ice Thickness at Hole Maximum Distance Between Entry/Exit Holes Maximum Number of crew required
Salinity, Temp, Depth, Turbidity Yes Yes -1.8 °C -20 °C 0.05 m/s 50 m 1 m/s 0.6 m 2m 500 m 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 scaleddown 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® Windowsbased 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 icespikes (although collision avoidance is beyond the scope of this thesis). This requires the ability to precisely position the vehicle at low speeds underneath the exit hole, assuming that the position of that hole is accurately known by the navigation system. Such fine control and stationkeeping tasks are virtually impossible for a conventional torpedo-shaped vehicle, steered by control surfaces such as rudders and dive planes, as the turning radii for such systems are usually very large and constant forward motion is required in order to generate lift on the control surfaces. Since the positioning tolerance for recovery of the Prudhoe Class AUV is so tight, failing to “catch” a torpedo-shaped vehicle during its first pass to exit would mean a complete wide turn-around in a decreasing spiral path (see Fig. 3.1.2), rather than a simple small position correction. Additionally, the horizontal flight characteristics of a torpedo-shaped vehicle further complicate the recovery effort, as the vehicle must be turned vertical before it can be lifted from the exit hole.
12 Figure 3.1.2: Flight path of torpedo-shaped AUV for a failed “exit catch”
Failed exit, vehicle enters turnaround maneuver
Beacon
Approach path
It was also determined that the benefits of low hydrodynamic were of little consequence since this particular AUV would be moving at such low speeds (< 1 m/s). The result of these design restrictions lead to a rather unconventional vehicle shape, intended to simplify control strategies, enhance maneuverability, and ease the launch and recovery effort (see Fig. 3.4). This shape was based on the design of a series of nuclear-inspection ROVs manufactured by Deep Ocean Engineering (DOE, www.deepocean.com) and will be discussed in more detail in section 3.3.1. The DOE ROVs work at slow speeds in tubular environments and what they lack in hydrodynamics, they make up for in maneuverability, stationkeeping, and ease of control.
13 Fig. 3.1.3: Deep Ocean Engineering’s Nuclear Inspection ROV “Firefly”
(from: www.deepocean.com)
14 Figure 3.1.4: Prototype Prudhoe Class AUV Design SSBL Transducer
Syntactic Foam Thruster Tunnel
Pressure Housing (2 for electronics) (2 for batteries)
Connector Rod
Spacer Plate Protection Cage
Taking all of these design issues into account, the Prudhoe Class AUV mission concept can be outlined as follows (a visual representation of this plan is shown in Fig. 3.1.5): 1. Drill a single 2ft. diameter entry hole and one or more exit holes in the ice sheet at the data collection site. 2. Deploy a simple acoustic beacon (a marking pinger) in the desired exit hole, approximately 1ft. below the bottom of the ice (7ft. water depth).
15 3. Deploy the AUV into the entry hole using a simple hand-operated rope winch. The mission is in a standby mode, and begins when the vehicle senses 1ft. of water depth. 4. The AUV executes its mission by homing-in on the beacon and navigating simple paths with respect to the beacon, a digital compass, and depth sensor. Data from the on-board CTD & Turbidity sensors is logged along the way, as the vehicle heads for the homing beacon, which is also at its intended exit hole. 5. Once at the exit hole, the vehicle ascends, positioning itself slightly to remain underneath the hole. 6. The vehicle is retrieved with the use of a simple hook and rope and concludes its mission once it senses less than 1” of water depth (i.e. it has been extracted from the water). 7. These point-to point missions can be repeated as necessary to map the whole field of interest.
16 Figure 3.1.5: Visual representation of AUV mission plan
17 3.2 Modeling & Simulation Upon completing the preliminary design, a MATLAB® Simulink simulation (Fig. 3.2.1) was created to model plant dynamics, refine controller designs, and examine the feasibility of the overall design through execution of test missions. The source code for this simulation can be found in Appendix D.
Figure 3.2.1: MATLAB ® Simulink Block Diagram for AUV Simulation
18 3.2.1
AUV Dynamics The first step in developing an accurate simulation is modeling the dynamic
equations of the AUV. In this case, a body-fixed coordinate reference frame will be used which is described by the following six degrees-of freedom (DOFs) and their respective derivatives:
x (surge) – linear motion with respect to the longitudinal axis y (sway) – linear motion with respect to the transverse axis z (heave) – linear motion with respect to the vertical axis φ (roll) – rotational motion about the X-axis θ (pitch) – rotational motion about the Y-axis ψ (yaw) – rotational motion about the Z-axis
Inputs to the system are defined as follows: T1 – Thrust force from the port-side thruster T2 – Thrust force from the starboard-side thruster T3 – Thrust force from the vertical thruster Fext(x,y,z,ψ) – External disturbance forces (water currents, etc) Fd (x,y,z) – linear hydrodynamic drag forces due to vehicle motion defined by the equation (see [1]): 2 V Fd = Cd * ρ * A p * 0 (3.2.1) 2 …where: Cd = coefficient of drag ρ = density of seawater Ap = projected drag area V0 = velocity of drag surface (*Note: rotational skin friction is considered nominal)
19
Other relevant parameters: m – vehicle mass (approx. 200lbs = 6.2 slugs) D – separation between horizontal thrusters T1 & T2 (11” = 0.91667ft.) Wauv – weight of the vehicle in water (assume neutral buoyancy, = 0) Iz – moment of inertia about the (vertical) z-axis (6.009 slug·in4 )
Figure 3.2.1.1: AUV Body-Fixed Coordinate Reference Frame z ψ
φ x θ y
Before beginning derivation of the equations of motion, it should be noted that y, φ, & θ are all uncontrollable DOFs, based on our thruster configuration. Furthermore, φ, & θ are of no concern due to their linear, decoupled nature. This is in fact one of the primary advantages of this design, in that roll and pitch can be removed from the equations of motion. This of course assumes that T1 , T2 , and T3
20 act at the vehicle’s centroid. In fact this is not the case. However, due to a heavy keel weight, coupled with a large buoyancy module, and large separation between the vehicle’s center of buoyancy (Cb) and center of gravity (Cg), we can assume that the vehicle will possess a high righting moment (GZ), allowing it to remain sufficiently stable in roll & pitch, so as to incur nominal disturbances in the other vehicle DOFs. Therefore, we need only be concerned with the 4 DOFs required to position the vehicle in space: x,y,z,ψ … three of which are controllable: x,z,ψ. As shown in [8], the dynamic equations of motion can be derived in the following manner:
Taking the sum of forces in the X, Y, and Z-directions, and solving for acceleration yields:
&x& =
&y& =
&z& =
(T1 + T2 ) + Fdx + Fx ext m Fdy + Fy ext m
+ y& ψ&
+ x& ψ&
T3 + Fdz − Wauv + Fz ext m
(3.2.2)
(3.2.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:
ψ&& =
(T2 − T1 ) D + M z ext 2 Iz
(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:
x1 x x y 2 x3 z x ψ X = 4 = x5 x& x6 y& x z& 7 x8 ψ&
T1 + T2 Fx D u = M z = (T2 − T1 ) 2 Fz T3
(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:
Cosψ X BG = Sin ψ
− Sinψ Cosψ
(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:
X nav
x1 α x ψ 2 = x3 = R x4 Z x5 H
(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
Mission File
Load
START MISSION
Vehicle In Water Column?
Ascend to Surface Standby
No
No Yes
Vehicle Out of Water Column?
Descend to Mission Depth 1
Yes
Listen for Beacon
No
STOP MISSION Yes
Beacon Acquired?
No
No
Timeout Expired?
Yes
Yes
Proceed with Mission
Abort Mission (Return to Origin)
Reached Target?
25 3.2.4: Low-Level Controllers The low-level controller set consists of three controllers, depth, speed and heading, which are dedicated to receiving commands from the mission planner and generating thruster outputs based on error between commanded and actual depth and heading. The simplest of the three, the depth controller, receives depth commands from the mission planner, vehicle depth (z) from the navigation system, and issues a thruster output (T3 ). From equation (3), it can be seen that the relationship between depth and thrust T3 is simple and linear. Therefore, it was decided that a conventional Proportional-Integral-Derivative (PID) controller with negative unity feedback would be more than sufficient (see [3]).
Figure 3.2.4.1: PID depth controller block diagram
INPUT Zdesired
CONTROLLER e
K p e + K i ∫ e + K d e&
…where: Zdesired = depth command from mission planner e = depth error T3 = vertical thruster output Kp = proportional gain
PLANT
OUTPUT Zactual
T3 AUV Model
26 Ki = integral gain Kd = derivative gain The speed and heading controllers are a bit more complex, due to their nonlinear, 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 oncourse. Heading correction is achieved by a sliding-mode controller (see [11]), which is activated if heading error exceeds the limits of the sliding boundary layer (+/- 3 degrees). A sliding-mode controller works by driving error (e) and error rate ( e& ) to zero, along a “sliding-function” defined by the line:
s = hT e
(3.2.9)
… where: h = a two-dimensional vector of controller gains (changes slope of sliding line) e = a two-dimensional vector containing error & error rate
27 Figure 3.2.4.2: Sliding-Mode controller behavior in the error plane
e&
Sliding Trajectory
e
Boundary Layer Sliding Line
As can be seen from the Fig. 3.2.4.2, when e and e& fall outside the sliding line, the controller moves back towards this line by making the control signal maximally positive (“reaching”). This allows the controller to compensate for unknown system nonlinearities, by forcing the system into a range where it becomes linear and can begin “sliding” towards the origin (along the sliding line). This is especially useful if little or nothing is known about the non-linear aspects of the system model. Once on the line, the controller continues to reduce e and e& , behaving like a linear P-D controller. Additionally, as shown in Fig. 3.2.4.2, a boundary layer can be added to reduce chattering, by “thickening” the sliding line. In the case of our hybrid
28 controller, the sliding-mode heading controller disengages inside of the +/- 3 degree boundary layer, allowing the PID speed controller to take-over and move the vehicle forward, based on commands from the mission planner. Thus, heading control is only initiated when the vehicle is off-course. These two controllers are shown below in Figs. 3.2.4.3 and 3.2.4.4.
Figure 3.2.4.3: Sliding-Mode heading controller block diagram INPUT ψ desired
CONTROLLER e
PLANT T1 , T2
K s * sgn (h1e + h2e& )
OUTPUT ψ out
AUV Model
… where: ψ desired = heading command from mission planner Ks = +/- bounds on controller output (thruster limits) h1 = error gain h2 = error rate gain T1 & T2 = horizontal thruster outputs Note that the sliding mode controller in Fig. 3.2.4.3 contains no estimate of nonlinear dynamics in the system, and therefore behaves like a bang-bang controller, which settles as it drives error (e) and error rate ( e& ) to zero (see [8]).
29
Figure 3.2.4.4: PID speed controller block diagram INPUT
CONTROLLER e
X& desired
K p e + K i ∫ e + K d e&
PLANT
OUTPUT
T1 ,T2 AUV Model
X& actual
…where: X& desired = speed command from mission planner e = speed error T1 , T2 = horizontal thruster outputs Kp = proportional gain Ki = integral gain Kd = derivative gain
It should be noted that since determination of vehicle speed is based on the rate of change in range (R) to the acoustic beacon, the vehicle’s speed cannot always be determined accurately, and cannot be determined at all in dead-reckoning mode. In this case, the PID speed controller is “bypassed” by feeding it a desired thrust instead of a desired speed. In this mode, there is no settling time and no need for a feedback loop, as vehicle speed is assumed to be linearly proportional to the combined commanded thrust of the two horizontal motors (T1 & T2 ).
30 3.2.5: Simulation Results The simulation was run many times, changing the location of the beacon, adjusting controller gains, etc. Figure 3.2.5.1 shows an overhead view of the vehicle moving from its starting location (0,0) to the beacon, located approximately 140ft (43m) away.
Figure 3.2.5.1: AUV Mission Simulation – Course Plot
In this simulation, the vehicle adequately navigates to its target location. During this mission, the vehicle was commanded to descend to two different depths, 20 ft.
31 and 15 ft, respectively, and then surface to 1ft. when within 10 ft. of the target. The PID depth controller performed exceptionally well as a P-D controller with Kp = 10, Ki = 0, & Kd = 5. As can be seen in Fig. 3.2.5.2, overshoot was minimal, rise & setting times are relatively short, and there is virtually zero steady-state error.
Figure 3.2.5.2: PID Depth Controller Performance
Although the hybrid heading/speed controller was able to get the vehicle to its target, it showed poor settling time, and caused the vehicle to oscillate fairly significantly at first (+/- 45º), eventually smoothing out to a low +/- 5º.
32
Figure 3.2.5.3: Sliding-Mode Heading Controller Performance
Additionally, the PID speed controller had difficulty maintaining speed, because it was constantly being switched-off in favor of heading correction. Despite this, it continued to move forward at an acceptable rate. Again, speed is not a priority for this AUV.
33 Fig. 3.2.5.4: PID Speed Controller Performance
As a test for robustness, the simulation was re-run, and the location of the beacon was moved during the simulation to see if the vehicle could easily “chase” the beacon, making turn-around maneuvers without any problems or instabilities. The tests were successful, and the resulting course and depth plots are shown below.
34 Figure 3.2.5.5: AUV Course plot for moving beacon simulation
35 Figure 3.2.5.6: AUV Depth plot for moving beacon simulation
Vehicle ascends and descends in response to beacon movement
It should be noted that the performance of the depth controller was unaffected. Since the range of the vehicle to the beacon changed as it was moved around, the mission planner changed its depth command to the controller, resulting in the ascent/descent spike in the depth profile. Overall, the simulation proved successful, and shows the ability of the vehicle to adequately navigate to its intended target. The depth controller performed excellently, and as a result of the simulation, was implemented on the AUV. The hybrid sliding-mode/PID heading controller also performed well, and
36 was implemented on the prototype. However, a re-design of this controller in the future may be beneficial to reduce chattering and increase robustness. Currently, the sliding-mode controller alters heading by reversing the thrusters to rotate the AUV. In the case of large heading errors this is acceptable, in order to make quick corrections. However, for small heading corrections, a simple imbalance in thrust between T1 and T2 should provide smoother control, with far less chattering and loss in forward momentum.
37 3.3 Prototype Design & Construction – “Tuvaaq” After evaluating the performance of the preliminary design through use of the MATLAB® simulation, work on production of a prototype vehicle began. The first in the “Prudhoe Class” of AUVs at Florida Tech, the vehicle has been dubbed “Tuvaaq”, an Inupiat Eskimo word meaning “hunter”, based on its characteristic “beacon hunting” behavior. The following sections discuss in detail all of the subsystems developed for the Tuvaaq AUV.
3.3.1: Mechanical Layout As stated previously, the mechanical design of the Tuvaaq AUV is based on research into ROVs used in tight-quarter working environments, such as Deep Ocean Engineering’s “Firefly” (www.deepocean.com). The basic layout of the vehicle is shown in Figs. 3.1.4 & 3.3.1.1, and consists of four vertically-mounted pressure vessels (two for electronics, two for batteries), two parallel horizontal thrusters, one vertical thruster, externally mounted CTD, turbidity sensor, and acoustic transducers, and upper & lower protection cages. Detailed drawings can be found in Appendix A.
38 Figure 3.3.1.1: Tuvaaq AUV Mechanical Assembly
This design allows the vehicle to fit vertically into a 2ft. diameter hole, simplifying launch and recovery through the thick ice on the Beaufort Sea. Also, the use and placement of the thrusters simplifies control by decoupling vehicle motions in the vertical and horizontal planes and allowing small position corrections at low speed. This low speed positioning, plus the advantage of being able to make a complete 360° turn within its own body diameter, makes the vehicle extremely maneuverable in tight quarters and gives it stationkeeping ability. The vertical separation of the buoyancy foam and ballast weight (batteries and additional lead keel weights) enhance roll and pitch stability, allowing the
39 vehicle to move in an upright position. The upper protection cage also serves as a recovery target, which can be “hooked” in order to catch the vehicle and lift it out of the exit hole. Each pressure vessel consists of a 15”-long, 6” diameter 6061-T6 aluminum pipe with a welded flat endplate. This sizing was chosen to accommodate the PC/104 electronics stacks and batteries discussed in later sections, with ample room for future electronics add-ons. The open end of each housing is then sealed with a single face-seal o-ring, which is embedded in a flat connector plate. The connector plate is mated to the sealing flange on the housing by six stainless-steel cap bolts. The housings have been black anodized for corrosion protection and aesthetics.
Figure 3.3.1.2: AUV pressure vessel (1 of 4)
40 The pressure vessels are held in place by three Type-I PVC spacer plates, which also contain a center hole for a flow tube, used to maintain output from the vertical thruster. The CTD is mounted between the second and third spacer plates.
Figure 3.3.1.3: Underside of AUV, with PVC spacer plate shown
The thruster assembly consists of three thrusters mounted into a syntactic foam buoyancy module. The entire vehicle is held together by 4 pieces of threaded-rod, which compress the housings, thruster/buoyancy module, acoustic transducer array, environmental sensors, and protection cages together into a single unit, shown below.
41 Figure 3.3.1.4: Assembled AUV (acoustic transducer array not shown)
42 3.3.2: Propulsion The propulsion system for the Tuvaaq AUV is based around two parallel horizontal thrusters and one vertical thruster. As shown in section 3.2, this arrangement simplifies control of the vehicle by decoupling motions in the horizontal and vertical planes. Furthermore, fine control and maneuverability at low speeds is possible because the thrusters, unlike fin-shaped control surfaces, require no forward motion to generate turning moment. This allows the vehicle to hold position underneath the exit hole, making small position corrections as it attempts to move as close as possible to the acoustic beacon. Early on, it was recognized that one major problem in the design of underwater thrusters, especially in cold environments is the presence of rotary shaft seals which often leak and can put significant frictional drag on the motor drive shaft, causing excess power consumption and accelerated seal wear. Unfortunately, conventional brushed-DC motors must be kept dry since their commutation is mechanical and requires open-air electrical contacts.
43 Figure 3.3.2.1: Typical brushed-DC motor construction
In contrast, brushless-DC (BLDC) motors achieve their commutation through electronics, which charge the appropriate coil at the appropriate time in the rotation cycle, thus creating the necessary rotating magnetic field. Furthermore, since most BLDC motors utilize a permanent-magnet rotor, coupling between the rotor and stator is strictly magnetic, with no open-air electrical contacts (brushes).
44 Figure 3.3.2.2: Typical Brushless-DC Motor construction
The advantage of this inductive coupling is that it allows the outer motor coils (stator) to be coated completely in epoxy without affecting the performance of the motor. It was hoped that potting such a motor would negate the need for shaft seals, allowing the motor to run completely submerged, with water flowing through it. This technique is frequently used with AC motors in commercially available aquarium pumps and sump pumps, with much success. The goal was to duplicate these results using a BLDC motor. First, a commutation method had to be selected. Since BLDC motors require electronic commutation, the position of the rotor must be known so that the commutator can energize each coil with the proper polarity at the proper time.
45 Several different commutation methods were examined. Initially, sensorless commutation was pursued, to avoid the need for extra conductors in the motor connectors and eliminate the need for potting the sensors with the motor coil assembly. This sensorless commutation technique uses back-EMF generated on the non-energized coil in a 3-phase motor to determine rotor position (see [2]). Unfortunately, after prototyping many designs, it was found that sensorless commutation performed poorly at low-RPM and could not adequately handle the fast direction switching, required by the AUV’s thrusters. Finally, it was decided that the hall-effect commutation method would be used. This widely used commutation scheme involves three small hall-effect sensors, which act as magnetically-driven TTL transistor switches. This method is proven and reliable, and can function at very low RPM (see [2]). After some searching, the Elcom ST N2312 motor was selected from the Pittman Motor Company (see Appendix F). This motor was selected based on its size, construction (for ease of potting), coil-type (3-phase wye-wound), low speed, operating voltage, and high torque constant (K t =5.30). A high Kt is desirable to maximize torque output, while minimizing power consumption. Once the motor was chosen, it was disassembled, and a fixture was made for epoxy-coating the stator and hall-effect sensors. The fixture was then coated with a synthetic mold release compound, “HMP 4-18B”, from Fluid Polymers, Inc., and the coil/cable/sensor assembly placed inside. The fixture, with coil, cable, and
46 hall-effect sensors was then potted using “HMP85-1 Black Slow” 2-part epoxy, also from Fluid Polymers, Inc. This epoxy was chosen for its workability, moderately high durometer (hardness), and color. Information on these substances can be found in Appendix F. During initial cure, each motor was run through approximately 5-10 vacuum cycles to remove air bubbles and fill any small voids in the assembly.
Figure 3.3.2.3: Motor fixture with coil, cable, and hall-effect sensors
After the epoxy had fully cured and cross-linked (approx. 48 hours), it was removed from the fixture and faced on an end-mill to ensure a perfectly toroidal shape.
47 Figure 3.3.2.4: Finished potted motor coil
To complete the final motor assembly, the original steel ball-bearings were replaced with nylon/glass-ball bearings, and endplates were machined from UHMW Polyethylene plate. These pieces, coupled with a factory epoxy-coated rotor magnet and stainless-steel drive shaft, offer corrosion resistance and the added advantage of water lubrication. The final motor assembly was then outfitted with a mounting bracket and 6”diameter trolling propeller.
48 Figure 3.3.2.5: Finished BLDC seal-less underwater thruster
To drive the thrusters, a computer-interfaceable motor controller was needed. Since a suitable motor controller was not commercially available, it was designed by the author and Larry Buist, at the Technical Support Lab in the College of Engineering. The motor controller was designed to support two motors per board and allow control from a host PC via a standard RS-232 serial port. The controller board was based around the Motorola MC33035 BLDC Commutator IC, which provides hall-effect commutation, direction control, and onboard 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 Commutation # of Motors per board Reversing Motor Voltage Range Maximum Motor Current Velocity Feedback Communications Circuit supply
3-Phase BLDC Wye-wound Hall-effect 2 Yes 12-24 VDC 20 AMPS (per motor) Yes, PID loop RS-232 Serial @ 9600,8,1,N 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: “” … where spdA & spdB are speed commands ranging from 0-255 (0100% 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/104Plus 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 deadreckoning system is a basic requirement for any AUV. Since a DVL was unavailable and prohibitively expensive for this project, the Tuvaaq vehicle was outfitted with a depth sensor (contained within the onboard CTD, discussed in section 3.3.4), and digital compass, which also serves as a roll/pitch sensor. The roll/pitch sensor is primarily used to correct for vehicle motions in the calculation of magnetic bearing, and also allows us to examine the true vertical stability of the vehicle during a mission.
56 Figure 3.3.3.1: EZ-Compass 3 Digital Compass module
In dead-reckoning mode, the AUV uses the compass for bearing and calculates velocity and displacement based on thruster commands, assuming certain linear characteristics about the relationship between propeller RPM and forward vehicle speed. Again, this method is highly error-prone, especially in the Arctic, where close proximity to the North Pole can cause magnetic compasses to give erroneous readings. However, it can be used if no other navigational data is available or to test simple mission plans, such as following a compass heading at a specified depth. Furthermore, this system is useful for field testing of the AUV in Florida, to prove the performance of the vehicle’s mission planning and control software. Acoustic navigation systems offer the ability to determine precise location over long distances, due to the high speed of sound underwater (avg. 1500 m/s in seawater). Several types of acoustic systems are available for AUVs, including
57 Long-Base-Line (LBL), Ultra-Short-Base-Line (USBL), Sound Navigation And Ranging (SONAR), and Acoustic Doppler (ADCPs & DVLs) technologies (see [4]). Review of these technologies lead to the decision to develop a simple homing system, which would allow the AUV to find its exit hole by targeting a continually repeating acoustic beacon. The system developed for this purpose is based on the Super-Short-Baseline method, or SSBL. The theory behind this technique is as follows. Sound in water propagates as a pressure wave, oriented orthogonally to its direction of motion as in Fig. 3.3.3.2.
Figure 3.3.3.2: Propagation of hydroacoustic waves across a straight-line transducer array
Beacon
∆t13
∆t12 α
∆t23
3
2
1
58
As the pressure waves meet a line of transducers oriented at an angle to their direction of travel, the incoming waves arrive at each transducer at different times. These time differences can be used to trigonometrically calculate the bearing angle to the acoustic source. In the case of an Ultra-Short-Base-Line (USBL) system, these transducer elements are placed very close together (on the order of millimeters), such that the time-of-arrival differences present themselves as phaseshifts in the incoming acoustic signal. For our purposes, a similar, larger scale method was chosen … the SuperShort-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 phaseshift. Furthermore, since it is necessary to discern which direction the acoustic signal is coming from in the full 360-degree horizontal and vertical planes, a single-line array would be unsuitable. Therefore, a triangular transducer “triplet” array was designed, so as to allow this determination (see Fig 3.3.3.3 and [4]).
59 Figure 3.3.3.3: Propagation of hydroacoustic waves across a triangular SSBL transducer array
TOP VIEW
α
Zone 6 (300º-360º)
Beacon
Zone 1 (0º-60º)
∆tac
∆tab 1
∆tbc Zone 2 (60º-120º)
Zone 5 (240º-300º)
3
Zone 4 (180º-240º)
2
Zone 3 (120º-180º)
60 SIDE VIEW
Beacon
∆tac
β
2
3
1
∆tac max
As shown in Figure 3.3.3.3, the angle α gives the horizontal bearing to the beacon and the angle β gives the vertical bearing. These angles are calculated in the following manner:
1. Logically resolve which 60º zone the beacon is in based on the order in which the transducers received the signal: 1,2,3 = Zone 1 (0º-60º) 2,1,3 = Zone 2 (60º-120º) 2,3,1 = Zone 3 (120º-180º) 3,2,1 = Zone 4 (180º-240º) 3,1,2 = Zone 5 (240º-300º) 1,3,2 = Zone 6 (300º-360º)
61 2. Determine the horizontal bearing angle (α) within the appropriate zone through time-of-arrival ratios:
∆t α = bc ∆t ac
60º + X
… for odd-numbered zones (1,3,5)
(3.3.1)
∆t α = ab ∆t ac
60º + X
… for even-numbered zones (2,4,6)
(3.3.2)
…where, ∆t ab = time difference between the first and second transducers to detect the signal. ∆t bc = time difference between the second and last transducers to detect the signal. ∆t ac = time difference between the first and last transducers to detect the signal. X = lower angle limit of each zone (e.g. for Zone 5, X = 240)
3. Determine the vertical bearing angle (β).
∆t ac β = Cos −1 ∆t ac max
(3.3.3)
… where, ∆t ac = time difference between the first and last transducers to detect the signal. ∆t ac max = Maximum time difference between the first and last transducers to detect the signal, based on the flat-line distance between them and an approximate speed of sound, Cs = 1500 m/s = 59055.118 in/s.
The horizontal bearing angle (α) functions like an acoustic compass heading, guiding the vehicle towards the beacon. Note that knowing the speed of
62 sound is not necessary when calculating α, because it is based on relative time differences between the transducers. This allows high accuracy in determining this angle, despite changes in the speed of sound between the beacon and the vehicle. Of course, it must be assumed that there is no change in the speed of sound between the transducers. This assumption is reasonable since the transducers are only 12” apart. The vertical bearing angle (β) is useful for two reasons. If the vehicle depth and beacon depth are known, the two can be subtracted, giving a vertical offset (∆d). This vertical offset and the vertical bearing angle can then be used to triangulate the position of the beacon, thereby allowing approximate determination of horizontal range (R), as shown below.
R=
∆d Tanβ
(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:
TL sph = 20 log r = 20 log 50 = 34.0 dB
450m Cylindrical spreading:
TLcyl = 10 log r = 10 log 450 = 26.5 dB
Absorption:
α=
10 log I 1 − 10 log I 2 r 2 −r1
… 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:
α = 7.0 dB/kyd = 7.0 dB/km = 3.5 dB total absorption (over 500m path)
64 Summing these losses, we get a total of: 34.0 + 26.5 + 3.5 = 64dB
Therefore, our beacon must be able to output enough power to be detectable, with 64dB of loss. The beacon selected for this task is the ULB-350, manufactured by RJE International. This pinger is often used as a marker beacon for subsea equipment, and can last on a single 9V battery for up to 40 days. Its output is a 10ms pulse every 1sec at 37kHz, with a power output of 163dB, which is more than sufficient for our needs.
Figure 3.3.3.4: ULB-350 Underwater Beacon
65 The counterpart to the beacon, the receiving transducers from Sensor Technologies, Ltd., were chosen based on omni-directional response, a 38kHz center-frequency, and relatively low cost.
Figure 3.3.3.5: SX-38 38kHz Omnidirectional Transducer
These transducers were placed in a triangular array to form the receiving-end of the SSBL system. Spacing of the transducers is 11.955” on each side (12” nominal), based on a multiple of the half-wavelength (0.797”) and the widest possible configuration suitable for placement on the top of the Tuvaaq AUV.
66 Figure 3.3.3.6: SSBL Transducer array mounted on test fixture
Development of the receiver electronics is based on a 5-part process, outlined below and shown in Fig. 3.3.3.7. The boards were also manufactured by ExpressPCB, and fit the PC/104 form factor. Detailed schematics and PCB layout drawings can be found in Appendix C. 1. First, the transducer signal is amplified to a useable voltage level (gain is set manually by a potentiometer). 2. A bandpass filter is applied to remove noise on either side of the frequency of interest (37kHz).
67 3. The amplified, filtered signal is fed through a tone detector, which “listens” for the frequency of interest (set manually by a potentiometer). 4. Simultaneously, the signal is fed through a fixed threshold detector, which determines if the signal is “loud” enough to be the pinger, and not just simply 37 kHz background noise (set manually by a potentiometer). 5. The result of the tone detector and threshold detector are combined in a “Boolean AND” fashion and fed to a PIC microcontroller. 6. The PIC microcontroller records the difference in arrival time of the signal at each of the three transducers and computes the horizontal and vertical bearing angles. The result is then sent to the host PC via an RS232 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 LightScattering 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 Resolution Accuracy
0-7 S/m 0.003 S/m +/- 0.001 S/m
CTD Temperature Sensor Range Resolution Accuracy
-2-32 ºC 0.001 ºC +/- 0.005 ºC
CTD Depth Sensor Range Resolution Accuracy
0-100 dBar (0-100m) +/- 0.01 dBar (1cm) +/- 0.05 % full scale (5cm)
LSS Turbidity Sensor Range Resolution
0-25 NTU +/- 0.03 % full scale (0.0075 NTU)
System Power Requirements System Communications System Data Output Format System Data Sample / Output Rate
12VDC @ 75mA RS-232 Serial @ 9600,8,N,1 ASCII Text 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 industrystandard 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 RS422). 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 EZCompass 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 fuelcells 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 Electronics (CPU, Motor Controllers, Navigation, Fans, etc) Mission time at 50% speed (0.5 m/s) over 500m Conservative power estimate per 1hr mission (FOS = 2.0)
1.5 A 1.0 A 17 min --------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, SlidingMode 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]; end
%initial conditions for each state
% 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 verticalaxis 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 %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
24/19
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 X_sep = Y_sep = Z_sep =
separation Beacon_X Beacon_Y Beacon_Z -
distances X; Y; 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 if X_sep >= 0 if Y_sep < Delta = end else if Y_sep < Delta = else Delta = end end
statement determines what quadrant the beacon is in 0 (90-Delta) + 270;
0 Delta + 180; (90-Delta) + 90;
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; speed_command = 0.25; else speed_command = 1.0; end %Depth decision if R < 10 depth_command = -1; elseif R < 25 depth_command = -15; else depth_command = -20; end
%Slow-down %Cruise
%Surface %Dive to 15ft. %Dive to 20ft.
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); PSIedot = input(2);
%Heading Error %Heading Error Rate
%Adjust Ks (maximum control signal ... 1 lbf) Ks = 1; %Adjust Sliding-Mode Heading Controller Gains h1 = 0.5; h2 = 0.1;
(Ht = [h1 h2])
%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; else sgn_s = 0; flag = 2; end %Calculate the control signal if flag == 1 correction u1 = Ks*sgn_s; u2 = -Ks*sgn_s; else (Simulink Block) u1 = 0; u2 = 0; end T1 = u1; T2 = u2; output = [flag, T1, T2];
%Use sliding-mode to make a heading
%Use PID to move vehicle forward
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 #define #endif
_BLDC_H _BLDC_H
//Function prototypes void getCommand(); void getStatus(); void runPID(int Kp, int Ki, int Kd);
void sendStatus(); void sendVersion(); int initPort(int baud); void writeByte(char byte); char readByte(); void interrupt ccpInterrupt();
//parses incoming //commands //gets current motor //states (RPM, direction) //computes PID control //action and outputs it //to motors //sends motor status info //to user via serial port //sends firmware version //information //initializes PIC serial //port USARTs //sends a character to //PIC serial port //reads a character from //PIC serial port //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 #include #include #include #include #include #define #define #define #define // Pin static static static static static static static static
PORTBIT(adr, bit) bitset(var, bitno) bitclr(var, bitno) FOSC (4000000L)
definitions bit brakeA bit brakeB bit dirA bit dirB bit DACwrite bit DACselect bit speedfbA bit speedfbB
//Global program, unsigned unsigned unsigned unsigned unsigned unsigned
@ @ @ @ @ @ @ @
((unsigned)(&adr)*8+(bit)) ((var) |= 1 255) { uA = 255; } else if(uA < 0) { uA = 0; }
//control signal upper bound
PORTB = uA; */
//Output speed command to DAC-A
PORTB = spdA_desired; DACselect = 0; DACwrite = 0; DACwrite = 1;
//control signal lower bound
//Select DAC-A //Enable writing data to DAC-A //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) { uB = 255; } else if(uB < 0) { uB = 0; }
//control signal upper bound
PORTB = uB; */
//Output speed command to DAC-B
PORTB = spdB_desired;
//!!!!delete this line when the //PID controller works //Select DAC-B //Enable writing data to DAC-B //Hold data at DAC-B
DACselect = 1; DACwrite = 0; DACwrite = 1;
//control signal lower bound
//-------------------------------------------//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; interruptA = 0; //interruptB = 0; //Get speed of motor A CCP2IE = 1; CCP2CON = 0b00000110;
//enable all interrupts //clear interrupt flags
//enable CCP2 interrupt //initialize CCP2 module to //capture on 4th rising //edge (2 revs)
136 TMR1H = 0; TMR1L = 0; T1CON = 0b0011001;
//clear timer 1
//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; CCP1CON = 0b00000110;
TMR1H = 0; TMR1L = 0; T1CON = 0b0011001;
//enable CCP1 interrupt //initialize CCP1 module to //capture on 4th rising //edge (2 revs) //clear timer 1
//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
