Design for control API of OpenROV


This topic is intended to design and discuss the contol APIs as made available in the OpenROV Software. This is a subset of all of the APIs that are available.

Assume the ROV is capable of full 6-axis control:

Rate Commands

The Rate commands controls how fast the ROV is changing its position. Most of theses are a percentage of total possible rate which must be exposed in the rov capabilities service. There is also a simple aggregate method for setting all of the rates with a singe message, both as individual values and as an aggregated vector
Yaw(-1.0 … 1.0)
Pitch(-1.0 … 1.0)
Roll(-1.0 … 1.0)
Thrust(-1.0 … 1.0)
Lift(-1.0 … 1.0)
Strafe(-1.0 … 1.0)

Orientation Commands

The Orientation commands set target orientations for the ROV to hold. Units are in degrees. The aggregated vector is a quaternion
SetPitch(-180 … 180)
SetRoll(-90 … 90 )
SetYaw(0 … 360)
SetOrientation(orientation vector)

Position Commands

The position command set sets relative and absolute location targets
SetAbsolutePosition(gps coordinates)
AlterRelativePosition(quaternion vector in meters)

@spiderkeys, @Jim_N let me know your throughts!


Looks appropriate. Typically you allow for either rate or position commands. I dig the target orientation setting, however, if you have the CG and CB on top of one another, than the orientation hold is pretty easy, yet if you don’t, that control law gets a little more complicated. I’ll give it some thought.


Yea, typically the orientation is also part of the position set of commands, since we are usually thinking about this in terms of pose and delta pose, i.e.:


Delta pose:

If we try and map the proposed commands, we’ll see:


  • Yaw, Pitch, and Roll rates map to dphi, dtheta, dpsi
  • Thrust, Lift, and Strafe rates map to dx, dz, and dy


  • Pitch, Roll, and Yaw map to theta, phi, psi


  • Depth, Forward, Side map to z, x, y

I think all bases are covered with the various API functions for affecting changes in these parameters with what’s listed here, from the point of view that all of these functions are simply ways of modifying the current setpoint (goal) of the currently active controller (rate vs position vs some hybrid controller). This of course beckons an API function for setting the control mode (to start off with, rate vs position).


Ditto that. I’m curious as to how the set orientation maps to vehicle control, for example. Unless you have a moment-less vehicle configuration, holding a set roll pitch yaw may demand a more complicated control law for position hold. With your CG CB line, your moment will grow as a function of distance. Each vehicle and a different payload will affect the moment and adjustments would need to be made to the controller to compensate. Now this isn’t a big deal as long as your controller has selected modes for the PID, i.e. PID for orientation, etc. You would just need to have a good control law that handles the rate adjustments. However, to much of a payload addition or change in the CG CB line moment would require a new controller more modification of the current controller via gains on the P/I/and or D. Not something I’d be to concerned about, but to be aware of.

But controllers for this exist so rock on.


You can hold pitch and roll with elevons. We’re making software that works with all possible ROV configurations :slight_smile:


Interesting…I certainly need to see the new vehicle design, lol. There exists a few interesting use cases, one being to hold orientation during motion and the other holding orientation in conjunction with a position hold. I just got done writing a position hold for one of our quads(non-vicon), and working on a VTOL ( wink to spiderkeys) tomorrow. So I’ll be more learned soon, lol.