Sometimes (or quite often), plans quickly fall through, requiring a quick pivot to best make use of time. This weekend served as a prime example of this concept, leading to some frustrating but interesting situations.
06/28/2025
We started by working to re-tune our static power as detailed in the previous pool test update, but quickly ran into some problems where our code to automate the process caused the robot to sink well below the desired 1m of depth, eventually leading to the robot moving in the x and y direction while near the pool floor. While debugging this issue, we also worked on training members on swimming and robot operation/setup during pool tests.
After using the joystick controls to test various static power values manually, we unfortunately had to end the test early due to lightning in the area. As the rain outside was too heavy to transport the robot back to the lab, we pivoted to tasks that could be done on land. We took some pictures for our competition report (see below), and continued training new members on pool test procedures and PID tuning. During this time, we also tested the drift on the IMU for Crush.
06/29/2025
At the previous set of pool tests, we had removed 4 external buoyancy blocks and replaced them with a smaller number on the bottom of the robot. However, as the robot was barely buoyant, we thought this might contribute to the natural drift of the robot when the motors were not running. Thus, at the lab, we added one additional buoyancy block to the bottom of the robot.
Now, back at the pool, we began working on tuning static power once more. We noticed that previously, we had not zeroed out our previously tuned PID values, which were impacting our ability to tune static power. By zeroing our stale PID values, and through our previously mentioned automated task and some joystick experimentation, we were able to get our static power value to stabilize the robot underwater.
Following this, we began tuning PID once again with a simple depth hold. We added some baseline values; however, as these values were not tuned, the robot oscillated quickly left to right while descending to try to correct positional error, and we noticed that we lost connection to the robot. After observing that the voltage indicator in the capsules was blank, we quickly pulled the robot from the pool.
We were able to confirm that no water had entered either capsule, so the next logical step was to check the fuses in the robot. We were able to confirm that a 30A fuse had blown, so we made the trip back to the lab to replace the fuse and ideally resume testing with the remaining time.
We were able to quickly replace the fuse and attempted to power the robot back on. This was unsuccessful, so we took a closer look at the fuse holder connection. We found that the wire from the fuse holder to the rest of the robot was disconnected and had burned, leaving a singed end and the exposed wire behind. We decided at that point to end the pool test and transport the robot and equipment back to the lab.
At the lab, we were able to remove the capsule covers to get a closer look. Below is the exposed wire that should be connected to the fuse, and then to the battery.
As a fix, we decided to replace the fuse holder, and soldered a connection from the now exposed wire to the fuse holder to the battery connection. With some solder and wire heat shrink, we were able to mend the connection and get the robot working once more.
Following a few additional tests, we were able to get Crush into operational state, ready for pool tests next weekend. Back in the lab, we also worked to collect IMU drift data from Oogway and ensured that Oogway was still operational after a dormant period. While not quite the pool test we had expected, this proved to be a valuable learning opportunity for everyone involved, and we are looking forward to next week!
Action Items
- Retune PID on Crush
- Test gyro accuracy on Crush
- Begin work on tasks