Home        Store        Learn        Blog

How to realize control allocation with BlueROV?

Hello everyone,
I have been trying to automatically control the vehicle, to make it track a certain trajectory. This needs to be done with modelling and controller design and so on. I have studied this thesis https://flex.flinders.edu.au/file/27aa0064-9de2-441c-8a17-655405d5fc2e/1/ThesisWu2018.pdf

The author had explained his way of control allocation, that is, to manipulate each thruster directly, but I am not sure how he did it in terms of coding, did he use Ardusub framework?
And most of the research on motion control of AUV base on decoupled thrust control. I would assume it is almost necessary to seperate every thrust to do my project.
All in all, is there a way of independently control each thruster of the BlueROV2?

I was somehow convinced before, that Ardusub cannot operate thrusters seperately, but is this the MAVlink command to do so? Pymavlink · GitBook

Hi @Lili_Marleen,

This comment addresses most of your post, but feel free to ask follow-ups if you want some extra information on anything in particular :slight_smile:

We would like to keep the auv away from an underwater column with a certain distance. The auv should rotate around the column while always facing it, with camera estimating the distance between the auv and column. We are simulating the scenario where the auv navigates around and examines underwater facilities in water tanks.

My persistence with independently controlling comes from the papers of controlling, most of them I believe bases on seperate thrusters. Especially, https://flex.flinders.edu.au/file/27aa0064-9de2-441c-8a17-655405d5fc2e/1/ThesisWu2018.pdf mentioned control allocation.

However, precision would not be too strict with out project. We plan to deploy PID control, and the idea was enlightened with this series of videos: Drone Simulation and Control, Part 2: How Do You Get a Drone to Hover? - YouTube

I find it really hard to seek some straightforward tutorial regarding ROV/AUV motion control. The algorithms in those cutting-edge research are very fancy, but we simply don’t know how to implement. They don’t mention any coding detail in most cases.

I would eagarly try to find out a few things, mostly related to how to command with Mavlink

  1. Offboard Control · MAVLink Developer Guide
    this link says “send low-level and high-level attitude, velocity or position commands to the vehicle.” is available, is there more details?

  2. Pymavlink · GitBook
    How many filght modes are there? Can we configure each mode`s thruster speed, or vehicle velocity?

  3. Pymavlink · GitBook
    What are the channels here specifically? What does it mean by commenting “# Set some yaw”

Thank you a lot! I find these are fundamental for carrying out my project!

Individual thruster control is required for vehicle control (understandably), but that isn’t necessarily the level you want to work at. ArduSub (and more generally the whole ArduPilot project) is made for doing that, with the intent that it abstracts the control for the user/operator. Instead of commanding individual thrusters users can instead control the motion of the vehicle (i.e. you can send a command for “go to this yaw angle”, and it should work for several different ArduPilot vehicles if they have their frames set up correctly - they could be different vehicle frames, and even different vehicle types, it shouldn’t matter for the user’s control). If positioning information is available to the vehicle the control can be abstracted one level further, with commands like “follow a path and go through this set of waypoints”.

Low level control like this is already implemented in ArduSub, but unfortunately we don’t yet have documentation on the ArduSub-specific implementation that I can point you to. The closest thing is the ArduCopter Attitude Control docs.

Note also that ArduSub vehicles aren’t the same as quadcopters. In your video link it’s discussing pitch and roll requirements for horizontal translation, but in ArduSub that’s instead accomplished with horizontally oriented thrusters that can push the vehicle sideways/forwards without affecting the vehicle rotation in the same way.

I haven’t heard of that interface, so I’m not sure whether it’s well established and just poorly documented, or whether it’s in the process of being developed, or perhaps just an expression of the general idea that control instructions don’t need to come from the flight controller.

ArduSub vehicles use directional control, which can be specified with either MANUAL_CONTROL or RC_CHANNELS_OVERRIDE MAVLink messages. Unfortunately the optional s and t axis fields in MANUAL_CONTROL are very new and not yet available in ArduSub, so to specify commands for all 6 DoF at once requires using RC_CHANNELS_OVERRIDE.

The flight modes are specified here, and the ones that take motion control rather than position controls are described in the “Roll and Pitch Control” section. There are additional descriptions in the ArduCopter docs, along with descriptions of several modes that don’t exist in ArduSub.

I don’t believe there are any modes that directly command vehicle velocity (so you may need to make a velocity controller if consistent velocity is important to you), but manual mode controls rotation rates and translational thrust, stabilise mode controls rotation angles and translational thrust, and depth hold mode is the same as stabilise but controls to a set depth.

Note that accurate velocity control requires an accurate position/velocity sensor, like a DVL or underwater GPS system. The vehicle can report a current velocity estimate, from integrating the IMU accelerometer values, but that value is prone to drift due to error buildup.

These are the RC Input Channels. By default channel 4 is for yaw control, so that comment is specifying that some yaw action is controlled. Values are between 1100 and 1900, where 1500 is stopped, 1900 is full positive, and 1100 is full negative. The effect of the specified value(s) will depend on the flight mode, joystick/pilot input gain, and potentially also the RC3_* parameters if you’ve changed them.

It may be helpful to refer to this gist that I made last year as an example of a full pymavlink program, that hopefully makes understanding the setup and control a bit easier/more intuitive. I unfortunately haven’t yet had a chance to transfer those components to our documentation examples.