AquaTux - RoboNationVictor Zhang, Ritchie Zhao, et al. University of Toronto Mechatronics Design Association email: [email protected] ABSTRACT AquaTux is the ﬁfth entry of

AquaTuxAdam Suban-Loewen, Anthony De Caria, David Biancolin,

Victor Zhang, Ritchie Zhao, et al.University of Toronto Mechatronics Design Association

email: [email protected]

ABSTRACT

AquaTux is the fifth entry of the Univer-sity of Toronto Mechatronics Design Associationinto the annual Autonomous Underwater VehicleCompetition. The vehicle is designed to au-tonomously complete the set of tasks described inthe mission1. It is equipped with an IMU, a depthsensor, and two cameras that allow it to navigatein its environment. This year’s frame was reusedfrom previous years. We are proud to presentnew electronics, a new embedded system using anFPGA, and new software.

1. INTRODUCTION

The construction of the vehicle that our teamwill present at the 2014 Autonomous UnderwaterVehicle (AUV) competition encompasses severalnew achievements. We explain the context of ourrealization by first describing the main objectivesof the competition and how our team is organized.

1.1. Mission Overview

The objective of the competition is to build an au-tonomous underwater vehicle to perform varioustasks involving image recognition, and passivesonar to interact with its environment. For thevision-guided tasks, the vehicle must pass througha validation gate, hit buoys, follow pipes, passthrough set of pipes, drop an object in a box,launch a projectile through a hexagonal target,

and manipulating a wheel. The sonar tasks con-sists of grabbing an object on top of an acousticpinger and surfacing above it. The details of therequired tasks for the vehicle are described inthe mission specification on the AUVSI website1.Through the design and testing phases, emphasiswas placed on performing a subset of these taskswell rather than attempting all tasks.

1.2. The Team

The team consists of twenty members that aredivided into three subsystems: mechanical, elec-tronics, and software. In order to maintain ahigh degree of integration throughout the project,members are encouraged to work in projects thatspan multiple subsystems. Our hardware is ob-tained through sponsorship and funding from ouruniversity (see Section 8).

Figure 1 illustrates the major components ofthe AUV and the reader should refer to it oftenas we describe the innovative aspects of thosecomponents in the following sections.

2. FRAME DESIGN ANDCONSTRUCTION

The current frame design is mostly unchangedfrom previous years. Under the vehicle’s oper-ating conditions, we determined that the effectsof fluid dynamics were negligible in terms of

1http://www.auvsifoundation.org/foundation/competitions/robosub/

Mechatronics Design Association – University of Toronto 1

Figure 1: Organization of the AUV modules and their connectivity.

functionality. For this reason, a “design formanufacturing” development methodology wasadopted: in efforts to minimize cost and ma-chining time, the frame has been designed totake advantage of commercial off-the-shelf partsas well as capitalize on simple manufacturingprocesses.

2.1. Design Considerations

The final design was conceived such that it couldbe fabricated without the need for outsourcing.

Below is the list of the desirable attributes forthe frame that we set out to obtain based on theexperience gained from past frame designs:

1. Minimize time required to access batteriesand electronics;

2. Maximize modularity for easier transportand progressive revisions;

3. Optimize mass for transport, functionalityand points;

4. Provide a secure removable internal rackfor electronics to facilitate bench testing;

5. Obtain a a waterproof seal with a simplelow tolerance assembly;

6. Create solid harness points and handles;7. Facilitate movement through water and max-

imize battery life with a neutrally buoyantdesign;

8. Compensate for changes in mass distribu-tion and motion calibration with adjustablethruster positions;

9. Design an attractive and professional look-ing vehicle.

2.2. Frame Overview

The AquaTux frame design can be divided intothree subsections: external frame, hull, and in-ternal rack. The goals based on above sug-gested the need to minimize the number of sealingsurfaces and reduce the number of waterproof


Figure 2: Adjustable PVC tube exoskeletonframe.

connectors. To achieve these objectives, a singleenclosure was created (the hull) to encapsulateeverything except for the markers to be dropped,the motor thrusters and the hydrophones. Theseexternal components would be connected to anexoskeleton type frame which allows for flexiblemounting arrangements. Finally an internal rackwas designed to hold all the electrical componentsincluding cameras and embedded computer.

2.2.1. External Frame

The external frame was designed with transporta-tion and fabrication as the primary constraints.This exoskeleton is made entirely of commercialoff-the-shelf parts, 1

2inch PVC plumbing pipe

and connectors. The thruster positions are fullyadjustable since they are attached to individualpipes fixed in place by standard gear clamps(Figure 2). The adjustability of the frame alsofacilitates transportation as the entire structure canbe collapsed to fit a smaller envelope.

2.2.2. Hull

The hull design attempts to minimize the num-ber of sealing surfaces while maintaining usablespace inside the vehicle. In order to seal the hull,a lid was made with a special simplified O-ringgroove (Figure 3). To avoid the need for preci-

Figure 3: O-ring displaced to show the groovesand nylon dowel.

sion milling or numerically controlled machines,an oversized rectangular groove was cut. Thecorners were then drilled out and replaced withnylon dowels to prevent the sharp corners fromcutting into the O-ring. This design eliminatedthe need for specialized end mills or the need tomill curved patterns in the lid.

Past experience suggested the need for a quicker,safer method to access the internal components ofthe hull. A torque wrench, used with nuts andbolts provides a fast, foolproof means to compressthe O-ring, creating a water-tight seal.

An endplate was designed to provide a singlereplaceable surface to accept all the connectorsbetween the interior and exterior of the vehicle.This endplate is sealed with a groove similar tothat of the lid and is attached with self seal-ing screws from APM Hexseal. The waterproofconnectors which pass through the endplate leadto two master-disconnects which allow for quickand easy installation of the internal rack (Fig-ure 4). The waterproof connectors chosen are 8-pin Neoprene molded connectors from ImpulseEnterprise. These connect the thrusters as well asthe wireless tether and provide maximal flexibilitydue to their pin count as well as small profile. Thepressure readings for the AUV are also gatheredthrough the endplate. In order to sense depth,a MPX4115 pressure transducer is coupled to a


segment of PVC tubing connected to a compres-sion nut on the endplate. The depth of the vehiclecorresponds to the pressure of the air trapped inthe PVC tubing. The hull is fabricated from 1

8

inch thick polycarbonate sheets, with waterproofepoxy bonding the joints together. To strengthenthe bonds, aluminum angle brackets were addedto the edges to increase the bonding area of theepoxy. The thin, clear polycarbonate walls ofthe hull allow peripherals such as the cameras,marker droppers and torpedo trigger to operatefrom within the vessel. Although the markerdroppers and torpedo launcher did not make it intothis year’s submarine, the polycarbonate wallsfacilitate the addition of the peripherals and amethod to actuate them.

2.2.3. Internal Rack

The frame was designed to be reconfigured andusable in future years. The concept for the inter-nal rack consists of base plates that accepts stacksof electronics. These plates can be removed asa single unit which facilitates wiring, and benchtesting. Due to the buoyancy of the hull, stainlesssteel bars were used to add weight to the vehicle.These weights act as a method of balancing thevessel and allow the electrical components to beeasily removed for debugging or modifications.The internal rack does not rest directly on the floorof the hull. In case of a leak, water would collectin the space below the electrical components andbe detected with leak sensors prior to any damage.

3. ELECTRONICS

Our electronics were designed to handle all low-level tasks that are required to move AquaTux,acquire sensor data from the IMU and depthsensors. The main goal of the electronics is toallow the AUV to be driven with only high-levelheading and depth commands. The electronicsare responsible for executing the commands andcontrolling their results (e.g. depth or heading)

(a) Endplate showing waterproof connectors.

(b) Master disconnects for the waterproof connectors onthe inside of the vehicle.

Figure 4: Connection system to the outside of thevehicle.

in a “black box” fashion. The electronics aremanaged by the embedded system described inthe next section, giving access to each electronicperipheral.

Aquatux’s electronics are arranged in two stacksof PCBs, one dedicated to power distribution andmanagement, and the “main stack”, which breaksout the on board FPGA’s I/Os to any number ofchildren.

3.1. Main Stack

At the heart of Aquatux’s electronic subsystem isa Terasic DE0-Nano, a small form-factor FPGAdevelopment board, containing an Altera CycloneIV FPGA. The DE0 mates directly to the “In-


Figure 5: The main stack connector. Top, theinterface board and DE0 nano. Below, two 6channel motor drivers.

terface Board” which breaks out all of the avail-able I/0s to a 120 pin board to board connector(Figure 5). Any number of new PCBs can bemated, by providing the mating male and femaleconnectors. These connectors form a wide busbetween the FPGA and the mating boards, whichwhen coupled with the reconfigurability of anFPGA, makes it very easy to incorporate newPCBs without having to physically rewire parts ofthe submarine – a Quartus recompile is all that’srequired. The interface board also connects to theIMU, a VectorNav VN-100 Rugged, which per-forms its own sensor signal processing to outputattitude data to the FPGA.

3.2. Motor Board

The motor boards are used to control the SeabotixBTD150 Thrusters used on AquaTux and otheractuators internal to the submarine. Each mo-tor board (Figure 6) consists of 6 NMOS high-side half bridges driven by Linear TechnologiesLT1660 half-bridge drivers. Each half bridge hasa sister with which it can be used a full bridge,by soldering the output connector in the correctposition. Complementary PWM inputs to eachdriver can be sourced from one of three sets

Figure 6: A motor board, configured with 3 fullbridges.

of I/Os provided via the main stack connector,allowing a multiplicity of boards to be mated tothe stack. Presently, two of three boards are used,providing the five full bridges required to driveAquatux’s motors. The final board is provision todrive internal peripherals such as marker droppersin future competitions.

3.3. Power Distribution

Power for Aquatux’s electronic systems, exclud-ing the netbook, is provided by two 24V NiMHbattery packs. The power distribution board switchesthe battery voltage with a relay, which is con-trolled by the FPGA’s soft-processor. Throwingthe kill switch (by removing the velcroed handleon the side of the hull) opens a reed switch whichbreaks the relay’s coil current. Three DC/DCconverters (3.3V, 5V, 12V) source from this volt-age, and form a stack of PCBs with the powermanagement board above them. LC output filterson power management board remove switchingharmonics, before breaking out the rail voltagesto the submarine through a series of copper bus-bars. Four pairs of analog comparators alert theFPGA when any of the rails over or under-voltsby 5 percent of their nominal voltage. As a finalbaseline precaution, breakers have been inserted


between the batteries and relay, and between thepower management board and bus-bars for eachrail.

3.4. Power Source

The NiMH battery packs were custom designedby our team: each pack is composed of 20SY136T Sanyo nickel metal hydride batteries.All batteries are connected in series to form a24V nominal battery pack with a capacity of4100mAh. Temperature sensors embedded ineach pack allow the FPGA to kill the sub if anyone pack overheats.

3.5. Leak Sensors

New, custom-etched leak sensors enable AquaTuxto pre-emptively surface upon detection of a leak.The leak sensor design, and etching process alsoprovided an excellent teaching tool for our youngermembers.

3.6. Sonar Board

The newly designed sonar board is used to pre-amplify, filter, and digitize the signals from ourhydrophones. There are four pre-amplificationand filtering channels and two analog to digi-tal conversion channels (as each ADC is dual-channel). The digital output is buffered, beforebeing sent to the main stack connector to com-municate with our FPGA over SPI. Additionally,the board serves as an interface for our IMUconnectors, as well as power monitoring andgeneral analog input.

A bandpass filter was designed using the SallenKey topology to attenuate low frequency noisegenerated from our thrusters, and provide a max-imum gain at the frequencies of interest, i.e.the frequencies of the RoboSub SONAR pinger(Figure 7). Our ADC, Analog Devices AD7264, 1Msample/s, 14-Bit, Simultaneous Sampling ADCwith programmable gain provides a flexible meansof digitizing and communicating with our FPGA.

Figure 7: Bode plot of Sallen Key bandpass filtertransfer function, note the bandwidth and centrefrequency corresponding with the frequency ofthe pinger.

It was selected for it’s high precision, high-speedsampling and communication interface, as well asfor it’s high input impedance, low signal-to-noiseratio, and programable gain amplifiers which al-low us to scale our digital signal according to thedistance from the pinger.

Placement and routing was optimized accord-ing to standard high-speed signal PCB designrules: we use power and ground layers, our high-speed analog and digital signals are kept far awayfrom each other, and trace impedance is designedas small and consistent as possible to minimizenoise and signal reflections (Figure 8).

4. EMBEDDED SYSTEM

The embedded system was designed to link thesubmarine’s computer with all electronic periph-erals, with a high-level interface to access groupsof peripherals. The embedded system consistsof a DE0-Nano FPGA, synthesizing custom cir-cuitry to communicate with each peripheral anda soft processor to communicate with the com-


Figure 8: PCB layout of the Sonar Board,showing a channel for each hydrophone.

puter. The FPGA was chosen for its quantity ofgeneral-purpose I/O pins, allowing it to manageall electronic peripherals, and its compact size of3x2 inches. The FPGA is the only programmableelement in the submarine besides the computer,reducing the amount of communication betweenprogrammable elements.

4.1. FPGA Soft Processor

The FPGA Soft Processor exposes high-level com-mands to the computer to access each groupof electronic peripherals. The IMU and depthsensor provide attitude readings and are used bythe PID controllers and the computer interface.Power management continually monitors eachvoltage rail, and will power off the submarine ifany voltage is invalid. The five motor driversare controlled together by the soft processor’syaw, pitch, roll, and depth PID controllers. Thecomputer interface can set target speed, yaw, anddepth, which are inputs to the PID controllers.Speed is implemented as an offset because thesubmarine does not have velocity measurement.The PID controllers are implemented on the softprocessor because they need immediate access tothe motor drivers and attitude readings. The high-level commands are text-based, allowing manual

control to test each peripheral individually. Futureplans for sonar processing will be implemented onthe FPGA, using the soft processor and built-inDSP elements.

4.2. FPGA Hardware

The FPGA also synthesizes custom hardware tocommunicate with peripherals through general-purpose pins. This flexibility can support anyprotocol to communicate with peripherals, in-cluding SPI and UART. Each peripheral protocolis a separate module, memory-mapped to thesoft processor across Altera’s Avalon Bus. TheDE0-Nano has 85 general-purpose pins for digitalinputs and 8 ADC inputs. The depth sensor isan analog peripheral, and all other peripheralscommunicate digitally. The hardware and softprocessor run at 50 MHz.

4.3. Sonar Signal Acquisition and ProcessingSystem

A newly designed SPI controller module acquiresdigital signals from the Sonar Board. It uses high-speed serializers and deserializers, following a 34MHz PLL clock, to transfer data from the SPImaster-out-slave-in (MOSI) and master-in-slave-out (MISO) lines. Enables are generated with 16-bit counters, and set according to the ADC’s serialinterface. Despite SPI providing a multi-slavecapable bus, we implement one SPI controller foreach ADC, ensuring samples are not lost when anADC is inactive (Figure 9).

The signal processing system uses the cross-correlation operation on each combination of hy-drophone signals to determine the point at whichthey are most in phase. From here, we cangenerate the time delay of sound arriving at sub-sequent hydrophones. Given this information, andknowledge of the hydrophone array geometry - asimple 10 cm per edge square configuration - wedetermine the attitude towards the sonar pinger.


Figure 9: Schematic diagram of the SPI controllermodule, showing serializers and deserializers.

Figure 10: Software module organization.

5. SOFTWARE

The submarine’s software is aware of the compe-tition objectives, and performs computer visionto command the submarine to move through theembedded system. The software is organized sothat it is easy to test the core vision and controlsystems with different sources of video input andto command the submarine or the simulator tomove.

5.1. Software Organization

The software is broken down into 3 components(Figure 10): (i) the video input; (ii) the mis-sion software gives physical commands to movethe sub; and (iii) the environment that reactsto the physical commands. The video input

Figure 11: Example image from the simulatorshowing pipe segments and the buoys in turbidwater.

can come from the submarine’s webcams, pre-recorded video, or the simulator (Figure 11).The mission software can be the autonomousalgorithms that drive the submarine or a manu-ally controlled user interface. The environmentthat reacts to physical commands can be thesubmarine or the simulator. The manual userinterface allows us to act as a passive observer,constantly requesting the state of the vehicle, oras a controller sending commands to the AUV.

5.2. Simulator

The simulator is a piece of software written inC++ using the OpenGL library. Its purposeis to simulate the competition grounds so thesoftware and vision algorithms can be tested withgreater ease (Figure 11). The simulator can acceptcommands to move the camera viewpoint, so thatwe can properly simulate video feedback whenthe submarine is commanded to move.

5.3. Software Control

Our control algorithms are run the submarine runsautonomously. The entire mission is broken downinto tasks, such as the gate or buoy task, whichare implemented in separate modules. The controlcode queries the vision system for circles, lines or


rectangles, and translates the vision result into amovement command. While the submarine is re-acting to a movement command, the video input isignored to prevent overshooting or oscillating thetarget. Each control task can be tested separately.

6. VISION

The machine vision system is defined as all soft-ware and hardware which converts images (theinput to the system) into numerical data (the out-put). This data refers primarily to the existence,position, orientation, and color of various objectsin the image, such as the starting gate or a coloredbuoy. This information is handed off to the restof the software, which acts on it to determinethe correct course of action for the submarine.Because the internal representation of an imageis simply a large matrix of numbers, the visionsystem’s job can be thought of as filtering thislarge volume of mostly extraneous data to a fewpieces of useful data, which the control systemcan then analyze.

6.1. Vision Hardware

The hardware for the vision subsystem consists oftwo cameras and a small netbook. Both camerasare Logitech Webcam 9000 Pro webcams, oneof which points forward, and the other of whichpoints down. These cameras were chosen fortheir price (about $50 each) and the availabilityof Linux driver support. The netbook used is anHP Atom netbook. This model was chosen for itssmall size and low cost.

6.2. Vision Software

All of our image processing code is written inC++, using the OpenCV library. A large numberof algorithms were tried and discarded during thedevelopment of our final flow. Due to the scope ofthis document only the final algorithms used willbe described.

The image processing flow can be brokenup into three distinct parts: image segmenta-tion (separating a 3-channel image into 1-channelpieces based primarily on color), object recogni-tion (classification of each segment as backgroundor target) and property calculation (deriving theobject’s properties such as location or color). Thealgorithm used for each step is distinct and will bediscussed below.

Image segmentation is performed using OpenCV’simplementation of the Watershed algorithm. Thealgorithm works iteratively from a collection ofsegmented pixels (seeds) and at each step asso-ciates the most similar pixel adjacent to a seg-mented pixel with that segment. It returns agrayscale image, with different gray levels corre-sponding to different segments. Each seed pixelhas a value associated and two seeds of the samevalue will contribute to a single segment.

The performance of the Watershed algorithmis heavily dependent on the quality of the seeding.Optimally we want at least one seed for eachdifferent object in the image and at least one seedfor the background. A single object should nothave two different valued seeds, as this will causetwo segments to emerge. To seed the algorithm,we take a random sample of pixels from thesource image, and run K-Means clustering tocluster the samples based on color similarity. Theresults of the clustering is a minimum collectionof pixels which are representative of the colorspace of the image. The clustering results used toassign values to the seeds - similarly colored seedswill get the same values (Figures 12 and 13).

Object recognition is made simple due tothe fact that only circles and rectangles need tobe recognized for the tasks we are aiming todo. OpenCV can find the minimum enclosingcircle and (rotated) box for any segment, and asimple comparison of area, perimeter, and varioussymmetry properties can be performed to checkif the segment is similar to its enclosing shape.For example, a the minimum enclosing circle ofa non-circular segment will leave large amounts


Figure 12: Example image at a test pool, withseed locations overlayed.

Figure 13: The test image segmented.

of blank space, and will therefore have a verydifferent area compared to the segment.

Property calculation is done on a target-by-target basis. For most targets (the buoy, forexample), it is sufficient to know the position andcharacteristic dimension in pixel space. We canthen use these numbers, along with the camera’sfield-of-view and the physical length to calculatethe position and range of the object in real space.For the pipes at the bottom of the pool, theposition angle is also needed. All of the pixleproperties are easily extracted from the enclosingshape derived by OpenCV. To identify an object’scolor, we convert the BGR color of the objectinto HSV, which is more robust against changesin brightness, and use the resulting hue value to

determine the color of the object.Finally, in order for the vision code to return

stable results and be robust against noise, we storethe objects identified in the current frame beginprocessed as well as a number of frames prior.We use this to average and filter the numericalinformation from multiple frames. This allows ussome room for error - a single frame with poorsegmentation or a stray object will not destroy thesystem’s performance.

7. CONCLUSIONS

This year’s team took on the challenge of buildingnew electronics, digital hardware and software.This AUV is composed of a Netbook that is linkedto a single FPGA that drives the electronic pe-ripherals. The Netbook runs mission-aware visionsoftware, which uses the OpenCV library. Circuitboard fabrication, plastic machining, embeddedprogramming, and software engineering are someof the skills that many of our members were ableto acquire. More rational design techniques andproject management skills are also derived fromthe our previous competitions and they had asignificant effect on maximizing the productivityof all the man-hours contributed to the project.

8. ACKNOWLEDGMENTS

We would like to thank the staff of the Universityof Toronto for supporting our project.

We would also like to thank all our sponsorswho have helped make this project possible: TheUniversity of Toronto Engineering Alumni As-sociation, The Edward S. Rogers Department ofElectrical and Computer Engineering, The Divi-sion of Engineering Science, the University ofToronto Engineering Society, and Altera.


Documents

AquaTux - RoboNationVictor Zhang, Ritchie Zhao, et al. University of Toronto Mechatronics Design Association email: [email protected] ABSTRACT AquaTux is the ﬁfth entry of