Insane IMU "Drift"

[SarangaR]

Problem

The reported yaw angle of the robot changes drastically while stationary and during mission runs. This only occurs after any competition mission is run. The issue does not appear if the robot is power cycled prior to every run. The drift appears to be an (almost constant) angle change sustained over a large period of time. Some times the angle will decrease or increase by some amount until it reaches the visible yaw of the robot, and other times it will never fully settle.

This causes the straight movements of missions (forward or strafing) to skew a lot in the yaw direction, causing the movement of the robot to change entirely and detections to go out of frame.

Note: This issue was only encountered at RoboSub 2025. It did not occur prior to competition, and it has not yet been tested after competition to see if the issue still exists.

What we have tried

Attempts at diagnosing the issue consist of:

• Ran a square mission (moves robot in a square with sassist2 move and turn commands) multiple times in succession to try and reproduce the issue.
  • Square mission ran successfully every time, and the reported yaw angle did not drift.
• Removed the control board from the main hull and read the reported yaw value.
  • The reported yaw value of the IMU directly from the control board was accurate to 5 decimal places with near-zero drift.
• Compared gate run and slalom mission code with other missions like path align that have not encountered this issue.
  • The IMU initialization and periodic read are done the same way in all missions, and there is no noticeable difference that could be causing the issue.

Possible theories

• The problem is caused by violent movements (aka barrel roll mission)
  • This theory is based on the fact that this was not an issue for the first 2-3 days of competition, during which basics of gate run and vision were being tuned. The emergence of the issue coincides with Day 4 being the day that full mission runs were being tuned, which included barrel rolls. The issue was visible instantly on Day 4 and continued to the end of competition.
  • To test this, a crude test was run involving barrel rolls but further testing is required.
• The issue has to do with unbalanced battery draw (LBB) and battery fischer corrosion
  • Coinciding with mission runs at competition, the load on the batteries was heavily favored toward one battery. However, both batteries were being used as intended in high demand situations which prevented brownout during barrel rolls. It was also found that the battery fischers (and a lot of other fischers including cameras) were actually waterlogged and had some corrosion.
  • An observation with this is that during our second semi-final slot, the second set of barrel rolls did not run at all on some runs (despite it being one mission and the CB command being sent) which has never happened in all prior testing. During this slot, the robot was power cycled prior to every run to make sure the IMU drift was gone.

[SarangaR]

Follow up

This issue did not appear at the pool test on 9/27/2025.

Observations

The slalom, gate, and barrel roll missions were all tested with all traces of this issue not appearing in any test. The robot was also run using the ArPiDrivestation and a gamepad. This uses the global stability assist and global speed set methods, which both internally use the IMU and have shown this issue in the past.

The full mission sequence was also run including gate run -> barrel rolls -> slalom with no issues. There were no issues directly after these full mission sequences either. This could be an issue with how the IMU is being calibrated as well (perhaps it is not stable during calibration causing issues?)

The yaw readings seemed relatively stable (as stable as they have ever been through normal pool tests) throughout the pool test with no power cycles required between mission runs. Perhaps this is a wear thing coming from consecutive intense testing sessions??

Further Testing

We will attempt this once more when pool test time permits and see if the issue resurfaces.