Home        Store        Learn        Blog

ROV2 Dives Downward with Payload Skid + 4" Enclosure

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:
    1. An approximately 250g circuit
    2. A 1152g BlueRobotics Lithium Ion 14.8V battery

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.

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!

Hi @lecheboludo, welcome to the forum! :slight_smile:

Undesired Rotation

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
image

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 :slight_smile:

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.

1 Like