Depth Hold Problems?

I also encountered this problem when training customers on ROV operation. For this reason, I modified the firmware to 3.5.4

Hello everyone, sorry for my late response.

I have just sent Willian the log file via PM.

Here is the plot from the second scene again but now with the mode signal included. Maybe someone can tell how the mode values (0,2) relate to the control modes of the ROV.

Cool, thanks for sending that through :slight_smile:

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)

@EliotBR was this issue fixed? If so is it on the Ardusub or companion side?

I just tested exactly the same config as Chris (ArduSub 4.0.3 and companion 0.0.26) and got the same behavior. I plan on updating companion but wanted to verify that this should fix it.

Thanks!

Hi @Jake,

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.

@EliotBR understood. I think I will downgrade ArduSub, could you recommend a version? I’m just looking to have normal behavior in depth hold and stabilize flight modes.

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 :slight_smile:

@EliotBR was this bug ever resolved? We downgraded our ArduSub version, but you know that’s not ideal.

Hi @Jake,

It should be fixed in ArduSub 4.1.0, which is the latest stable version :slight_smile:

@Jake I don’t remember experiencing it since the last time I posted here, so I would consider it fixed.

Hi guys!
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.

Hi @Gleiber,

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 :slight_smile: