“This was a forgettable pool test.” – Sid Kini
We started this pool test with high hopes, as the robot was working normally on land and we got to the pool test on time.
Our first goal was to tune the robot’s buoyancy. A few of the buoyancy shafts were filled to the top with several small buoyancy blocks; we replaced them with larger buoyancy blocks zip-tied underneath the shaft.
We then developed task planning code to make the robot perform a simple depth hold while repeatedly calling move_to_pose_local with a zero pose. If the robot had imbalanced buoyancy, it would tilt according to the imbalance, indicating how to adjust the buoyancy to make it level.
When we ran this code, for the first few seconds, the robot submerged as expected, but it then started moving in the X and Y directions uncommanded. We tried this a few times, but observed the same results; the direction of the uncommanded lateral movement was random.
We spent the rest of the pool test trying to debug this issue. We progressively reverted recent code changes, going back to the Pool Test March 1 commit on main, which was the code Oogway successfully prequalified with. However, this didn’t solve the issue.
We noticed that the position error computed by controls (which is the primary input to the PID controllers) had the opposite sign for the X and Y components. For example, if the position setpoint lay in front of the robot, controls would think it’s behind the robot and so would move the robot backwards, away from the actual setpoint. Thus, when we commanded the robot to do a depth hold, it would submerge initially, but as its X and Y error increased, controls would move the robot away from the setpoint, increasing the X/Y error even more, which increased the speed of the movement away from the setpoint; this cycle continued indefinitely.
Twice during the test, the state went haywire. The X position estimate and covariances increased rapidly even though the robot was barely moving.
Next Steps
While we weren’t able to solve the issue at the pool test, we did narrow down the potential causes of the issue. We know that the code isn’t the problem, as even the pre-qualification code, which worked on March 1, didn’t solve this. Furthermore, we successfully performed several depth holds at last weekend’s pool tests. Additionally, this was the first pool test this academic year where state went haywire unexpectedly. So, the issue must be something other than the code, it must stem from a change made this past week, and it likely has to do with state.
There haven’t been any significant electrical or mechanical modifications to Oogway this past week. However, earlier this week, Denton had connected to Oogway’s DVL using Teledyne’s software to see how it was configured. When I tested the robot on Friday night, I found that the DVL wasn’t publishing data. I called Denton, and he told me to run two commands on the DVL, updating its settings to ensure it publishes data without needing a prompt and the data is in the format our code expects.
It’s likely that other settings on the DVL were changed as well, such as the DVL’s coordinate frame. The DVL’s X and Y axes may be swapped, which could explain the issues with state and movement.
For today’s pool test, I’d suggest closely examining the DVL’s output and changing its settings if necessary to ensure it aligns with the robot’s coordinate frame.
