ROV with 9 or more Motors

Good morning,
We are building a 12‑motor ROV, and I noticed that in the configuration, under Vehicle Setup, I can only see 8 sliders for motor testing. How can I view all 12 motors?
Is there a way to display the additional N motors in the test area?

If we were to add even more thrusters (12 and above), what would be the correct procedure?

To add 12 motors, I created a new frame configuration in AP_Motors6DOF.hpp and defined the corresponding matrix in AP_Motors6DOF.cpp.
Regarding this, is there any documentation explaining how to calculate the motor values for each column? I haven’t found anything about this in the official documentation

Hi @Ruben_malacarne -

I don’t think ArduSub supports frames with more than 8 motors, even with a custom frame definition! Are any of your motors redundant, oriented in the same direction perhaps in pairs? They could be used in an 8 thruster configuration in this way, just connecting more than one to the same control signal… otherwise more in-depth modification of ArduSub may be required…

I believe ArduSub works with up to the 12 motors supported by its output channel (SERVOn_FUNCTION) parameters.

BlueOS is currently limited (for no intentional reason) to only show the first 8. We should be able to fix that quite soon, but it will require an update to be able to test the full set of available ones - sorry!

For more than 12 motors you would need to add parameter options for them in ArduSub, not just a custom frame design. For what it’s worth, we’re currently working our way towards supporting Lua-script-based motor configurations, in which case I believe you could add arbitrary numbers of motors, and not need to build custom firmware to do so.

I’m working on some, but it unfortunately isn’t completed yet.

As a very brief summary, the thruster contribution factors in ArduSub are answering the question “to achieve X commanded motion, how much should each thruster be engaged?”.

Thrust factors can be calculated for arbitrary motor orientations by

  1. calculating the matrix of control authorities (i.e. the maximal force/torque each motor can exert on the vehicle’s centre of mass, decomposed into the standard motion axes (roll, pitch, yaw, forward, lateral, throttle)), then
  2. inverting that matrix (or taking a pseudo-inverse in the case where you’re not using 6 thrusters) to get desired command proportions, then
  3. normalising (to ±1) either the whole matrix (to get balanced responses), or the set of contributions to each axis (to get maximal axis control authority, potentially at the cost of some cross-axis coupling when multiple axes are activated at once)

Note that with a sufficiently symmetric vehicle design the whole thruster factors matrix can be determined intuitively by hand, without specific calculations required. This thread may be of interest.

If you can share more about your motor placements and orientations I can help more, and/or I can try to give a more concrete worked example, but that will have to be later this week / next week some time.

Thank you. At the moment we are working to correctly set up the matrix, and with a frame similar to the BlueROV Heavy — but with four additional parallel thrusters — we obtain a matrix similar to the one shown in the image.

However, when we load it onto the ROV, it doesn’t seem to be configured correctly.Right now we’ve developed our own script which, given the position of the motors, computes the matrix by taking into account:Where the motor is located: its distance from the drone’s center of mass (the balance point), also known as the lever arm.Where it is pointing: whether it pushes upward, forward, sideways, or diagonally.How the propeller rotates: whether it spins clockwise (CW) or counter‑clockwise (CCW), since the rotation generates a torque on the vehicle.

We are wondering whether we are missing something that needs to be configured besides the CPP and header files.

I share an image of the configuration:

The order of trhusters are not the same of the Bluerov

What do you think?

Is wrong ?

(The ROV’s center of mass is slightly shifted upward.)

Parallel to what / which vehicle axes?

What do you mean by this? The firmware fails to load? The motors don’t spin? The motion between different axes is unexpectedly coupled?

At a quick glance the thrust factors look to at least be linearly independent, and have the kind of symmetry that could make for a feasible setup.

That said, it’s hard to say much about their correctness without also knowing either the thruster control authorities or their positions and orientations (to figure out some reasonable control authorities).

There are 8 horizontal thrusters (up and down) and 4 vertical thrusters, with a tilt angle of 40 degrees for the horizontal ones and 20 degrees for the vertical ones. I’m attaching an image to better illustrate the configuration.What I’m noticing is that some of these thrusters do not rotate in the correct direction as defined by the matrix. Besides configuring the matrix in the .cpp and header files of ap_motors6dof, is there anything else that needs to be set?Another question: if I’m moving along the X axis, should the vehicle correctly move forward?

Here you can find and image that describe the ROV

The front of the horizontal thrusters is facing outward from the ROV — forward (fore) for the front thrusters and aft for the rear thrusters.

If I’m understanding correctly, you’re saying there are two layers of horizontal thrusters, with 4 above the central plane and another 4 below the central plane? And from your diagram it looks like the ones from the higher level are directly over the top of the ones from the lower level (not offset / rotated around)?

Which axes are those 'tilt angle’s relative to?