Today, in our last pool test of the summer, we completed the gate and buoy tasks in one continuous run.
We started with the gate task: submerge, correct yaw for the coin flip, move through the gate, and finally barrel roll. We put the gate in the water in the opposite direction from our previous tests, so that red was on the left and blue was on the right. We tested the coin flip by rotating the robot at three different angles: 90° clockwise, 90° counterclockwise, and 180°.
While the robot was able to complete this sequence on its first attempt, we made some changes to make its behavior more robust.
- We made it go through the gate faster by taking larger steps towards it and removed a Y correction we had previously applied (this was to account for the front mono camera’s offset from the center of the robot).
- We increased the pitch tolerance to 0.2 radians, as the robot would sometimes be unable to proceed after correcting its yaw as it thought it was pitched too much, when in reality it was level.
- We made the robot move forward one meter further past from the gate, to ensure there was enough clearance between the robot and the gate before it started the barrel roll.
While testing these tasks, we observed a few persistent issues
- After the yaw correction, the robot sometimes ended about 10° off from facing the gate directly. While it still moved through the correct side of the gate, there was a higher chance of it bumping into one of the legs of the gate or losing CV detections too early. It may be a good idea to use the whole gate detection to dynamically correct yaw, instead of relying on the IMU to not have yaw drift.
- Even if the yaw correction is perfect, there is a very small margin of error for the robot to go through, since the robot itself is 3 feet wide and half of the gate is 5 feet wide, giving only a 1 foot margin on either side. To minimize the chances of the robot bumping into the legs of the gate, we can add a static Y offset towards the middle of the gate. Since today the red side was on the left, we added a Y correction of +0.2, which helped it avoid bumping into the gate. At competition, the red side could be on the left or the right, so we either need to manually change the sign on the correction before every run, or we use CV to automatically detect whether the red side is on the left or right. This could be done by using the detection for the entire gate – we can simply see if the red gate image detection is closer to the left side of the whole gate detection or the right side.
- After the barrel roll, we tried correcting the yaw of the robot again to be parallel to the gate. However, the robot would end up about 30° off from where we intended, likely because the IMU’s yaw angle drifted significantly during the barrel roll. Since the robot also drifts significantly in its X and Y positions, it would be difficult to find the path marker to navigate to the buoy task. A better approach might be to slowly yaw and search for the buoy itself – just like what we did at last year’s competition.
We then moved on to testing the buoy task. While it did work in the first try, there was scope for improving its reliability.
- CV would rarely detect the buoy when the robot got within 3 meters of it. This was because the contour match score would be too high (lower score indicates better match) and the score threshold was too low, causing the contour for the actual buoy to be filtered out. With a higher threshold, CV would detect the buoy even when the robot got up close to it.
- For the gate task, the robot submerged -0.7 meters. For the buoy task, however, we found that this was too low and the buoy would go out of frame too soon. So, we instead had the robot submerge to -0.5 meters to keep the buoy in frame. This value would need to be adjusted at competition. We could also have the robot simply compute and match the Z of the buoy, although this would be risky if the buoy is too close to the surface.
- Using the formula involving the focal length and sensor size of the camera, we compute the distance to the buoy and switched the task planning code to reference this distance instead of the pixel width of the buoy bounding box.
- We increased the rate at which the robot approached the buoy; the previous rate was overly cautious, which was unnecessary.
- We changed the direction of circumnavigation to be clockwise, in line with our chosen side of the gate (red, clockwise).
- We changed the size of the square the robot made when going around the buoy to be 3m x 3m, to leave enough margin on both sides to ensure the robot wouldn’t hit the buoy.
- We found that the robot slowly yawed as it went around the buoy, making its behavior unreliable. To avoid this, we recorded the IMU’s yaw angle just before the robot started circumnavigation, and then corrected yaw after every step while circumnavigating.
- After the robot completed one circumnavigation, we had the robot correct its X and Y positions using the buoy CV detections before beginning another half-circumnavigation.
With these changes, the robot was able to complete the buoy task much more reliably.
Finally, we combined the gate and buoy tasks into one run. We avoided doing the barrel roll as the battery voltage was low and we didn’t have a way to correct the robot’s yaw afterward to face the buoy. Here’s the video of this run:
This was the last pool test of summer 2024. This is the most prepared we’ve ever been heading into RoboSub, having pre-qualified and completed the gate and buoy tasks. At competition, we’ll refine the gate and buoy tasks, and work on the path markers and bins task.
Go Duke Robotics! See everyone soon in California!