RoboSub 2021

Our 2021 RoboSub submission, Cthulhu v2, iterates on our past designs by extending the principles of modularity and simplicity.


Flexibility starts with the mechanical design. We overhauled the mechanical stack, designing a brand-new frame. Ultimately we chose a flat, rectangular design with multiple capsules to keep the electronics neat and the robot well balanced, as well as to allow for easier access to the batteries (placed in an individual capsule) which needed to be swapped often. The multi-capsule design allows for improved organization, ease of access, and improved balance. We added legs to allow Cthulhu v2 to either stand right-side-up or upside-down, allowing us easy access to adjust components when pool testing or at competition. Other key strategic outcomes include ease of manufacturing and adjustable mounting.

We found that the previous cylindrical design of Cthulhu was neither space efficient nor flexible, hindering our ability to quickly access and debug components as well as incorporate new hardware. Our new rectangular design remedies these limitations. One of our key strategies for earning points was to ensure that Cthulhu v2 had six degrees of freedom. We achieved this by designing our frame to be wide and flat, such that the thrusters could be spaced far apart and generate more torque.

Cthulhu v2 features a brand-new suite of pneumatic-based actuators, which offer faster response and cycle times than previous servo solutions. They also reduce the complexity of our actuators, increase reliability and safety during competition. Furthermore, Pneumatics don’t short or react dangerously with water, so these systems are much safer than comparable motor-based systems.


The software team continued the approaches of modularity and lean design that were established in prior years. The switch to ROS added much needed flexibility to our software stack, allowing all teams to work on packages simultaneously without fear of breaking a system.

Rather than take a top-down approach to writing code for competition tasks, the software team chose to utilize a bottom-up programming methodology. In our system, all tasks inherit from an abstract Task class, which gives us a standard interface program, execute, and coordinate individual tasks. Our primary software strategy was to develop basicfundamental tasks”, which can then be combined to form complex high-level tasks. The fundamental tasks can be considered basic building blocks which can be executed/combined in any order. This allows us to mix and match fundamental tasks to accomplish a variety of competition tasks without having to overengineer for any specific task.

The controls system was modified to use nested PID loops to allow for more precise movement. The “outer” loop controls on position for each degree of freedom, and the “inner” loop controls on velocity. The position loop can be bypassed for direct velocity control which is useful for style tasks. The system is designed to be robot agnostic; the only thing that changes between robots is a configuration file containing information about thruster position and orientation.

The simulation was a crucial alternative to in-person pool testing during remote learning. The simulation was designed to be as similar to pool testing as possible. As such, the workflow of running the simulation is the same as running the robot itself. It is, in a sense, an integration test and sanity check for changes that will be deployed on the robot.

The past two years have been a breakthrough period for the computer vision team; we developed version 1 of Detecto, an accessible, performant object-detection deep-learning framework. We actively maintain Detecto as an open-source library, and it has since received more than 30,000 downloads on Github. Continuing this momentum, the team’s primary focus this year was stereo vision, which would allow us to identify the 3D locations of target objects. Detecto generates bounding box predictions for target objects, and with stereo vision, we now can estimate their depths as well. This information is crucial for the task planning team, which depends on not only position but also depth data to ascertain whether Cthulhu v2 is within an acceptable range of an target object (e.g. a pipe that needs to be gripped by a claw).

For a more comprehensive overview of the entire software stack, visit our GitHub repo.


A major focus of the electrical team this year was Acoustics. Cthulhu v2 uses two separate arrays of four omnidirectional hydrophones to locate acoustic pingers. The hydrophone data starts out as analog data and is fed through a Saleae logic analyzer to get digital data for our algorithm. The location algorithm involves two major steps.

First, we use one array obtain an initial guess for the octant in which the pinger is located relative to the robot. The four hydrophones are generously spaced 0.3 meters apart in a right triangular pyramid configuration. We obtain the time differences between the pings in the x, y, and z axes as they reach each hydrophone by using a Butterworth bandpass filter for the desired frequency followed by a cross-correlation. From the time differences, we can derive the octant, which is our guess.

Second, we use our guess and the other hydrophones to precisely locate the pinger. The other array consists of four miniature hydrophones spaced just millimeters apart in a square. Taking synchronized readings from the hydrophones, Short Time Fourier Transform is used to obtain a magnitude and phase list for each. After several window selections, a final small window is determined based on the stability of phase difference between each hydrophone pair, and from there an average phase difference. Those phase differences and the guess from the first step are input into our Time Difference of Arrival algorithm to find exact horizontal and vertical bearings for the pinger.

We were able to test our algorithm virtually with a data generation program. We also developed a wrapper class for our acoustics algorithm. This integrates acoustics nicely into the rest of the robot system, and it abstracts away many of the complexities of the acoustics interface. Task planning merely must specify a few things, like the target frequency, and the acoustics algorithm will run automatically to find the correct pinger location.


Systems play an important role in making development and testing as painless as possible. Docker containers ensure that the development environment is unified across all systems; if code runs properly on a dev laptop then it will run properly on the robot computer. CI/CD pipelines automate the processes of unit/integration testing and deployment, allowing our developers to focus on writing robot code instead of worrying about infrastructure.

Development and Testing in Simulation: Photos

Simulation Testing of Tasks with Mock CV (Computer Vision)
Basic Simulation Model with the Gate

Development and Testing in the Pool

Robot Doing a Depth Hold
Robot Completing a Square