I am going to work on BlueROV2 Heavy soon and am trying to simulate it in Matlab/Simulink by following the model presented in the following thesis. https://flex.flinders.edu.au/file/27aa0064-9de2-441c-8a17-655405d5fc2e/1/ThesisWu2018.pdf
I have a question about thruster force directions shown in Fig 4.2 on Page 40 of the thesis. I am confused about how the horizontal thrusters are oriented. I think horizontal thrusters 3 and 4 on the ROV are oriented such that when positive input is applied, they would move the ROV forward in the x direction. Similarly, when negative input is applied to thrusters 1 and 2, that will cause the ROV to move in the positive x-direction. It would also mean that the effective directions of forces applied by thrusters 3 and 4 on the ROV are in the directions opposite to those depicted in Fig 4.2. And same would apply for thrusters 1 and 2. However the thesis uses force directions as shown in that figure in calculating actual forces and torques on the ROV. Am I missing something here or misinterpreting things?
Also, are all vertical thrusters on the ROV oriented such that they produce forces in the same direction? Figure 4.2 in the thesis shows varying directions for forces generated by the vertical thrusters.
I will greatly appreciate any input in this regard.
The force directions in any diagram are somewhat arbitrary, as long as they are appropriately accounted for with negations as relevant when determining the resultant forces. In the case of a vehicle like the BlueROV2 Heavy, which uses T200 Thrusters that have non-symmetric thrust, I would personally be inclined to display and model the force directions based on the front direction of each thruster, and abstract away the propeller and control signal specifics (which is effectively what ArduSub does). That is not what seems to have been done in the figure you’ve referred to, and from a quick skim of the thesis it looks like the thrust asymmetries were ignored (see Section 5.3), in which case the specific directions aren’t really important, just their consistent application through any calculations.
Our thrusters use brushless DC motors that can have their rotation direction swapped by either swapping two of the phase wires controlling a thruster, or just reversing the PWM signal sent to it (which our ArduSub autopilot firmware has a parameter per thruster to do), so the effect of “positive input” to a thruster depends on its wiring and software configuration.
That said, physically speaking the installed propeller orientation/type in a thruster determines which way the water flows through it when the propeller turns in a given direction. The propellers are set to counter rotate (see Figure 3.4), which keeps vehicle torques balanced.
By inspection, it seems like Figure 4.2 in the thesis mostly uses an approach where
negative signal (1100-1500 PWM) → counter-clockwise propeller rotation, and
positive signal (1500-1900 PWM) → clockwise propeller rotation
except that thrusters 3 and 4 have their assigned forces the opposite way around to that convention. I’m not sure why that would be the case, and the choice may have been completely arbitrary (i.e. the mostly consistent rotation directions could be a coincidence). Equation (4.61) follows the force arrows shown on their diagram, so it seems that part of the thesis is at least self-consistent.
I haven’t read or analysed the thesis and its results in any particular depth, but there doesn’t seem to be an obvious issue with that part of the model, although it may need to be accounted for later. If it’s not then perhaps you can try negating thrusters 3 and 4 to see if that aids stability, and if it doesn’t you can try instead negating thrusters 1, 2, 3, 4, 5, and 8 such that positive input corresponds to each thruster’s individual forward direction.
@EliotBR Thank you so much for your detailed reply, it cleared many things for me. When I originally drew my force diagram, I tried to abstract away propeller rotation and control signal by assuming that positive control input corresponds to forward direction as you have suggested, and as also what ArduSub does. Then looking at the thesis force diagram completely threw me off Again, thanks for the excellent explanation!
The comment in Motors Setup in QGroundControl saying “When a slider is moved down, the thruster should push air/water toward the cable entering the housing” also conforms to the convention that positive input corresponds to forward direction for each thruster. Could you confirm?
Based on how ArduSub assigns forces (positive input - forward direction), I modified the thrust configuration matrix in Eq 4.61. Then I simulated the model with constant positive input to thrusters 3 and 4, and constant negative input to thrusters 1 and 2, thus simulating forward movement of the ROV along the x-direction. All the vertical thrusters were at zero inputs. The initial depth of the ROV was 50m and it would rise slowly because of buoyancy in the absence of vertical thrust. What I observed is that the with only forward movement, ROV pitches down slightly with small oscillations around that average negative pitch. This is counterintuitive to me since I was expecting to see a slightly positive pitch angle since horizontal thrusters are slightly below the CG (as per the model in the thesis) and because of that they would produce a positive pitching moment. Does the physical ROV pitch up or down in water moving forward without any vertical thrust? As the control input increases beyond 30%, ROV basically becomes unstable and just keeps pitching extremely steeply, almost in place. I wonder if this is the expected behavior and you see large pitch angles on the real ROV with only horizontal thruster inputs for forward motion. Or if my thrust configuration is still messed up and if I am still not clear about it.
In order to figure this out I looked at SIM_Submarine code (I have not run the sim yet) and realized that the model used there is substantially different in many details. Is there any documentation about the model used in SIM_Submarine? Does SIM_Submarine exhibit any such pitch behavior as I am seeing?
I tried to find out where ArduSub does the motor mixing. Could you point me in the correct direction?
I still do not have the actual ROV to work on, so I am unable to test what it does under these circumstances and hence relying on simulations.
Took some time to get back to this, as responding meaningfully to this kind of detailed post takes a decent chunk of time.
That depends what you mean by “positive input”. ArduSub operates at the abstracted vehicle level, where the operator/pilot provides vehicle motion commands in the x/y/z/yaw/pitch/roll directions, and ArduSub converts those into relevant commands that are sent to the thruster ESCs. At the vehicle level, “positive input” corresponds to intended vehicle motions, and the signals that get sent to the ESCs depend on the active frame configuration and flight mode.
At the thruster level, the front of our thrusters is the more rounded side, where the cable comes in. ArduSub’s frame configurations are set up such that a thruster has positive contributions in the forwards direction of the thruster. Accordingly, if a thruster is pointing backwards relative to the vehicle then a “positive input” to that thruster will have a backwards effect on the vehicle motion, so the corresponding thrust factor (in the frame configuration) is negative.
At the ESC level, “positive input” just spins the motor in a particular direction. If that does not match the forwards direction for the thruster (which is what ArduSub intends, with our default frame configurations) then it can either be corrected for in hardware (by switching two of the thruster’s phase wires), or in software (by telling ArduSub to invert the signal it sends to that ESC).
Honestly I’m not certain, because
we rarely operate without some form of feedback-based stabilisation/depth hold mode on,
I don’t personally have much experience with a plain BlueROV2 Heavy,
different revisions and variants (e.g. aluminium vs acrylic enclosures) of the vehicle will have slightly different mass and volume distributions, which moves the centers of gravity and buoyancy, and
we tune to the water conditions and mass/volume distributions by adding and moving ballast weights on the bottom (e.g. salt water is more buoyant than fresh, so may need more ballast)
I expect this is an issue with the modelling, but it’s possible it’s a model simplicity problem rather than an incorrect application of the chosen model.
It’s worth noting that
the ROV is designed (with buoyancy at the top, and weight at the bottom) to have a self-righting moment if it pitches or rolls unexpectedly
there is more drag area near the top of the front face, which would contribute to some amount of upwards pitching force when moving forwards
if the vehicle has forwards momentum but starts pitching then the top/bottom surfaces would increase the drag, which has a stabilising effect (but the most stable angle then depends on the speed)
fluid interactions between the thruster flows may also be relevant, and with asymmetrical thrusters like the T200s it may be non-negligible that the front thrusters are facing backwards, so when trying to move forwards there is more thrust coming from the rear of the vehicle
I’m not sure - it’s not something I’ve worked with. The only simulation-focused documentation I’m aware of is
I’m not aware of documentation for SIM_Submarine specifically, beyond the comments in the source code files.
Unfortunately we don’t yet have decent documentation on the ArduSub components of the ArduPilot codebase, although that is something I’m planning to work on.
As a (brief) walkthrough of finding this particular information,
searching for _roll_in we find that it is used within AP_Motors6DOF.cpp, which is where ArduSub’s thrust factors are defined (for frame configuration)
within that file it is used in three functions, the most relevant of which is output_armed_stabilizing_vectored_6dof (because the BlueROV2 Heavy is a 6DoF capable vehicle with vectored horizontal thrusters)
note that it’s a bit unintuitive to follow, because ArduPilot was initially written for vehicles with no direct lateral control, so the extra motions have been somewhat shoehorned into the existing variables
Thank you so much for a very detailed reply to my post; that helped immensely. And sorry for the late reply. I did some digging and found a paper that was referenced in the SITL+Gazebo sim forum (freefloating gazebo plugin).
The paper mentioned that since most values in the added mass matrix Ma and the Ca matrix are calculated empirically, they can be substantially wrong. As such, the freefloating Gazebo plugin disregards those matrices in the vehicle dynamics. I followed that paper and removed Ma and Ca matrices from the BlueROV2 Heavy model. Since then the model has been working very well.
And thank you for pointing out the motor mixing code. I am going through it and now have a reasonable understanding about how BlueROV works
Thanks again for taking time to answer my questions!
