We’ve observed a repeatable behavior with our ROV; I have a patch to ArduSub which appears to be effective but before I spin up the Github side of things I thought I’d check with the community.
Our BlueROV2 Heavy is running BlueOS-1.4 with Ardupilot 4.5.7 (also tested with 4.5.5). Under a very specific set of circumstances:
Vehicle in the water, armed, running in alt hold
Disarm vehicle
Set to manual mode
Arm vehicle (now in manual mode)
Set to alt hold mode
The vehicle will descend suddenly by ~1m, then stabilize at a depth slightly below its original depth. The second and third steps are interchangeable (manual then disarm or disarm then manual).
I believe it is due to this line in Arudpilot mode_manual.cpp:
Hi @amarburg -
To clarify - the vehicle is at depth, say 1m, in alt_hold, and you disarm it. It floats to the surface of the tank, and then you put it in manual mode. When you arm, it is expected that the vehicle will descend to the last depth is was in alt_hold - so I don’t think you’re experiencing anything unusual?
If nothing else, code from the manual control mode is unlikely to be related to behavior in alt_hold mode…
Typically, manual mode is not used at all in the field, and users switch between stabilize and alt_hold, depending on their activity. In manual mode, the vehicle is very hard to drive - I only use it to check motor function before launch!
By BlueOS 1.4, I hope you mean the latest stable, 1.4.2 !
This would all be happening at depth. The amount/direction of vehicle drift while disarmed seems not to affect the behavior.
The expectation is that the manual → alt_hold transition would cause the vehicle to hold at its current depth and heading at the time of the mode transition (as per usual).
We initially noticed it when an unrelated comms issue was triggering the user input timeout, causing unplanned disarmaments while in the water; and we ocassionally needed the vehicle to go “fully idle” in the water, which was why we were using manual mode.
It’s a bit hard to interpret, but here’s one such event in the log viewer:
Red is depth, blue is Servo5. While disarmed, and then once re-armed in Manual, the depth continues to “drift” slightly downward (as expected) – the joysticks are kept neutral throughout. When switched to alt_hold, it immediately drives full down throttle and the vehicle dives ~0.7m. In this case we popped back to manual control, but given time, alt_hold would recover and stabilize at about 2.5-2.6m depth (slightly below where the vehicle was when alt_hold was initiated).
Orange and green are the “CTUN.ThrottleIn” and “CTUN.ThrottleOut” values (with green being offset by 1 to separate the lines).
Those Throttle* values do not impact the motor output when in Manual control. When it switches to ALT_HOLD, the throttle value starts from a value of 0 (full down), and it takes multiple cycles for the control loop in alt_hold to “wind” it back to a more reasonable values around 0.5.
Here’s the logfile (it’s quite short) 00000039.BIN (779.9 KB)
We’ve had limited opportunity to test with other ROVs. I’d like to see the problem replicated, and get some hours on the proposed patch to Ardupilot before we finalize the solution.
