We got to the pool about 20 minutes late due to the acrylic separating from the capsule we had been using. We instead used a non-ideal capsule.
We tested the sonar. The new sonar algorithm using scikit-learn worked well, returning accurate distances to the buoy. If sonar can’t find the buoy, CV would think that sonar was still processing a request, so it wouldn’t send more requests to sonar. We created a temporary fix for this issue, but we weren’t able to test it since for no apparent reason the robot could no longer connect to the sonar for the rest of the pool test.
We recorded footage of the path markers using the bottom camera. We found that the path markers were very positively buoyant, and couldn’t be weighed down with the weights that we had at the pool. So, the swimmer held the path marker down with her foot while we recorded footage. Our first attempt at recording was unsuccessful, due to the bag file not saving the data, so we had to do it a second time for it to work. While doing this, we discovered that our custom camera autodiscovery only works for the front camera and not for the bottom camera (despite changing the MAC address). However, DepthAI autodiscovery works for the bottom camera.
We tested the recent changes to task planning, due to the migration to tf2. We found two bugs in the code, one in converting from Euler angles to quaternions and one in performing the tf2 conversion. Both have been addressed, and the robot now moves like normal.
We also set the controls settings to behave as it had before last week’s pool test. This allowed the robot to behave normally, without experiencing the issues we faced last Sunday. It was able to submerge and hold depth while remaining very stable.
We also tested if the yaw angle reported by state and the IMU changed as the robot was slowly rotated. This was found not to be the case; the yaw angle from state and IMU did change as expected as the robot was rotated. When the robot was commanded to submerge and hold position, it did not yaw (apart from PID oscillations). This is a positive sign that the recent updates to the IMU’s settings are helping, but further testing is needed before the issue can be considered to be solved.
When we started testing task planning, we ran the code without enabling controls. However, we did not realize that task planning itself enables controls. This fact, combined with the bug in converting from Euler angles to quaternions, caused the robot to roll 180 degrees; the robot became upside down. As soon as we saw this, we disabled controls and we pulled the robot out. We observed water inside the capsule, so we took it off and dried the capsule and electrical stack. Fortunately, no electrical components were damaged, and the robot still functioned like normal. We put the capsule back on and carried on with the rest of the pool test.
We removed the code in task planning that enabled controls automatically, and we will keep it that way. This means that the initial submerge function that we had written won’t be effective, so we will have to find a different way to do that.
There were several times during the pool test that the thruster Arduino disconnected. It would be helpful to switch it to serial, without using ROS, to prevent these issues.
After we finished the pool test, we observed condensation inside the capsule. When we came back to the Foundry, we took the capsule off and discovered a large amount of water on the plate at the bottom. There seems to be a leak in either the capsule or one of the ports. It also suggested that the issue we had earlier with water inside the capsule was not entirely due to the robot flipping over; it was also partially due to some other issue with the capsule or ports.
All throughout, we were using the SONR underwater radio communication system, which made communication with the swimmer much easier. We found that if the receiver is turned on but audio is not transmitted for an extended period of time, the receiver turns off automatically, so it needs to be turned back on.
Positives
- With scikit-learn’s clustering algorithm, sonar reports accurate distances to the buoy.
- Path marker footage has been collected, albeit with Lilly’s leg.
- All bugs related to task planning’s tf2 migration have been fixed, and it is functioning normally.
- Controls settings have been reverted to what they were 2 weeks ago, and is functioning normally.
- The IMU is reporting the correct yaw angle, although more testing is needed.
- We did not have issues with the pressure sensor.
- Underwater communication system works well.
Issues
- CV needs to be able to send requests to sonar even when sonar can’t find the object.
- Sonar needs to handle incoming requests, even while a request is being processed.
- Sonar disconnects without any apparent reason.
- Path markers need to be made negatively buoyant so they stay at the bottom of the pool.
- A reliable method of connecting to both DepthAI cameras simultaneously is needed; we may need to refactor the DepthAI camera connect script.
- Water seeps into the capsule due to a faulty capsule, port, or both.
- A new initial submerge function is needed in task planning, one that does not require that controls be enabled automatically.
- Thruster Arduino still disconnects from time to time; we should switch it to serial, without ROS.
- One of the bottom thruster guards is partially broken (from before the pool test).
- A humidity sensor in the capsule would be very useful to catch issues with water seepage early.