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 
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
@EliotBR was this bug ever resolved? We downgraded our ArduSub version, but you know that’s not ideal.
@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
I encountered a similar issue and would be curious to know if this helps anyone else.
- Changing to depth hold mode caused the vehicle to engage the vertical (I’m assuming Z axis) thrusters at maximum speed and cause the vehicle to dive and continue diving until it reached the bottom.
- Changing to stablize mode caused the vehicle to attempt to roll 360 degrees in the pitch/roll axes.
Environment:
Board name: Navigator
Manufacturer: Blue Robotics
Mavlink platform: navigator
Firmware version: 4.1.0 (STABLE)
Vehicle type: Submarine
After taking some time to debug the issue, I discovered that this behaviour occurs for me when performing the following steps:
- Open QGroundControl and connect to the vehicle
- Change flight mode to manual
- Arm vehicle
- Pilot vehicle around normally with joystick
- Change flight mode to depth hold
- Vehicle immediately dives with maximum Z thrusters
- Change flight mode to manual
- Pilot vehicle around normally
- Change flight mode to stabilize
- Vehicle immediately attempts to pitch/roll 360 degrees
The behaviour does not occur, however, if the following steps are performed:
- Open QGroundControl and connect to the vehicle
- Change flight mode to depth hold
- Arm vehicle
- Pilot vehicle around normally with depth hold
- Change flight mode to manual
- Pilot vehicle around normally with joystick
- Change flight mode to stabilize
- Pilot vehicle around normally with stabilize
- Repeat
Thus, from my limited experience: it appears to be an issue with selecting manual mode as the first mode, arming, and then attempting to transition to other flight modes. As long as selected depth hold first and then armed, everything worked as expected, and I could freely transition between manual/stabilize/depth hold.
Hi @oneironautics,
I believe this issue should be fixed in the latest 4.1 beta
If you try it out and find the problem still occurs, please let us know (and ideally provide an autopilot log).
That’s generally an issue caused by misconfigured thrusters, or a bad sensor calibration.
Given it apparently isn’t every time you go into stabilize, then most likely it’s not a thruster configuration issue.
It’s possible that issue will fix itself when you update, but if it doesn’t please run the accelerometer and gyroscope calibrations, making sure that the autopilot orientation is set to Roll90 (for BlueROV2 vehicles, at least), and that after the calibration the artificial horizon in QGC’s attitude widget is steady (not spinning), and blue (sky) is on top, above green (ground).
If the gyroscope calibrates while the vehicle is moving (e.g. on a boat/floating jetty, rather than stable ground) the EKF can end up getting dizzy and being unable to properly estimate the vehicle attitude. It’s possible your INS_GYR_CAL parameter is set to calibrate on startup (1), in which case please set it to never (0), in which case it will only calibrate when you do so manually.
If the issue persists on ArduSub 4.1 beta, and after a good sensor calibration, then please provide an autopilot log so we can try to figure out what’s going on