BEI Gyro Accuracy

[John Gutmann]

I guess the part I am really interested in is this, because this is what I am having troubles with:

/*************************************************
Timer ISR to grag Gyro value at rate 
determined in SetuoTimer2
**************************************************/
ISR(TIMER2_OVF_vect)
{
  //Toggle the IO pin to the other state.
  //digitalWrite(TOGGLE_IO,!digitalRead(TOGGLE_IO));
sample_accum  += analogRead(GyroPin);
sample_counter ++;
  if (sample_counter == SAMPLES_PER_UPDATE)
  {
    val = (sample_accum/SAMPLES_PER_UPDATE)-gyroBias;
    if (val < -DEADBAND || val > DEADBAND)
    {
    gyro_angle += (long)val;
    }
    sample_accum = 0;
    sample_counter = 0;
  }
  //Capture the current timer value. This is how much error we
  //have due to interrupt latency and the work in this function
latency=TCNT2;
  //Reload the timer and correct for latency.
TCNT2=(latency + timerLoadValue);
}

What why are you toggling a pin?
The latency part is just accounting for the time spent processing?

Other then those 2 things my ISR is basically the same.
I cant really post the code now because I am at work, but I can give a brief pseudo coding of it.

get adc reading
if it is less then dead band
     then subtract from position
if it is greater then dead band
     then add to position
else do nothing

send position over USART

I know I am technically using an accumulated rate but lets assume I am using a Riemann sum with a coefficient of 1.

Thanks,
John Gutmann

EDIT: I think when I get home I will try to eliminate the dead band, and see if that will help any.

[billbo911]

Originally Posted by John Gutmann

I guess the part I am really interested in is this, because this is what I am having troubles with:

/*************************************************
Timer ISR to get Gyro value at rate 
determined in SetuoTimer2
**************************************************/
ISR(TIMER2_OVF_vect)
{
  //Toggle the IO pin to the other state.
  //digitalWrite(TOGGLE_IO,!digitalRead(TOGGLE_IO));
sample_accum  += analogRead(GyroPin);
sample_counter ++;
  if (sample_counter == SAMPLES_PER_UPDATE)
  {
    val = (sample_accum/SAMPLES_PER_UPDATE)-gyroBias;
    if (val < -DEADBAND || val > DEADBAND)
    {
    gyro_angle += (long)val;
    }
    sample_accum = 0;
    sample_counter = 0;
  }
  //Capture the current timer value. This is how much error we
  //have due to interrupt latency and the work in this function
latency=TCNT2;
  //Reload the timer and correct for latency.
TCNT2=(latency + timerLoadValue);
}

What why are you toggling a pin?
The latency part is just accounting for the time spent processing?

Other then those 2 things my ISR is basically the same.
I cant really post the code now because I am at work, but I can give a brief pseudo coding of it.

get adc reading
if it is less then dead band
     then subtract from position
if it is greater then dead band
     then add to position
else do nothing

send position over USART

I know I am technically using an accumulated rate but lets assume I am using a Riemann sum with a coefficient of 1.

Thanks,
John Gutmann

EDIT: I think when I get home I will try to eliminate the dead band, and see if that will help any.

Well, that is what happens when you have compiled bits and pieces of different code, from various times during the creation process together and forget to remove the commented out sections you don't use anymore.

If you will notice, those two lines are commented out. I had originally used them to toggle an LED on and off so I could measure the rate at which I was generating the ISR. I just attached an o-scope to the LED pins to do the measuring and verification. Once I proved to my self I actually made good assumptions, I commented those lines out. Sorry for the confusion.

The latency part is exactly as you described. It adjusts for the various time spent in the ISR and keeps the sample rate consistent. I suppose I could have streamlined it by doing this.

TCNT2 += timerLoadValue;

I'll have to verify this later.

[John Gutmann]

What is the not moving voltage on your gyro end up being? (Your using a BEI right?) I know it is supposed to be 2.5, but mine is 2.1 volts. That just seems a littles too far off to just be a tolerance issue.

-John

[billbo911]

Originally Posted by John Gutmann

What is the not moving voltage on your gyro end up being? (Your using a BEI right?) I know it is supposed to be 2.5, but mine is 2.1 volts. That just seems a littles too far off to just be a tolerance issue.

-John

Honestly, I don't know what my offset, or "bias", is for this gyro. But as I recall it is near 2.5vdc. In the code below, I do a 30 sample average of the gyro while it is stationary during initialization to determine what my "bias" is. 30 samples takes 3 seconds.

for(int i=0; i<=29;i++) // Collect 30 samples of Gyro output while stationary.
                          //The average will become the value for the BIAS.
{
  bias_acum += analogRead(GyroPin);
  delay(100);
}
  
gyroBias = (bias_acum/30);

The gyro I am using is a Analog Devices ADXRS150 equivalent. In fact the chip is a 22304, but the specs are the same as the 150. It came in the 2005 KOP.

[John Gutmann]

Ok, so I have spent a few hours playing with this. calculating the bias is working well. I added a tolerance constant. This works very well. One thing I noticed is because of my awkward neutral value the linearity of this is well....not linear any more so I had to add in scaling values because it will be mostly consistent in either direction, but the mV/deg/sec isn't the same for above and below the neutral value. It is more or less decent for getting in the ballpark. But I am beginning to think just by the behavior of the device that it is broken in some way. I know it is a VERY old gyro that i got from my team at least 2 years ago. So I am going to see what it is going to take to get a new working gyro from somewhere. This way I won't be programming in circles.

-John

[billbo911]

Originally Posted by John Gutmann

Ok, so I have spent a few hours playing with this. calculating the bias is working well. I added a tolerance constant. This works very well. One thing I noticed is because of my awkward neutral value the linearity of this is well....not linear any more so I had to add in scaling values because it will be mostly consistent in either direction, but the mV/deg/sec isn't the same for above and below the neutral value. It is more or less decent for getting in the ballpark. But I am beginning to think just by the behavior of the device that it is broken in some way. I know it is a VERY old gyro that i got from my team at least 2 years ago. So I am going to see what it is going to take to get a new working gyro from somewhere. This way I won't be programming in circles.

-John

Hey John,
I wouldn't jump to the conclusion that your Gyro is bad yet. Let me explain why. I have been playing with my Gyro and Arduino set up most of the day. I seem to be stuck on virtually the same situation that you seem to be seeing. Simply put, when I rotate my Gyro 180° in a positive direction, I will get approximately 180° read out from the software. When I rotate it in a negative direction I do not get the same -180°. So when I rotate it forward 180 and then backward 180° I always end up with a total somewhere near five to 10°. If I continue to rotate the Gyro back-and-forth 180° I continue to increase my total about 10° positive every repetition.

What I seem to be seeing it a nonlinearity of the output when rotating clockwise and counterclockwise. I have observed this behavior in the past with Analog Device gyros, both the 150 and 300° percent conversion. Although, I have never seen it to this extent. I do know when this particular chip that I have had this problem in the past, but because I was using it for prototyping I wasn't too concerned about it. It may just be a characteristic of this particular chip.

When building the navigation system for our robot this year, we used an Analog Devices' 300° per second gyro. It did exhibit this behavior but too much lesser extent. Because the only plan on using the Gyro for returning the robot in one direction, we did not feel that it was worth worrying about. Besides the air we would get with less than 1°.

So what I'm looking for now is a way to compensate for what appears to be the nonlinearity of this Gyro.

[John Gutmann]

I found a way to compensate for the non linearity of the gyro but, the problem is that the gyro isn't consistent. I will turn it 90 degrees on way, then back to the starting position and it will read 0. But then when reset the system and try the same test it will be off by about 20 degrees. I then reset the system again, and its off by 5 degrees, and then without event reseting the system I turn it 90 degrees and it only changes the position by about 15 degrees, i turn it back to the starting position and it goes -90 degrees from where it was at.

I see absolutely no consistency in this device. It will work fine, but then when the controller is reset it will work totally difference.

I have scaling factors in to change the readings so they are equal from one direction to another, but that only solves the linearity problem.

I have figured there is something wrong with it this whole time simply because the neutral voltage is 2.1 volts. That just seems too far from the spec'ed 2.5 volts to be acceptable.

-John

[billbo911]

Originally Posted by John Gutmann

I found a way to compensate for the non linearity of the gyro but, the problem is that the gyro isn't consistent. I will turn it 90 degrees on way, then back to the starting position and it will read 0. But then when reset the system and try the same test it will be off by about 20 degrees. I then reset the system again, and its off by 5 degrees, and then without event reseting the system I turn it 90 degrees and it only changes the position by about 15 degrees, i turn it back to the starting position and it goes -90 degrees from where it was at.

I see absolutely no consistency in this device. It will work fine, but then when the controller is reset it will work totally difference.

I have scaling factors in to change the readings so they are equal from one direction to another, but that only solves the linearity problem.

I have figured there is something wrong with it this whole time simply because the neutral voltage is 2.1 volts. That just seems too far from the spec'ed 2.5 volts to be acceptable.

-John

I can't argue with your logic. It does sound like something is a little screwy with that gyro.
BTW, is there a chance you can share your scaling code to compensate for the non-linearity. For some reason, mine doesn't seem to work.

[John Gutmann]

Well, my code, ( I am at work now ), is simply a scaling factor. as far as linearity I was talking about from positive to negative, so crossing the neutral value it was non linear, so -90 degrees/sec for 1 sec wouldn't read the same as 90 degrees/see for 1 sec.

I will post it later tonight.

-John

[John Gutmann]

As an update: Mostly to you billbo911

I realized I had no "base" code to even drive the bot around, so I decided to work on that first. I am doing the 2 drive motors off of the 16 bit Timer1. Timer0 I decided to make an "event" timer. This way I can say do this after x seconds, or whatever and it will be very easy to do. The resolution is .01 seconds, which should be fine for my needs. The accuracy should be 0.0128% assuming the internal clock has 0% error (pffft! yea right!) and not counting any latency. But this should all be fine for this application. I wrote some simple motor functions to stop, both, stop individually, and set the speeds either together or individually.

I mounted my bread board to the top of the bot, it is a very nice set-up now.

The only problem I am having is that with how the motors are on there, one is turning CW while the other is turning CCW to go forward. So it curves. To solve this, I think I am gonna try to somehow mount the motors both facing the same direction. This should solve the problem.

I can share the plans of the bot and my code if you would like. I assume you can almost just use it with little to no modification from what I have.

-John

[billbo911]

Originally Posted by John Gutmann

As an update: Mostly to you billbo911

I realized I had no "base" code to even drive the bot around, so I decided to work on that first. I am doing the 2 drive motors off of the 16 bit Timer1. Timer0 I decided to make an "event" timer. This way I can say do this after x seconds, or whatever and it will be very easy to do. The resolution is .01 seconds, which should be fine for my needs. The accuracy should be 0.0128% assuming the internal clock has 0% error (pffft! yea right!) and not counting any latency. But this should all be fine for this application. I wrote some simple motor functions to stop, both, stop individually, and set the speeds either together or individually.

I mounted my bread board to the top of the bot, it is a very nice set-up now.

The only problem I am having is that with how the motors are on there, one is turning CW while the other is turning CCW to go forward. So it curves. To solve this, I think I am gonna try to somehow mount the motors both facing the same direction. This should solve the problem.

I can share the plans of the bot and my code if you would like. I assume you can almost just use it with little to no modification from what I have.

-John

Anything you would like to post up would be great. I'm sure I am not the only one who might benefit from it.

My ultimate goal is to use the Arduino, or some other variant of the ATMega chips, to build a single board to both read in two+ quadrature encoders and a gyro and be able to provide distance and orientation from a single serial stream. I might use I2C but I will definitely have a simple RX/TX source.

BTW, as a test, I have removed the guts from a ball mouse and will be using this as a source for a test set of Quadrature encoders. Hey, it was cheap at $5 for a pair of quad's. Now I just need to interface them mechanically.