Home        Store        Docs        Blog

Precise meaning of rc_override commands for automatic control

Hi everyone ! My current project is to implement my own controller to do waypoint navigation on the BlueRov. To do so, I need to have a precise understanding of the available commands that can be sent to the vehicle and what they represent.
FYI, I will use x,y and z to denote forward, lateral and throttle in this post (x,y,z is thus the ROV frame).

After reading the available documentation and experimenting with the BlueRov, I have come to the following conclusions, which may be wrong :smile: (the purpose of this post is to correct me) :


  • in stabilize and depth hold mode, the only way to send a command is through rc_override or manual control. For instance, when using MAVROS to send commands to the ROV from ros, publishing to the various setpoint topics (setpoint_attitude, setpoint_accel …etc) doesn’t do anything.

  • the rc_override and manual control commands do exactly the same thing, but are just not scaled the same way. However, when using QGroundControl and sending mavlink commands from another software at the same time, manual control should be used and not rc_override which can cause a conflict.


  • the rc_override commands for translation (x, y and z) do the same thing in manual, stabilize and depth hold modes. It is directly translated into a proportional increase or decrease of the speed of the propellers responsible for the given translation. For instance a 1490 command on the z axis results in a proportional increase of the speed of the horizontal propellers in the rotation direction that provides lift, equal to 1490 - 1500 = - 10 multiplied by the throttle factor of each individual propeller.

What seems weird to me about this is that the increase of a propeller’s speed is not exactly proportional to the increase of its thrust, given that the rotational speed / thrust curve of a propeller is not a linear function. Because of this, if you increment the speed of your horizontal propellers by 10 to provide a force on the z axis but the individual propellers originally had different speeds (because of a pitch command for instance), you will not get the same thrust increase on every propeller and you will create a residual torque. In other cases, you could create an unwanted residual force the same way. Is this phenomenon taken into account or negligible ?

  • in stabilize mode, there is no automatic control of the x,y,z translation commands. In depth hold mode, there is automatic control of these commands, only to stabilize the depth.


  • in manual mode, the rc_override commands for roll, pitch and yaw correspond to proportional increases / decreases of the speed of some propellers, according to the roll, pitch and yaw factors for every propeller. It works the same way as translation commands.

–> If a propeller has both yaw and forward factors set to 1, how do you handle a maximal command on both yaw, and forward ? It would require a propeller speed that the ESC can’t deliver, right ? How do you handle this ?

  • in stabilize or depth hold mode, the rc_override yaw command controls the target yaw rotation rate. This target rotation rate is given as input to the PID controller that controls the motors to reach this target rotation rate.

  • in stabilize or depth hold mode, the rc_override commands for pitch and roll control the target pitch and roll angles (and not rotation rates !). This target is reached by the P and PID controllers.

  • in stabilize and depth hold modes, the pitch, yaw and roll angles are stabilized when there is no command. The pitch and roll are stabilized at zero (the ROV is maintained in a horizontal orientation). The yaw angle is stabilized at the initial yaw value (initial = when the angle control started).

–> In the situation where we stop sending a rc_override command for yaw, the ROV switches from controlling the rotation rate to controlling the angle value. What is then considered the new target angle ? Is it the angle at the precise time where the yaw command stopped ? Furthermore, does a 1500 rc_override cmd for yaw stabilize the rotation rate at zero or the angle value around the initial value ?

WHY DID I WRITE ALL THIS ? :sweat_smile:

This is the extent of my understanding of the control of the BlueROV, please correct me if I’m wrong, I really need to precisely understand the physics of these commands in order to implement my controller on top of the existing attitude control.

I also need to understand the commands quantitatively, and not only qualitatively. To that end, could you tell me how the rc_override commands translate to pitch, roll target angles and to yaw target rotation rates (what is the scale basically) ?
Do you know the relationship between the rc_override forward, lateral, throttle commands and the thrust ?
If you also have information about how fast (orders of magnitude) the P and PID controllers are able to reach the target rotation rates and angle values, that could also be very useful.

I could probably reverse-engineer the ardusub code to get these answers, but I think that having all of that information in one place in the forum (or even better in the ardusub doc) would be extremely useful and time-saving to a lot of people.

Congrats and thank you if you made it through this long message, and I hope you will be able to provide me (and the whole community) with illuminating answers !



These ‘forward, lateral, throttle’ commands that you are referring to are just pilot input. They are do not result in proportional change in motor speed. The motor output will depend on the operating mode that you are using. In manual mode, the input command is just passed directly to the speed controllers (there is no closed loop control of rotor speed here, or in any case). In the other modes, the motor output is closed loop to maintain attitude and speed of the vehicle. This closed loop control (again it’s not controlling rotor speed, but relative thrust to maintain attitude) will compensate effectively for the nonlinearities you pointed out.

ArduSub already has position and waypoint controllers (not deemed stable, but demonstrated to work). I recommend you look into this rather than rolling your own with automated pilot input.

You don’t have to reverse engineer anything, the code is open source and available on github. I recommend you check that out to gain an intimate understanding of how it works.

The motor output is saturated, no normalization is performed.

It again, depends on the operating mode that you are in. In stabilize or depth hold mode, the angle target is locked 250ms after the rate command drops to zero. Then it is stabilizing angle.