SLOCUM AUGV:

AUTONOMOUS UNDERWATER GLIDING VEHICLE

USER’S MANUAL

Version 1.0 (September 2002)

WEBB RESEARCH CORPORATION

John Kerfoot

Coastal Ocean Observation Laboratory

Institute of Marine and Coastal Sciences

Rutgers University

71 Dudley Road

New Brunswick, NJ 08901

CONTENTS

1.0 System Requirements

1.1 Hardware

1.2 Software

2.0 Software Installation

2.1 WinCVS

2.1.1 Installation

2.1.2 Configuration & Updating Glider Code

2.2 Metrowerks Codewarrior

2.2.1 Installation

2.2.2 Configuration & Compiling New Glider Code

2.2.3 Configuration of Motocross and Uploading New Code

3.0 Glider Code Theory & Operation

3.1 SLOCUM Operating Systems

3.2 Glider Code Design

3.2.1 Control Levels

3.2.2 Stacks, States and Abort Sequences

3.2.3 General Control Structure

3.3 Sample Mission and Comments

OVERVIEW

The Slocum Autonomous Underwater Gliding Vehicle (AUGV) (Webb Research, Falmouth, MA) is an integrated instrument platform designed to operate in the coastal ocean. It is designed such that, by adjusting it’s volume to weight ratio, it dives and climbs in a sawtooth pattern to predetermined locations. The result is a low cost, highly adaptable autonomous underwater vehicle with a very low power requirement. The user programs the glider using text based mission files, which instruct the glider to dive and climb to a predetermined set of waypoints. Gliders are capable of communicating with a shore based computer or user via high frequency radio transmission as well as by satellite. The estimated range of operation is 1500km.

Each vehicle contains two computer chips: one to control movement and communication, and one reserved solely for collection and logging of scientific data. While the majority of the glider is reserved for mechanics, battery storage and communications, a section of the glider is devoted to scientific payload. As of this writing, the development of the science bay and associated software is still in the early stages. Future plans include outfitting the vehicles with a suite of miniaturized physical and bio-optical instrumentation. These instruments, combined with the high mobility and long range communication capabilities of the glider, will provide continuous, near real time information on ocean physics and biology.

The aim of this manual is to provide a basic understanding of the SLOCUM vehicle and the software architecture used to control it. This manual is a collection and distillation of information obtained from various sources, including Webb Research’s ftp site on glider development, numerous visits to Webb Research, personal communication with Webb scientists and Rutgers scientists, and (most importantly) personal trial and error. While this manual is not all inclusive, my hope is to provide a reference piece which will explain all the steps necessary to become proficient in glider operation and maintenance, while at the same time, gaining an understanding of the theory behind the design.

1.0 SYSTEM REQUIREMENTS

The system requirements for maintenance, operation and deployment of the SLOCUM glider can be broken down into two areas: 1) Hardware and 2) Software. The specific requirements of each are listed below:

1.1 HARDWARE:

1) SLOCUM Autonomous Underwater Gliding Vehicle (AUGV). The AUGV is factory shipped with all necessary tools.

2) Pentium based computer with a COM port and at least 1 GB of hardrive space for loading the glider source code and the C compiler.

3) While not necessary, I have found it very extremely helpful to use a SLOCUM simulator which is, simply, a Persistor chip in a box. Discussion of the Persistor chips used is included below. The use of a simulator allows us to continually change, compile and upload new code and mission files prior to the actual field deployment of the AUGV. This allows the user to change and/or rewrite missions for trial and error without the cost or time associated with a lost glider. A SLOCUM vehicle can also be used in a simulator mode, so it is not necessary to have a simulator.

1.2 SOFTWARE: the following is a list and location of all necessary software to allow for downloading and compiling of new glider code as well as uploading of the compiled code to the AUGV. The most current working version of all software except CodeWarrior v5.0 and the Persistor Host Tools is located online at the glider devlopment web page:

ftp://glider@www.glider.DinkumSoftware.com/home/glider/glider-software-development-tools/

We also have CDR’s of ALL of the software here at Rutgers. A discussion of the software as well as the installation procedures follows in the next section.

1) WinCVS: Windows Concurrent Version System Client Software.

2) Metrowerks CodeWarrior v5.0 (CDR-1) and v5.3 update (CDR-2).

3) MotoCross (CDR-2).

4) CF1.Patch.Lib patch (CDR-2)

5) MotoCross.PostLinker.dll (CDR-2)

6) Persistor host tools v.2.2.2.6 (CDR-2)

7) User’s Manuals (CDR-3)

Much, if not all, of the software is version specfic. This means that although there may be newer versions of each piece of software out there, the versions listed here have been thoroughly tested and appear to work.

2.0 SOFTWARE INSTALLATION

The following is a complete guide to the installation of each piece of software used for the development of the SLOCUM AUGV. I have tried to be as thorough as possible here in the hope that, by following this guide, you will successfully install all necessary software to download new code, compile it into an executable program, and load it onto the glider with minimal pain and frustration.

Where applicable, there is a cursory discussion of the software’s specific function. While accuracy is the goal here, it is possible that I have misinterpreted some of this information, as our use of the AUGV is still very limited. So, take this information in with a bit of skepticism.

2.1 WinCVS (Windows Concurrent Version System, http://www.cvshome.org).

Webb Research uses WinCVS to archive and disseminate all prior and current versions of the operating software used in the Slocum AUGV and Thermal Glider. The server containing all of this code is housed at Webb Research (Falmouth, MA).

There are a few reasons for the use of a central repository and retrieval of the code using WinCVS. WinCVS allows Webb to maintain a database of the source code, and then check files in or out of the database. This makes it easy to track changes to the code since the code is steadily evolving through additions, changes and deletions. Of course , Webb could save every version of every file ever created for the gliders, but this would waste an enormous amount of disk space. CVS stores all the versions of a file in a single file in a clever way that only stores the differences between versions. Because it is all too easy to overwrite others' changes unless we’re extremely careful, CVS also insulates different developers from each other. Every developer works in his own directory, and CVS merges the work when each developer is done.

In short, WinCVS keeps track of when files have been modified and only updates those files for which a newer version is available. There are two components to WinCVS: host software and client software. We are only concerned with the client side.

2.1.1 INSTALLATION of WinCVS:

Once you have obtained a copy of WinCVS, double click the ‘Setup.exe’ icon and the software will be installed on the drive you have selected. The installer is self explanatory.

In order to download the code from the repository, you must arrange for access through Webb Research. This can be arranged by emailing:

glideraccess@DinkumSoftware.com

You must include four pieces of information with your request: 1) Your username, 2) Your password, 3) IP address, 4) DNS suffix and computer name (ie: computer.marine.rutgers.edu). Your username and password are chosen by the user. The IP address and DNS name can be obtained by opening a DOS command window and entering the following: ipconfig\all.

2.1.2 CONFIGURATION of WinCVS

Once you have obtained permission to access the repository, you must obtain a clean copy of the source code. To do this, follow these steps:

1) Open WinCVS and from the CVS Admin menu, select Preferences and the General tab. In the Enter the CVS Root line, enter the following:

:pserver:username@joshua.DinkumSoftware.com:/usr/local/cvs/webb

Select [“passwd” file on the cvs server] on the Authentication line.

And select [Use cvs 1.10] on the Use Version line. Your screen should look like the following:

2) Next, from the CVS Admin menu, select Login and enter your password in the following window:

3)

From the CVS Admin menu, select Checkout and browse to and select the directory ABOVE where you want the glider directory to be created. If you want the source code to end up in the c:\cvs_glider_code\glider directory, browse to and select c:\cvs_glider_code. You must first create this directory yourself on your c:\ drive. Select the directory from the following window:

4) Click OK. The following window should appear. Enter the module name and path on server, which is glider.

5) Click the Globals tab and make sure the Prune(remove) empty directories is checked.

6) Click OK and you should get a clean copy of all the source code.

To obtain revisions of and additions to the source code as they are posted, follow these steps.

1) Open WinCVS and from the CVS Files menu, select Update Files. Browse and select the directory you’d like to update (I find it easiest to update the entire glider folder, so select glider):

2) Select okay and the following window will appear. Select the following boxes: “Reset any sticky date/tag/’-k’ options” and “Create missing directories that exist in the repository”.

3) Click OK and the glider directory will be updated with any new revisions to the source code.

2.1 Metrowerks CodeWarrior.

The Glider Controller code is written in C and is based on a layered single thread approach where sensor values (sensor: _) and behavior arguments (b_arg:_) are arranged to generate a specific behavior. A more in depth explanation of this approach follows the software installation section.

You now have the newest version of the Glider Code, but you still need to compile/link it and then load it onto your glider/Persistor. When you are ready to produce a binary file, such as an application, you must use a compiler, which builds the selected project type by updating the newly-added, modified, and touched files, and then linking the project into a final executable file.

The compiler used by Webb Research is Metrowerks CodeWarrior v5.3 and the terminal emulator/postlinker is MotoCross. Once all the modified files and touched files have been compiled successfully, CodeWarrior links (MotoCross.exe) all the files in the project to produce your output binary (aka: application, which, in our case is glider.app).

Metrowerks CodeWarrior uses .mcp files to organize the code into projects. Below is a step by step procedure on installing CodeWarrior and the associated patches.

2.2.1 INSTALLATION of Metrowerks Codewarrior:

1. Insert Metrowerks CodeWarrior v5.0 CDROM and perform a target install, checking the following: a) MacOS 68K PPC C/C++ b) Win32-x883 C/C++ (CDR-1).

2. Upgrade to Metroworks CodeWarrior v5.3 (CDR-2).

3. Install Persistor Host Tools (v. 2.2.2.6) (CDR-2). Run the Persistor setup. This will install MotoCross and the MotoCross Support folder into Codewarrior.

4. In directory:

C:\Program Files\Metroworks\CodeWarrior\MotoCross Support\

Rename the motocross.exe > motocross-version220-from2226-CD.exe and copy in (CDR-2) motocross-beta-229.exe. Then rename it motocross.exe.

5. In directory:

C:\ Program Files\Metroworks\CodeWarrior\MotoCross Support\CF1\libraries\

Rename CF1.Patch.Lib > CF1.Patch-from-2226-CD.Lib.

Copy in (CDR-2) CF1.Patch.Lib.

6. In the directory:

C:\Program Files\Metrowerks\CodeWarrior\bin\Plugins\Linker\

Rename MacBinarzePostLinker.dll > MacBinarzePostLinker.org.

Copy MotoCrossPostLinker.dll (CDR-2) into the directory

7. You’re ready to compile!

2.2.2 CONFIGURATION and OPERATION of Metrowerks CodeWarrior:

Now you’ve got the most recent version of the Glider Controller code and you’ve installed your compiler. The next step is to compile and link the source code into an executable application. Follow these steps to compile your code.

1.

Open CodeWarrior v5.3 and select Open from the File menu. Select glider.mcp from the dialog box and hit “Open”.

2. A project window called ‘glider.mcp’ will open. Double click edit_struct.mcp and a project window called ‘edit_struct.mcp’ will open.

3. Now, you’re going to ask CodeWarrior to ‘make’ the edit_struct project. Click the highlighted button, referred to as the ‘MAKE’ button, to make edit_struct.

4. Open a DOS window and set the working directory to:

c:\mycode\glider\code\

Then, enter edit_struct. You should get the following result:

5. Return to the CodeWarrior window. Make sure the glider.mcp window is active and then hit ‘make’ to make glider.mcp. A building glider.mcp window should appear as below. The Glider Controller source code is now being compiled and linked.

2.2.3 CONFIGURATION & OPERATION of MotoCross:

Once you have successfully compiled the Glider Controller code using CodeWarrior, you still need to load the glider.app onto the SLOCUM vehicle. This is done using MotoCross.

1. Start MotoCross.exe. For this first time only, select Communication Settings from the File menu and select the following settings:

a. Port: 1

b. Baude Rate: 115200

c. Max Download Rate: 115200

d. Parity: None

e. Data Bits: 8

f. Stop Bits: 1

g. Flow Control: None

2. Once MotoCross is open, turn on your simulator. The simulator should boot into GliderDos and run ‘autoexec.mi’. All loading and unloading of new code, data files, data log, etc. is done in PicoDos, so you need to exit GliderDos and load PicoDos. To do this, enter the following at the GliderDos command prompt:

pbm <> Loads the Persistor Boot Monitor

pico <> Loads PicoDos through the Persistor Boot Monitor (PBM)

You must be in PicoDos to load the new Glider Controller code (glider.app). If you try to do it in GliderDos, the simulator will hang, and you’ll have to start over.

3. Select Load from the Transfer menu (F7). Highlight glider.app and hit Open. A progress window will open and begin the transfer. The screen should look something like the following:

4. After the transfer is complete, you want to reboot GliderDos. To do this, enter the following:

boot app <>

5. The new code is now loaded and ready to go!

3.0 GLIDER CODE THEORY AND OPERATION

The brain of the SLOCUM AUGV is a Persistor Instruments Inc.â CF1 computer chip (Figure 1A) based on Motorola’s MC68CK338 design (Figure 1B). The disk space is provided via a removable compact flash card. The SLOCUM vehicle also contains a separate Persistor for the collection and logging of scientific data (science computer) in addition to CTD measurements, which are currently logged by the glider computer.

3.1 SLOCUM OPERATING SYSTEMS

The operating system for the Persistor CF1 is PicoDOS (Persistor Instruments Card Or Disk Operating System). PicoDOS is smaller than, but very similar to DOS, and many DOS commands will work in PicoDOS. Uploading of new Glider Controller code, new mission files, and retrieval of data files are all done in PicoDOS.

GliderDOS is an application that is loaded onto the Persistor(?). This resident operating system is a subset of PicoDOS which is used to run the glider controller code. Missions are executed from within GliderDOS. It is written in C/C++ and compiled using Metrowerks CodeWarrior, and then postlinked and uploaded to the SLOCUM vehicle via MotoCross.

3.2 GLIDER CODE DESIGN

The user commands the SLOCUM glider by writing mission files (text files with a .mi extension) and loading them onto the Persistor. The mission is then executed from within GliderDos. Mission files are based on a layered single thread approach where tasks are coded into behaviors (behavior:_) which themselves, are composed of behavior arguments (b_arg:_).

During a mission, the glider is continually updating a large number (ca. ~500) of variables. These variables are referred to as sensors (sensor:_). In the simplest terms, sensors are defined as any variable whose value is changing over the duration of a mission. Some examples of sensor values are gps fixes, piston displacement pump position and CTD values.

All sensor definitions, behavior arguments and behaviors are defined in a file called MASTERDATA, which is located in c:\mycode\glider\code\. When a mission is run, GliderDos checks the sensor values against those in the MASTERDATA file. If a sensor value is set in the mission file (.mi), the default value in the MASTERDATA file is overridden; otherwise, the default value is used to determine the behavior, movement or limit thereof the glider for that specific mission.

3.2.1 CONTROL LEVELS

The SLOCUM glider controller software contains five ‘layers’ or levels of control. These layers of control can be visualized in the following hierarchal structure:

Layered Control (behaviors)

Dynamic Control (movement of motors)

Device Drivers/Device Scheduler

Sensor Processing

Data Logging (.dbd, .sbd, .mlg, .log files)

Layered Control determines which behavior is controlling glider movement. Once layered control determines this, Dynamic Control moves the motors, inflates/deflates the bladders, etc., to initiate the movement or behavior commanded under the layered control. In order to do this, Dynamic Control uses a specific set of Device Drivers to perform the movements. Sensor Processing involves the algorithm calculations to assign values (1 or 0) to the sensors. Log Data is self explanatory, except that values of all sensors (ie: variables), instruments, gps fixes, etc are actually logged.

3.2.2 CONTROL: STACKS, STATES & ABORT SEQUENCES

In order to understand this controlled flow structure, it is useful to look at how various types of aborts are initiated and which layers are used to execute the aborts. Much of this information is taken from a text file called ‘abort-sequences’ on the Glider Development website. First, the general structure of a mission file and the assignment of priority levels to a particular behavior will be explained. Then, the three types of aborts will be discussed. Following this discussion, the structure of an actual mission will be explained in further detail.

Once the glider has been instructed to execute a mission, GliderDOS reads the mission and assigns a priority to each behavior. The priority is denoted by a numerical assignment and is determined by the physical location of the behavior in the mission text file. The assigned priority list is called a log_c_stack or stack and takes on the following generic form (the particular behaviors will be explained in further detail later):

log_c_stack():

1 – abend 2 – surface 3 – set_heading 4 – yo 5 – prepare_to_dive

6 – sensors_in

where the words following each number are specific behaviors. When one behavior is assigned priority over another and a behavior argument (b_arg) is satisfied in both of the behaviors (ie: if two or more surface behaviors have been written into the mission), the behavior with the higher priority wins out.

After the log_c_stack() has been created, GliderDOS begins to scroll through the mission in order to activate various sensors and/or behaviors by changing the state of a particular behavior. Whether a particular behavior changes from one state to another depends upon numerous sensor values.

While a mission is being executed, all behaviors are in one of the following states:

(1) Uninitiated

(2) Waiting for Activation

(3) Active

(4) Complete

Towards the end of MASTERDATA is a list of numbers and their ‘assigned’ actions. This list is named ‘beh_args.h’ and can be found in the C code. This list primarily deals with the two b_arg statements: b_arg: start_when and b_arg: stop_when, and determines when a particular behavior becomes ‘active’. Only one behavior can be active at a time (?).

3.2.3 GENERAL CONTROL STRUCTURE

During a typical glider deployment, a mission file is created by layering behaviors in a pre-determined sequence to obtain the desired glider path and vertical movement. The glider mission is being executed through the ‘Layered Control’ as displayed above. All motor settings are controlled through the behaviors.

There are three kinds of aborts which the glider can trigger to get to the surface. They are synchronous abort, out of band abort and a hardware generated abort. Each type of abort utilizes different control layers to perform the abort.

A synchronous abort is an abort in which the behaviors selected in the mission files are no longer called. Instead, Dynamic Control is used to bring the glider to the surface:

Dynamic Control (movement of motors)

Device Drivers

Sensor Processing

Data Logging (.dbd, .sbd, .mlg, .log files)

The dynamic control uses the device drivers to move motors so that positive buoyancy is achieved. All communication and location devices are also turned on (gps, argos, etc.). Also, all system log files are available to trace the cause of the abort. The abort terminates when the glider detects that it is on the surface or if the user interrupts with a keystroke (CTRL + C). Once the abort terminates, control is returned to GliderDOS. You will see a prompt similar to: GliderDos A # >. The A stands for abort (N stands for mission ended normally and I stands for intial, ie: no mission has been run. ) and the # refers to a specific abort code. The abort codes are listed below:

ABORT CODES

-3: MS_NONE

-2: MS_COMPLETED_ABNORMALLY

-1: MS_COMPLETED_NORMALLY

0: MS_IN_PROGRESS

1: MS_ABORT_STACK_IS_IDLE

2: MS_ABORT_HEADING_IS_IDLE

3: MS_ABORT_PITCH_IS_IDLE

4: MS_ABORT_BPUMP_IS_IDLE

5: MS_ABORT_THRENG_IS_IDLE

6: MS_ABORT_BEH_ERROR

7: MS_ABORT_OVERDEPTH

8: MS_ABORT_OVERTIME

9: MS_ABORT_UNDERVOLTS

10: MS_ABORT_SAMEDEPTH_FO

11: MS_ABORT_USER_INTERRUPT

12: MS_ABORT_NOINPUT

13: MS_ABORT_INFLECTION

14: MS_ABORT_NO_TICKLE

15: MS_ABORT_ENG_PRESSURE

16: MS_ABORT_DEVICE_ERROR

17: MS_ABORT_DEV_NOT_INSTALLED

18: MS_ABORT_WPT_TOOFAR

*Abort Codes #5 and #15 are used with the Thermal Gliders only.

During the second type of abort, referred to as an out of band abort, the glider assumes that the software is no longer reliable. For this reason, the upper 2 layers of software control are no longer utilized. Instead, only the device drivers/schedulers are utilized. As with the synchronous abort, the device drivers will be used to achieve positive buoyancy, the last known GPS fix is output and communication devices are turned on. The abort can only be terminated by user keystroke, even though the glider is on the surface. The following dialog is presented:

Want to reset the system? (Y or N)

Want to exit to the operating system?

Make sure you know what you are doing before answering Y

Want to exit to the operating system? (Y or N).

In general, you want to reset the system. When the system is reset, you will be returned to the GliderDos prompt.

The third type of abort is a hardware gererated abort. The glider hardware is capable of autonomously generating an abort sequence and getting the glider to the surface by triggering the burn wire and dropping the weight. There is a watchdog circuit in the hardware with a time constant of either 2 hours or 16 hours, set by a jumper in the hardware and referred to as COP_TICKLE (COP = Computer Operating Properly).

3.3 SAMPLE MISSION AND COMMENTS

The following is an actual SLOCUM glider mission called gy10v001.mi . Black text denotes mission behaviors and behavior arguments (b_arg’s) and is what appears in the mission text and/or MASTERDATA. Blue text denotes comments on what each b_arg actually does. Red text denotes .ma files, which are discussed as they are presented.

behavior: abend

b_arg: overdepth(m) 1000.0

# <0 disables,

# clipped to F_MAX_WORKING_DEPTH

b_arg: overdepth_sample_time(s) 10.0

# how often to check

b_arg: overtime(s) -1.0

# MS_ABORT_OVERTIME

# < 0 disables

b_arg: samedepth_for(s) 120.0

# <0 disables

b_arg: samedepth_for_sample_time(s) 30.0

# how often to check

b_arg: no_cop_tickle_for(s) 7000.0

# secs, abort mission if watchdog not tickled this often, <0 disables

The following ‘behavior: surface’ instructs the glider to come up if haven't had comms for a while, 20 minutes

behavior: surface

b_arg: args_from_file(enum) 10

# read from mafiles/surfac10.ma. This is a new feature of software in which the ‘10’ in enum (see notes below for more on b_arg enum values) tells GliderDos to surface only if the conditions in the .ma file are met. The corresponding .ma file is displayed below:

behavior_name=surface

# surface-20deg.ma

# climb to surface with ballast pump full out

# pitch servo'ed to 20 degrees

# Hand Written

# 08-Apr-02 tc@DinkumSoftware.com Initial

<start:b_arg>

# arguments for climb_to

b_arg: c_use_bpump(enum) 2

b_arg: c_bpump_value(X) 1000.0

b_arg: c_use_pitch(enum) 3

# 1:battpos 2:setonce 3:servo

# in rad rad, >0 climb

b_arg: c_pitch_value(X) 0.3491 # 20 deg

<end:b_arg>

#This allows for ‘generic’ missions to be written with new conditions for b_arg’s to be inserted. A more practical (or obvious) use of this feature is to insert a behavior_name = goto_list which contains inserted waypoints for the glider to go to. Then, you will not have to go into the actual mission file to change the waypoint coordinates; instead you can just insert a new .ma file on the glider with the waypoints.

b_arg: start_when(enum) 12

# BAW_NOCOMM_SECS 12, when have not had comms for WHEN_SECS secs

b_arg: when_secs(sec) 1200

# 20 min, How long between surfacing, only if start_when==6,9, or 12

b_arg: when_wpt_dist(m) 10

# how close to waypoint before surface, only if start_when==7. In this example, this b_arg is not active.

b_arg: end_action(enum) 1

# 0-quit, 1 wait for ^C quit/resume, 2 resume, 3 drift til "end_wpt_dist"

b_arg: report_all(bool) 1

# T->report all sensors once, F->just gps

b_arg: gps_wait_time(sec) 120

# how long to wait for gps

b_arg: keystroke_wait_time(sec) 300

# how long to wait for control-C

b_arg: end_wpt_dist(m) 0

# end_action == 3 ==> stop when m_dist_to_wpt > this arg

The following ‘behavior: surface’ instructs the glider to come up when mission done.