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.
@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.
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.
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.
@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)
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?
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.
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.
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.
