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