Tartan Autonomous Underwater Vehicle

Design and Implementation of TAUV-20: Kingfisher

Tom Scherlis, Joey Wood, Advaith Sethuraman, Joy Sodon, Maheer Sayeed, Rishabh Jainand Shubhankar Agarwal.

Carnegie Mellon University

Abstract - TartanAUV (TAUV) is a secondyear Robosub team driven by undergraduatestudents from diverse backgrounds and disci-plines. We set out to use the knowledge weacquired last year to design an enduring AUVplatform to use for the next several years.This meant a complete overhaul of our engi-neering processes, and the construction of oursecond vehicle TAUV-20: Kingfisher. King-fisher is extendable, easy to maintain and re-pair, and larger than its predecessor Albatross.To support the addition of a Doppler Veloc-ity Logger, rotating sonar, and stereo vision,we rewrote our software stack with 3D per-ception and navigation in mind. We replacedour off-the-shelf external controller with an in-tegrated model predictive controller, allowingus to more accurately execute complex 6DOFmaneuvers.

1 Competition Strategy

As a second-year team, TartanAUV’s driving goal wasto design an AUV that is sustainable for the future.The first year was a great learning experience for usand had a great impact on our strategy this year. Oneof the biggest learnings was to focus on excelling in afew tasks, rather than faintly trying all tasks. There-fore, we set out to build a solid base for our AUV ac-companied by rigorous testing on all fronts: mechan-ical, electrical, and software. The Mechanical andElectrical Team focused on designing a modular andversatile AUV, which can be improved and adjustedto run at the competition in future years. This deci-sion was made upon the discovery that competitiontasks only varied slightly from year to year. We con-cluded that creating a vehicle that could be slightlyadjusted to achieve the new tasks was the most pru-dent course of action. The Software Team focusedon developing a generalized autonomy stack to moveaway from a per-task hardcoded stack. We wanted to

Figure 1: Kingfisher

make it easy for new members to contribute and alsodevelop generalized autonomy algorithms that can beleveraged for multiple tasks (e.g. MPC controller ).Our software team firmly believes that investing in astate-of-the-art simulator is one of the most rewardinginvestments to succeed in Robosub. A software teamcan do testing with much faster iterations in a simu-lator. We devoted significant efforts into developing astable simulator, which later on helped us debug ourlocalization, mapping, vision, and trajectory planningalgorithms.

Keeping in mind how we nearly missed a perfectbuoy run due to hard-coded qual gate code in our firstyear, we chose to focus on completing the first sev-eral tasks with a high degree of precision, completingthe new vehicle, and securing a Top-10 rank. Thismeant accomplishing software and maneuverabilitybased tasks, with a hopeful ambition to add manip-ulators later on in the team’s schedule. We specifi-cally focused on the gate, buoys, and path-followingtasks. We designed and rigorously tested these scenar-ios in our simulator. Manipulator ideas and designswere at their infancy when COVID-19 shutdowns hit,completely stalling their development. We also triedexperimenting with our upgraded sensor suite whichincluded: 360 sonar, stereo cameras, and DVL.

Tartan AUV Page 2

2 Design Creativity

2.1 Mechanical Design Drivers

This year, we fully redesigned our mechanical sys-tem, looking to improve on the major limitations ofour first-year (2018-2019) vehicle. We identified ac-cessibility to internal electronics, modularity of vehi-cle internals, and thermal management of our inter-nal electronics as three major areas of improvement.Namely, the need to accommodate a larger main com-puter (from the NVIDIA Jetson Tx2 to the NVIDIAJetson Xavier), two sets of stereo cameras, a DVL(Doppler Velocity Log), Hydrophone acoustic system,and upgraded IMU (Internal Measurement Unit) ne-cessitated a larger enclosure. We also wanted theflexibility to improve and adapt our perception andcompute hardware as we advance as a team and em-ploy more advanced algorithms in future years, so weintentionally oversized the electronics enclosure.

2.2 Enclosure System

The core of our AUV is a pressure vessel, consistingof two transparent acrylic tubes joined by a centralaluminum ”midcap.” The tubes are joined to the mid-cap with temporary double o-ring seals, so they canbe easily removed in a field environment for on-the-flyelectronics servicing. The midcap is a large (7” diam-eter) 5-axis CNC machined part, which constituteda significant manufacturing challenge for our team.The midcap contains two o-ring tube seals on eachend, and four face seals around the circumference ofthe part, which seal four removable panels contain-ing cable pass-throughs. The enclosure is separatedinto two halves, one for battery and power electronicsand one for compute and perception electronics. Thisyear, we decided to move the battery from a sepa-rate sealed enclosure into the main enclosure for easeof wiring and to reduce possible points of failure insealing and electrical connections.

Figure 2: Kingfisher Enclosure System CAD Model

2.3 Structural System

The main driver for our redesigned structural systemwas the ability to easily service internal electronics,especially on-the-fly both at competition, and at ourtesting facilities in Pittsburgh. This drove us to afolding chassis design, where the superstructure ofthe AUV folds away, allowing access to electronics on

3 sides (left, right, and top). This design allows usto have a compact profile during operation and ship-ping, but also open access with minimal obstructionsduring electronics servicing. We hope this design al-lows us to quickly iterate and experiment with newcompute and perception hardware. The main acrylicelectronics enclosure is reinforced underneath with asteel weldment, termed the ”spine.” The spine is de-signed with maximum rigidity in mind, as it is the pri-mary bracket on which vibration-sensitive perceptionhardware (IMU, Stereo Cameras, DVL) are mounted.Even small deflections of these sensors relative to oneanother can throw off the localization algorithms, sothe spine weldment is as stiff as possible.

Figure 3: Kingfisher Structural System CAD Model

2.4 Electronics System

2.4.1 Compute

Kingfisher’s electronics package is designed to supportthe complex needs of our software team, by provid-ing the primary computer, communications systems,power and battery management, and sensing systemsfor the vehicle. The electrical design is optimizedaround simplicity, compute performance in definedareas like GPU and multithreading ability, I/O inter-

Tartan AUV Page 3

Figure 4: Kingfisher Electronics System Overview

face availability, and power/space requirements. Tosatisfy these goals, we settled on an NVIDIA JetsonAGX Xavier as our primary single-board-computer(SBC). This is an upgrade over the Tx2 unit we usedlast year, and the AUV had to be designed aroundfitting this larger computer. The upgrade was drivenby a desire for improved CPU performance and I/Oavailability, allowing us to upgrade our cameras froma single monocular camera in Albatross to a set of twostereo camera systems this year (4 cameras total).

2.4.2 Power

The vehicle’s power system is managed by our custompower distribution board (PDB), shown in Figure 4.The PDB supports up to 200A power draw, whilemeasuring current draw and battery state-of-chargeinformation. It also supports an external hardwarekill-switch that can immediately disable all power tothe thrusters based on either a TTL input from ourmagnetic kill switch, or a software pin controlled bythe Xavier in the case of a critical software fault.

2.4.3 Sensing

We removed the off-the-shelf Pixhawk unit that weused last year with an Xsens MTi-200-VRU Iner-tial Measurement Unit (IMU), which provides signif-icantly improved attitude and heading informationto our custom Guidance, Navigation, and Control(GNC) system. The Xsens was chosen because of itsproprietary software designed to improve resistance tounmodelled magnetic field distortion in the environ-ment, which is notoriously challenging to deal with.This was a significant problem for us last year, sowe spent extensive time testing and verifying XsensIMU in magnetically noisy environments. The only al-ternative is high performance MEMS or Fiber OpticGyroscopes (FOGs), although these are notoriouslyexpensive and hard to integrate into the sensing sys-tem. The Xsens is also capable of operating in a

large variety of time synchronization modes. Addi-tionally, we purchased and have begun integrating aBlue Robotics Ping360 sonar.

The most significant upgrade to our electronicsthis year was the addition of a Teledyne PathfinderDoppler Velocity Log (DVL). This sensor providesaccurate linear velocity data which can be fused withinertial and visual data to provide a high degree of po-sition sensing accuracy. To make this work, the DVLneeds to be precisely synchronized with the IMU. Weachieve this using the Xsens IMU’s sync port, whichallows us to output a regular sample signal to theDVL, and receive an accurate timestamp from theIMU indicating when the sample occurred with re-spect to the IMU’s clock. We have not yet attemptedsynchronization between the Xavier and the IMU, al-though we intend to use either a direct Pulse-Per-Second (PPS) clock sync between the devices, or usethe ETHZ clock bias estimator: Cuckoo Time Trans-lator [1].

2.4.4 Communications

A significant upgrade this year was the transition fromslimrun cat5 ethernet cable and Fischer connectors toBlue Robotics’ Fathom Tether and Subconn connec-tors. This cable is neutrally buoyant, leak resistant,and more mechanically durable than the slimrun eth-ernet. Likewise, the wetmate connector is far more re-liable in a marine environment. We also constructed atop-side box, with a router and connections for powerand the fathom tether spool to provide wireless accessto operator laptops. Internally, we use a combinationof RS-232 and USB to communicate with sensors andactuators.

2.5 Software Systems

The focus for this year’s software systems is creatingflexible code for autonomy. We draw inspiration forour system design from well established autonomoussystems such as self-driving cars and exploratory mo-bile robots. The software stack is split into State Esti-mation, Perception, and GNC (Guidance, Navigationand Control).

2.5.1 State Estimation

Underwater state estimation is known to be a chal-lenging problem due to being in a GPS denied, lowvisibility, and dynamic environment. We use an IMU,DVL, and Depth Sensor in conjunction with an Ex-tended Kalman Filter. However, in precision tasks,these sensors can still develop drift. We have con-ducted experiments in MATLAB involving the use ofPose Graph based SLAM methods [3], [4], [7] to pro-vide a framework for loop closure and landmark-basedlocalization.

Tartan AUV Page 4

Figure 5: Kingfisher Perception System Overview

The Pose Graph minimizes an error function involvingthe constraint between nodes:

eij(xi, xj) = zij − zij(xi, xj)

The objective function we must minimize over the setof constraints C becomes:

F (x) =∑

(i,j)∈C

eTijΩijeij

The system of equations is solved using a nonlin-ear Levenberg-Marquadt optimizer. A full pose graphimplementation will be integrated before the comingseason. Currently, we use a combination of robot poseand landmark Kalman Filters.

2.5.2 Perception

Regardless of what the specific challenge is, Kingfishermust be able to perceive the world and accuratelygather information. The perception system is man-aged by the Detector Bucket (Figure 5). A detectorwill report a detection to the Bucket, which will spawna Detector Daemon to filter, and track the data. Thisabstraction allows for asynchronous sensor informa-tion and minimizes the latency between detection andupdating the robot’s beliefs.

We use the Mahalanobis Distance and theKuhn–Munkres (Hungarian) algorithm [5] to effec-tively match and reject detections. This is usefulbecause the Mahalanobis Distance can incorporatea sensor’s reported error uncertainty. Any efficientinteger programming algorithm can be used, includ-ing graph-based methods such as Joint CompatibilityBranch and Bound.

Our vision detection system is composed of DeepNeural Networks and classical Computer Vision de-tectors. For simple detection tasks such as the gate,

we can use traditional line-fitting, which reduces over-head and complexity.

The default tracker for detectors is a constant po-sition Kalman Filter Tracker in 3D . In the event ofdynamic objects, the encapsulated tracker can be re-placed by a higher order filter. Using a configurableobject manifest, any prior information about objects(dimensions, location, quantity) are incorporated intothe robot’s beliefs. The end result is a 3D perceptionsystem that allows for accurate navigation (Figure 7).

2.5.3 Guidance, Navigation and Control

We use a hierarchical nonlinear model-based controlstrategy. At the low level, we use a differentiallyflat dynamics model with flat outputs correspondingto position and heading as well as their derivatives.A low-level PID attitude controller is used to sta-bilize the roll and pitch axes, while a custom linearModel Predictive Controller (MPC controller) with a2-second horizon based on the OSQP quadratic pro-gramming toolbox is used to provide position andheading tracking control. A second order linear modelbased on the flat outputs is used, so the output ofthe Model Predictive Controller includes accelerationin x, y, z as well as yaw velocity. These are com-bined with the roll/pitch velocity inputs from the at-titude controller and fed through our inverse dynam-ics model to determine a 6DOF force/torque wrench.Finally, the Thruster Allocation Matrix (TAM) is ap-plied to the wrench to determine 8 thruster force com-mands which are each fed through the inverse thrusterdynamics model.

High level guidance is provided using a MotionUtilies system, which provides easy-to-use trajectoryprimitives for mission applications. While a trajec-tory primitive is active, the Motion Utilities objectacts as a reference trajectory server providing a 2second horizon reference trajectory to the MPC con-troller. We have created a small toolbox of trajec-tory primitives, including S-Curve (finite jerk) lin-early interpolated trajectories, minimum snap trajec-tories computed by a custom 5th order polynomialspline optimizer based on OSQP, simple ray trajecto-ries for following a straight line indefinitely, and searcharea trajectories based on a polynomial bounding re-gion within which to perform a grid search.

Quadratic Programming allows extremely fast con-trol frequencies, easily satisfying our requirement of20 Hz with a 2 second horizon time on our embeddedcomputer. Details regarding our MPC and Trajec-tory optimization implementations can be found in itsown paper [2]. We are currently working on addingparameter adaptation using EKF to allow our inversedynamics controller to learn and update model pa-rameters online to reduce model innacuracies.

Tartan AUV Page 5

2.6 Simulator

We realized early-on that having an offline testingframework is very important for the software teamto iterate faster and develop a more robust softwarestack. Our software stack is explicitly designed suchthat the simulator is a drop-in replacement for ourlow level sensor drivers package, and all other soft-ware including controls, state estimation, and percep-tion are tested in the simulator. CFD analysis is usedas a starting point for model identification of the ve-hicle, allowing us to create an accurate digital twin ofour AUV for simulations (Figure 6). Our simulator isbased on the UUV Simulator [6] and with an addedsoftware layer to fine-tune for Robosub.

2.7 Frameworks

We have been working on a set of frameworks aimedto improve software reliability within our codebase.First, a fault tracking service was designed to allowROS nodes to set and unset fault statuses in orderto centralize information about system health. Somefaults can be defaulted to active, and only clearedafter an initialization and verification phase, for in-stance. This provides a quick way of verifying thatall systems are running nominally before switching toautonomous modes or even arming the vehicle.

Finally, we use continuous integration to run auto-mated build and test jobs to prevent regressions indevelopment. These automated checks have been im-mensely useful as we have approach 300 commits and30 finished pull requests on our codebase this year.

3 Experimental Results

We began testing new controls frameworks in the highbay of Carnegie Mellon’s Robotics Institute early inthe year. However, once the quarantine began, wetransitioned to simulation (Figure 6). We createdmock navigation and perception tasks in our simu-lator to test our software stack offline. Some of thesetasks include navigating to a point of interest, iden-tifying the gate and navigating through it safely, andtesting our perception pipeline on a variety of newobjects (Figure 7). We wanted to ensure that oursystem could handle higher level tasks that would al-ways show up in Robosub competitions, regardless ofthe specific challenge for that year. We rely heavilyon detailed visualizations and data analytics to gaugethe performance of our systems (Figure 8).

4 Acknowledgements

TartanAUV would like to thank our parent organiza-tion, RoboClub, as well as faculty members MichaelKaess and George Kantor for their incredible men-torship and support. We would like to thank Chuck

Figure 6: Kingfisher in a Simulator Environment

Figure 7: Kingfisher Internal Perception System

Figure 8: Kingfisher Control Input Visualization

Whittaker and the Field Robotics Center for train-ing and access to the Robotics Institute water testingfacilities. We would like to thank Jim Bain (CMUECE), Margaret Noel (CMU ECE), and CatherineCopetas (CMU SCS) for their crucial help in negoti-ating sponsorship deals. We would like to thank ourgold sponsors: Leidos, Carnegie Mellon Student Sen-ate, and Altium designer, our silver sponsors: BlueOrigin, Fischer connectors, Blue Trail Engineering,and the Robotics Institute, and our bronze sponsors:NVIDIA, Robot Perception Lab, Advanced Circuits,Connect Tech inc, Molex, and IMC. We would alsolike to thank Vortex NTNU for their initial simulatorsetup and Harvey Mudd Robosub Team (MuddSub)for a high degree of collaboration. We look forwardto everyone’s continued support in our effort to bringRobosub to the Carnegie Mellon community.

Tartan AUV Page 6

References

[1] Cuckoo Time Translator, ETH Zurich.https://github.com/ethz-asl/cuckoo_time_

translator.

[2] A.Shek and T. Scherlis. Highly Dynamic Quad-copter Control For Drone Racing. 2020. http://

tomscherlis.com/wp-content/uploads/2020/

05/drone_control_16899_final_report.pdf.

[3] F. Dellaert and M. Kaess. Square rootSAM: Simultaneous location and mappingvia square root information smoothing. 2006.https://www.cc.gatech.edu/~dellaert/pub/

Dellaert06ijrr.pdf.

[4] Giorgio Grisetti, Rainer Kummerle, CyrillStachniss, Wolfram Burgard. A Tu-torial on Graph-Based SLAM. 2018.http://www2.informatik.uni-freiburg.

de/~stachnis/pdf/grisetti10titsmag.pdf.

[5] H.W. Kuhn. The Hungarian method forthe assignment problem. 1955. https:

//web.eecs.umich.edu/~pettie/matching/

Kuhn-hungarian-assignment.pdf.

[6] Musa Morena Marcusso Manhaes, Sebastian A.Scherer, Martin Voss, Luiz Ricardo Douat, andThomas Rauschenbach. UUV simulator: Agazebo-based package for underwater interventionand multi-robot simulation. In OCEANS 2016MTS/IEEE Monterey. IEEE, Sep 2016. https:

//doi.org/10.1109%2Foceans.2016.7761080.

[7] S. Thrun and M. Montemerlo. The graph SLAMalgorithm with applications to large-scale map-ping of urban structures. 2006. http://robots.

stanford.edu/papers/thrun.graphslam.pdf.

Tartan AUV Page 7

A Components List

Components Vendor Model/Type Specs Cost (if new)Buoyancy ControlFrame Various Aluminum 150Waterproof Housing (Generic) 6in Acrylic Tube 150Waterproof Housing Custom Aluminum Midcap Sponsored

Waterproof ConnectorsBlue Trail

EngineeringCobalt Series Sponsored

Waterproof Connectors Subconn DBH8F/DOM8M 300 per pairThrusters Blue Robotics 8x T200Motor Controls Blue Robotics Generic ESCHigh Level Controls custom

ActuatorsBlue Trail

EngineeringWaterproof Servo Sponsored

PropellersBattery Various 4s LiPo 16Ah Already OwnedConverterRegulator Texas Instruments VariousCPU Nvidia Jetson Xavier SponsoredInternal Comm Network RS232/USBExternal Comm Network EthernetProgramming Language 1 PythonProgramming Language 2 C++Programming Language 3 MATLABCompass See IMUIMU Xsens MTi-200-VRU Sponsored

DVL Teledyne PathfinderSponsored(Leidos)

Camera(s) Stereo Labs 2x ZED miniHydrophones Aquarian AS-1Manipulators

Algorithms: visionYolov3

Template MatchingAlgorithms: acoustics FFT

Algorithms: localization/mappingEKF

Pose Graphs

Algorithms: AutonomyModel PredictiveControl (MPC)

Open source software

OSQPOpenCV

ROSGazebo

UUV-SimulatorTeam size (number of people) 7HW/SW expertise ratio 1:1Testing time: simulation > 100 hours

Testing time: in-water0 hours

(Pandemic)