Costum ROV with 12+ motors

Dear fellow developers!

I am currently working on a project to develop and build a ship’s hull cleaning ROV. The ROV is going to be fairly heavy(60kg) and is going to suction itself to hulls to perform cleaning - Simplified, we are building a Roomba for ships :). Jokes aside, the weight and suction warrant the need for quite a lot of motors. The basic configuration needs 12 times T-200 motors. The full version would need at least 16 motors. Check the image for better understanding.

For control we will use the Pixhawk 4 and Ardusub software. I have been scouring the stable 4.0.3 code and the internet for a way to use at least 12 motors with current Ardusub software. We don’t need any other functionality from Ardusub like lights, gimbals, camera… only stable control. From here on are my ramblings, discoveries and questions that I would love to get fact checked on :slight_smile: :

  • Inside the default code there are defined 12 motors → AP_MOTORS_MOT_n. This gives me hope that it should be fairly easy to implement the basic config. Will 12 motors defined in a frame interfere with other channels (lights, servos…).
  • How to remove other functionality from Ardusub like lights, gimbals, camera…?
  • How to rewire freed up channels to motor control to maybe get 16 PWM channels? Is this maybe done “automatically” because the AP_Motors6DOF.cpp library just iterates through all defined motors and sends the commands to RC_Write() function. What about other functions?
  • Where in the code are defines for pins/channels? To edit/remove/change this defines.
  • Has anyone rewritten/replaced this RC_Write() function in the AP_Motors6DOF.cpp to write to CAN output using the UAVCAN library instead of PWM channels?

Thank you all in advance!

Have a great day!

Hi @Fluyer2, welcome to the forum :slight_smile:

Looks like an interesting project!

The output channels are defined using the SERVOn_FUNCTION parameters - if an output is configured as a motor then it can’t simultaneously be configured as something else, so there shouldn’t be conflicts once the parameters are set appropriately.

I don’t believe this should be necessary. Configuring the outputs as motors will stop the other functionalities from occurring.

Camera functionality on our ROVs is handled via the onboard computer (Raspberry Pi), so is unrelated.

I expect it would primarily be handled with parameters and an appropriate frame configuration, but there are currently only motor parameters up to 12, so you would need to add additional ones. I’m also not certain whether motors 9-12 are actually implemented in ArduSub, so I’ve asked internally and will get back to you.

That’s not something I have experience with, but also that may not be possible for every output, depending on the flight controller’s capabilities.

As a couple of alternatives, you may be able to

  • use fewer, larger thrusters
    • we’re working on this, and should have some news to share soonish
  • double up on some of the thruster signals
    • mentioned here
    • loses some movement independence, but that’s unlikely to cause issues (since even 8 independent controls is plenty)

Following up on this,

Thank you so much for the help! I will post my findings in this thread right after I fix the problems with compiling the stable version :slight_smile:

There are some issues with that at the moment - this may be helpful :slight_smile:

Thank you, this helped a lot. I successfully build and programmed the custom software. I can confirm that 12 motors work with only changing the frame. If necessary for the project I will play with 16 motors (will upload here the solution if successful).

Regarding the custom frame is there any documents that thoroughly explain the calculation for the motor factors? I find it confusing when comparing the BlueROV1 and the vectored ROVs. The BlueROV1 has different and “logic/expected” factors while the vectored ROVs only have +1.0f and -1.0f in correct spots.

Please correct my understanding. Motor number 1 in SUB_FRAME_VECTORED_6DOF gives 100% of its thrust to yaw in clockwise direction - therefore 1.0f. But why isn’t the forward factor -0.5f and lateral factor 0.5f? Since it is giving “half” of its thrust to these directions… This concept is quite important for me to understand because our ROV is not fully symmetric (see the top and bottom motors on the same corner)

1 Like

We don’t yet have great docs on that, but you may find these useful:

The reasoning there is that the thrust factors are scalers for the output, so if no normalisation is done then it’s unintentionally limiting motion directions that don’t have a thruster directly aligned with them.

A notable caveat is that