The AUV has four primary sensors, the Pressure, Machine Vision, Sonar and Compass.

Pressure

The Pressure sensor used is Northwest Instruments Aquistar PT2X. We chose the Aquistar PT2X for its rugged design and high-accuracy readings.

Aquistar PT2X Pressure Sensor

Our second generation AUV used an analog Pressure sensor, which read the pressure readings. A microcontroller was needed to perform ADC (Analog to Digital Conversion). While this method was cost-efficient and worked well, we thought it would be a great upgrade to bring to our third-generation AUV.

The Aquistar PT2X is a digital sensor, which reads and stores information including time, pressure and temperature readings into its onboard registers. The PT2X uses the MODBUS1 protocol, via its RS485/232 interface it allowed us to easily read its onboard registers and build custom Java classes allowing our navigation system to have persistent access to the pressure sensor

The PT2X also functions as a data logger, running off of 2 AA batteries, in the event that something goes wrong, we can read the pressure readings afterwards.

Sonar

ARISE’s third generation AUV will feature a passive SONAR system, which will be based on Altera EP1S80 DSP development board.

Altera EP1S80 DSP development board

This decision was made to facilitate shorter development time, smooth integration with MATLAB/Simulink tools as well as Altera’s DSP Builder software. Complete system will feature four hydrophones located on a plastic pod mounted to a AUV’s hull connected to a four channel bandpass filter which is significantly reduces any noise beyond 20kHz-30kHz range, then analog signal is digitized by four Texas instruments A/D 12-bit converters and passed to Stratix FPGA device. Stratix will be running a VHDL code which was designed using Simulink tool with the help of DSPBuilder processing functions. As a result, FPGA should output a heading vector via RS-232 connection to main x86 mission computer.

Machine Vision

Machine vision is of utmost importance in the AUV mission. It is essential in completing two of the four stages of the run. Machine vision is used to track the light buoy, the dashed line and the drop bins for "Davey Jones' Tribute". We are using two 3Com Home Connect PC Digital Web Cams in sealed aluminum enclosures. One is placed facing in the direction of the submarine's motion - used for the light detection - and the other facing downwards - for dashed line and drop bins detection. These cameras have performed very well in testing and we are hoping that they will be sufficient to provide "vision" in the murky waters of the competition site.

As for the software, we are using the OpenCV library for object detection (http://sourceforge.net/projects/opencvlibrary/). It is an open source project by sourceforge that allows users to read and process a video stream in real time. The video is examined one frame at a time. After the frame is obtained, it is put through the Canny algorithm and examined under several threshold levels to detect the object edges. This sequence of steps was borrowed from a sample application provided with the library. Once the edges are found, they are examined depending on the stage of the mission the AUV is currently in. In the case of the light buoy, only the edges with a large number of data points are considered, meaning the circular shapes. For dashed lines and drop bins we look at objects with 4 data points and with 90-degree angles between lines connecting said points. Once the rectangles have been detected, the ratio of the sides is measured and compared the expected as specified by the mission guidelines. Afterwards, the threshold of the area inside the aforementioned shapes is measured and compared to expected values found experimentally, be it green, orange, black or white. The sampling is done by averaging the color value of points along two diagonals in the case of the orange tubing and the black bins, the two perpendicular diameter lines for circles and scaled rectangles for the white area surrounding the drop bins.

We opted for using this technique instead of object detection and tracking using Haar classifiers, which are also provided by OpenCV, because said classifiers take about 30 hours to train. This number is simply unacceptable since there is no way we can simulate exact water and lighting conditions of the competition site at our testing pool. We would have to train the classifier at least once during the competition, which would severely reduce the time that could be spent perfecting and testing the rest of the code.

Compass

The compass used is the HMR3000 manufactured by Honeywell. It operates on the RS232 serial interface and being solid state, it was perfect for our application.

The HMR3000 is a simple device, it broadcasts NMEA formatted strings through its RS232 serial bus providing us with the heading needed by the Navigation System.

Honeywell HMR3000 Compass

Thursters

The thrusters are custom made and each thruster uses a Hacker Brushless motor at 12V. The brushless motors were chosen because of their greater efficiency over brushed motors and their longer life. Each thruster is sealed with CNC machined dual o-ring end caps; a CNC machine also fabricated the motor's shaft couplers and shaft extender.

Custom-made Thrusters

All mechanical fabrication was done in- house by the talented mechanical engineers on our team.

Dropping Mechanism

The dropping mechanism used is based on a servomotor, which rotates a metal bar allowing the metal marble to fall through a PVC shaft.

The servomotor is enclosed in a sealed aluminum compartment exposing its rotating torque screw. Screwed to the torque screw are the metal bars, which keep the metal marble in place.

The servo motor is set to rotate 180 degrees, 90 degrees will drop the first marble and another 90 degrees drops the second.

The servomotor is controlled with a PWM (Pulse Width Modulation), which is simulated by an ATMEGA8 microcontroller. The microcontrollers are part of an Arduino board.

Arduino Board	Dropping Mechanism

System Architecture

The system architecture is the biggest change, as all the previous AUV designs by ARISE were based on Linux, using C/C++ and using a compact Hard Drive.

This year we decided to use Windows 2000, why? Well windows 2000 installation is much smaller than Windows XP’s and we were quite limited to Hard Drive space as we are using a micro drive with 4Gb.

The micro drive consumes much less power than the 2.5” counterpart, which reduces the overall heat in the electronics compartment to reduce the chance of condensation.

Our previous generations were based on C/C++ code, we decided to change all our code to Java, why? Well Java as you know is platform independent, so if we ever would want to move back to a Linux based platform, it would be just as easy as moving our code over to the new operating system.

Our SBC (Single Board Computer) is an Acrosser AR-B1832 operating at 1.6 GHz using a Pentium Mobile processor and 256Mb of RAM. Our previous generation SBC was clocked at 266MHz which gives us over 6X the processing power.

The SBC acts as a hub for all communication. Every sensor is connected to it including the DSP board. All onboard sensors are connected to the system bus via RS232 or USB. The compass and pressure sensor are using the RS232 serial bus and the Machine Vision (3Com Home Connect Webcam) is connected via USB.

Acrosser AR-B1832 SBC

All electronics, including the SBC, sensors and DSP board are in the upper hull, which has been designed to house all electrical components. The rest of the hull is used for the mounting of the motors and the lead-acid battery. Power System The AUV is powered by a lead-acid battery housed in the lower hull. Placing them in the lower hull aids in the vehicle’s stability underwater. The battery provides 12V at 12Ah.

All processes and software are written in Java. The software blocks communicate using a simple client-server framework. Servers are the devices that have data to offer, such as the compass pressure sensor and machine vision, the clients are those who need that information, such as Navigation. A client-server framework allows great flexibility in development. This framework allows software blocks to communicate anywhere there is an IP network.

Although the servers can be located anywhere, they are located in the SBC. Each physical sensor sends information to an interface software module residing in the SBC. This interface module contains the most recent data of all sensors. This ensures that any data received by the clients, such as Navigation control is operating with the latest data acquired by the sensor network.

At the lowest level are four modules responsible for the dynamics of the AUV: forward motor, lateral motors (lateral movement and heading change), vertical motors and marker dropping. The decision making is done by the state machine running in a separate process which directs the four lower level controller based sensor inputs and mission parameters.

The controllers operating at the lowest level (forward, lateral, vertical motion and marker dropping) are independent of each other physically, hence also in software. Each controller receives information from sensors relevant to it and automatically adjusts the physical outputs to maintain a state without external intervention.

Our third-generation AUV was designed to last for many years. The streamlined exterior, and highly organized and modular system architecture allows for much flexibility that should meet the changing challenges of the AUV competitions.

Much effort has been placed to ensure the vehicle is as safe as possible, including redundant seals and a kill switch for the motor controls. The code has been completely rewritten in Java. Given Java's Object Oriented nature, the software architecture is as clean and manageable as can be.

We believe our third-generation AUV will be a great success.

See our AUV Pool Test in Action below

AUV Pool Test June 24 2007

Gen 3 photo album