6 DOF Nonlinear AUV Simulation Toolbox

Xiaodong Chen, Dave Marco, Sam Smith, Edgar An, K. Ganesan, Tony Healey

Email: [email protected]

Abstract:

This paper describes the organization of 6 DOF nonlinear autonomous

underwater vehicle (AUV) simulation toolbox, which is currently under
development for the Ocean Explorer (OEX) series AUVS developed at Florida
Atlantic University. This software development is part of 5-year ONR MURI
effort of which its goal is to develop innovative tools and methodologies for the
control of complex nonlinear dynamic systems. The purpose of this software
simulation is to supply a flexible 3D-simulation platform for motion
visualization, in-lab debugging and testing of mission-specific strategies as well
as those related to C3 purposes. This software is currently jointly developed by
the Ocean Engineering Department at Florida Atlantic University and Naval
Postgraduate School for the FAU OEX and NPS Phoenix AWS.

Introduction shared memory and data synchronization is

achieved by using semaphores. Simulation
The new generation multipurpose programs are written in C and C++. In particular,
autonomous underwater vehicles (AW) such as Motif is used to design GUI and Open Inventor is
Ocean Explorer are modular designed [Smith] in used to create 3D models. Current implemented
order to cut time and cost for vehicle modules include a nonlinear dynamic model for
recontlguration. A flexible 3D-simulation the OEX, shared memory and semaphore
platform is desired to visualize testing of AW manager tools, shared memory monitor, data
components before porting to vehicle meanwhile logger, fuzzy sliding mode pitch controller and
platform can also be used for mission replay. 3D graphics interface for displaying real-time or
Comparing to the most available simulation post-processed data. Additional modules which
software, advantage for using this software include vehicle hydrodynamics model, thruster
architecture, which is almost identical to the model, wave and current models, sensor model,
OEX software running on real-time operation an annotated map for bottom terrain will also be
system VxWorks, is based on behavioral implemented within the project duration.
decomposition methodology, where each
behavior is implemented as an independent Unix
process. A behavior is viewed as an independent Model of Ocean Explorer
conceptual task that cooperates with other
behaviors in the system to perform a given The Ocean Explorer AW (Figure 1) is 7.14
mission. The nearly identical structure gives the feet long and 21 inches in maximum diameter.
user great flexibility that program tested on the Weight in airis714.21bs and displaced weight is
simulation platform can be directly ported with 716.71bs. Hull volume is 11.193 lft3. It is
few or no modification onto the OEX and this is designed with
expected to reduce the development cycle by ● a teardrop shaped fiberglass hull based on a
minimizing the difference between the actual modified version of the Gertler Series 58
system and simulation environment. Shared Model 4154-body shape.
memory is used as the backbone of data ● aft-mounted cruciform control surfaces.
communication among processes instead of ● a 3-bladed propeller 18 inches in diameter.
conventional message passing. Access control of

0-7803-4111-2/97 $10.00 (c) 1997 IEEE

 Form Approved
Report Documentation Page OMB No. 0704-0188

Public reporting burden for the collection of information is estimated to average 1 hour per response, including the time for reviewing instructions, searching existing data sources, gathering and
maintaining the data needed, and completing and reviewing the collection of information. Send comments regarding this burden estimate or any other aspect of this collection of information,
including suggestions for reducing this burden, to Washington Headquarters Services, Directorate for Information Operations and Reports, 1215 Jefferson Davis Highway, Suite 1204, Arlington
VA 22202-4302. Respondents should be aware that notwithstanding any other provision of law, no person shall be subject to a penalty for failing to comply with a collection of information if it
does not display a currently valid OMB control number.

1. REPORT DATE 3. DATES COVERED

2. REPORT TYPE
1997 -
4. TITLE AND SUBTITLE 5a. CONTRACT NUMBER
6 DOF Nonlinear AUV Simulation Toolbox 5b. GRANT NUMBER

5c. PROGRAM ELEMENT NUMBER

6. AUTHOR(S) 5d. PROJECT NUMBER

5e. TASK NUMBER

5f. WORK UNIT NUMBER

7. PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES) 8. PERFORMING ORGANIZATION

REPORT NUMBER
Naval Postgraduate School,Center for AUV
Research,Monterey,CA,93943-5000
9. SPONSORING/MONITORING AGENCY NAME(S) AND ADDRESS(ES) 10. SPONSOR/MONITOR’S ACRONYM(S)

11. SPONSOR/MONITOR’S REPORT

NUMBER(S)

12. DISTRIBUTION/AVAILABILITY STATEMENT

Approved for public release; distribution unlimited
13. SUPPLEMENTARY NOTES

14. ABSTRACT
This paper describes the organization of 6 DOF nonlinear autonomous underwater vehicle (AUV)
simulation toolbox, which is currently under development for the Ocean Explorer (OEX) series AUVS
developed at Florida Atlantic University. This software development is part of 5-year ONR MURI effort of
which its goal is to develop innovative tools and methodologies for the control of complex nonlinear
dynamic systems. The purpose of this software simulation is to supply a flexible 3D-simulation platform for
motion visualization, in-lab debugging and testing of mission-specific strategies as well as those related to
C3 purposes. This software is currently jointly developed by the Ocean Engineering Department at Florida
Atlantic University and Naval Postgraduate School for the FAU OEX and NPS Phoenix AUVs.
15. SUBJECT TERMS

16. SECURITY CLASSIFICATION OF: 17. LIMITATION OF 18. NUMBER 19a. NAME OF
ABSTRACT OF PAGES RESPONSIBLE PERSON
a. REPORT b. ABSTRACT c. THIS PAGE
5
unclassified unclassified unclassified

Standard Form 298 (Rev. 8-98)

Prescribed by ANSI Std Z39-18
 intelligent Ni-Cd battery packs. The battery name, type, initial value, unit, sampling rate and
packs can supply up to 12 hours of etc. A sample from “shmem.in” is listed below:
continuous missions at 3-knot cruising
speed. //Sync

main computer and electronics board AuviWotion //written by StateMgr

(MC68030 at 50 MHz on the VME bus). (

head “deg” double = 0,0; 8 IfChanged;
Each of the components is embedded with a
roll “deg” double = 0.0; 8 IfChanged;
LonWorks Neuron node, and the control
pitch “deg” double = 0.0; 8 Ifchanged;
communication is achieved via LonTalk yawRate “deg/s” double = 0.0;;
protocol. rollRate “deg/s” double = 0.0;;
sensors include Watson AHRS-C302RS (3- pitchRate “deg/s” double = 0.0;;
axis acceleration, angles and rates), XAcc “G” double = 0.0;;
SIMRAD mesotech 809 (altitude), Druck yAcc “G “ double = 0.0;;
!tG !’
PTX 1649 (water depth) , Sonic Speed rlicc double = 0.0;;
..
(water speed), DGPS, LBL and USBL } ,}
positioning system.
Here a unit which includes head, roll, pitch etc.
The hydrodynamic and maneuvering models of called ‘AuvMotion’ in shared memory is defined
OEX have been developed [Humphrey]. where “head” is a “double” type variable with
Vehicle equations and notation can be referred initial value 0.0. The unit of head is degree. The
from [Fossen], Figure 2 shows an open loop time sampling frequency is 8Hz. The logger strategy
history of the heading angle and yaw rate while is head value will be logged only if it is changed.
rudder angle was set to 0.1 radius. (Assuming a Two filter programs are supplied to convert
constant propeller force). More work on “shmem.in” to C source code, one for VxWorks
developing a suitable thruster model is needed. and one for Unix.
All processes can only interact with shared
memory via dedicated function call to prevent
Shared memory and Semaphore the incorrect operation on shared memory. To
minimize the time for a process of keeping
The critical aspect of multiprocessing semaphore, two operations are usually used by
programming is the communication among special functions, “SMGlobalToLocal” and
processes. Shared memory is chosen as the way “SMLocalToGlobal”, which are used for process
of communication because it is fast and effective to read from and write to shared memory. (Figure
[Ganesan]. . Semaphore is used to control the 3).
access of shared memory to avoid the conflict A shared memory and semaphore manage
and for synchronization problem. The normal tool is designed for users convenience. Users can
procedure for any process to access the shared use the tool to create or delete shared memory
memory is to acquire the related semaphore first, and semaphores, can get variable information
then access the data and then give up the such as variable values and relative semaphore
semaphore. Shared memory is implemented as a number, can set special semaphore values to
multiple units’ data storage where related block or release the access to particular part of
variables are carefully grouped. If the shared shared memory and can reinitialize shared
memory is considered as a single unit, most of memory. The Motif version manage tool is also
processes have to wait for a long time before available.
they get the semaphore. If each variable is
assigned its own semaphore, synchronization can
not be guaranteed or deadlock may occur. The Arbiter and Manager
number of semaphores within a group is also
limited on Unix. The structure of shared memory The advantage of OEX behavior-based
must be very carefully chosen. A simple text file structure design as compared with hierarchical
“shmem.in” with C-like language is used to make architecture is that interaction among processes is
it easy to design or reconstruct the required highly modular and thus processes can be added
shared memory structure such as the variable or removed without much interfering with others,

0-7803-4111-2/97 $10.00 (c) 1997 IEEE

thereby minimizing software rewrite. However set rpmo
multi-processes have multi-output. An arbiter is set torqueo
designed to make a final decision for its given set direction
multiple input behaviors. There are several Go
different types of arbiters, such as Boolean Stop motor
arbiter, (fuzzy) weighted average arbiter and Stop mission
fuzzy constrains. The difference between fuzzy
constrain type arbiter and others is its input and For a typical mission listed above, AW was
output are fuzzy sets instead of simple values. tirst commanded go south 1800m with speed
The final result will be defuzzified. 1.5mlsec and depth 8.Om, then come to surface
Usually an arbiter take the confidence, for GPS fix and go south 400m. The required
importance and variable value as inputs and manager is state manager and heading manager
generate an output with its confidence and which run at priority 70 and 80. “Set criteria” is
importance. Confidence represents a degree of used to set the criteria of the completion of a set
accuracy of input data and importance initially is point or way point command . “Go” means to
a user-defined value. start the mission.
In order to make behaviors well organized, Simulation software shares the same mission
manager is used to manager related behaviors plan file as vehicle. So mission status can be
and arbiters and is used to schedule the start easily relayed to simulation platform.
time, priority of processes and decide the final
output by using arbiters. There are three different Monitor and Data Logger
types of managers: synchronous, asynchronous Monitor is an independent process with
and event manager. The event manager is used Motif GUI used to monitor and change the values
for handle condition-based execution. The of shared memory variables. Monitor can also be
advantage for using manager is that it can be used to show the real vehicle motion dynamically
dynamically reconfigured via client server communication. One advantage
For example in Figure4, manager manages of monitor is you can change the shared memory
two controllers and one arbiter. Two controllers variables at any time. So it can be used for
are depth and altitude controllers. An arbiter is “hardware in loop” simulation.
used to combine the commanded pitch from both An editable monitor parameter file is
controllers and open loop pitch then generates generated by filter program when you generated
final pitch angle. the source code for shared memory. Users can
select their desired monitor variables.
Data logger is used to record the variable
Mission Plan values along with the updating time for further
use. Variables can be logged at a user given
Mission plan is a plain text file with English sampling frequency or be logged if it is changed.
style language. Below is a typical mission file: A parameter text file for logger is also supplied
//set initial point for user connivance. Logger data can be rewritten
Set Origin 26 22.22N806.27 W to shared memory for mission replay on
//start state manager with priority 70 graphical platform. Extracting data from logger
Start Mgr StateA4gr 70 file is achieved by a supplied program. Data
Start A4gr HeadingMgr 80 analysis package written in MatLab is also
//disable the su~ace safety feature available.
Need NoSu@aceSafety
Start Motor Controller
clear criteria
set criteria plane –5 TSK type fuzzy controllers were widely
set speed 1.5 used to control vehicle motion such as heading,
set depth 8.0 pitching and depth because of their robustness.
goto xy O –1800 For an example, the pitch controller takes in
set depth O pitch and pitch rate as inputs and produces a
goto Xy 200-2200 desired stern plane angle which was then fed to
//end mission the vehicle. The detailed description of the fuzzy
clear criteria controller can be found in [An]. Fuzzy sliding

0-7803-4111-2/97 $10.00 (c) 1997 IEEE

mode controller is currently under being implemented based on the database. Obstacles
developed andtested (Figure 5). avoidance algorithm will also be implemented.
As parameters of controllers are stored in
shared memory, the performance of controller References
can bedynatically changed. With the help of
simulation platform users can easily tune the Humphreys D. E.(1996) “Vehicle Hydrodynamic
parameters of controller. & Maneuvering Model for the FAU Ocean
Explorer Vehicle (OEX)” V.C.T Technical
3D Graphics Memorandum 96-05

3D graphics is used to help user visualize Ganesan K et al (1996) “A progmatic software

AW motion. OpenGL, Open Inventor, architecture for UUVS” IEEE Symposium on
Performer are three most widely used developing Autonomous Underwater Vehicle Technology.
tools. OpenGLis industry standard and platform
independent. It provides C, FORTRAN, Ada An, P. E. et al (1996). “ A Quantitative Measure
API. But it is a low-level graphics programming of Sea-State Effect on Small Autonomous
tools. It is hard to develop complex graphic Underwater Vehicle Motion in Shallow Water” ,
application. Performer is easy to use and Oecanology International 96, Brighton, UK,
provides C, C++ API. But it is platform pp.21 1-233.
dependent. Open Inventor is object-oriented built
on top of OpenGL. It comes with a rich set of Fossen, T. I. (1994). Guidance and Control of
built-in objects and animation tools. Standard Ocean Vehicles, John Wiley Publishing.
text file format, which is supplied by Open
Inventor, is easily used to generate complex Smith ,S. M. et al “The Ocean Explorer AUV: A
objects (such as OEX). Objects are easily added Modular Pla#orm For Coastal Oceanography” ,
or modified without code modification. UUST, Durham, New Hampshire, September.

Future Work

Up to now simulation package has already

been used for tuning controller. “Hardware in
loop” simulation will be tested in recently. In the
coming year, we will improve this simulation
software. We will characterize sensors such as
GPWLBL and setup sensors model that will be
incorporated into the package. Environment
factor will be taken into consider too. Basic
currents and waves model will be studied and
coded to simulate the environment. More delicate
wave and current models will be included with
the help of MURI partners. Environment
database will also be created. CTD survey data
will be incorporated. Feedback adaptive
sampling controller development will be

Figure 1 3D AUV model

0-7803-4111-2/97 $10.00 (c) 1997 IEEE

 w $q mpmn (d+-. Q.9 MO

Cmd Fuzzy Depth

Depth confidence
-1 -

Controller
-2 - Auv
FDC Pitch
Depth
-3 - En
itch Pitch
-4
t?u 130 I to 150 la 170 180
htwcl

, , , , , confidence I I
-Om I t40 150 16! 170
I
180
120 130
W@

Figure 2 Step response of AUV model Figure 3 Sketch of manager

mulamdatiehn
ShmEdmmuy
“ &@=@=if

● qydmd
mmxytokcrd -051 , , 1 b , 1
d d 0 2 4 6 8 10 !2 14
[
#cll @t&

@Me AlvMlial )wRlte ~

@lRate @lRate

miteawuialieto ..... 0s, 1 [ 1 I I I I

.....
: $8 dlmxlmllmy
“ S*
lad Imlmy ● cqYyloalnrmry &FJ’jm
todEldnEnLxy

Figure 3 Sketch of shared memory Figure 5 Time history of fuzzy sliding mode pitch controller

0-7803-4111-2/97 $10.00 (c) 1997 IEEE