Last weekend marks a major milestone for the team. Crush, our mini-robot, officially entered the water with all its electrical systems and software fully mounted! This achievement reflects a year’s worth of collaboration, persistence, and innovation across all subteams. With Crush finally in the water, we can now begin testing its full capabilities, including performing competition tasks and establishing inter-vehicle communication with Oogway for IVC points.
Crush
We began by testing Crush’s movement using the joystick. We verified its five degrees of freedom (all except pitch) by setting desired power levels through the joystick and confirmed that everything operated as expected. After joystick testing, we moved on to controls and task planning. Crush was able to maintain depth; however, we observed significant roll and yaw oscillations (around 30 degrees), indicating that the PID controllers require tuning.
During the pool test, we also experienced connection issues between the fiber tether and the new network switch. Although we were unable to identify the root cause, the issue resolved itself after about 15 minutes. Future pool tests should prioritize tuning Crush’s PID constants to address the observed oscillations.
Oogway
During our Saturday pool test, we began by verifying the DVL, and we verified that the previous issue with the DVL’s coordinate frame has been fixed.
After that, we continued looking into the state issues with Oogway that we’ve encountered over the past two weeks. Right after starting the tasks, we saw the same roll and pitch drift we’ve been struggling with. To help debug, we manually rolled and pitched Oogway a full 360° in both directions (clockwise and counter-clockwise in both axes). We confirmed that both the IMU’s angular position and velocity values had the correct signs and values. State data also looked reasonable, and the control outputs matched what we expected. Occasionally, the roll or pitch would blow up after a full rotation, but that’s consistent with what we’ve seen before when we did a full barrel roll at competition.
To try and dampen the drift, we temporarily doubled the Kp and Kd gains for roll and pitch. This seemed to help, as Oogway was able to hold depth with better orientation and stability, settling around +10° roll and pitch. However, after running for a long period of time (about 10 minutes), Oogway experienced the same drift issues again, so the fix clearly wasn’t enough.
We also tested our new CV models for the torpedo task. The newly trained YOLO model reliably picked up accurate detections for the banner, sawfish, and reef shark objects, even when the banner was tilted at a 45° angle normal to the camera. However, the model wasn’t as robust when we rotated the banner upside-down, and we also noticed there were lots of false detections throughout. The HSV model performed worse, as it couldn’t detect the torpedo targets at all. We think this is because the red outline around the target is too small and difficult to distinguish from the background.
We resumed our pool testing on Sunday. To further investigate the drift issue, we had Oogway move back and forth in 1-meter steps using move_to_pose_local. It seemed to be stable for the first two legs, as Oogway managed to keep the same level orientation as it performed the lateral movements. However, after that, it started to roll and pitch heavily again, sometimes even moving forward at a 45–60° pitch. This made it clear that PID wasn’t the issue, nor was it the correct solution.
At the end of the test, we reverted our code back to the “Pool Test March 1st” commit, which we know is fully functional as that was the code we completed the prequalification task with. Doing this would help us narrow down whether it’s a software or hardware issue with Oogway. With that code, Oogway returned to normal behavior – holding depth and staying level during movement over multiple legs, just like before. That confirmed the problem is likely software-related, specifically amongst the changes we have made in the last month.
Since the IMU, DVL, and control outputs have been verified, we think the issue might be with the updated wrench matrix in controls. That matrix was recently changed but hasn’t been tested in the pool yet. Verifying it will be a key task for the next test.
Action Items
- Oogway:
- Validate and test new wrench matrix values in controls
- Fix the battery capsule latch
- Crush:
- Tune PID constants
- Balance center of mass to reduce oscillations
- Computer Vision:
- Adjust confidence thresholds to reduce false positives
- Retune HSV masks and evaluate performance
- Explore alternative detection methods if HSV remains unreliable