Page (1/3)


Seawolf I is an advanced autonomus underwater vehicle (AUV) based on a patent-pending mechanical design by Vortex HC, LLC. It achieves true holonomic motion in six degrees of freedom by virtue of its three posable thrusters, which independently pivot 270 degrees. All electronics are housed in a clear acrylic tube at the front of the vehicle. A full suite of sensors guide the vehicle including a doppler velocity logger (DVL), inertial measurement unit (IMU), altimeter, color camera, and an acoustic hydrophone array. Processing is carried out on a PC/104 computer running Linux, along with a custom DSP-based system for performing acoustics navigation.

Libraries

Seawolf I uses a vision library written with Intel’s OpenCV platform to acquire and process images taken from a color CCD camera. The Video4Linux API is used to acquire images, and OpenCV, in conjunction with some specially written processing libraries is used to analyze the images, producing useful mission data

 

Acoustic Navigation

This year's mission requires the vehicle to locate and swim towards an acoustic beacon (a "pinger") the emits ultrasonic sinusoidal bursts. We developed a navigation computer that is based on a digital signal processor (DSP) from Texas Instruments. We first prototyped this system using a development kit from Spectrum Digital and a breadboard. We then migrated our design over to a 2x8 inch custom PCB (shown below).

To detect the bearing of the ping, all four channels are sampled within a timer interrupt routine that runs at 200kHz. Data is sampled for 2 seconds, after which the timer is shut off and the ping detection algorithm runs. We first bandpass the captured data on one channel using a 4th order Butterworth filter centered around the expected ping frequency with a bandwidth of 1kHz and perform an adaptive threshold to determine a rough location of the edge of the ping. We then establish a window around this location and bandpass the remaining channels within this window. If we’re running in “practice” mode, then we should see two pings, so this analysis is done again to differentiate the pings and select the correct one, based on whether they are .9 seconds apart or 1.1 seconds apart. Pair-wise time delays are calculated by evaluating the cross correlation series for each pair of channels. Given the geometry of the hydrophone array and assuming a plane wave propagation of the ping, we can triangulate the location of the pinger using simple trigonometry. Using 3 hydrophones not only eliminates the 180-degree ambiguity of 2 hydrophones, but it provides 3 pair-wise delays that can be averaged for greater accuracy. The resulting angle calculations are sent to the main PC/104 computer via an RS232 data link.

 

PC/104

For our main computer, we chose the Diamond Systems Hercules PC/104 with a 550MHz Via Eden processor, 256MB of RAM, and a 20GB 2.5 inch harddisk. This particular model has onboard data acquisition circuitry (DAQ) that provides 32 analog I/O and 40 digital I/O lines (4 of which are PWM channels), thus eliminating the need for an additional card. A Parvus FG104 framegrabber board is used to capture images from our camera.

 

Acoustic Navigation DSP Board

It was quickly realized that a dedicated processor would be required to process acoustic data from our hydrophone array. For this, we chose to build our own system from scratch based on the Texas Instruments TMS320VC5502 DSP. We use a 64Mbit SDRAM chip for storing sample buffers and for algorithm scratch space. For sampling data from the hydrophones, we tried several ADCs before settling on the AD7655 from Analog Devices. This particular ADC has 4 input channels and samples two channels simultaneously. It is capable of a per-channel throughput of 250kSPS. The signal chain begins with a 3-stage instrumentation amplifier circuit composed of AD743 op-amps. The first two stages each provide a gain of 20, and the last stage is a summing amplifier which uses the AD780 precision 2.5V reference source to center the signals at 2.5V before they are sent to the ADC.

Aucoustics nav board

We used Spectrum Digital’s C5510DSK development kit to prototype our algorithms and analog front end hardware and then migrated our design over to a custom 4-layer PCB. This PCB contains the DSP, SDRAM, ADC, op-amps, a power supply, an RS232 level shifter, and a header for a JTAG emulator.

Thruster Controller Processor

A BasicATOM microcontroller was used to translate messages received over RS232 from the PC/104 to the thruster’s I2C bus. Each message is formatted with a start-byte, three bytes representing the speed of each thruster and a checksum. The start-byte guarantees that the BasicATOM will not misinterpret messages and the checksum guarantees that the BasicATOM will not execute corrupted data. If the BasicATOM does not receive a signal from the PC/104 for a certain length of time, it automatically shuts down the thrusters.

 

Software Architecture

The main computer runs Slackware 10 Linux with a 2.6 kernel. Diamond Systems Universal Driver 5.8, Boost uBLAS, XSens Motiontracker, and OpenCV are external libraries we used for collecting sensor data, calculating control solutions and image processing. Seawolf I’s software is written in C++ and is organized into three tiers along with a common hardware API. Each tier adds a layer of abstraction from the hardware.

 

Hardware API

Seawolf I needs several interfaces to communicate to all of its devices. For instance, the DVL and IMU use RS232, but the altimeter uses an analog input to the onboard DAQ. The thruster servos rely on PWM signals from the DAQ. A central API was developed that encompasses all of these requirements, providing a streamlined interface to the computer’s hardware and a unified error handling scheme. This API allows for future updates to underlying hardware drivers without modification of upper level components.

The API wraps functionality provided by Diamond System’s Universal Driver, which allows access to I/O on the DAQ. The API also provides functions for RS232 serial communication. Several functions using the Video4Linux library were added that allow the image processing routines to capture video frames or change properties of the framegrabber.

 

Multi-threaded Software Framework
We utilized a pthreads library for creating multiple execution threads in Seawolf I’s main program. One of the problems with using this C threading library with our C++ application was creating a C++ function of a class as a thread. The pthreads library only allows C-linked functions to be threads, but we needed to have C++ member functions (or the very least, functions that could access private class fields) act as threads. The only workaround for this problem is to create a separate C-linked function which calls our C++ member function. This fix allowed us to write almost every class as a separate execution thread (or sometimes multiple threads in a single class).

 
Page (1/3)

 

For more detailed information about Seawolf I, refer to our 2005 AUVSI journal paper