Today, our primary focus was on completing the pre-qualification with Oogway. We also tested torpedoes and the minibot.
Battery Cable
Before the pool test, a few electrical and mechanical members removed excess epoxy off of the battery cable and clamped the copper part down with pliers, as it was loose. The cable worked for the entire duration of the test, save for one minor hiccup (listed at the end).
Torpedoes
Although the right torpedo cartridge is still broken from the last pool test, the left one is intact, so we used it to test the launcher. This is the first time we’ve launched torpedoes underwater on the robot.
We tested two torpedoes: one made with PLA and another made with ASA, which is closer to neutrally buoyant. The one made with ASA traveled about twice the distance as the one made from PLA.
In the video below, Oogway was located approximately 3 meters away from the gate. The ASA torpedo went approximately straight for the first 1.5 meters, before dipping down and touching the ground just below the gate.
Minibot
A few mechanical members brought the minibot to the pool today. The minibot’s capsules were loaded with Gatorade bottles to simulate the weight of the electrical stack. They intended to determine the number of buoyancy blocks required to make the minibot buoyant with its full weight.
After about 2 minutes in the water, however, the capsule with the thrusters going into it was leaking. The thruster wires weren’t properly tightened and the capsule o-ring wasn’t greased, hence the leak. The team brought the minibot back to the Foundry without a buoyancy block estimate.
Oogway Pre-Qualification
The bulk of our time today was spent on trying to complete the pre-qualification with Oogway. At the beginning of the pool test, we did a few tethered runs. Once we thought we were close to completing it, we switched to untethered runs and recorded video both underwater and above ground. After each run, we adjusted the task planning code to try to increase the chance of success in the next run.
In most runs, the robot was able to make it all the way to the buoy. When it went around the buoy, it would go into the adjacent lane and yaw by an unpredictable amount. Because of the yaw, when the robot would come back into our lane, it would either not move far enough into our lane or run into the wall, making it impossible for it to move back through the gate.
We believe that the task planning code has been adjusted to account for the average behavior of the robot. However, random fluctuations, as mentioned above, lead to significant changes in the behavior that the code cannot correct.
Overall, the robot is still very slow, as it only moves in increments of one meter and spends significant time stabilizing and correcting Y, Z, and yaw deviations. It still experiences significant yaw drift. It also consistently stays rolled 10º, which throws off the calculations made using CV (as they require zero roll). In short, not surprisingly, it’s experiencing all the issues it experienced at RoboSub 2024.
Other Issues
- CS
- The DVL disconnected during one run. It read 5 empty lines from serial, then reset the connection. While it reestablished the connection right afterwards, the few seconds of down time was enough for the robot’s movement to go haywire.
- After the robot was power cycled, we couldn’t connect to the thruster Arduino. We power cycled the robot again and established connection. We’ve been experiencing this issue occasionally since we migrated offboard comms to ROS2; power cycling the robot or pressing the reset button on the Arduino fix it, but we need to stop it from happening in the first place.
- Sensor fusion still prints an error when launched. This is a non-fatal error, as it still publishes state as usual. The error may be fixed by converting the
robot.xmllaunch file into Python and adding a few seconds of delay before launchingsensor_fusion, so that all sensors (IMU, DVL, pressure) have a few seconds to start publishing data. - When launched, the front mono camera publishes a feed for a few seconds, but then disconnects and is unable to recover.
- The pink bins detector still raises an error immediately after launching.
- Electrical
- Halfway through the test, we replaced the battery. Before putting the battery back in the capsule, we turned on the red and blue switches but the robot didn’t power on. After we put the battery back in and closed the capsule, the robot turned on and remained on for the rest of the pool test. This suggests that in spite of the fixes made to the battery cable, it still needs to be flexed a certain way in order to work.
- Mechanical
- The right torpedo cartridge (broken at the last pool test) needs to be replaced.
- The battery capsule mount (broken at the last pool test) also needs to be replaced (we zip-tied it today).
- After the pool test, seemingly out of nowhere, the bottom back right thruster fell off. One of the metal inserts in the thruster partially came out, breaking the plastic around it. See the picture below.
