Hello! I’m currently having stabilization issues when moving my ROV2 underwater.
Setup
6 thrusters in the BlueROV2/Vectored position
Weights attached to various positions of the ROV2 for stability.
Payload skid attached to bottom of ROV; no weights attached on the payload skid area.
Payload: BlueRobotics 4" acrylic enclosure tube; inside the enclosure are two items. In terms of space, each individual item takes up approximately half the length of the tube:
When operating the ROV2 (payload skid + payload attached) in manual mode using the controller, attempting to move in a straight direction forward as one normally would results in the ROV2 tipping downward about 15 degrees. You can think of it as sort of diving down while trying to just move forward.
When operating the ROV2 in depth hold mode with this same setup, the ROV oscillates up and down a considerable amount in an attempt to stabilize itself. Think of it as a dolphin moving through the water.
When the payload skid and the payload are not attached, the ROV moves as expected.
My Thoughts
Clearly, the uneven distribution of weight at the payload tube is affecting the balance of the ROV2.
During depth hold mode, it seems to me that the PID controller is attempting to compensate for this imbalance, but seems to fail at maintaining stability, hence the large up/down oscillation.
Questions
Is this in issue of weight distribution? I.e. is this a problem that could be fixed by adding enough weight to the ROV2 on the side of the circuit, opposite of where the battery is in an attempt to balance out the payload’s weight distribution?
Or is this an issue of buoyancy? I.e. would adding extra buoyancy foam to the side of the battery help with stability?
I believe that the PID controller parameters could probably be tuned differently (not sure how at this moment) to help with stabilization, but I believe that attempting to solve the problem physically at first is a better direction to take. Thoughts about this? I could be totally wrong, and PID could be the way to go.
Has anyone had experience with balancing out the ROV2 when attaching unbalanced (in terms of weight distribution) payloads? Any advice, ideas, or comments are greatly appreciated. Thanks for reading!
Undesired rotation like this has to do with the center of mass (CoM), center of buoyancy (CoB, aka center of displaced volume), and the locations and orientations where external forces (e.g. from thrusters and drag) are applied.
Passive Rotation (pitch/tilt while stationary)
Passive pitch or tilt is caused by the CoM and CoB not being vertically aligned, in which case there’s rotation down towards the CoM, about the horizontal perpendicular axis halfway between the CoM and CoB
It’s worth noting that buoyancy wants to be on top, so if the CoB is below the CoM then there’s something of an unstable equilibrium, so the ROV will be trying to flip itself over, which is why normally buoyancy is placed at the top and ballast at the bottom, so the ROV effectively hangs in the water in the desired orientation, which makes it self-righting. Some specialty ROVs/AUVs are designed to have the CoM and CoB at the same location, so that they can freely rotate in all directions.
If your ROV sits flat in the water, this isn’t your issue.
Active Rotation (tilt/pitch/roll in motion)
In the active case, your net thrust, drag, and/or buoyancy forces aren’t aligned with the CoM. The torque (rotational force) applied to the CoM is the multiplication of each contributing force by its corresponding perpendicular distance (see below)
To reduce undesired rotation you can either reduce the contributing forces (volume, surface area in direction of motion, and/or thrust), or the perpendicular distances (move CoM by redistributing weight, move CoB by redistributing volume, move thrusters). Achieving stable dynamics is a careful balancing act of all of these factors, which is understandably a difficult task.
Tuning/Compensation
Passive (Redistribution)
For an existing ROV, usually there isn’t a heap that can be done about the thruster locations, minimum volume, or the tether size/placement, so tuning is mostly done with a combination of ballast weights, buoyancy foam, and possibly changes to the drag surface in a particular motion direction (although this is less common and generally has less of an effect).
For the easiest tuning experience it’s good to have an understanding of how much mass and volume you have, and where your CoM and CoB are so you can determine what to adjust for the most effective results. The BlueROV2 technical details provide weight and buoyancy estimates for the standard setup, and a 3D model that you could use to estimate volume (and CoB). It may be helpful to assume the CoM is at the center point from the top view, and you can probably also assume the vertical component is roughly line with the horizontal thrusters. If you’ve got some kitchen scales available you could measure that more exactly by putting one under each corner of the ROV from the upright orientation and another measurement on its side, which can also be a good way of measuring CoM for your payload-added ROV without needing to put the material properties and whatnot into a CAD model.
In your case you’ve already identified that you’ve got an unbalanced mass distribution horizontally, so to close the gap between the CoB and CoM you can put ballast weights on the lighter side and/or add buoyancy foam to the heavier side. Take care to keep the ratios relatively balanced so you can keep a suitable net buoyancy - if there’s too much or not enough buoyancy for the mass you’ve got then the vertical thrusters have to work really hard to move the ROV up/down.
Note also that your payload skid adds mass down low, which pulls down the CoM, so the thrusters contribute more of a torque. You can partly offset that by putting ballast weights up high (ideally above the thrusters), and/or putting buoyancy foam down low.
Active (thruster motion contribution factors)
It’s also possible to do active compensation if you have thrusters correctly oriented to negate a particular rotation direction, which is done automatically by ArduSub based on the stored frame configuration, which specifies factors for how much each thruster contributes to the ROV’s roll, pitch, yaw, throttle, forward, and lateral motion.
If you can accurately determine or estimate your CoM you could create a custom frame configuration with updated values so that ArduSub is at least aware that X forward motor has some pitch component, which may help with the automated control.
Note that the motors do have a full speed however, which from what I understand ArduSub doesn’t really know/care about, so if you’re driving your ROV hard then one or more motors can saturate (run at full speed) while others that partly contribute to the same motion aren’t yet, so trying to increase motion in that direction will increase the not-yet-saturated motor speeds but can’t increase the saturated ones, which means ArduSub’s understanding of the forces it’s applying isn’t correct, so the control doesn’t work as well. A similar discrepancy occurs for thrusters in their dead zone (attempted really slow movement that just doesn’t rotate the thruster), and it can also be worth noting that ArduSub doesn’t know about or intentionally compensate for vehicle or tether drag, which can sometimes be significant.
BlueROV2 Pitch Control
Unlike the heavy configuration, the standard BlueROV2 configuration has no pitch contributions from any of the thrusters because of how and where they’re oriented. The control issues stem from the difference between the forces ArduSub thinks it’s applying, based on its thruster contribution factors, and what it’s actually applying, based on the changed CoM and CoB of the ROV from the added payload, as discussed above
Accordingly, when it tries to go forwards there’s an unexpected pitch angle that it can’t do anything about. The pitch angle then means the forward thrusters are pointing slightly downwards and there’s additional drag on the top which both push the ROV down. ArduSub then reacts to the corresponding change in the measured depth by pushing back up, which incidentally causes steeper pitching because of the CoM being in front of the vertical thrusters. The ROV pressure sensor then gets to the desired depth, but with a steep pitch angle. At a steep enough pitch angle the CoB is in front of the CoM in the water, so causes a reverse pitching torque which brings the nose back up, and the cycle starts again.
Hey @EliotBR, thank you so much for the excellent detailed, yet understandable, explanation!
I wanted to share this paper from Georgia Tech that goes over the principles behind CoG and CoB for those who may need to develop/refresh their understanding of the topic. It’s a great read with a lot of information, but it’s presented in a very readable format that is easy to digest.
If you’ve got some kitchen scales available you could measure that more exactly by putting one under each corner of the ROV from the upright orientation and another measurement on its side, which can also be a good way of measuring CoM for your payload-added ROV without needing to put the material properties and whatnot into a CAD model.
Would you mind elaborating a little bit more on this experimental method for determining the CoM? I can visualize the process of weighing the ROV on 4 different scales from two different orientations, but I am lost at understanding what the next step would be from here.
I am also wondering if for practical purposes could we say that this point is the same as the CoG, for both above and below the water? I have a hunch that it is, but some confirmation would be great.
No problem, glad I could provide some helpful information, to you and anyone who comes after. No doubt we’ll end up refining it a bit and turning it into a guide on the main website so it’s easier for others to find later
Thanks for the share - good stuff. That goes quite nicely into the maths, which complements the more intuition-focused explanation I provided
You can use static analysis to determine the location of an equivalent point mass applied at the CoM, as below:
The object isn’t moving, so you know that all forces and moments/torques equate to zero. Taking the vertical forces due to gravity, with corresponding reaction forces,
\begin{align}
\Sigma F_v &= W - (R_1 + R_2)\\
0 &= W - (R_1 + R_2)\\
\rightarrow W &= R_1 + R_2
\end{align}
The same applies to the moment (rotational reaction), so considering the moment about point A,
\begin{align}
\Sigma M_{A\curvearrowleft} &= R_2 \cdot x - W \cdot x_{CoM}\\
0 &= R_2 \cdot x - W \cdot x_{CoM}\\
\rightarrow x_{CoM} &= x \cdot \frac{R_2}{W} \\
\therefore x_{CoM} &= x \cdot \frac{R_2}{R_1 + R_2}
\end{align}
Note that scales return mass rather than force, but if everything gets divided by a constant (earth’s gravity in this case) the relationships still hold.
As a couple of examples, consider the following cases:
For the uniform mass distribution you just end up with x_{CoM} = x/2 (which matches intuition), then in the uneven distribution case you get x_{CoM} = x \cdot \frac{50}{130}, so the CoM is 38.46% of the way across from the left.
One measurement with two scales constrains the CoM to a plane, so you can then rotate 90 degrees about each axis to get the other two planes, and the CoM is the point intersection of the three planes you determine. Alternatively you can do two measurements with four scales, and just pair up the scales for the calculations, and you should end up with redundant information for one axis (e.g. if you have scales S_1, S_2, S_3, S_4 in a rectangle you can take a measurement with the ROV sitting flat, then do R_1 = S_1 + S_2,\ R_2 = S_3 + S_4 for one axis, then R_1 = S_1 + S_4,\ R_2 = S_2 + S_3 for the second axis, then rotate the ROV from flat to lying on its side for the second measurement, and then you only need to do the missing axis (since one of them was done by the first measurement), or you can do the calculation anyway as a consistency check).
To anyone curious, CoG is the same as CoM when in a constant gravitational field, which we can definitely assume is the case of an ROV operating on earth. Significant differences only occur when the object of study is similar in scale to the source of the gravitational field, or if the object of study is between one or more gravitational sources with a similar influence at the object’s location.
To answer the question, water exerts pressure but that’s unrelated to CoG. The gravitational force can change somewhat if you get close enough to earth’s centre that there’s enough mass above that it, but given earth’s radius of ~6370km that’s not feasible in an ROV, particularly given the ocean’s deepest point is all of ~11km down. On top of that, ROVs are far too small and tightly bundled for the CoG to change much with respect to the CoM anyway, so yes, for practical purposes CoM and CoG are equivalent here
@EliotBR, thanks again for the excellent content! The scaling method makes a lot of sense. After doing a little bit of research myself, I came across another method for determining CoM/G, for the case that people do not have some scales handy. This method is used for finding the CoM of drones, but it should work great for the ROV as well.
I regularly determine the 3d centroid of UAVs (drones) in this way:
a) Find a container with flat, orthogonal faces (a box) that contains the object tightly
b) Pad the interior with tissue or styrofoam peanuts so that the object does not move
c) Use a wooden dowel as a fulcrum and balance the container
d) Mark the location of the dowel vs. the box face
e) Repeat for the other sides
f) the intersection of the planes marked on the container coincides with the mass centroid.
The mass of the container + peanuts should be small compared to the object to be measured.
Perhaps it will be possible to skip the step of packing the ROV into a box, assuming that all payloads are secured and that the body is sturdy (which should be the case).
I’m going to try out this method to see if I can get some decent results. I’m hoping that it should be somewhat in line with what you had mentioned earlier.
It may be helpful to assume the CoM is at the center point from the top view, and you can probably also assume the vertical component is roughly line with the horizontal thrusters.
I can share how my experience goes later on—cheers!
Nice! That should also work
The main differences would be that
the scale method gets the total mass as a side-product, which means when adding payloads you can calculate the new CoM if you have the CoM and mass of the payload as well (may be easier to measure than re-measuring the full CoM of ROV+payload, or if you don’t have access to them both at the same time), and if you’re able to determine the volume (with CAD or experimentally) then you can also determine if the ROV will float in fluid of a given density
finding a suitable box and obtaining enough packing peanuts for the balancing method may be a bit difficult for an ROV, as compared to a drone, although if the ROV has suitably flat faces you could potentially just balance it directly on a wooden dowel or other similar low round/pointed object (as you mention)
@EliotBR Thanks for the info! You’re a physics and engineering whiz.
BTW, I have another (somewhat related) question.
The Problem
When operating the ROV2 (payload skid + payload attached) in manual mode using the controller, attempting to move in a straight direction forward as one normally would results in the ROV2 tipping downward about 15 degrees. You can think of it as sort of diving down while trying to just move forward.
When operating the ROV2 in depth hold mode with this same setup, the ROV oscillates up and down a considerable amount in an attempt to stabilize itself. Think of it as a dolphin moving through the water.
After some thinking, with some colleagues a few minutes ago, it seems to us that the oscillation issue while moving can be attributed to two possible factors: force and/or drag. I have to admit that I have yet to do some research on this, but I was wondering if there are any telling symptoms for either (or both) of these two factors, and if so, if there are any fixes that could be made to mitigate the issue(s).
Off the top of my head (in no particular order—just brainstorming for now), I can think of a few questions that could be helpful to understand; perhaps I am missing or overlooking something, so please take these questions with a grain of salt, especially if you have a better understanding of this than I do (I’m and EE by trade). While the ROV is in motion…
How can we estimate CoB on the fly while the ROV is in motion?
What are signs of drag being a contribution to tilting?
What are signs of buoyancy being a contribution to tilting?
We are planning to take the ROV out to the water soon to try to fix our oscillation issues on the fly. We’re prepared to add a few weights to the ROV and to move the payload tube back/forth to try to help with balance, but at this point it seems to be more of a guessing game for us than anything else. I’m looking into seeing if there are ways to identify possible issues, and if there are potential solutions to mitigate them.
What do you think? Thanks again so much for your help so far. You’ve truly been making my life easier!
This seems reasonable given the components I discussed in my initial response. It’s a little difficult to decouple these experimentally, because you can’t really test force without drag (let me know if you can find a way to completely remove drag from an object in motion, would solve soo many aerodynamics problems… :-P), and it’s relatively difficult to test drag with a different force, especially since some of the drag may be from your tether.
Likely the best bets here are
determining the CoM, so you can see if the horizontal thruster plane is significantly above it (ie force is too high relative to CoM, in which case your options are removing mass below the horizontal thruster centres (e.g. reduce payload mass, or move it up), adding mass above the horizontal thruster centres (e.g. ballast), or moving the horizontal thrusters down), and/or
pushing the ROV by hand while disarmed and seeing if you can find the height at which you can push it at close to the desired speed but without it pitching, which sort of combines testing for CoM and drag together to determine the optimal horizontal force level, and/or
make the ROV go fast in a large enough body of water, and then stop exerting force and see if it stabilises with a non-zero pitch. This can give an estimate of drag contributions to the motion, but is likely difficult to get it going fast enough to see what you want for long enough - slow-mo footage might be helpful, or just going through a video frame-by-frame?
Depends. If it’s fully submerged then the CoB stays the same relative to the ROV. If you’re operating more like a boat, where it’s partially out of the water, then the CoB depends on which parts are under the water. If you’ve got a cad software that can calculate displaced volume then you could take a couple of planar cuts at different angles and see where the displaced volume of water matches the mass of the ROV to see how it would sit if constrained to that angle of pitch+roll, noting the stabilising counter-rotation that gravity would be exerting on the CoM.
I addressed this one in the passive rotation section of my first comment. If the ROV is tilting in the water without any thruster action then the buoyancy force is misaligned with the desired direction from the CoM - you generally want to design the CoB to be directly above the CoM, or perhaps slightly in front of it to counteract some drag force while in motion - depends on how you want to operate and how fine-grained your control over buoyancy and mass are in your ROV.
As mentioned in points 2 and 3 above, kind of hard to test in isolation, but if you can remove applied force while the ROV is in motion and see how much it’s pitched when it stabilises (while still going forwards) then you can get a sense of this. Likely the best approach to measuring drag is doing a CFD simulation over the profile of the ROV you’re using and seeing how much drag force there would be at a given velocity. You could also do a simpler equivalent(ish) by just projecting the design onto a plane, or taking a photo of the actual ROV (or just looking at it) and seeing where the cross-sectional area is concentrated. That doesn’t help much with estimating tether drag, but unless you have a really long or fat tether then that’s likely not too much of an issue starting out (although it definitely is a relevant consideration in high-performance situations).
Without good tools for this, or a very strong intuition of the forces at play and the components of the device your working with (with respect to mass distribution) it’s definitely a decent amount of trial and error. If you’ve got a very well-representative model in CAD and some decent software for analysing modifications then that can significantly simplify and speed up the process, but beyond a domain-specific iterative solver the best both software and intuition can give you are recommendations for what you likely need more or less of, and where it would help most, which are just ways to be a bit more efficient in the trial and error process. I discussed some of that intuition in my original section on passive compensation.
It’s also understandably beneficial/helpful to have good alignment between your control software and the reality of the product, particularly with respect to things like the thruster motion contributions, but I’ve already covered that and provided a couple of links in my original active compensation section.
Incidentally I’m currently working on an analysis/design tool to help with this kind of thing, but that’s in my own time and it’s understandably relatively complicated to set up so that it’s easy to use and rapidly iterate/tune while still being accurate, so I’m not expecting that to be available until closer to the end of the year, if then.
Glad to be of help
Thanks for the interesting questions. Part of the point of this forum is building up a bank of the relevant domain knowledge, for using our equipment but also just for underwater robotics in general - it’s always good to be contributing to that. Part of my role is to make it more functional in that capacity, and high information density posts like this are really useful for that, along with the work we’re doing on improving the searchability and navigability of the forum and our docs and website.
Not much point making awesome products if no one can use them, and we’re very much trying to make it easier for people to do interesting and high-level projects rather than having to focus on every little detail, like waterproofing a container or making thrusters that work well underwater
Hi @EliotBR , do you have any pictures or examples of CM distribution, weights/buoyancy configuration, or compensation in such cases?
I am striving for minimal passive stability on a BR2 Heavy (without the payload skid) to navigate effectively in a 6-DOF environment, maintaining a specific roll/pitch attitude without excessive power consumption from the thrusters constantly countering passive stability during rolls and/or pitches.
Many Thanks for contributing all this @EliotBR The math is beyond me but often good to know what you don’t know.
I can’t believe how lucky I’ve been to customize by BlueRov heavy (sonar/dive lights/unusual gripper arm placement etc) and haven’t experience any oscillations described above - flies like an arrow. I did make sure that its sits perfectly balanced in the water (almost) so not sure if that’s why.
One thing I’d like to know is how to fly at a constant depth/level when the ROV has a negative or positive pitch?
Not sure this is possible without continuous manual adjustment of the controls but be good to know.
I think Depth Hold/Stablize mode zeros the pitch settings or results in excessive vibrations when using forward thrust.
I’m afraid not, but it’s worth noting that the distribution is very dependent on the weights and volumes involved, so a lightweight or buoyant payload on the skid could have little effect (excluding drag), whereas a (net) heavy payload would increase the propensity for the vehicle to act like a pendulum, if the CoM is pulled quite far below the CoB.
If you have specific requirements then it’s generally necessary to tune for your specific setup, although for common setups it would definitely be nice if we had a configuration model available or something with the weights and densities built in. I’ve spent very little time on the analysis/design tool I mentioned earlier, so unfortunately that’s not close to being available yet, although it is still a long term project since I think it would be really useful.
@williangalvani is the most likely to know about the current state of this, and whether there are any issues or tricks to doing so effectively at the moment.
I do recall that there’s been some discussion on whether pilot inputs should be in the vehicle’s frame (e.g. forwards is vehicle forwards, so if it’s pitched downward then forward moves downward, which then changes the depth hold target) or earth frame (e.g. forwards is horizontally forwards, regardless of orientation). My recollection is we decided the operator should be able to choose, but I can’t remember whether that’s been implemented or if it’s still ongoing.
Thanks Eliot, be really interested in learning more about whether there is anyway of implementing an ‘earth frame’ mode in BlueOS. I guess this may not be straight forward - particularly given the buoyancy/balance issues you detail above but would significantly enhance the operation of the BlueROV.
Also I noticed that ardusub (ardupilot?) already has a ‘terrain following’ function that seems to provide the ability to ‘fly’ at a constant altitude. Wonder how difficult this would be to implement in BlueOS for vehicles fitted with a Ping Sonar (@williangalvani)?
Being able to fly at constant distance from the sea floor rather than the surface (as for ‘Depth Mode’ currently) seems more optimal for the kinds of tasks people would use a submersible drone for and presumably a bit easier to implement in BlueOS rather a more comprehensive ‘earth frame’ mode?
BlueOS is onboard computer software, that runs on the Raspberry Pi in the vehicle
It’s used for passing MAVLink telemetry between the control station (/topside) and the flight controller, and handling of advanced sensors that the autopilot doesn’t need to know about (e.g. the video stream from a camera, and the sonar scans from a Ping360)
ArduSub is the autopilot firmware we use to run our flight controllers (previously Pixhawk, currently Navigator)
It’s the submarine variant of the ArduPilot family of autopilot firmwares
The vehicle’s control algorithms are implemented here, and are unrelated to BlueOS
Cockpit (and QGroundControl) are control station softwares that run on a control station computer (often called the “topside computer” in submarine applications)
This is the software that converts operator input from clicks and joysticks/gamepads into commands that can be sent to the autopilot and/or onboard computer as relevant
It’s also in charge of displaying video streams and telemetry to the operator
There are some parameters for terrain following but as I understand it they’re effectively “left over” from when ArduSub was split off from ArduCopter. That said, a new surface tracking mode was very recently merged into ArduSub’s development branch, which is intended for precisely what you’re asking about (maintaining a fixed altitude relative to rangefinder estimates from sensors like a Ping Sonar or a DVL).
If you’d like to try it out you may be able to by installing the Dev release of ArduSub, but be aware that dev is quite unstable, especially since we’re aiming to bring ArduSub up to date with the other firmware variants (which will involve skipping several versions at once: 4.1 → 4.5). I’m also not sure whether Cockpit or QGroundControl know about that new mode yet, so enabling it may require manual MAVLink commands at this stage.
The math is beyond me but often good to know what you don’t know.