04/12/2025
Oogway: After several weeks of frustrating issues with state, Denton finally fixed the issue by resetting the pose0_differential and odom0_differential fields in Oogway’s oogway.yaml config file in sensor_fusion to true, which reverts them to their original settings. Combined with the earlier fix to the DVL coordinate frame, these changes restored proper state behavior. To confirm that everything was working, we ran Oogway through a series of tasks: moving in both small and large squares, holding depth, and completing the buoyancy task, all of which went smoothly. In addition, we verified that the new Crush integration branch, crush_final, is compatible with Oogway. Furthermore, before the pool test, while launching robot.xml, we initially ran into unexpected [RTPS_TRANSPORT_SHM Error] Failed init_port fastrtps_port7000: open_and_lock_file failed -> Function open_port_internal errors coming from multiple nodes, something we hadn’t seen before. Fortunately, a full system update with sudo apt update && sudo apt dist-upgrade resolved the issue.
Crush: Today we primarily focused on getting initial information about our sensors and ensuring that the publish rate and outputs are reasonable. We confirmed that after the usual spin-up time, the Gyro publish indeed hits 1000Hz, and the DVL hit around 6.7 Hz, which Denton confirmed is what we’re looking for. We also did some basic movement testing and confirmed that the values form State are at least reasonable. We also hacked in reasonable values for PID so we could do basic maneuvering and static power tuning for next time (starting from Oogway’s values, we removed all kD, saw that at kP values of 1.x, there was a lot of oscillation, so we set all kP values to 0.1, and this appeared to be stable).
04/13/2025
Oogway: We started the pool test by updating the settings of our Pathfinder DVL to have a correct coordinate frame. With this change, we no longer need to intercept and modify the DVL values in the dvl_to_odom.py file. We verified that the sensors/dvl/odom topic is publishing the correct values. We then started testing the torpedo task. We extended the cv.py task planning interface to include “shark_front”, “swordfish_front”, and “torpedo_banner” and also fixed minor issues in the task planning package related to ROS 2 migration. We ran through the torpedo task several times; however, we were unable to make significant progress. There appears to be problems with the correct depth logic in the yaw_to_cv_object coroutine which resulted in Oogway misaligning its depth relative to the torpedo buoy. This issue can likely be resolved by refactoring and simplifying parts of the task planning code.
Crush: We first tune static power. While this historically has been a very tedious and estimate-heavy (and thus imprecise) task, we want to automate this to try to get more accurate results and make us have to spend less time to tune it. To do this, with a static power calibration depth of -1m, we repeat having Crush trying to sink to the depth level, with the stop condition being solely based off of velocity thrusters approaching zero (and thus the PID algorithm reaching a steady state), and not off of the depth — after all, our differential and a next run of approaching the desired depth level results in a closer value to the desired depth. Once we are within a tolerable error, based on the velocity outputs at the point that it reached the -1m depth, we extract the velocity and set our static power to that point. We ultimately came up with a stable value of 0.03 for static power, and this was confirmed by oscillations when trying to re-run our tuning algorithm. Now, to rid the oscillations, time to tune that PID! Tune in next time 🙂