Before the test:
Last night, Philip finished wiring the Ping1D.
Today morning, we discovered that the epoxy applied to the battery connector had gotten into the connection, causing the connector to be very tightly connected with the wall power connector. We couldn’t separate them with brute force, so Philip cut off part of the insulation. For the rest of the test, we exercised caution when interacting with the battery connector.
Philip put the capsule on this morning, and the o-ring was thoroughly greased. There was a gap between the capsule and plate, about as thick as a credit card, despite us tightening the screws as much as we could.
Instead of going to the pool the usual way – going out the main Foundry doors – we have found an alternative path in which all doors are wide enough to let the robot through without tilting it. Go up the elevator at the back of the Foundry to floor 1, go straight towards the main entrance, make a right turn, go out through a set of double doors (one of the doors can open automatically by pressing the handicap button), follow the perimeter of the building, go down a ramp, and link up with the sidewalk to the Towerview-Science Dr intersection. I strongly recommend everyone use this route in the future to minimize damage to the robot.
Session 1:
We got to the pool at 9 AM. We started with 67% humidity. For the first hour of testing, the humidity stayed in the high 60s.
We started by testing the Ping1D. We found that its reported distance varied widely and continuously, with the robot held steady. We held the robot in the part of the pool about 7 feet deep, and the Ping1D’s distance varied from approximately 1.8m to 3.8m. It was never stable or consistent. We recorded a bag file of this.
We tested the marker dropper. We put brass balls in both sides of the dropper. We tested the code to move the servo by calling a ROS service, which worked. When we rotated the servo, both balls came out – we expect this to be fixed once our embelem is added to the balls and the servo horn is redesigned. The balls dropped straight down. Due to the varied depth of the lane, the balls would quickly roll to the deepest point of the lane, making them difficult to retrieve. For future tests, we recommend either catching the balls or placing a bin underneath the robot to prevent them from rolling.
We tuned buoyancy. We took off one buoyancy block on the marker dropper side.
We tuned static power global. It was last tuned to -0.5, which we quickly found to be too much. We tuned it to -0.285; the robot was very stable with this static power when 1m submerged.
After we finished tuning static power global, we noticed humidity had jumped to 81%. This increase happened in the last 30 minutes of testing. We took the robot out of the water and observed some condensation on the acrylic. We took the capsule off and observed small drops of water inside the capsule in various places.
Session 2:
We dried inside of the capsule and put the robot in the water at 11:55. I called Hung to setup the livestream for the Blue Devil Day, but by then BDD had already ended. We started with a humidity of 72%.
We tuned PID. We removed Kd from roll and pitch and lowered Kp. Although Z pid was pretty good to start with, we added a little Kd to make it stabilize faster. During one of the depth holds, over several minutes, the robot slowly yawed 90 degrees. We observed state and IMU orientation during this time. We found that while the state’s yaw stayed the same throughout the slow rotation, the IMU’s orientation yaw did change about 40 degrees, suggesting that the IMU’s orientation yaw was more accurate than state yaw.
At 12:17 we noticed the humidity had gone up to 81%, so we took the robot out again. Inexplicably, the robot couldn’t connect to the internet, even though `nmtui` indicated it was connected to Wi-Fi. We restarted the robot, which fixed this issue.
We video called Vincent to show him the capsule’s seam before we took it off. Although the gaps were a little more than he preferred, there wasn’t anything we could do about it since the screws were already as tight as possible. When we took the capsule off and observed small pools of water near the old DVL and DepthAI camera ports. Some water had also gotten onto the second level. We dried everything off and put the capsule back on.
We resumed the test at 12:47 with a humidity of 67%.
We tested moving the robot long distances in +X direction. We found the existing task planning tolerances to work well – we didn’t need to change them; the robot would complete submerging and start moving forward without delay.
We found that once the robot submerged and then moved forward, the robot would eventually surface. We found this to be the result of three issues:
- Task planning’s Z setpoint is higher than expected. For the initial submerge, the Z setpoint is -0.5. However, when moving forward, the Z setpoint changes to -0.3, even though it should have stayed at -0.5.
- State accumulates error in Z position.
- We would like the state’s Z pose to be almost the same as the depth from the pressure sensor. However, the two diverge significantly.
- In one of our tests, after the robot moved forward, the state’s Z pose was -1.5 while the depth was -0.11 and the robot had surfaced.
- In another test, after the robot had moved forward, state’s Z pose was -0.27 while depth was -0.15 and the robot had surfaced.
- As the robot moves forward, this error increases significantly, to the point that the robot believes that it has reached its Z setpoint whilst actually being at the surface.
- When the robot begins moving forward, the robot experiences significant jerk and a change in its water dynamics. This causes the Z error calculated by PID to wildly go up and down. The Z error stabilizes after the robot has moved forward a few meters.
While moving forward, the robot’s Y oscillations took up the entire width of the lane.
Putting all of this together, consider the following sequence of events:
- The first `move_to_pos_local` task starts, intending to submerge the robot to Z -0.5 whilst holding all other axes constant.
- The robot submerges very well, being very stable with little movement in all axes other than Z.
- The robot reaches all setpoints, within the task planning tolerances. State’s Z position is about -0.48.
- The first `move_to_pos_local` task ends and the second `move_to_pos_local` starts, intending to move the robot 10 meters forward (+X) whilst holding all other axes the same as they are this very moment.
- Controls receives the new X setpoint commanding the robot to move 10 meters forward. It also receives a new Z setpoint, commanding the robot to change depth to -0.3.
- X control effort instantaneously shoots up to +1. The robot jerks itself forward. Water rushes to the underside of the robot, pitching the robot up a little.
- The robot is moving forward and no longer stable in the Y or Z directions. Z error graph has seemingly random ups and downs, with Z control effort closely following error.
- State’s Z pose is quickly diverging from the actual depth. The robot comes closer and closer to the surface.
- The robot is moving left and right, going back and forth between almost touching the wall and going into the other lane.
- Robot moves forward 5 meters. It breaches the surface. State’s Z pose is now close to -0.3. Z error has now stabilized.
- Controls believes it has reached its Z setpoint, so it keeps the robot surfaced for the remainder of its movement.
- Robot finishes moving 10 meters forward. It has surfaced and is stable in all axes.
- Task planning believes robot has reached all setpoints within tolerances, so the second `move_to_pos_local` completes and task planning exits.
We took the robot out at 1:20 with a humidity of 74%.
Positives:
- Charted a new path out of Gross Hall.
- Marker dropper ROS code works.
- Markers drop straight down.
- Static power global tuned well.
- PID tuned so the robot is stable when holding depth.
- Task planning tolerances ok.
Issues:
- Battery connector needs to be replaced. In the future, please avoid epoxying the inside of the connector.
- Front mono camera and sonar mounts need to be nail polished.
- Ping1D is very inaccurate.
- Robot still leaks. All ports need to be double-checked. Our prime suspects are the old DVL and DepthAI camera ports.
- Robot still yaws.
- Robot surfaces when moving forward.