1

LEVIATHAN: The Design and Implementation ofDuke Robotics Club’s 2017 AUVSI Competition Entry

Andrew Buie, Nathaniel Brooke, Mark Chen, Neil Dhar, Kelsey Evezich, Estelle He, Sameer KhanAustin McKee, Morton Mo, Vinit Ranjan, Logan Rooper, Samadwara Reddy, Raiyan Sobhan

Ramil Shaymardanov, Will StewartIn 2017 the Duke Robotics Club returns for their second year in recent time to the AUVSI RoboSub competition with a faster,

smarter, and leaner reconstruction of their faithful robot, Leviathan. Like last year, Leviathan is the brainchild of dozens of Dukeundergraduate engineers and computer scientists working tirelessly throughout the year through the completely student-run DukeRobotics Club. Leviathan’s outstanding waterproof mechanical design is the result of extensive research, simulation, modeling, andin-house CNC machining. In dozens of hours of testing no capsule has ever leaked, and the vehicle has proven highly maneuverablein every direction. Electronically Leviathan combines four brushed motor drivers, three hydrophones, two cameras, two inertialmeasurement units, a doppler velocity log, an altimeter, an on-board computer, and a unified power system to create a fully featuredplatform for informing and running the code base. The Python software stack retrieves the sensor data and fuses it to obtain aprobabilistic estimation of state. It uses this state estimation to power controls, optimally derived from a model of the robot. Finallyto navigate, a convulational neural network recognizes and tracks surrounding obstacles at 60 fps, allowing motion planning to plotthe best course through the water. Leviathan was the result of incredibly hard work by students at Duke University, but equallyas important, the project owes its continued success to the club’s long-time mentors and sponsors, The Lord Foundation and theDuke Student Government Student Organization Funding Committee.

I. INTRODUCTION

LEVIATHAN returns this year to the 2017 AUVSIRoboSub competition with the Duke Robotics Club

for their second time competing in a competition since2008. Work on the project, split between three differentsubsystem teams (subteams), began in Spring 2014. Themechanical subteam was responsible for the electronicsenclosures, actuators, frame design. The electronics sub-team was responsible for the power architecture, the sens-ing systems, the onboard computation hardware, and thefirmware for the microprocessors. The software subteamwrote software to control the robot, handling everythingfrom sensor fusion to motion planning to computer vision.Lastly, the testing team was responsible for ensuring thequality of the other subteams’ contributions as well asrunning integration tests in the pool.

II. HARDWARE DESIGN OVERVIEW AND STRATEGIES

A. High-Level Approach

Leviathan was originally designed in the context ofa brand new team approaching the AUVSI competitionwith no previous experience. Because of that, the designprocess began with a detailed study of the competitionrules, previous score results, and previous design entriesinstead of a traditional iteration on a previous entry.Research revealed that many teams struggle to implementeven basic functionality, and many others are unable touse sophisticated features because of reliability problems.This research led the team to prioritize navigation-basedtasks and to build a highly maneuverable AUV. The goalwas to create a design that is sufficiently modular thatnew instrumentation and robotic manipulators could be

added later without difficulty, and a design that wouldbe robust and reliable enough to function as designedat the competition, something that many teams strugglewith. Competition rules and requirements were weightedagainst soft factors to develop the following additionaldesign constraints:

– Make maintenance and troubleshooting as easy aspossible

– Focus on navigation-based tasks, but allow for mod-ular upgrades

– Give up size/weight optimizations for potential func-tionality

– Give up size/weight optimizations for greater inde-pendence of the subteams

– Favor reliability and robustness over complexity andadditional functionality

However, last year’s competition gave the team invalu-able insight to the tradeoffs these design choices effect,and with this knowledge the team aimed to take theexisting design and bend it towards an updated set ofgoals. These are the mistakes that were made, and thisis what was learned:

– The robot was too buoyant, requiring in return toomuch weight to keep it underwater

– The robot uses much less power than expected, ren-dering a double set of batteries unnecessary

– The plan to minimize main capsule openings byhaving separate battery capsules was not realizedbecause the main capsule usually had to be openendbefore each test for troubleshooting anyways

– The minimally-structured main capsule interior,while easy to initially wire, proved challenging to

2

troubleshoot and a major reliability concern– Thermal design must be considered at a module-by-

module level, rather than total capsule heatEach of these insights was leveraged to improve this

year’s design.

B. Vehicle Design

1) Hull

Fig. 1: Simulation of the Capsule

One of the mechanical subteam’s top priorities wasdesigning a capsule system that can be opened quickly,requires little maintenance, and never fails. The vehiclehull system consists of a single main capsule and twocamera capsules.

Last year’s competition demonstrated that the maincapsule was even more reliable than we had originallyprojected. The reliability of the main capsule, combinedwith weight and buoyancy considerations, led to theremoval of the two separate battery capsules from thedesign.

As part of optimizing for weight, the weight of eachmechanical subassembly was found in SolidWorks. Whilethe team intuitively thought that the best way to cut backon weight would be to reduce the aluminum frame size,it was found that there were only a few pounds of excessaluminum on bot (which to even save, would require acomplete re-machining), compared to almost 10 poundsof weight in battery capsules. The team also consideredshaving down the sealing flange and plug on the maincapsule. This was also ruled out because while the largealuminum flange looks quite heavy, only a pound wouldhave been saved by lathing it down, which did not justifythe risk of damage to the main capsule or intoducingstrain not seen in the simulations which could impact thewatertightness of the design.

The sealing flange bore-seal design combines the ro-bustness and simplicity of bore seals with features that

make removing the end cap much easier. The acrylic-mating face of the sealing flange is machined to matchthe exact piece of acrylic tubing with which it seals.Mating the removable endcap directly with the acrylicwas intentionally avoided; the tolerances of acrylic tubeare imprecise enough that even one of the correct nominalsize can be outside the recommended parameters of thechosen o-ring. This metal flange creates a surface thatcan be used with a jack screw to remove the endcap withno risk of cracking. Although the metal flange adds size,weight, and construction complexity, it provides a durableinterface to the endcap and ensures the o-rings have aperfect sealing surface.

Fig. 2:Capsuleexploded

view

The removable endcap was originallydesigned with two o-ring glands so thateither a single o-ring could be used forremovability, or an additional one couldbe added for higher reliability. After test,there was no noticeable difference in dif-ficulty of removing the endcap, so botho-rings were ultimately used. The remov-able endcap also serves as the interfacefor the vehicle’s SubConn and SEACONwaterproof connectors. On fixed side of thecapsules, valves ensure that the removableendcaps are immobilized by vacuum dur-ing removal.

Last year’s permanently sealed cameracapsules were replaced with resealablecapsules because of upgrades to the cam-eras. This year’s cameras were consider-ably more expensive, and the risk of dam-aging them from trying to open a permanently sealedcapsule outweighs the risk of leaks.

2) FrameThe frame consists of two aluminum “cross sections”

that hold the main and battery capsules in place withpolypropylene bushings to prevent the acrylic tubes fromscratching. These cross sections attach to an aluminumbox frame designed with extra mounting area for com-ponents to be added or moved during integration andtesting. The frame was designed so that the center ofmass is directly beneath the center of buoyancy, makingLeviathan self-righting. In this way, good mechanicaldesign simplified the work of the computer science andelectronics subteams, an overall design success.

3) Battery PodsC. Bridge

The bridge is the structure on which all main capsuleelectronics are mounted. The bridge is designed hold allof the electronics and wires neatly, while also meeting thethermal requirements of individual modules. Between the

3

two rails of the bridge, cards are mounted, each holding asubsystem, and each customized for that subsystem. Forexample, the motor driver cards have integrated fans, andsupports to allow airflow between the motor drivers.

Fig. 3: The Bridge

Mounted on the bridge is an Acromag 6400 singleboard mil-spec computer, a ConnecTech carrier board, 3Atmega microcontrollers, four dual-motor brushed motordrivers (not pictured), two IMUs, an acoustics filteringboard (not pictured), a USB hub, a switchable thermalbreaker, adjustable DC-DC power converters, and a fusebox. The fuse box and thermal breaker provide adequateovercurrent protection in the event of an electrical fail-ure. The digital components interact over the USB hubnetwork, and all external connections are made throughdetachable plastic connectors.

D. Actuators

In line with the goal of focusing on navigation basedtasks, only thrusters for vehicle motion and marker drop-pers were implemented. SeaBotix BTD150 thrusters werechosen because of their easily sealed electrical inter-face, their simple mechanical mounts, and their discount

through Seabotix’s generous sponsorship. Four verticalthrusters are mounted on each of the four corners, givingthe vehicle freedom to move up and down the Z axis(heave) and around the pitch and roll axes. Four horizontalthrusters attached on the bow and stern at 30 degreesallow the craft to sway, surge, and yaw. Testing showedthat this angled configuration offered greater sway controlat the cost of less efficient surge, a reasonable tradeoffwhen considering the relatively short length and durationof the competition course. Two magnetic marker droppershave been implemented as well. Drivers inside the maincapsule, when signaled, drive a solenoid, retracting amagnet. When the magnet retracts, the force applied tothe steel marker decreases, and the marker falls.

E. Sensors

Leviathan uses a combination of motion, vision, andacoustic sensors to understand its own state and the worldaround it. Localization and mapping of the AUV’s envi-ronment is one of the hardest challenges of underwaterrobotics and was the driving factor behind many of ourdesign decisions. The sub uses a single [TODO: insertcamera name here], a Teledyne Doppler Velocity Logger,an Omega PX309 pressure transducer, an array of threeAquarian Audio Products H1c hydrophones, a VectorNavVN-100 IMU, and a thermocouple to monitor the internalcapsule temperature of the robot. This raw sensor data isprocessed and sent to the computer where it is combinedand used to determine the output of the sub’s actuators.

F. Model Dynamics

The robot is modeled as a rigid Newtonian body subjectto gravity, a buoyant force, non-linear drag forces, andits own thruster forces acting on the robot’s mass andown inertial tensor matrix. Attitude is represented as aunit quaternion, and the entire state is represented inthe local North-East-Down (NED) frame. This model ofthe robot is continously linearlized around the currentstate and fed into both the Kalman Filter and the LinearQuadratic Estimator controller. Quaternions were chosenin this context for their lack of singularities and for theircomputational speed, an important factor when simulat-ing at high frequencies. The condensed state vector isshown below.

q4 :=

qwqxqyqz

=

cos(β2 )

ex sin(β2 )

ey sin(β2 )

ez sin(β2 )

4

xk :=

r3q̂4

v3

ω3

k

uk =

u1u2...u8

k

Perhaps unsurprisingly, the most difficult part of us-ing such a model is the number of physical constantsinvolved, many of which are difficult to find experimen-tally. To this end, the computer science team devised anexperiment to estimate the most difficult constants: theinertial tensor matrix values and twelve independent dragconstants. The robot was driven around underwater forminutes at a time, logging sensor data. Assuming thesensor data is zero-mean and only corrupted by gaussianwhite noise, the data was naively fused together withoutfiltering into a sequence of thousands of state vectors.After defining an error function, an off-the-shelf mini-mization technique can then be run massively in parallelin the cloud to find the optimal set of hard-to-find physicalconstants that lets our model most closely match therecorded data.

err(c) :=∑k

|f(xk,uk, c, dt)− xk+1|2

The results are noisy but show a strong tendency to-wards what in all cases are physically reasonable resultswhich could then be qualitatively tested in the simulator.Most importantly, the values found through this novelapproach led to great performance by the robot in bothsensor fusing and controls.

Fig. 4: Stochastic gradient descent results for x-axis drag

G. Controls

This year, controls were rewritten to use a LinearQuadratic Regulator built from a linearized version ofthe robot model. Because of the complexity of the modeland the fragility in manually coding in the large gradientfunctions, it was decided to as much as possible representthe math symbolically. However, wanting to keep the code

Fig. 5: Simulated annealing with the same data

base purely Pythonic, the team created a flexible mathand physics library that can operate on both floating pointnumbers (NumPy) and symbolic expressions (SymPy)agnostically. All of the robot’s controls are then repre-sented symbolically, allowing for higher-order operationslike derivatives to allow linearization. At run-time, theselarge functions are then compiled by Theano into tensorgraphs to run in C, boosting execution time by an orderof magnitude and enabling previously impossible uses ofthe model, such as the gradient descent described above.

Fig. 6: Simulated annealing with the same data

H. Software Infrastructure

Both to avoid the steep learning curve for new membersand to not be restricted to a certain platform, the softwareteam decided to again forgo ROS in favor of a homemadesolution. Leviathan uses a completely Pythonic infras-tructure of microservices which pass messages to eachother through the Redis Publish/Subscribe paradigm. APython hypervisor then starts and monitors the services,and a websocket-enabled Django server offers live GUIfeedback and control of all data streams including video.A series of scripts and microservices then provide theability to simulate controls, sensor fusion, and even com-puter vision in real time, streaming the output to the webGUI where Leviathan and its environment are rendered in3D using Three.JS.

1) AcousticsA passive hydrophone array is used to triangulate

the location of the Benthos ALP-365 acoustic pinger.

5

Fig. 7: Live streaming the robot state to the web interface

The task’s foremost obstacle is reaching a minimumanalog-to-digital sampling rate on a microcontroller. Inorder to sample the 40 kHz signal, an open sourcehandwritten assembly routine for the Arduino Due wasused. The signals from the three Aquarian H1C hy-drophones individually pass through pre-amplifiers, a8th order butterworth low pass filter board, and then tothe microcontroller where they are band-pass filtered toisolate the pinger’s signal. From the cross-correlation-peaking/Time-of-Arrival/difference-of-phase of the threesignals, the location of the pinger can be calculated. Cur-rently, the array fails to pick up every ping– preliminaryinvestigations point to the microcontrollers poor samplingrate so an exploration of other microcontrollers with fasterADCs is necessary. An ultimate design would requirean array that accurately triangulates the pinger within areasonable passive listening time, aiding the guidance-decisions made by the main computer.

2) Computer VisionThe computer vision module is designed to provide

estimates of objective positions relative to the robot. Twocomplementary methods are used in tandem. The first, astraditional computer vision, cleans all images using con-trast stretching and then thresholds in the RGB and HSVcolor planes to identify objectives. The Hough Transformthen detects lines and circles via a voting algorithm, andseparately contour analysis finds all contours in the imageand evaluates them as possible matches with the objective.Once the objectives are marked on the image, determin-ing position reduces to a geometry problem with a fewunknown constants that are solved for with calibrationimages.

The second is through a convolutional neural network(CNN). After hand-segmenting a dataset of thousands ofimages taken last year at the competition, a 25-layer CNNdesigned by Google for mobile device object classifica-tion (SSD MobileNet) was reconfigured for RoboSub.Pre-configured weights trained by Google on the COCOimage database were used as a starting point, with onlythe last few layers needing retraining for obstacle detec-tion. The network is able to classify and give a bounding

box to all obstacles in a video stream at 60 FPS while stillmaintaining 90% accuracy.

Ultimately, a combination of both approaches is usedby Leviathan. In most cases, the machine learning isused to find a bounding box, and then the traditionalcomputer vision techniques are used within. However,with different obstacles only one or the other is used.

Fig. 8: Obstacle detection with SSD MobileNet

Fig. 9: Cleaning and rectangle extraction using traditionalCV methods

III. TESTING PROCESS

Vigorous testing of the mechanical systems has beenconsidered core to the entry’s success and was utilizedthroughout the construction process. The initial designswere guided by bounded Solidworks simulations, placing

6

theoretical bounds on the hull thicknesses needed to main-tain integrity. Mechanical components were then stresstested early and often, with both the hulls and batterypods having completed multiple ten-hour trials at over 15feet in depth. The electrical components were also testedoften, but full-system tests were intentionally kept to aminimum because of the disastrous damage a single leakcould cause the electronics.

The testing subteam developed specific tests for eachsubsystem that could be run in-lab. The team also rec-ognized the rarity of full-system tests; together with thesoftware team a program to record and play back allsystem parameters and values was created so that eachtest could be re-simulated and each run scrutinized. Datafrom these runs could be viewed in real-time or could bedownloaded to a computer for later analysis.

IV. EXPERIMENTAL RESULTS

At the time of this writing, Leviathan is a bare-bonesvehicle capable of full freedom of motion at low speeds(roughly 2 knots translational speed). The vehicle hastwo functional cameras for identifying obstacles belowand in front of it, three positioning sensors includinga DVL for navigation, and a single pressure hull. Therobot is capable of sophisticated motion planning andobstacle interpretation through vision, but currently hasno external actuators for non-navigational tasks. It hasenough battery capacity to run for around 20 minutes withmedium duty-cycle thruster usage (30-50%). Lastly, bythe time of the competition, it is hoped that the vehiclewill have also gained acoustic localization functionalityfor the final task.

ACKNOWLEDGMENT

Duke Robotics is a club within the Pratt School of En-gineering. We are supported by the faculty here at Duke,and gratefully acknowledge the faculty and administrativestaff here who have helped and continue to help makeour club a success. Special thanks to Professors MichaelM. Zavlanos, Kris Hauser, and George Konidaris, and ourUndergraduate Program Coordinator, Lauren Stulgis.

APPENDIX

A. Outreach

Duke Robotics Club recognizes the importance ofworking with their local community and inspiring futuregenerations of STEM students. They have worked withboth local middle schoolers and high schoolers, helpingDurham Academy Middle School coach a pilot FLL teamand robotics afterschool program and mentoring Team900 Zebracorns navigate the FIRST competition. Theyhave also advised countless teachers’ curriculums through

a partnership with Project Lead the Way. Even thougheach member’s time could have been spent betteringLeviathan the team still acknowledges how much morescience and robotics can advance with each class of stu-dents. Duke Robotics Club wants to encourage as muchinnovation as possible, and they are proud to be able tospark ideas in generations of students to come.

B. Team Photos

REFERENCES

[1] J. Huang, V. Rathod, C. Sun, M. Zhu, A. Korattikara, A. Fathi, I. Fischer,Z. Wojna, Y. Song, S. Guadarrama, and K. Murhpy, Speed/accuracy trade-offs for modern convolutional object detectors, CVPR 2017.

[2] R. Tedrake, Underactuated Robotics: Algorithms for Walking, Running,Swimming, Flying, and Manipulation, MIT 2016.