ROV barrel rolling in Stabalise/Depth hold mode

We had an issue where the ROV will start doing barrel rolls when in depth hold mode, we don’t have any errors on the screen but when reverting it to manual mode the altimeter keeps spinning so I’m assuming that in the auto-modes its trying to compensate for this.

It first happened last summer but since then we’ve cleaned and repaired the thrusters and reinstalled all the software and it seems to have been fine since then but on the 2nd dive today it started spinning again

has anyone got any suggestions on whats wrong or how to fix it?

This happened to me a couple times out the blue. Do the auto direction test in the water, this worked for me.


I spoke with our software team about this, and we expect this could have occurred if the gyroscope was calibrated while the vehicle was moving / on a boat. Are you able to check the INS_GYR_CAL parameter value in QGroundControl? It should be set to 0 (‘never’), but may be set to 1 (‘start up only’) in which case it automatically tries to calibrate the gyroscope when the vehicle is turned on, which could result in a calibration with a large bias.

That said, it’s still quite unusual that the gyroscope calibration bias could be large enough to overpower the accelerometer values. It would be useful if you’re able to provide a log file of when it was happening. A DataFlash log would be preferred if possible, but a Telemetry log should still provide some level of insight.

It’s worth noting that QGC >= 4.1 allows manually calibrating the gyroscope from the Sensors page, which should fix the issue if it’s done while the vehicle is sitting still on the ground :slight_smile:

The Automatic Motor Direction Detection could solve a similar symptom if one or more of the thrusters have their directions reversed, although that’s a different underlying cause, and wouldn’t be expected to have the attitude indicator constantly spinning while the vehicle is still.

I’ve checked the INS_GYR_CAL and can confirm its set to 0, (we launched from the land as well) and this was the 2nd dive of the day and half way through the dive it started this time.

the log for the dive is here:

it seems to show it all goign wrong at about 15mins into the dive, the ROV itself settled down and was fine in manual mode but the log still shows it as spinning as well

1 Like



We looked into this, and found that there’s a point where one of the x-axis gyroscopes very suddenly diverges from the other, after which they maintain a constant offset, and stabilisation stops working properly

It’s quite unexpected, particularly since it’s not at a mode change or anything, where it’s more feasible that a bug could occur in some parameter resetting or whatnot - this seems to have been completely random. The other sensors and the other axes of that gyroscope seem to be unaffected, and if it weren’t for the vehicle being quite deep underwater at the time we might suspect it was from a cosmic-ray-induced bit-flip or something.

@williangalvani mentioned he’ll bring this up with some of the other ArduPilot developers, in case they’ve got ideas about what might have gone wrong :slight_smile:

Bug or otherwise, doing a manual gyroscope calibration should revert the issue, although understandably that may be a little challenging while the vehicle is in the water and far from stable land.

1 Like

I have had the same thing happen for the first time four weeks ago.

In each case powering up the ROV shows a calibrated and sensible artificial horizon, and compass in QGroundControl, flight mode. After power up, and sometime after arming, the AH, and Compass “spin”

First time that happened, we retrieved the ROV and recalibrated on dry land. The second time was on a boat in a seaway, so no chance of recalibration.
Third time was on the test bench.

I’ll endeavour to post log files.

I should add, we have had nothing but flawless performance beforehand.

Following up on this, the response we got was

Accordingly there’s unfortunately not much we can do to actually fix the issue if/once it occurs.

If this has happened to you I’d recommend contacting and providing a link to this post to let them know what’s gone wrong, along with the order number / when you purchased the board. That’s useful for us to understand how often this kind of thing is occurring and whether it’s from a particular batch, and we may also be able to provide a replacement.

Noting Eliot’s solution,
prior to the fault, we did note increasing numbers of IMU reset messages while operating, to no ill effect.


Thanks for the extra info @Dale_A :slight_smile: