Home        Store        Learn        Blog

How to control thrusters independently

Hello everyone,

I would like to know if there is some way to control thrusters of a heavy bluerov2 independently.
I read that it was not possible via mavlink in 2018. I am asking if today that’s changed.

If not, is there an other way to do it ?

Thank you for the answer(s)

Hi @Guillaume1, welcome to the forum :slight_smile:

QGroundControl provides a Motors Setup page which allows you to manually test individual motors. I searched the QGC github page for Motor Test and found this commit, which shows that src/Vehicle/Vehicle.cc uses the mavlink message MAV_CMD_DO_MOTOR_TEST to achieve that. Your ROV will need to be armed to use it (as with any thruster/motor message), and I believe you’ll need to be in Manual mode.

I’m not sure what your use-case is, so if you’re just after a testing scenario then the information above is likely sufficient. If you’re wanting to understand how the thruster directions are understood by ArduSub:

  • the BlueROV2 Heavy frame configuration is here
  • the add_motor_raw_6dof function signature is here
  • info on making/adding a custom frame configuration to ArduSub is here (you could conceivably make a custom configuration which moves up to 6 thrusters individually with your normal joystick movements, assuming you’re happy to operate only in manual mode)

If you’re wanting to keep your frame the same but sometimes control individual thrusters then if you particularly want you could create an inverse-mapping of the frame configuration which would allow you to set motion based on individual motor control. That kind of control is likely much better off inside ArduSub though, since it can operate at a much faster rate and doesn’t have communication overhead. You could possibly add a custom control mode that basically does manual mode but with an inverse mapping in front, or ideally a lower level one that bypasses the existing mapping and just directly sets motor values.

Hello Eliot,

Thank you for your fast answer !

In simulation I built some command laws taking into account the fact that we can control each thrusters independently. The goal is to stabilize the ROV in a certain pitch and roll using Python and ROS.
However, override function only allows to command directly the orientations and the forward/backward, upward/downward movements. That is why I want to know if there is a way to control each thrusters independently.

Thank you,

Guillaume

Hi Guillaume,

While this can definitely be a fun and interesting thing to experiment with, you’re likely to get much tighter control by using ArduSub for it due to the higher frequency measurement readings and reduced communication overhead. Are you aware of Stabilise mode? If not, have a look at the Pitch/Roll control section of the ArduSub docs :slight_smile:

Note that control in any particular direction or rotation axis is only possible with appropriately placed thrusters. The BlueROV2 Heavy can control both pitch and roll, whereas the standard frame configuration has no pitch control capabilities.

Hi Eliot,

I didn’t knew that but I would like to do it myself with my own control laws and the manual mode.
However, do you know how this stabilize mode is made ? Does it use override channel or does it control each thrusters independently ?

Guillaume

It’s part of ArduSub, which is the firmware that runs on the Pixhawk itself. RC_OVERRIDE is part of mavlink, which is the communication protocol for communicating with an ArduSub (or more general ArduPilot) autopilot device. The pixhawk firmware needs to be able to accept mavlink messages as input commands, and send them to update status to external devices like the ground control station (generally QGroundControl for ArduSub devices), but all the actual motor control is done by a PID controller which sends the the desired direction/rotations to the selected frame configuration mapping, which then sends the relevant commands to each motor.

For more of an understanding of how ArduSub works, here’s

Note that the ArduPilot codebase is quite large and interconnected, so it can definitely be difficult to understand all the different components of it and how they fit together. At some point I’m hoping to map out more clearly how ArduSub fits within the ArduPilot code, but I don’t expect that to be done until at least a few months from now, and quite possibly not until the end of the year.