Advice on automatic control strategy?

Hello folks, I have been working with my graduation project. The task is to make the robot tour around a vertical column in a clear swimming pool, but no wire is allowed. That is, we would have to make the AUV navigate around the column. It can either head towards the column, or heads forward, with the tube on its side.

I have written a demo. With OpenCV I created trackbars to continously tune the pwm input of the channels.Pymavlink · GitBook
It turned out that the robot itself is rather “clumsy”, and it was hard to guide it towards the desired path.

Eventually, the task should be done without remote control. The image of the column might be helpful, with it we may extract distance information. Also, IMU can probably contribute to a reference trajectory.Gait tracking with x-IMU – x-io Technologies The hard part is how to control these thrusters? Now that three channels(yaw, lateral, forward) are coupled and not that precise.

Thanks for your time a lot! I am really out of thoughts.

Hi @Lili_Marleen,

If the vertical column is reasonably easy to detect you may be able to make your controller focus on yaw and in/out motion, with a reasonably constant sideways motion propelling the vehicle around the column.

For a cylindrical column, if you keep the edges at the same places in the camera frame then the vehicle will be maintaining a constant distance from the column. You can even split that up, so the centre position of the column gets corrected for with yaw rotation, and the spacing/width between the edges can be corrected for with in/out motion.

I’m unsure if there are other obstacles or things on the pool walls, but if the scene is reasonably clear then you could likely downsample the video quite a lot before doing the edge detection, which could help with robustness (at the cost of a bit of fidelity/precision), and would speed up the processing.

The IMU is quite noisy/error-prone, so you could use it to determine general directionality, and count rotations around the column by when the vehicle ends up facing the same direction again (if that’s relevant to keep track of), but beyond that it probably won’t have a huge impact on the control side of things.

Thanks for your timely reply. I have been thinking about the method of keeping lateral speed constant and alter yaw angle as well. But the set_rc_channel_pwm function seemed to be not sufficient. With our 6 thrusters machine, the lateral control ends up pushing it in the direction of both forward and sideway. I also tried mixing lateral channel and forward channel, but this failed in keeping it move sideway too.

Also, I have been trying using manual_control_send function to simulate joystick input. Pymavlink · GitBook example code in this gitbook does not work steadily. Sometimes nothing happens after running. I try placing it in a while 1 loop, and arm the machine previously, but the outcome varied.
In a few trail with significant movement, it dashed downwards quickly even with very small y-axis input. I wonder if our depth sensor didn`t work.

# Send a positive x value, negative y, negative z,
# positive rotation and no button.
# https://mavlink.io/en/messages/common.html#MANUAL_CONTROL
# Warning: Because of some legacy workaround, z will work between [0-1000]
# where 0 is full reverse, 500 is no output and 1000 is full throttle.
# x,y and r will be between [-1000 and 1000].
master.mav.manual_control_send(
    master.target_system,
    500,
    -500,
    250,
    500,
    0)

I would like to make sure that this function`s input parameters are in x,y,z,r-axis order right?

Not really sure what you mean by this. rc_channels_override sets thrust levels - does this example work for you?

If you want speed control you can try to use the IMU values for that, but without an actual velocity sensor it might not be very effective. I was mostly thinking you could command a constant thrust and it would be “good enough” to keep things moving.

If your vehicle can’t move directly sideways in manual mode when controlled with a joystick then either you’ve got one or more thrusters configured/connected incorrectly (check here), or your frame configuration may be poorly suited to your thruster directions and weight and volume distribution.

If it works well with a joystick but not via code then your code is doing something incorrectly :slight_smile:

Yes, the first four arguments to the MANUAL_CONTROL message are x,y,z,r, which should be as described here.