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!
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.
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
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.
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.
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?
Please do not use sub3.6: it is not supported, and never will be (I failed to mention this before, sorry)
Use Sub3.5.4 (stable) or the sub 4.0-beta.
Let me know your results with those softwares
Compare the results with Sub to the results with stable Plane firmware
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.
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.
We are experience the same issue as you. May I ask, what external IMU sensor you used to resolve this issue? Was the ArduSub firmware capable of interfacing with this IMU out of the box?
Hi @rune -
Please make sure you are running the latest stable version of Ardusub, and have calibrated the vehicle compass in a region far from any large metal objects or high electrical currents. Typically this can be a challenge if located on large maritime vessel - best to do outside! Such a drift is usually indicated by a bad calibration, old firmware version, or external magnetic interference.