Rising with v2.8 twists whole ROV


I recently completed building my OpenROV 2.8 and I’ve taken it out for a few successful ~1hr shore dives. As I’ve gotten more comfortable and adventurous with my ROV there’s been a few issues, mainly solved by reading through these forums.

But I have one annoyance that I can’t seem to fix as of yet: When I rise straight up, the whole ROV twists in the water. It’s worse at higher motor settings, but noticeable at a 2 as well. It’s always the same direction, to the left, and I don’t have any evidence of it happening when descending

I have the IMU sensor installed and nothing out of the ordinary.

Thanks for the help, super excited to explore more.

Bonus: picture of a car on the bottom of Lake Washington, Seattle.


Hi @pazrul,

This is caused by the fact that the OpenROV 2.8 only has one vertical thruster. I’m sure someone more mechanically inclined can provide a better/more detailed explanation than the following, but the basic reason is this:

When a prop spins in some fluid, be it air or water, depending on which way it is turning, it creates two primary forces. The first is the force along the axis about which the propeller rotates, and the other is a torque opposite to the direction of the rotation of the prop, on the body to which the thruster is attached (in this case your ROV). For vehicles such as quadrotors and helicopters, there are additional props which provide a countertorque to prevent rotation of the vehicle as a result of this. On quadrotors, two of the props rotate in the opposite direction to allow for fine control and balancing of the rotational forces on the vehicle. If you slow down one set of rotors and speed up the others, you can maintain altitude while rotating the vehicle. For helicopters without counter rotating vertical rotors, the tail rotor is what provides the ability to counter this torque and also give you control of the vehicle’s yaw.

As the OpenROV only has one vertical rotor, there is no counter to the torque, and that is why you see the rotation when you go up and down. However, you can use the port and starboard thrusters to counter the torque. As you have the IMU, you can put the vehicle into heading hold while you ascend and descend and it should help to counter the twisting.


@charlesdc Thanks so much for the detailed response. I thought the single vertical thruster might have something to do with it, but I appreciate for the clarification.

I’ll try setting heading hold in the future, I’m sure that will work just fine.



It sounds like code could be written to run one of the aft thrusters to counter act the twisting.

Just built mine and will be testing in a few days.


I was going to suggest the same thing, but figured that the OpenROV software developers might have that in mind for the next software release as it really make sense to do so.


@bokum I’m curious to see how much twisting you see on yours, I’d appreciate it if you’d update once you’d done some testing. Thanks!

@TCIII I will look through the open issues on github today, if one doesn’t exist for this I’ll create one. Maybe take a stab at solving it myself, heh.


@TCIII @pazrul @bokum,

I’m currently the primary engineer/developer in charge of the embedded software, ESCs, controls, etc. I joined OpenROV just over a year ago, and have mostly focused on Trident development (cameras, new microcontroller, Raspberry Pi, etc), though I have done quite a bit of refactoring on the firmware side of things. When I reworked a lot of the firmware, I made the decision to let the controls side of things for the 2.X series sit on the backburner, mainly because I knew that I would eventually be developing a new system for the Trident. Part of the work I’m doing now is the development of a new set of control schemes which are mainly applicable to Trident, but will also likely serve as a significant upgrade to the 2.X series as well (or at least those equipped with the IMU+Depth sensor).

The primary mode of control that we are imagining the Trident to be piloted with is two controllers working together which can interchangeably be absolute position or rate controllers. For example, The depth controller can be set in absolute position mode, while the yaw controller can be set in rate mode, allowing the user to maintain a constant depth without needing to touch the controls, while the yaw/throttle axes of the joystick can be used to manoeuvre in a 2D plane. When you let go of the joystick, you will be essentially commanding a 0 deg/s yaw rate, which will drive the control system to bring you to a stop. You could also put the yaw controller in absolute mode, and it will maintain a fixed heading (to the best of the sensor’s abilities to estimate the heading). In absolute mode, you have the option to lock the control such that yaw inputs on the gamepad don’t affect it any more, or allow the setpoint to be modified by the controller in a sort of “carrot on a stick” control scheme. In general, we expect that most people will prefer to control the depth with a modifiable setpoint, in the same way that depth lock works on the 2.X series, while the yaw mode will vary depending on the user’s preferences and the situation.

This development is important for the 2.X as well, because it currently does not have a rate controller, and the vertical and horizontal control planes are currently entirely decoupled, so short of using the existing heading and depth lock controls, you can’t achieve isolated vertical control. Arguably, because of the uncertainty in the sensors we have, the arrangement of the thrusters, the unknown underwater dynamics, propeller dynamics, and more, you can never achieve perfect control along any given control surface with the 2.X series (or any vehicle), but with a proper control allocation step, we can improve the situation.

The new control software that I will be working on will feature the following to hopefully achieve a flexible and more complete set of control mechanisms:

  • A thruster abstraction which contains information about the thruster’s capabilities, physical properties, and orientation
  • An Allocator stage which relates and mixes input signals pertaining to principle axes of control (yaw, pitch, x, z) to thruster signals for a given thruster arrangement (similar to our current concept of the CThrusters2x1 class in the arduino firmware)
  • A rate controller (PID or something else) which maps input signals (from a gamepad or another control system) to desired velocities along principle axes
  • A position controller which maps input signals to desired absolute positions (mainly only achievable for yaw and depth with a three thruster setup).

An allocation stage which includes a model of the vertical thruster’s effect on the yaw axis combined with a rate controller allowing only user requested yaw inputs, should be the answer to eliminate the twist while not having to put the vehicle in heading hold, as addressed in this thread. Once the Trident implementations are mature and tested, I will definitely be looking into bringing the 2.X series in line. That said, we certainly encourage anyone to feel free to write a new CThruster configuration or CAutopilot implementation in the current firmware and give a shot at tackling the problem.

We are also completely open to discussing new control schemes and methods going forward, so feel free to voice any ideas you might like to see explored. Having so few sensors inputs, so many unknowns, and strange, unmodeled dynamics, precise control of the 2.X is a tricky subject which will probably require some clever thinking to tackle beyond what I’ve got planned.


A nice analysis of the ROV dynamics and interaction.
It will indeed be nice when your Trident axis control philosophy is migrated to the OpenROV2.x series.


Just minor addition to @charlesdc. The effect has not correlation with the thruster rotating in some kind of fluid but also works perfectly well in vacuum. Imagine an OpenROV flying without gravitation on the ISS (space station). Once you power a thruster, the prop will start rotating. Because of the counter momentum the whole ROV will turn in the opposite direction, maintaining the momentum equilibrium (overall the momentum of the vehicle is constant).