Depth Hold Problems?

Hello, we’ve tested with 0.0.25 and ardusub-402-depth-hold-fix and versions but the vehicle still goes for a unwanted deep dive!

We figured that this most often reproducible when arming first into manual or stabilize mode and then switching to depth hold mode.
So as a workaround we had to switch first into depth hold mode before arming the vehicle.

Here you can find an example of how the signal logs look like for such an incident:
According to ardupilot/LogStructure.h at Sub-4.1 · ArduPilot/ardupilot · GitHub
pida target refers to the depth/altitude setpoint of the PID Controlller. The unit of this variable was not given in the documentation. However, those peaks seem not to be desired.

That is weird. I haven’t had a single occurrence since I switched to “ardusub-402-depth-hold-fix”. Have you tried 4.0.3? It’s supposed to also include the depth-hold-fix and maybe it will fix your problem somehow.

Yeah, before that I actually used ArduSub 4.0.3 with companion 0.0.26, where this problem occured for the first time.


Here is another scene, where it can be seen that the integrator of the depth controller winds up just before we switched into depth hold mode from some other mode (ROV already armed).

I took a quick look into the last commits. I guess that the proposed depth-hold fix was pos_control.relax_alt_hold_controllers();,which was
added in control_althold.cpp:19

However, it seems that this function does not reset the integrator term of the PID controller.

Also, I am wondering why should the depth hold integrator be running in the background in modes other than depth-hold (where it just winds up without being added to the control output). In addition to a reset of the integral term at init() of depth hold mode, I propose to deactivate the calculation of the integral term during other modes if possible.

Hi @cbusse1 ,

Thank you for your investigation! Did you actually try any of these changes?

The integrator reset was removed to fix the depth hold bounce-back issue: AC_PosControl_Sub: do not reset accel_z integrator when relaxing by Williangalvani · Pull Request #12952 · ArduPilot/ardupilot · GitHub

Apparently it resulted is this other issue. The integrator shouldn’t be touched in manual/stabilize, which is why I suspect this is to blame:

This is called every time the controller is initialized, which includes mode changes.

Do you still have the .bin log for these plots? I’m wondering if the mode change coincides with the jump in the integrator.

1 Like

@williangalvani can you please confirm what logs you’re after?
@Ryan6419 is now also having this issue, as brought up here.

1 Like


We need the dataflash logs of a dive where the issue happened.

1 Like

I also encountered this problem when training customers on ROV operation. For this reason, I modified the firmware to 3.5.4

Hello everyone, sorry for my late response.

I have just sent Willian the log file via PM.

Here is the plot from the second scene again but now with the mode signal included. Maybe someone can tell how the mode values (0,2) relate to the control modes of the ROV.

Cool, thanks for sending that through :slight_smile:

They’re defined here in the code (0 → stabilize, 2 → depth hold), but you can also check the ‘custom_mode’ portion of the HEARTBEAT message in a MAVLink inspector (e.g. you can look at the value live in QGC while changing the mode)

@EliotBR was this issue fixed? If so is it on the Ardusub or companion side?

I just tested exactly the same config as Chris (ArduSub 4.0.3 and companion 0.0.26) and got the same behavior. I plan on updating companion but wanted to verify that this should fix it.


Hi @Jake,

It’s a control issue, so is unrelated to Companion.

From what I recall the behaviour shouldn’t be present in ArduSub >= 4.1, but it’s very possible I’m mis-remembering, so I’ve asked internally and will confirm.

In terms of releases, 4.0.3 is still our current stable release (hasn’t changed, so behaviour will still be there), although we’re moving towards 4.1 (the current Beta release). ArduSub development of late has been held back behind BlueOS Beta and some other critical development, although the load from that is now starting to reduce again slightly, so more regular ArduSub changes/updates should start coming through again soon.

In terms of updating, while this particular issue isn’t related to Companion we would still recommend updating your Companion software, to make use of and benefit from the bug fixes and performance improvements that have been introduced between 0.0.26 and 0.0.31.

If you’ve got some testing capacity you’re welcome to try out the ArduSub Beta (4.1) release (and BlueOS for that matter), but as with any beta software I can’t recommend it be used in critical/high stakes applications.

@EliotBR understood. I think I will downgrade ArduSub, could you recommend a version? I’m just looking to have normal behavior in depth hold and stabilize flight modes.

I looked into @williangalvani’s earlier comment, and it seems like what he thought was the potential cause may not even be in ArduSub stable, so it’s unclear to us what the actual source of the issue is.

I spoke to Willian earlier today, and he expects that the 3.5 versions are unlikely to have the issue, so maybe try one of them :slight_smile:

@EliotBR was this bug ever resolved? We downgraded our ArduSub version, but you know that’s not ideal.

Hi @Jake,

It should be fixed in ArduSub 4.1.0, which is the latest stable version :slight_smile:

@Jake I don’t remember experiencing it since the last time I posted here, so I would consider it fixed.

Hi guys!
I’m trying to use my BlueRov2, which was out of use for over two years. It’s still a great vehicle, but when I change to stabilization or auto depth modes, it seems like all the thrusters go into high RPM, and the ROV goes completely crazy. I have had this problem since I first used it (in 2018), but I haven’t fixed it before. I would be grateful if someone could help me fix this problem and tell me what updates I should make to have everything working the best way.
Thanks in advance.

Hi @Gleiber,

I’ve moved your post here because it seems to be on the same topic. As above, this should be fixed in ArduSub 4.1.0. I would recommend updating to that, as well as our other latest recommended software versions. You may also wish to check out BlueOS :slight_smile: