HI, I more or less understand how to add a custom config using the documentation. I’m concerned about not knowing what exactly the numbers represent for the roll,pitch,yaw… factors and how to actually derive them. My thruster configuration is very similar to the bluerov vectored 6dof :
Except I want mine to go a little bit faster so I’ve angled my thrusters(in yellow) 1-4 to face more forwards at a 30 degree angle. I was also wondering whether the distance of the thrusters from the main board affects these factors? Like if my thrusters 5-8 are positioned further apart, they may have a greater sensitivity towards roll and pitch.
The vectored 6dof config in ardusub I’'ve been using is this:
This comment is likely a good starting point for understanding that, branching out as relevant from there.
There are two levels here - the thrusters act on the vehicle’s center of mass, which is what the thrust factors should be relative to, and then the flight controller board may have an independent offset from that (which can and should be corrected for if there is one, although it’s preferable if there’s no offset to correct).
Hi Eliot, Thank you for your response. I had not checked out the first post you linked so that was really helpful.
The way I understand it right now is that the factors in the thruster config table are determined by the relative location and orientation of the thrusters to the robot’s COM. Of course, this would also be affected underwater by the robot’s center of buoyancy. If I can add/remove ballast/volume to the robot to make it as close to neutrally buoyant as possible (it is a custom build with limited testing time), would it be sufficient to simply ignore the buoyancy effects while determining the config factors?
Additionally, I understand the numbers in the thruster config to be like a percentage value from 0.0 to 1.0 referring to how much the thruster should be powered (and in what direction) to positively increase the partical movement of the robot (pitch, roll, thrust, etc.) Even if I determine that my vectored thrusters are slightly above the plane of the COM, how would I precisely/reliably figure out this number? or is it all relative, like the highest possible value I can set it while adhering to the relative contributions of the other thrusters?
And finally, just a quick confirmation. if my orbot and thrusters were placed in the exact same way as the default vectored 6dof config assumes, except the fact that my vectored thrusters are turned to 30 degrees instead of 45, is it reasonable to assume that the factors in the thruster config table would be the exact same?
This is in the right direction, but more precisely the thruster contribution factors are a tool, and are determined by the vehicle frame designer. They’re generally intended to be used to align thruster contributions with motion axes, so the autopilot has a nice abstraction for its control of the vehicle (e.g. the factors determine how autopilot tries to achieve commands/decisions to move in a particular way).
It is technically possible to do some extra things with the factors though, like if you have several vertical thrusters and they draw more power than you have available, then you could potentially reduce the magnitude of all the vertical and pitch/roll factors to restrict the vehicle’s vertical output.
The vehicle’s motion (and hence the autopilot’s control authority) are affected by the center of buoyancy, but because it’s orientation dependent I don’t believe it’s typically relevant for deciding on (or calculating optimal) thruster motion-axis contribution factors. Same applies for the effects of drag (including from external currents) - they affect how hard it is to move the vehicle from in a given orientation and environment, but for the autopilot that’s all just extrinsic factors it needs to deal with as it tries to achieve its set points.
It would in principle be possible to directly compensate for estimated buoyancy and drag forces with more advanced state estimation and control algorithms, especially if ArduSub supported more advanced control mechanisms and environment sensors, but that’s not currently the case, and is at a higher level than the thruster configuration.
Neutral buoyancy is an equalisation of the total buoyancy force with the gravitational force - it doesn’t actually tell you anything about how the mass and volume are distributed, and also depends on the density of the fluid the vehicle is suspended in (e.g. a vehicle that is neutrally buoyant in brackish, salty water would sink in fresh water).
Buoyancy distribution is relevant for passive stabilisation, but it’s a tradeoff - if the center of buoyancy and center of mass are in the same place then the vehicle is easiest to pitch/roll, whereas if the center of mass is below the center of buoyancy then the vehicle naturally stay upright, with its base effectively ‘hanging down’ like a pendulum. If they’re not horizontally aligned then the vehicle tends to rotate until they are, which also means a vehicle can have a natural tilt and/or roll angle, instead of sitting “flat” in the water.
As above though, those considerations are relevant to vehicle design, but not the thruster motion contribution factors.
My “passive stabilisation” link provides some approaches here, but you can either measure it by physically balancing or weighing the vehicle in different orientations, or using a CAD model with known component weights to calculate it.
That’s probably the most common approach, yes, especially where thrusters are arranged in a sufficiently symmetric pattern.
Hi @kushion -
I’ve configured the BlueROV2 to use the 30 degree mounting angles for thrusters, rather than 45, for better forward speed or lateral strafe speed. No change to matrix was required, but the performance benefitted all the same!
My vectored thrusters are placed a bit higher than the COM so they have significant pitch, roll contributions.
I run
./waf configure --board navigator
./waf sub
to build the firmware. I can see a new firmware file in build/navigator/bin which I then upload to blueos using the upload option in the autopilot firmware page.
To then choose the custom frame I change the FRAME_CONFIG parameter to custom
I was wondering whether I need to use the checkbox in any way and just checking if this is the right way to do it. when I go to vehicle setup now, I don’t see a visualisation of the robot (expected) but I still see 8 thrusters I can control and they run fine when I individually control them. I still have some other issues to sort out before I can put it in the water to test properly.
The “Custom” checkbox is for setting parameter values outside those known about by BlueOS (e.g. those included in official ArduPilot firmware builds). In this case there happens to be a standard parameter value with the name “Custom”, which corresponds to the frame you have created, but since that is a standard value you do not need to use the checkbox
