I am creating my own thruster configuration matrix that takes into account the force/moment contributions from the thrusters for the vectored configuration on the BlueROV2.
I see that the thruster configuration matrix looks like this in Ardupilot.
My understanding on thrusters 5/6 specifically is that they have opposite pitch propellers in order to cancel out the torque on the vehicle. From my understanding, they spin in the same direction, but create force in opposite directions. If this is the case, why are the fourth values (throttle factors) for motors 5 and 6 the same sign? Isn’t motor 5 creating a force in the opposite direction of motor 6, given the same control inputs?
The thrust factors in ArduSub are determined based on the thruster forward directions (by which way the front of each thruster is pointing) - the propeller spin direction is considered irrelevant, and is generally handled in software by setting a parameter to reverse the output commands to the ESC if it is relevant to do so. There’s some additional discussion here.
Depending on what you mean, this may be somewhat misguided. The thrust factors are multipliers to form linear combinations of thrust commands for a given target direction, and are normalised for each motion axis.
If you’re planning to factor in small forces like minor pitch contributions from the horizontal thrusters due to not being completely vertically aligned with the vehicle’s center of mass then fair enough, but if you’re planning to e.g. reduce the forward and lateral factors for the horizontal thrusters because they are not fully aligned forwards or sideways then that will just end up limiting the output of those thrusters. There’s a bit more discussion on that here, and possibly in other posts tagged vehicle-design
Thanks for the quick response. I appreciate the clarification there. I suppose that is simpler from the perspective of you all creating a commercial product. My reasoning for exploring this is because we are creating a test platform for a full size AUV using the blueROV2 and are going to create a fin/rudder attachment for the BlueROV. We need the thruster matrix to be scaled correctly to produce actual forces/moments, not just normalized thrust so that we can do the same for our fins and optimize when to use fins vs thrusters for power efficiency
Technically speaking there is no direct relationship between the command sent to the speed controller and the thrust output of a thruster, because different water flow and transients have an impact on the thrust at any given moment.
ArduSub does not try to model the forces exerted on or by the vehicle, and that’s not what the thrust factors are currently used for, so changing to non-normalised ones will likely mean the existing flight modes no longer work as intended. If you’re planning to operate only within your own custom flight mode then that may be ok, but just a bit of forewarning that this will significantly differ from the existing behaviour.
If force estimates are an integral part of your control approach then fair enough, but if the intent is “only” to support a combination of fins and thrusters then there may be other ways of doing so that involve less modelling needing to be built into the firmware (e.g. perhaps fin movement and thrust differentials could be linearly correlated, or you could try to use fin movements by default, but limit them by a maximum rotation rate which is then compensated for by the thrusters).
Out of curiosity, where did you find the code there to add/modify the ArduSub frames? My lab has been looking at doing that for awhile, but to no avail. I’m very interested!
