Meet Our 2021 RoboSubs
Our goal this year was to prepare as much as possible for the 2022 RoboSub competition. We wanted to create a virtual simulation to enable development without the assembled sub. We want to make this simulator open source and available as a resource for teams to use.
Sim to Real
In 2020 we used Gazebo along with ROS and SITL to simulate the basic movement of our AUV and use of the PixHawk. After an increase of products in the field of Sim2Real this year, we aimed to create a far more realistic and open tool for the community. We moved to Unity which allowed us to easily model custom assets and create a photorealistic environment. Unity also allows us more control over the objects in the simulation at a low level, helping to serve as an intermediary towards our goal of creating a custom flight controller.
This simulation, named the RoboSub-Sim, includes a full model of TRANSDEC, the game missions, functional models of sensors commonly used in the competition, and serves as an efficient and practical way to test for RoboSub teams. Currently, we have basic autonomous and user-directed control for anyone to try out our view here. We are continuing to expand this functionality and develop more advanced sensors including hydrophones and underwater intersub communication modems. With the help of interested members of the RoboSub community, we hope to improve the RoboSub-Sim to become a platform similar to VRX (used in the RobotX competition) and build upon the ideas of the data sharing effort.
System Overview
This year we mainly focused on creating a full simulation or digital twin of our robots and the competition pool. We also focused on improving our AUV’s navigation and expanding our mission capability. We designed Onyx to be our primary AUV which we created with all of our lessons learned from the past 2 years. We updated Græy so it could work in tandem with Onyx through intersub communication and the mission planner. In making Græy, we learned how to use industry standard practices for design, data analysis, and design of printed circuit boards (PCBs). We continued using the systems engineering process and parallel prototyping as they both served us well in the previous years. Continuing to work through the COVID-19 pandemic, our team followed stay-at-home orders and communicated through bi-weekly team video conferences and multiple inter-subteam calls.
Since our AUVs must run autonomously, they have multiple sensors and programs to navigate and control their movement. This year we used sonars, hydrophones, cameras, modems, Doppler Velocity Log (DVL), Micro Electro-Mechanical Systems Altitude and Heading Reference System (MEMS AHRS) sensor and a 3D imaging sonar (loaned to us by our sponsors). This way we can detect missions or obstacles around the robot, locate the missions, communicate between the subs, and know our exact location in the pool so we can navigate accurately.
Onyx
Onyx is equipped with a DVL, modem, sonar, 2 cameras, 3 hydrophones, and a mems sensor
Græy
Græy is equipped with a DVL, modem, sonar, 2 cameras, and a mems sensor
Last year, we aimed to perform in the top third and exceeded our expectations by ranking 1st overall. The systems engineering process, doctrine of K.I.S.S. (keep it simple, silly), and the Agile/sprint process were integral in our success last year, so we continued using these processes to drive our team. To expand our knowledge and optimize our AUV, we designed custom hardware, software, and electrical components while buying commercial off the shelf parts to supplement as needed. Besides updating and building our physical AUVs, we heavily focused on simulation; we worked to recreate the Transducer Evaluation Center (TRANSDEC) competition environment in Unity to be able to integrate and test our systems in an environment similar to the competition. Furthermore, we wanted to create a collaborative environment that RoboSub teams from around the world could utilize and build upon.
Competition Strategy
Both AUVs will pass through the gate and spin to earn the style points. Additionally, both AUVs will be equipped with downward-facing cameras used to follow the orange path. Græy will hit the buoys and drop the team markers. Meanwhile, Onyx will launch torpedoes and surface in the octagon, utilizing the hydrophones to locate the random pinger that marks the missions. Through inter-sub communication, both AUVs will approach missions looking for the same image set (G-men or Bootleggers). To accomplish the missions, the AUVs rely heavily on our program’s ability to identify and classify objects, as well as navigating to the missions. Therefore, we focused on improving the AUV’s software system to fulfill these goals. The programs on the AUV’s main computer serve a variety of purposes, including localization, perception, mission planning and execution, and sensor data fusion. Computer Vision (CV) is used to identify the missions and differentiate whether the tasks correspond to the G-man or Bootlegger. We enhanced our vision capabilities by focusing on integration and increased volume of testing through simulation to refine the accuracy, creating a realistic testing tool for the RoboSub community. To enhance navigational accuracy, we added a Micro Electro-Mechanical Systems Altitude and Heading Reference System (MEMS AHRS) sensor and 3D imaging sonar (loaned to us by our sponsors). During mission execution, sensors are compared against each other to filter out inconsistent data. Additionally, to gain a deeper understanding of our robot’s navigational system, we have opted to design our own flight controller; the development process is aided by a simulator we have developed. We use Robot Operating System (ROS) to enable interprocess communication between the programs for a modular software system.
Mechanical
We updated Onyx and Græy’s electronics and enclosure holders, staying true to our simple and modular design. The design allows for alterations by increasing the cylinder diameter and length to accommodate for the increased amount of electrical components and ports for added equipment.
Enclosure Clamps
We understood the team limitations and requirements. We utilized a cheap and accessible manufacturing method that we could continuously and rapidly iterate designs - 3D printing. The team utilized PLA plastic for easy printing. This year we pursued an 8 in diameter acrylic tube for the enclosure. Instead of 3D printing two pieces for the clamps, we needed to print our clamp in 4 pieces to allow all components to fit on the print bed. With the larger distance between mounting bars, we needed to design our battery enclosure clamps in 3 pieces to fit within the 3D print bed. The team utilized strain simulation to determine potential failure points in the design.
Hull
The team established the requirements that the sub needed to be modular, maintainable, and simple. The simplicity of the frame is highlighted when the team needed to add extra buoyancy to the sub. We just added in extra hardware and secured the buoyancy foam onto the needed location on the frame. A second story was when the team flipped the configuration of the propellers. Instead of needing to re-manufacture the frame, the team flipped the direction of the enclosure and adjusted the configuration of enclosure holders to enable the sub to swim the correct direction.
Electrical
Previous years the team utilized a magnetic switch that would interrupt the software with a background script. The switch faced latency when pulled. This new switch would mechanically interrupt the electronics cutting battery power to the main power terminals. The team pivoted from securing the battery latch with magnets which were not strong enough to a pivot point.
Kill Switch Design
Previous years the team utilized Fusion 360 to model the electronics harness. This meant that there were multiple files that needed to be edited when the dimensions of the electronics plates needed to be updated. With Onshape utilizing global variables all dimensions of the electronics plates are centralized in one file. With the editing of variables, this updates multiple sketches within the code to reflect the correct dimensions. The team pivoted to a server rack like an electronics board. This enables easier maintenance as each board can be slid out individually. This technology is enabled by a PCB back plane.
Electronics Harness
Electronics Harness
Previous years the team utilized Fusion 360 to model the electronics harness. This meant that there were multiple files that needed to be edited when the dimensions of the electronics plates needed to be updated. With Onshape utilizing global variables all dimensions of the electronics plates are centralized in one file. With the editing of variables, this updates multiple sketches within the code to reflect the correct dimensions. The team pivoted to a server rack like an electronics board. This enables easier maintenance as each board can be slid out individually. This technology is enabled by a PCB back plane.
Software
Software Overview (Architecture)
There are four parts of the software subsystem. The first is a group of programs that process sensor data to reveal more about the robot’s state and environment. These include the computer vision programs, the signal processing programs (to triangulate the location of the robot based on the hydrophones, the velocity integrator, and so forth.
Mission Planner
We realized that if we want to optimize our scoring capabilities, the AUVs need to be able to prioritize the missions and not get stuck in a mission loop if a portion fails. Therefore, we are developing a mission planner. Our mission planner was loosely inspired by the National University of Singapore's RoboSub team, team BumbleBee's mission planner, and chess computers. It has two key parts: the decision maker and the mission scheduler.
Our two AUVs communicate underwater using acoustic modems. These allow the AUVs to send data between each other, containing information about the status of tasks. The status of each mission is logged on the AUV throughout the entire competition run. The statuses are: not attempted, traveling to, in progress, unsuccessful (timed out), unsuccessful (missed the object), unsuccessful (dropped the object), and successful. Missing the object would be not touching the correct buoy while dropping an object would be like missing the torpedo shots or dropping the team markers in the wrong place. If the missions are completed successfully, the AUV continues to follow the ideal path we outlined in the mission scheduler. The AUVs will log when communication is established, sent, or received.
The decision maker works like a trade study. It plans the next steps the AUVs will take through weighing different variables: the current status of the missions, time it takes to complete each of the remaining missions, the point value of the remaining missions, the probability of successfully completing the remaining missions, and the time remaining in the run. The planner includes consideration of redoing a mission if the mission was unsuccessful via time out or not hitting the object. A mission attempt log runs in the background on the sub and tracks which missions have been attempted, how many times it was attempted, how much time it took for each attempt, and the success of each attempt. Missions where the AUVs drop or shoot objects are not reattemptable as the robot cannot pick up and reload those payloads. After making its decision and logging it, the AUV updates the mission scheduler.
The mission scheduler is the part of the mission planner that points to the mission blocks based on the decision maker's decisions and executes the program/runs the blocks. Once the mission scheduler is updated, the AUV will send a signal with the updated schedule to the other AUV. Each configuration of the mission scheduler is assigned to a different signal value/pattern which makes it easy to communicate the multiple missions in the path. This way, both AUVs are on the same planned schedule, and conflicts are avoided.
On the left is the decision maker and on the right is the mission planner.
