Home        Store        Learn        Blog

Slow rotation around z axis even staying on a table


I’ve noticed that even if Brov2 is staying on my table it “rotates” around z axis. Here is a graph of our last dive:

I’m pretty sure robot was all the time perpendicular to the flat wall. But, as you see, it recognizes itself as a slowly spinning being :slight_smile:

  1. All calibrations are successful (green), magnetometer readings are good.
  2. EKF flags for attitude is good all the time.
  3. Stock firmware.

I’d be so grateful if anybody suggests what can cause such a weird behavior!

BR, Alex

Hi @slovak194,

Can you set the default parameters ?
You can check how here: https://www.ardusub.com/operators-manual/parameters.html

Hi, Patrick!

Thanks for the suggestion, but it seems to be no such option in QGcontrol (https://github.com/mavlink/qgroundcontrol/issues/7299). Is there another way to reset parameters to their default values?
I’ve used ardupilot/Tools/Frame_params/Sub/bluerov2-heavy-3_5_2.params from the ardupilot repository to do the test:

  1. Flash Sub 3.6 firmware.
  2. Load parameters from file.
  3. Reboot vehicle (on my table)
  4. Wait for the EKF to init.
  5. Rotate vehicle just a little.

As you see, there is a long drift heading even if the vehicle is staying still. Magnetometer readings are perfectly flat with no slope. But yaw is drifting significantly. Please, suggest how to deal with that. Many thanks!

Similar issue is reported here: Yaw Drift due to increase of EKF_GYRO_BIAS estimation with no answer.

BR, Alex

I don’t see where you have calibrated the sensors anywhere here. Don’t load parameters from a file. To reset the parameters to defaults, set the SYSID_SW_MREV parameter to 255 then reboot. Then perform a calibration and take note of the compass considerations.

Jacob, many thanks for such a fast answer!

I don’t see where you have calibrated the sensors anywhere here.

I’ve done this dozen of times before, with “green” result. But this makes logs looks like in my initial message.

Will do that again, it becomes important for our task now.

Thank you again!


What are the units on the time/X-axis in your plots with the long-term drift?

Horizontal axis is in data points. Vertical - angle in degrees.
Here is the same flight data plotted in seconds and radians for convenience:


OK, just wanted to make sure about the X-axis value, because it looked about right for one rotation per day if it was in seconds :joy:

I don’t expect the Earth’s rotation to show up compared to gyro drift in low-cost IMUs (and I’d expect it to show up in a couple axes unless you’re at the north or south pole) but I just wanted to check.

Hi, @jwalser !

I’ve spent a nice time outside the office today calibrating Bluerov2 as you have suggested. Here is the list of steps I’ve performed:

  1. Drive to the parking lot really far from the buildings, power lines, anything.
  2. Build and flash Sub-3.6 firmware.
  3. Set SYSID_SW_MREV parameter to 255, reboot.
  4. Wait 10+ minutes to warm up.
  5. Calibrate accelerometer - green, reboot.
  6. Calibrate compass - green, reboot.
  7. Check if drift is still there - yes, it is.
  8. Repeat steps 2-7 for the Sub-4.0.beta
  9. Check if drift is still there - yes, it is.

In every experiment, I’ve started with a robot staying still on the ground. I’ve rotated it several times by 90 and 45 degrees with the intention to achieve a stairs-like yaw response.

Before any movement, it looks like everything is good. But when I rotate the robot - there is a visible overshoot in the heading. And it seems that EKF is trying to compensate this overshoot. I think that the problem with gyros, not the compass. Or how data from gyros being used by EKF.

Here is the raw data form the compass. LGTM.

And this is the yaw in the Attitude message.

There are more screenshots down here, but all of them show us the same trend - any change to the robot attitude causes an overshoot and drift in yaw.

Please, give your opinion on that and I will put all my effort to solve this issue asap.

PS1: I’ve noticed that even if INS_GYR_CAL is set to “never” as suggested in “compass considerations” - gyro calibration is still performed and corresponding parameters are changed: INS_GYROFFS_(X, Y, Z)
Is it expected behavior?

Best regards,

  1. Please do not use sub3.6: it is not supported, and never will be (I failed to mention this before, sorry)
  2. Use Sub3.5.4 (stable) or the sub 4.0-beta.
  3. Let me know your results with those softwares
  4. Compare the results with Sub to the results with stable Plane firmware
  5. There is some mesh in the ground where you are. It looks like plastic, make sure it is not ferrous. As you mentioned, the raw data is ok so it indicates some problem with the filtering.

PS1: I’ve noticed that even if INS_GYR_CAL is set to “never” as suggested in “compass considerations” - gyro calibration is still performed and corresponding parameters are changed: INS_GYROFFS_(X, Y, Z)
Is it expected behavior?

Please clarify the gyro calibration is performed only when you do the calibration sequence in QGC? This parameter controls the gyro calibration behavior AT BOOT. Setting this to never prevents the gyro from automatically recalibrating at boot (it wouldn’t be good with the rocking motion of the ocean).

It looks like you are having a lot of trouble with this, whereas it is usually not a problem for our other customers. I’m sorry to hear this, but I appreciate your helping us to work through the problem. I assure you that we will resolve it in the end. If you need to operate, my best recommendation right now is to use our stable 3.5.4 software and default parameters.

Hi, @jwalser!
Many thanks for you suggestions!
I’ve tried enormous amount of options and combinations. It seems to be I even enlarged my muscle mass doing compass calibration over and over. I’ve made a rig to make it easier, with no luck.

I was not able to find a correlation between spinning around vertical axes and any of the options I’ve tried. Sometime it is spinning, sometimes it does not. I do not have much time to dig into the EKF implementation in Ardusub, but it looks that without GPS correction it simply cannot provide stable solution.

It is very sad to admit that I’ve gave up.

The only solution I’ve found is to install separate IMU (~200$) unit into the robot which shows no drift in the same situation Pixhawk is spinning around.

Oleksandr Slovak

Is one of those Pixhawk 2.4.8s installed in your BlueROV2? If it is, that is probably your problem. The 2.4.8 is notoriously bad and I have seen similar issues with that board on the ArduPilot forums: External IMU configuration

The Pixhawks from our store are the closest we could find to the original 3DR 2.4.6 Pixhawks.