Abnormal depth_holde mode

Blue Robotics Software
1

Hi.

Im having trouble with depth hold mode that the ROV just want to go down on full speed. If I take first in stabilize than depth_hold everything works fine. I have testet this on two ROV with the same result.

Someone else that have the same issue?

Im running the latest software of ardusub, companion and QGC.

1 Like
2

Hi,
Exactly the same problem as you with the latest updates, I’m waiting for the correction …

3

Hi, do you mind running some tests and sharing the dataflash logs?
Do the following:

First test:

  1. Turn on ROV, put it in the water (preferably slightly positively buoyant at the surface)
  2. Engage depth hold
  3. Arm
  4. wait until things stabilize to disarm (or earlier if you think it is unsafe).

Second test:

  1. Turn on ROV, put it in the water (preferably slightly positively buoyant at the surface)
  2. Engage stabilize
  3. Arm
  4. Engage depth hold
  5. Wait a few seconds
  6. Disarm

Third test:

  1. Turn on ROV, put it in the water (preferably slightly positively buoyant at the surface)
  2. Engage manual mode
  3. Arm
  4. Engage depth hold
  5. Wait a few seconds
  6. Disarm

That would help a lot at diagnosing the issue.

1 Like
4

I didnt get the behavior I expected. I thought the third test was gonna trigger that behavior. I can see that the rov going a bit down before it stabalize in depth. But if I change back to manual, and than to depth hold it stabalize right away. Our test tank is 1m deep.

I can say that the ROV frame is somthing we have build on our own and not 100% level on manual mode, but the electronic is all Blue Robotics.

We have some other deeper testtanks that i can test the BlueRov, but that have develope 4.1.0 with DVL software on.

But here is the bin files, plus I got an depth-sensor error in the end. But the ROV seems fine in depth hold mode. Im gonna give you the Bin files if I see the described behavior.

log01-first-test.bin (488.1 KB) log02-second-test.bin (384.1 KB) log03-third-test.bin (535.6 KB) log04-depth-sensor-error.bin (52.6 KB)

5

I couldn’t find anything outstanding. Please let us know if you find a consistent way to reproduce this issue.

There are two factors at play there. First , the depth target is set to SURFACE_DEPTH - 5cm to avoid sucking in air, this triggers the short dive it does when engaging Depth Hold at the surface. Secondly, there is also some overshoot (only 3cm in your case) that seems to be related to PSC_ACCZ_I and PSC_ACCZ_IMAX, but you shouldn’t worry about this one.

Please check the wiring for the Bar30, maybe move it away from other wires, I²C can be pretty sensitive to noise and running on long wires.

6

Thanks for the information. Im gonna let you know if I find a consistent way to reproduce this problem.

Mby @JeanBenoit have some more information?

Why isnt the cable shield on depth sensor?

7

No information…

8

Hi, I have had this happen to me randomly as well. It only really happens if I’m close to the surface when I engage depth hold. I now just either engage depth hold. The vehicle will dive down fast. I go back to manual and back to depth hold and all is good. Or , I dive in manual deeper. Engage depth hold then reduce depth in depth hold .

1 Like
9

We had a similar problem. The problem was caused by the depth/pressure sensor giving incorrect data.

2 Likes