Troubleshooting Depth and Movement Functions
Progress 07-05-2024 through 07-08-2024
We intend to use the set_depth() and movement() functions defined in robot_control.py in order to move our AUVs to their target.
However, there is/was much troubleshooting that we have/had to do.
First, when we tried to run pix_standalone.py when Graey was armed, the AUV flipped over. Everytime we run pix_standalone, when armed the depth_hold() in pix_standalone activates, which causes this to happen; this is because pix_standalone is constantly running, even when you kill the physical script. Only cutting power completely and restarting will stop this from happening. Video.
Even though depth_hold() is supposed to run automatically, the AUV is not supposed to flip. After troubleshooting with Eesh and Maxime, we found that the issue was with the thruster configuration; the thrust vectors were not properly configured. We originally thought that there might be a rotational issue with the Pixhawk; i.e. because the pixhawk is oriented sideways on the old BlueROV, that QGround may have configured the thrusters to roll 90 degrees in initialization. However, we found that the roll setting at initialization was none. Picture.
We used QGroundControl’s motor tab to fix the thruster configuration; green thrusters to move clockwise when fired, blue thrusters to move counterclockwise. The original configuration was set as thus, and we changed it so that it was then this. Video showing Graey moving properly in the vertical axis.
Unfortunately, when testing using control.py, a script that enables keyboard input to control the robot, we found that the configuration of the four holonomic thrusters (thrusters located at a 45 degree angle on the corners of the AUV) was off; when we attempted to move forward, we would execute a yaw, and when we attempted to execute a lateral motion we would move backwards. We switched to this configuration, which gave us the original configuration of the holonomic thrusters, while retaining the new revised vertical configuration.
This new configuration has not truly been tested; rudimentary testing showed that the set_depth() may not move properly. Additionally, when setting the depth, Graey only goes down, and never comes up – debugging showed that the PID controller is working properly, and even the PWM value sent seems reasonable. Additionally, the target depth does change when we call set_depth() with a different value – the only problem (which is not inconsiderable) seems to be that somehow the PWM value is not getting to the thrusters. However, further debugging by monitoring the ROS topic “/mavros/rc/out” showed that the Pixhawk is sending different PWM values to all eight thrusters, which seems to align with the physical appearance and movement of the thrusters.
Next steps:
Continue looking at the ROS topics “/mavros/rc/override” and “/mavros/rc/out”; these are most likely the keys to debugging the set_depth and movement() functions.
PWM logic, thruster commands sent to the pixhawk all look good, but there could be something wrong with either the PWM value sent or the bridge between PWM command and physical actuation (for example an override)
Reach out to Maxime and Eesh about the problem by the end of 07/09 if the problem does not resolve.
Once this problem is complete, we need to verify that we can use set_depth() and movement() simultaneously. Right now, it seems to be one or the other (and very inaccurate and unpredictable at that).
