Depth Hold Problems?

Hi, we experienced exactly this issue last time when testing with the BlueROV using companion 0.0.26 and ardusub 4.0.3 .
Which software versions are now the recommended ones?

As you can see, I have confirmed that the “ardusub-402-depth-hold-fix” does solve my problem.
https://s3-us-west-1.amazonaws.com/ardusub.bluerobotics.com/test-builds/ardusub-402-depth-hold-fix.apj

But I have also personally upgraded my BlueROV2 to 4.0.3 and 0.0.26 and it made it unusable and the companion computer ping was around 500ms: Low Network Transfers, ROV unusable I was hoping that it was just an minor configuration issue on my part, but if you have also experienced the issue, then maybe it wasn’t an isolated incident on my hardware on my part. I would personally recommend 0.0.25 and ardusub-402-depth-hold-fix,apj since that I what I was running before everything went south.

1 Like

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.

@williangalvani

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

Hi,

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.

Thanks!

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.