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 :
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?
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
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)
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.
This is cool. I’m wondering trying to build some suction cups into the BlueROV2 to fix it while carrying out a task. Could I pick your brains on your approach for the suction?
We were never successful with suction with ROV due to the failure in the design of pumps - too little suction. We tried it without the ROV only cleaning attachment and stronger pumps - It sucked itself so much to the surface no human was able to move it. I think it could work nicely. But after suctioning to the surface I would suggest some wheels or tank tracks because using only the motors would produce jerky motion because of the stiction and friction forces and the point of force being high = high torque tiping the ROV.
I overcame the problem of sticking to the surface with changing to manual flight mode and pushing down. This way it was able to align itself really nicely with the surface. Here is a link to video:
:
