Depth Hold Problems?

Has anyone else experienced problems with the Depth Hold autopilot where it just fires the downward thrusters at full power when the Depth Hold is engaged? It’s happened to me 3 times now, 2 times in a row last November and once again today. The weird thing is that is works exactly as expected except for those 3 specific times.

The first clip I was accidentally flying in Stabilized mode and the problem happened the moment I switched to Depth Hold. I then disarmed the thrusters, and then the problem repeated itself as soon as I tried Depth Hold again.

The second clip is the start of the dive. I flew it manually away from shore a few feet and then the problem happened exactly the same as the other 2 times. I then disarmed the thrusters as usual, but then Depth Hold worked as expected for the rest of the dive.

2 Likes

Hi @btrue !

Thank you for sharing your dives!

I believe the depth-hold issue is caused by the I-term of the depth-hold not being reset when switching into it from stabilize (and other modes).

I made a test build to fix it, you cant try it here. Please let me know if this fixes the issue so we can put out a 4.0.3 release.

1 Like

@williangalvani Thanks for the super fast support!
Is there anything I can do to ‘force’ the issue to happen when flying to make sure that it’s the cause? Should I try to compare the old and new versions to see if it’s the fix, or just use the new version and see if the problem disappears? It’s a intermittent problem for me right now so it might be hard to tell if it’s really fixed, though it only happened when Depth Hold is engaged, so I can try switching between Stabilized and Depth hold every minute or 2 and see what happens.

Edit: What do I do with the .apj file?

Hi. To flash the .apj file, navigate to http://192.168.2.2:2770/system
and click “choose file”.
image

I was able to replicate the issue by going into depth hold, switching to stabilize, going up or down to change depth, and switching back into depth hold.

@williangalvani I tried the test build today and there was no sign of the problem, so far it’s looking like it’s fixed. Was this a known issue or was I the first person to mention it? It seems like other people should have experienced it before I did.

We had this problem before, but we was not able to track down the issue.

Yes, we had reports of it but we were unable to replicate it properly to narrow down the issue. When you reported it, I gave it another try and managed to track it down.

Hi,
how did you record the thruster sounds?
Chris

@schleitauche It’s the audio from the GoPro Hero 4 Silver mounted on the front (shown as the top left part of the video). Right now I sync the videos for the GoPro and the ROV stream with my phone camera flash as shown in the bottom picture at: Soap Lake, WA 1/29/2021 (Shallow Dive)

A Gopro, I thought as much. That makes videos some more interesting. Thanks! :+1:

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