Gyro drifting

[a8Chcx]

Hi,

I am using IMU on my demo board and found YAW keep moving when in stationary condition.

I knew it is because of the nature of MEMS gyro and there is no ideal solution to fix it.

I want to set the certain threshold on MAG and ACC to decide there is the real change on YAW because my application will move above certain speed in X,Y,Z.

1. Could you tell me how to change it in fusion library to make it work?

2. There is the recommended threshold for MAG and ACC?

3. If my moving speed is < 100 degree per second, it is better to use the smaller rang Gyro or there is no big difference?

Thanks,

Christie

[markpedley]

I'm not clear about what precisely you're seeing and with which algorithm. The yaw should not be drifting with the 9 axis algorithm.

- If you're using the 6 axis accel+gyro algorithm (no magnetometer) then the yaw will drift since obviously you need a magnetic sensor to give yaw angle and stabilise the gyroscope in yaw

- If you're using the the 9 axis algorithm and it re-stabilises to the correct yaw angle after very aggressive rotation then you could easily be clipping the gyro. We always run the gyro at maximum 2000deg/sec for that reason. The human wrist is easily capable of 2500 deg/sec rotation. If you have the gyro set to a low range below 2000deg/sec then the gyro will clip, the gyro integration will be in error and you'll see a slow correction of those integration errors by the Kalman filter as it stabilizes to the magnetic vector.

To answer your questions specifically:

- we don't see drift in gyro yaw on the reference software

- the problem is likely in your gyro settings and not fixable by tweaking accel or magnetometer settings

If you have changed the gyro gain settings from the default 2000dps then make sure that you also change the gyro sensitivity setting in these lines in file drivers.c to match your new setting. See the datasheet for the gain setting to be used.

// place the gain for this full scale range into the gyro structure

FXAS21002_COUNTSPERDEGPERSEC 16    // for 2000dps=32000 counts

iCountsPerDegPerSec = FXAS21002_COUNTSPERDEGPERSEC;

fDegPerSecPerCount = 1.0F / FXAS21002_COUNTSPERDEGPERSEC;

[a8Chcx]

Hi Mark,

Thank you your answers and your fusion library. The pitch & roll are working perfect for my stabilizer...

1) In 9 axis fusion, no YAW drifting. But it is not accurate as pitch & roll. YAW is changing around 0.5 degrees. I do not know if it is because of GYRO offset or MAG accuracy? Looks like it is related to MAG accuracy because there is no big difference on pitch & roll. I checked Gyro, the number is around 1.5 degree per second on X, -1.5 degree per second on Y, and 0.5 degree on Z.

2) In my application, we move our stabilizer no more than 100 degree per second with certain constant speed like 1 degree per second(Min). Because there around 0.5 degree difference on YAW on 9-axis, I want to IMU with certain conditions, like MAG or ACC threshold, to get less change on YAW when in stationary conditions. Could you tell me if it is possible to do it when I am using your library?

3) For my application, the smaller Gyro range will be better?

Thanks,

Christie

[markpedley]

This sounds like magnetometer sensor noise causing your yaw jitter. The magnetometer is the noisiest of the three sensors (accelerometer, magnetometer and gyroscope). You could try increasing the value of this constant in fusion.h from its default value of 7 to 10 or perhaps higher.

// minimum magnetometer and magnetic disturbance

#define FQVBQD_MIN_9DOF_GBY_KALMAN 10E0F

This instructs the Kalman filter to place a lower weighting on the magnetometer data and so attenuates the magnetometer sensor noise. The drawback is slower convergence to the geomagnetic vector after aggressive motion. But that might not be a problem if your application is rotating at low rates.

Yes, for your application you could try a lower gyro range setting. The default value of 2000dps is set for gaming applications. It cannot do any harm but I do not think you will see much improvement since the noise is magnetometer noise almost certainly.

[a8Chcx]

Hi Mark,

I will try to change the above settings to see if it get better? Like you said, I do not think it will be better because there is noise on MAG.

I checked the performance on GYB and GY.

I can see GY has the faster response and stable angle as well. My application needs faster response time, that is why I am trying to use GY instead of GYB. When I have other condition to determine there is no YAW moving, but I still need to use pitch & roll. I really care about the relative YAW, what kind of input do I need to set for GY algorithm to make that they are changing on pitch & roll properly, but it is not on YAW?

Thanks,

Christie

[michaelestanley]

Christie,

Mark is out today, so I'll field this last question.  It's important to understand that the V5 algorithms internally use quaternion representations for orientation.  Roll, pitch and yaw are computed from those after the fact.   If you want to force Euler angle tradeoffs, do it in the computation of Euler angles from rotation matrix (See AN5017 in the kit).  You do not want to attempt to change the operation of the Kalman filter itself.  What you CAN do is increase the fusion rate by decreasing OVERSAMPLE_RATIO in build.h, which should help responsiveness.

Mike

[a8Chcx]

Hi Michael,

From what you said, there is no easy way(like set certain inputs to constant value) to force YAW stay as it is, and keep the pitch & roll calculated the same way as before in IMU because you are using quaternion representations?

I tested other sensor fusion in BNO055. There is the sensor fusion built in this chip. When I run in IMU mode and keep moving the chip, Pitch & Roll & YAW are changing properly, even YAW is shifting after certain time of moving. When I stop moving, I can see YAW stay as it is, no any shifting. I think that they put certain conditions, like GYRO, MAG below threshold, they will not be counted in...

I do not know if I can do the same by using IMU algorithm without changing the way to calculate?

You can see IMU performance on pitch, roll and YAW is more stable than in GYB mode...

Thanks,

Christie

[michaelestanley]

Christie,

There are no free lunches.  Some fusion functions may compute gyro offsets when the IMU is stationary, and then subtract those from the sensor readings before doing the fusion computations.  Our library chose to instead compute gyro offsets for consistency when the device is moving.  We figured that was the more important use case.

In GYB mode, you are probably seeing the effects of magnetic noise.  As Mark notes, you can adjust filter coeficients to favor accel over mag, but that will just increase the amount of time it takes for the filter to converge to magnetic north.

At the end of the day, what you (and other users in the community) are learning is that there is a limit to just how well you can compute orientation based on the standard sensor sets.  The algorithms can predict good, but not perfect, results.

Mike

[a8Chcx]

Hi Mark,

Is it possible to use two same Gyro sensors installed on opposite direction to cancel the noise and error?

Thanks,

Christie

[markpedley]

No, that will not work. The noise and zero offset error are uncorrelated between parts.

[a8Chcx]

Thanks, Mike and Mark.

The reason I ask is because I saw some people use 4 Gyro on one axis to try to cancel the drifting. I do not doubt if it work?

Another question:

When I use 9-axis mode, the Euler angle will change only based on ACC and GYRO if I keep the MAG input unchanged. YAW change will be very small and almost the same as Pitch&Roll...

Thanks,

Christie

[michaelestanley]

1. Again, unless you can prove via characterization or other means that the offset drift of multiple gyros is correlated (which I don't think you can), you are not going to be able to cancel it out.  The best you can do is average it.
2. I'm not sure I understand your 2nd question.  Are you aligning one axis with earth's magnetic field (which is the only way I see to keep mag constant while chaning acc and gyro inputs)? What is your question?

[a8Chcx]

Hi Mike,

Thank you.

My second question is: If I move to the final position and I know there is no change on YAW, there is +/-0.5 degree change on existing 9DOF because of MAG noise. This change will be small and close to pitch & roll (+/- 0.2 degree) if I keep MAG input the same as my last stable one?

Thanks,

Christie

[michaelestanley]

Christie,

If you are dealing with sub-1 degree issues, then you have done very well. I do not expect the algorithms to do better. As you note, magnetic noise alone is larger than that.

Mike

[a8Chcx]

Hi Mike,

If I keep MAG input the same as last one for 9DOF algorithms' input, YAW will be less change, just like pitch and roll?

I just want to know if I can get what I want before I am doing some testing...

Thanks,

Christie

[michaelestanley]

Christie,

It’s tough to comment without really seeing what you are doing. If you want to video what you are doing, I might be able to comment more. But again, if you’re fighting sub-1 degree issues, my advice is to stop. You’ve succeeded as well as I think you can.

Mike

[a8Chcx]

Hi,

I have a question about Gyro sensor.

In FXAS21002C, the noise density is about 0.025. This will cause 1.5 degree/hour drifting?

If this is right, I can see the drifting in IMU is much more than this...

Could you tell me why?

Thanks,

Christie

[markpedley]

The specified noise is a noise density figure at 200Hz. So at 200Hz ODR the expected noise is 0.025 * root(200) = 0.35dps.

Assuming no other error sources, integrating that up over one hour or 0.7 million samples is going to give an angular error far larger than 1.5deg. I would expect the integrated error to follow a square root of time random walk.

But in practice other error sources will integrate linearly with time and swamp this term. Gyroscopes have, for example, a very small sensitivity to acceleration which means that the zero rate offset is sensitive to orientation in the earth’s gravity field. There is also a small non-linearity which means that the integrated angle depends on the rotation rate.

In general, it’s not a good idea to integrate consumer grade gyros for significant periods of time without stabilization to known orientation vectors.

[michaelestanley]

Christie,

No it is not.  By definition, noise is uncorrelated between devices.  Offset is as well.  You could cancel out the signal, but I don't think that is what you are after :smileywink:

Mike

[a8Chcx]

Hi Mark,

Another question:

In IMU mode, if I do not want YAW change, what do I need to set for GY algorithm?

Thanks,

Christie

[markpedley]

The GY (accel and gyro) performs three axis gyro integration so the yaw angle does change (but with slow gyro yaw drift).

The only algorithm that always points in the same yaw direction (always to 0 deg north) is the accelerometer only algorithm. If you just want pitch, roll and tilt and your dynamics are not very aggressive then accelerometer only could be an option for you.