We have a BlueROV2 Heavy R3 with an RPi 3B and Pixhawk, running ArduSub 4.1.0. Recently, we replaced the Bar30 (R1) sensor with a new Bar30. Since we didn’t have an adapter available, we cut off the JST GH connector and soldered on the DF13 connector. The depth readings appear to be accurate.
However, after replacing the sensor, the behavior of the Depth Hold Mode has changed. We can no longer adjust the depth by pressing the throttle stick. Instead, the ROV maintains the depth at which the Depth Hold Mode was activated. To change the depth, we have to switch to a different mode, go to the required depth, and then engage the Depth Hold again. We did not modify any ArduSub parameters or firmware after replacing the sensor.
Do you have any idea what might be causing this issue?
The depth sensor is only used for feedback about the current depth - it has no other influence on the autopilot’s behaviour or what kinds of control inputs the autopilot accepts.
I expect there’s some kind of issue with your ArduSub version, or (unlikely) the software you’re using to send control commands to ArduSub. I’m not aware of any parameters that disallow vertical adjustment commands while in depth mode.
Assuming you’re using BlueOS, I’d recommend saving/downloading your current parameters from the Autopilot Parameters page (just in case you want to revert to them), then loading the default parameters from the Configure section of the Vehicle Setup page, and if that doesn’t help then try flashing on the latest stable (4.1.2) or beta (4.5.0) firmware.
Note that there have been some stability updates to the firmware flashing process in recent BlueOS 1.3 beta images, so you might want to install the latest BlueOS beta version before flashing on a new Pixhawk firmware (you’ll need to turn on Pirate Mode to be able to see the beta versions in the BlueOS Version page).
Thank you for your response. We initially tried upgrading the firmware, but that did not resolve the issue. Fortunately, loading the default parameters worked. It seems the problem was related to the parameters after all. We now consider this issue resolved!