Of Many
Goals:
The main focus of our first few pool tests is to test our Comp 2026 code and make sure that it is in an acceptable state to be merged into the main branch. This meant testing a few things:
- Move to CV Object and the New HSV Filtering for the torpedo banner)
- Anthony’s Sonar Algorithm (on the wall and for objects like the torpedo banner)
- State + Localization
- Static Power + Gyro Zero Bias Offset
- Thruster Allocations in Offboard Comms
- Arduino Status on the Foxglove Panel
We were able to test all of these changes except for the Arduino Status on the Foxglove, which can be tested on land anyway. However, we were only able to test Oogway this weekend due to any major surgery on Crush. Furthermore, we aim to test some of our sensing tasks more rigorously to ensure that they truly work.
Saturday 10/03/2026
If anyone is familiar with the pool tests over the summer, this was more of the same. We reach the pool with…another tether issue, as one of the ends was snapped off the end going into Oogway. Luckily, we were still able to attach the tether and had no further tether issues.
Unfortunately, dependency challenges as a result of switching to main caused problems that allowed us to only test WASD controls (which suffered yawing since we forgot to re set the zero gyro bias when moving from CA to NC. Static power was mostly good, so we determined that it wasn’t worth messing around with it.
The dependency issue occurred when we tried to upload the Arduino Code from main due to (what I suspect to be) driver issues in the updates made in the competition branch. Unfortunately, likely one of us accidentally rebuilt the Dev Container from main, which did not pin any of the dependencies we used and thus resulted in the numpy issue that was a result of updates over the summer. Unfortunately, switching back to comp-2026 branch and rebuilding also did not fix this issue since despite pinning the dependencies, they were not declared as constraints, resulting future dependencies overriding the intended version of numpy. This resulted in a new issue being created to switch to UV instead of pip, which is a faster and more reliable package manager, which happens to be by the same group that created our linter, both created in Rust, which led Srinath to become the idea’s biggest supporter once hearing that #rustglaze.
The day wasn’t completely wasted however. Our swimmers today enjoyed the refreshing feeling of the brand-new Wilson pool water.
Sunday 10/04/2026
What a 180! Sunday went wonderfully, with everything just working due to Srinath and I spending our Saturday night in the Foundry to debug these issues. No dependency issues, no major tether issues (outside of the previous tether from Saturday being completely cooked).
This pool test was a bit tricky since only Anthony and I were there to test since Sid was a little under the weather, but we made it work. We started off with tuning the gyro for the zero bias. Once we made that change, the WASD worked without issue, which enabled us to move onto the next step: testing state. Somehow, our state is good? Despite Patrick insisting that our state was good, I was adamant that our state was broken and required significant reworking, and I couldn’t be more wrong. Anthony and I tested forward movement for 3 Oogway meters, and the robot went there without timing out.
However, the issues of 1 Oogway meter not equaling 1 meter still remain. Additionally, discussion with Patrick during the meeting later that day is leading us to more rigorously test our state next pool test. He suggested running the forward task for a larger distance (ideally 6-8m) and testing it multiple times to check for drift. Furthermore, our DVL suffers from man issue of bottom lock, which means that when the pool floor has some object there the DVL’s readings are unreliable, in which the correlation flags that the DVL outputs are used to determine if this is the case. Currently, the DVL is the only thing being used to determine linear x and y movement. Integrating our VectorNav IMU might help solve this issue during these moments despite being overall noisier.
After this, we tested Move to CV object and it ran successfully at a reasonable distance away (around 4m) despite Anthony and I somehow hanging the torpedo banner is a really janky way. Impressive! We then proceeded to test Sonar, and it also worked. It gave distance data, and even identified the torpedo banner when 1m away.
Conclusion and Future Plans
Overall, a successful weekend despite Saturday’s rough patches. However, the lack of a Temp-Humidity Sensor in Oogway resulted in us realizing that there was a worrisome amount of water in the capsule. Everything is fine, but we NEED it back in there before getting Oogway in the water. Additionally, the movement tasks need to be sped up. They currently move to some angle and pause. Our goal is to smoothen these movements by making it continuously moving. Furthermore, shifting the yaw to cv object task to open-loop control allows the cv to determine when to stop, not requiring the weird 90 degree jolts in movement.
This emphasizes the need for testing the night before the pool test so that we do not arrive at the pool without basic things working on our robot to avoid Saturday again.
Next pool test we plan on testing:
- Crush (all of it to merge Comp 2026 code)
- The Intel Realsense for Depth
- Test a Sonar movement task and test at further distances
- Test State more rigorously (define rigorous to be objects on pool floor and repetition)
- Smoothened movement algorithms
- Updated Dockerfile with uv instead of pip (does not require pool time)
All of these changes will come alongside the refactoring to CV and Task Planning, as well as the big three projects: acoustics, CV, sim development. So yeah, there is no shortage of things to do for the team.