hitechnic Gyro sensor (NGY1044) noise

[mightor]

Aswin,

Well, I don't really have an issue with changing my driver if it improved its performance. You mentioned one thing already which was to take a 100 readings instead of the 5 that I do. If you have other ideas, let me know and I'd be happy to include them in my drivers.

- Xander

[physics-matt]

I think the problem comes from using an integer type offset in the HTGYRO-driver. This is an approximation of the true offset. The error in the offset adds to the error in the calculated heading everytime it is updated with a new reading. So it is not drift your seeing but the accumulation of errors.

I think that an integer offset will be a major contribution to the problem. A simple analysis shows that the best estimate of the offset is the average of readings taken when the gyro is stationary. This average will usually be a real, not integer, value, which is best represented by a float.

To see the effect that rounding will have, I have just collected 10,000 values from my gyro:

a value of 3 occurred 227 times
a value of 4 occurred 9766 times
a value of 5 occurred 7 times

The average offset in this case is 3.978. If I round this to 4, then I automatically give myself an accumulated error of -0.022 degrees per second. This appears to correspond nicely with Xander's observation.

Even without rounding the offset, there will be an accumulation of error as we integrate due to the fact that the mean we calculate won't be equal to the "true" mean (assuming it also doesn't drift!) However, we can then use this data to get an indication of how many samples we need to get a good approximation of the mean. The error in our estimate of the mean is approximately:

error in mean = standard deviation / sqrt(number of samples)

so, depending on the value of the standard deviation, we need to choose the number of samples to make the error small.

The standard deviation of my data is approx 0.15, so the accumulated error in degrees per second when integrating is:

accumulated error in degrees per second = 0.15 / sqrt(number of samples)

If we had taken only 100 samples, then the error would accumulate at around 0.015 degrees per second, which is about the same as the error we get from rounding the offset (which was 0.022 degrees per second). On the other hand, by using a float to represent the mean, calculated from 10,000 samples (in this example, giving a value of 3.978) then we can expect an accumulated error of about 0.0015 degrees per second.

Matt

[aswin0]

[quote="physics-matt]
The average offset in this case is 3.978. If I round this to 4, then I automatically give myself an accumulated error of -0.022 degrees per second.
[/quote]
The error is per reading, not per second. Also a rounding function gives an average error off 0.25, that is ten times bigger than in your example. You were very lucky. But on average the error of the mean for 100 samples is 6% of the error of the rounding function.

Matt, You are very right about the importance of sample size. I did quite a few experiments myself with this sensor. But one thing is still bothering me. All the statistics we calculated are based on the assumption of a normally distributed noise in the sensor. But, the sensor returns integer values and the vast majority of the redings are within a range of 2. Can we safely asume that we are dealing with a normal distribution? Or, if not, what formulas do we use to calculate stdev or the error of the mean given the sample size?

Here are some statistics from my sensor:
N 14014
min 594
max 600
mean 597,49001
median 597
modus 597
var 0,284742839
stdev 0,533613005
drift -0,16791478 (degrees per minute)

[mightor]

Aswin,

If you have a small program (or excel sheet) to calculate those values you have in your post, I would be keen to see if my gyro has similar characteristics.

- Xander

[gloomyandy]

Hi Folks, interesting thread...

I'm no expert on stats, so can anyone tell me what the impact of the various sample rates will be? Does anyone know what the update rate is for the actual sensor i.e. how fast do HiTechnic sample the sensor value and how fast does the actual gyro update)? This is an analogue sensor so the ATMega will be sampling the A/D every 3ms, then the NXT will sample that reading every 2ms, then in the case of the above code the program will sample that value every 5ms... So what does this mean for the actual real values obtained? I assume that if your program is sampling faster than say the HiTechnic sample rate then you will end up reading the same actual reading more than once, but how do the other sample rates impact things and finally how will the sampling impact things like like standard deviation etc? As an example using my modified light sensor/laser sensor I obtained the following graph when sampling the output every 1ms.

You can clearly see the way that the 3ms/2ms sampling interacts to give clusters of 4 and 2 identical values...

Also given the relatively small range of values from the sensor 0-1024 you could consider using fixed point rather than floating point.I'm not sure how much slower fp is for the various languages being used, but it may help...

Andy

[aswin0]

Nice and important questions.

Analogue sensors do not have a sampling rate on their own respect, the change of current is continuous. Although there might be a kind of maximum change rate (with this I mean the sensor can't go from 0 to 3 volts within a millisecond) that could influence statistics. But for the NXT this can be ignored I think. When converting the voltage output from an analogue sensor to a number the AD converter uses a sample rate, for the NXT this is 333 samples a second. This means that the converted values are updated every three msec. This is what you see in your graph.
If you base your statistics on samples taken more often than you will use the same measurement more than once. This results in underestimation of the standard deviation and error of the mean and should really be avoided. Using a lower sample rate will not affect statistics, standard deviation will be the same.

But what if you need a value only once every 30 msec in our program? Could you then take the average of 10 readings (done every 3 msec). This average has far less error in it than an indivudual reading made every 30 msec, and could greatly reduce the standard error. (I used this trick in my Kalman filter, but that is another thread) But can you safely calculate the standard deviation of a number of mean values? I don't know for sure but I do think so.

[physics-matt]

The error is per reading, not per second.

The error per reading is the same as the error per second in this case. The best way to see why is to look at Xander's code (a few posts back) and ask yourself how you would work out the error in degrees per second if there was an error in the offset.

But one thing is still bothering me. All the statistics we calculated are based on the assumption of a normally distributed noise in the sensor. But, the sensor returns integer values and the vast majority of the redings are within a range of 2. Can we safely asume that we are dealing with a normal distribution? Or, if not, what formulas do we use to calculate stdev or the error of the mean given the sample size?

This has been bothering me as well. The rounded values will have different statistics to the underlying normal distribution (assuming the raw sensor noise is normal), so we do have to be a little careful when inferring things from the standard deviation.

In this case I am fairly confident we are on safe ground as the statistics are essentially the same as a discrete random walker. I'd have to think about it some more to be sure, but generally the discrete random walker behaves very similarly to its continous (i.e. normally distributed) conterpart.

If you base your statistics on samples taken more often than you will use the same measurement more than once. This results in underestimation of the standard deviation and error of the mean and should really be avoided.

Indeed. Nearly all of the standard statistical results and their inferences rely on the measurements being independent. So, if you sample too often, your results are not independent and your analysis is flawed.

But what if you need a value only once every 30 msec in our program? Could you then take the average of 10 readings (done every 3 msec). This average has far less error in it than an indivudual reading made every 30 msec, and could greatly reduce the standard error. (I used this trick in my Kalman filter, but that is another thread) But can you safely calculate the standard deviation of a number of mean values? I don't know for sure but I do think so.

You can do this, and indeed you can calculate the standard deviation of a number of mean values. However, if I've understood you correctly then you're talking about using a series of averages taken over 30ms intervals to do your integration. This will actually make no difference to your result.

If I get time later I will try to explain what I mean a little more carefully. I would usually try to write up the maths and post a pdf, but I'm afraid I can't spare the time at the moment.

Oh, and in case anyone is interested, I used R to calculate my statistics. It's amazing!

Matt

[gloomyandy]

Hi,
thanks for the thoughts on the sample rate issue. I would still like to understand how this sensor works a little better. Does anyone know what the actual chip is that is being used?

Also my understanding is that the gyro produces a value that is proportional to the angular velocity is this correct? If so and assuming that it produces a continuous output, then I assume that you really need to sample the values as frequently as possible otherwise any peak values between the samples would be missed. So for instance if you sample at say 6ms intervals and the velocity goes from 0 to say 10 units and back to 0 over a 6ms period then (assuming the samples coincide with the end points), the readings will be zero in both cases and so you will miss the actual rotation completely... Is this true?

Also given the 3ms ATmega 2ms NXT sampling (as shown in my graph above), what is the best way to sample (or process the results) so that you obtain the underlying 3ms sample rate?

[physics-matt]

Can we safely asume that we are dealing with a normal distribution? Or, if not, what formulas do we use to calculate stdev or the error of the mean given the sample size?

Just realised that the mean of the samples will be normally distributed for a large enough number of samples, thanks to the central limit theorem. You just need the samples to be independent and identically distributed with finite variance - all of which ought to be true if we sample the values far enough apart for the readings to be independent.

then I assume that you really need to sample the values as frequently as possible otherwise any peak values between the samples would be missed.

Yes, this is true. You're best off sampling as often as possible if you're integrating the results. However, because it will always be a finite sample rate, you will always have innaccuracies creep in and this is the famous "drift" problem you get in all inertial measurement approaches.

Matt

[gusjansson]

I did some testing and found that the AD conversion in the NXT has some variables that will affect how well the Gyro sensor appears to perform. One surprise was that the values were heavily affected by the NXT being plugged in to the USB port.

I wrote and NXC program that takes 100 samples. I calculate the offset as the average of the 100 samples. Then I check the sample set to see the distribution of the values.

Here is the test program:

Code: Select all

//=============================================================================
// HiTechnic Gyro Test
//
#define GYRO   IN_1

#define SAMPLESIZE 100

task main()
{
  int i, y, d;
  int v, offset;

  float gyroAvg, gyroSum = 0;

  int data[SAMPLESIZE];
  int cSet[7];

  SetSensorHTGyro(GYRO);

  // Let user get finger off start button before starting sampling
  Wait(1000);

  for (i=0; i<SAMPLESIZE; i++) {
    v = SensorHTGyro(GYRO);
    data[i] = v;
    gyroSum += v;
    Wait(4);
  }

  // Display floating point gyro average
  gyroAvg = gyroSum/SAMPLESIZE;
  TextOut(0, LCD_LINE1, "Avg:     ");
  NumOut(6*4, LCD_LINE1, gyroAvg);

  // Round to nearest int
  offset = gyroAvg+0.5;
  
  // Go through sample set and see how many are
  // offset-3, offset-2, offset-1, offset, offset+1, offset+2, offset+3
  for (i=0; i<SAMPLESIZE; i++) {
    d = data[i] - offset;
    if (d < -3) d = -3;
    if (d > 3) d = 3;
    d += 3;
    cSet[d]++;
  }
  
  // Display on the screen now many of each value was in the sample
  y = LCD_LINE2;
  for (i=0; i<7; i++) {
    if (i==0)
      TextOut(0, y, "<=   :");
    else if (i==6)
      TextOut(0, y, ">=   :" );
    else
      TextOut(0, y, "==   :");
    NumOut(6*2, y, offset+i-3);
    NumOut(6*6, y, cSet[i]);
    
    y-= 8;
  }

  // Keep display on screen until button pressed
  until(ButtonPressed(BTNCENTER, false)) Wait(100);
}

When I run this with the USB cable connected, here is the output:
Avg:15.83
<=13 :0
==14 :9
==15 :28
==16 :34
==17 :29
==18 :0
>=19 :0
Note that there was a fairly wide distribution of values.

Now same program without the USB cable connected:
Avg:15.96
<=13 :0
==14 :0
==15 :5
==16 :94
==17 :1
==18 :0
>=19 :0
This is clearly a much cleaner set of data.

Note that the NXC function SensorHTGyro has a built in offset of 600 so an offset of 15.96 is actually 615.96 of the raw value.

So... if you are experimenting with the Gyro sensor, make sure the USB cable is detached.

I also did some experimenting with running the motors and found that if I powered an NXT motor while I was sampling the data, the average value was more than 1 less then when the motor was not powered.

Gus