Goals: 1. Get Crush into the water and tune static power and begin PID tuning. 2. Get Oogway driving and collect Acoustics data
06/13/2026
This day was dedicated to getting Crush into the pool and driving. Back at the Foundry, we made sure that our previous SSH issues were resolved and that we could connect to Crush and start the thrusters. Luckily, all of the thrusters worked, so no issues on that front.
Crush Buoyancy Block
Having tuned Crush in the past, Jared had some experience with the location of the buoyancy block and the importance of placing the buoyancy along the periphery rather than the center. He found that when tuning PID values last summer, the old buoyancy block placed on the bottom of Crush made it impossible for Crush to change direction without drifting and messing up the motors. The way to think about this: the further apart the buoyancy is from the center, the larger the cross-sectional area for lift –> increased stability.
After removing the old buoyancy block, the PID values were instantly tuned, which Jared feared would happen again with this new buoyancy block with 100% certainty. Thus, before placing Crush in the pool, he talked with Niko and made sure that this new buoyancy block would be removed, as PID would simply not be able to be tuned with this buoyancy block like last year. Unfortunately, this will go against a good portion of the Mechanical subteam’s Technical Design, but the Mechanical leads are currently at work on how to appropriately address the situation.
Crush’s Leaks
Once Crush was placed in the water, we tested the buoyancy and added some buoyancy along the periphery to account for the reduced buoyancy from the removed top buoyancy block. A few minutes in, Niko notices a leak in the battery capsule and, upon inspection, finds that the intercapsule ports leaked. The leak was not major, as tape was able to provide a temporary fix. Unfortunately, the issues didn’t stop…
SSH Issues
We’re back at it with SSH issues. Despite working at the Foundry, the light on the switch would not activate when tethered into Crush, suggesting a wiring issue. When directly wiring into the inner modem, the switch was connecting, suggesting an issue with the recently replaced fiber-optic cable. However, when wiring the two switches together using the fiber cable on Crush, they did recognize each other.
When initially installing it, we found that when the cable bent, which happened when closing the capsule, the switch was quite finicky in connecting to Crush. Likely, the same issue occurred here, with the fiber optic cable bending inside Crush. Unfortunately, this brought a close to the pool test, as we did not bring Oogway with us to Brodie.
06/14/2026
This day was dedicated to getting Oogway into the water so that we could just test that it drove and that we could collect acoustics data for Saagar and me to continue building out our model.
Driving Oogway
Due to an IVC dependency issue in the task_runner, the main branch would not work, and the robot would not be able to move. Luckily, there was a state-testing branch in which we could test Oogway’s movement, with all of the IVC code commented out. So, in the future, unless fixing IVC, the state-testing branch should be used for Oogway.
Upon launching the robot and actually running task_runner this time, Oogway executed the initial submerge perfectly and drove 10m forward while dead reckoning incredibly smoothly, with Jared stating that it was the “smoothest [he’d] ever seen Oogway drive.”
Acoustics
Unfortunately, we again could not obtain any acoustics data, but were able to get Logic2 working and begin sampling after resolving some issues. First, the filepath for the AppImage was nonexistent, as it was referring to a file in the robosub-ros2/ folder instead of the acoustics-v3/ folder, where the recorder.py script was actually running. There was a Logic_Software folder in Oogway, but that only contained the AppImage for Logic-1.2.4, so we had to scp Logic2’s AppImage onto Oogway and then run chmod +x /path/to/file before running it through MobaXTerm. However, we had to be careful to run it in headless mode by adding --no-sandbox to the terminal command to open Logic2. Once that worked, though, we simply ran recorder.py, and the samples worked, but by the time the time ran out, we unfortunately could not get any acoustics data.
Reflections and Next Week Goals
Honestly, Crush is in a rough situation with the electrical issues we’ve been having. At a minimum, the Fiber cable needs to be shorter because SSH issues derail entire pool testing sessions, and then after that, we need to tune its motors, test sonar, and test CV, which is unlikely to be completed this summer. I would be happy if the PID tuning is completed, but our goals for this summer with Crush should honestly just be that we can consistently connect to it and avoid leaks.
As for Oogway, it was really unfortunate that no substantial progress was made outside of now getting Logic2 working, which could have been done in the Foundry. A couple of things to note from this: 1. My fault for not getting this resolved and talking with Patrick, Saagar, and Sid before the pool test to confirm everything was working; 2. We need to document the process, as well as the issues, in running different scripts (not just acoustics). I noted down in the summer pool testing doc the steps for running Logic and collecting acoustics data so that it’s a bit easier for someone to pick this up.
On the way back to the Foundry, Jared said that if this summer is anything like last summer, things will magically work on the last two days. With Crush, I’m hoping that is the case, but I’m honestly not too sure. However, for Oogway, I am definitely hopeful that we can get what we need done (including Move-to-CV object and acoustics). It’s unfortunate that Crush (our main goal for the summer) is unable to even run most of the time.