Let us see what we have in our hands. The output of every inertial sensor consists of at least 4 components:

1. Real acceleration/rotation rate: we can be sure that these are 0 during the bias tests by properly aligning our sensors.
2. Additive white noise: we can be sure that the effect of this is 0 by computing sufficiently long averages rather than measuring a single sample.
3. Bias: this is what we try to estimate
4. Flicker noise: this is the noise that puts a lower limit to the Allan variance.

Every time you measure the sensor output, you must always assume your readout is at least the sum of bias and flicker noise. This brings us another important question. What is a flicker noise? Can we get rid of it by again computing long averages of the sensor outputs?

There are plenty of papers out there which investigates the physics behind the flicker noise in the semiconductors.  It could be quite difficult to understand them thoroughly. However, as a navigation engineer you are at least supposed to know following basic facts about the flicker noise even if you do not understand it:

1. The power of the difference between 2 samples of the flicker noise (i.e. y(T)-y(0)) increases with time proportional to “2h.ln(T)” where h is the flicker noise value.
2. The power of the average of this difference also increases with time proportional to “h.ln(T)”. In other words:

This 2nd property is extremely important for us to understand the concept of bias in low cost inertial sensors. There are significant number of people out there who are not even aware of this simple property, yet do not hesitate writing papers (and even books) on INS. Naturally, these texts written by such idiots contain lots of statements which directly contradict to above properties of the flicker noise.

So, what should these properties mean to you? Let me list a couple of important results so that you do not repeat the same mistakes in your future papers as those fools did.

1. Property 1 dictates that the flicker noise itself is divergent. This means that the value of the flicker noise can theoretically be anything between -infinity to +infinity.
2. Property 2 dictates that the average of the flicker noise is also divergent. This means that you cannot eliminate the flicker noise by taking the average of sensor outputs regardless of the averaging duration.
3. (But, we have to define a bias value. We cannot throw away an inertial sensor just because we cannot come up with a theoretically consistent bias estimate.We are engineers, not physicists.) Let us suppose that we define the sensor bias as the average of the sensor outputs in T seconds. Property 2 also dictates that this bias value changes more as you increase T. In other words, if you plot time vs average value (your bias estimate), you will see that your bias estimate changes more with time (and eventually diverge) instead of converging to a fixed point.

You must always remember this 3rd result. It simply says that it is impossible to define a constant bias value for an inertial sensor regardless of the averaging duration. In other words, the longer the averaging duration is, the more diverse bias estimate you will observe. You should not be tricked by the fact that the Allan variance of flicker noise is constant regardless of the cluster time. Although the Allan variance is constant, the power of the flicker noise average grows with the averaging duration. This is in fact quite an interesting result. As an example, suppose you compute 2 different bias values by taking the average of sensor outputs for 5 minutes and 1 hour respectively. The variation (the power of change) of 1-hour bias estimate will be bigger than the 5-minutes estimate. However, this does not mean that one of these bias estimates is better than the other. They are just 2 different values which are equally valid (or equally wrong). This is because there is no constant value that you may call as bias. You cannot differentiate flicker noise from bias. You must assume that the bias itself evolves in time in an unpredictable manner.

As a result, there is nothing called perfect bias calibration. You cannot claim that the bias calibration value that you compute now can be assumed valid some later time. The best bias estimate is the one that is computed most recently, not the one that is computed with longer averaging durations. As a matter of fact, you should consider bias as the current state of the flicker noise. As the flicker noise of low cost MEMS units are very dominant, representing the bias as the state of the flicker noise is a better mathematical model than random constants.

The next time you see an “INS expert” claiming that he/she obtain better bias estimates by repeating the calibration tests with longer times (or with more position), you can now easily conclude that he/she is another self deceptive ignorant that you should stay away.

It looks quite normal, doesn’t it?
Well then. Let’s play with it a little bit by downsampling the GyroY data as follows:

• gdat5=GyroY(1:5:end);
• gdat10=GyroY(1:10:end);
• gdat15=GyroY(1:15:end);
• gdat20=GyroY(1:20:end);

Just the simple downsampling. And now, let’s compute the allan variance of each of these downsampled data. In the following figure, you can see the computed Allan variances for the downsampled version of the GyroY (together with the original one).

What a striking result we have! The Allan variance of the gdat10, gdat15 and gdat20 (red, magenta and black curves) have a very strange additional bulge on their initial segments. Where do they come from? What happened?

Let me explain what you have just witnessed. When we downsample the data, we change the frequency of the additive sinusoidal error (remember the effect of downsampling operation on sine/cosine functions). The downsampling shifted the frequency of these sinuosidal components to the lower part of the signal spectrum where the Allan variance coefficients are computed with a smaller frequency window (in other words with a larger time window/cluster). The power of the white noise within that smaller window is obviously less. As the windows get smaller, the power of the additive noise becomes smaller than the power of sinusoidal components. From that point on, we can start seeing the effect of sinusoidal components on the Allan variance figures. But of course this procedure is also upper limited. For very large cluster lengths (narrow frequency windows) the sine function is also filtered out.

As you can see from the figure above, IMU3000 has a serious additive sinusoidal noise problem. An inexperienced navigation engineer can easily miss this fact if he/she just trusts simple Allan variance figures (because, the ignorant stupids usually advices them to do so).

In fact, one should always use correlation based analysis techniques together with the Allan variance figures in order not to miss such important error components. As an example, you can see the correlation of the GyroY output in the following figure.

The figure speaks for itself. We can immediately see that the correlation is a sinusoidal function.

To tell the truth, I first computed this correlation only to observe that we have an additive sinusoidal component problem for this sensor. And then, I came up with this downsampling idea in order to be able to see it in the Allan variance figures. (Yes, it is my original invention. But feel free to use it whenever you want to annoy stupid ignorants.)

Unfortunately, the autocorrelation computation for the inertial sensors is not simple. If you just try to compute the autocorrelation with “xcorr” function (of matlab), you won’t be able to see anything other than a triangular waveform. One should subtract the “approximate” signal before computing the autocorrelation. (The modelling section of the toolkit should give you some idea about how to do it properly.) However, as this example suggests, the results that we obtain is usually worth the additional efforts that we spent for correlation computation.