Gyro Repeatability, Expected Drift ?
 

1) Does anyone know what gyros were in previous First kits (or how to interpret the printing on the gyro case) ? I'm using one mounted on a dark green PCB for testing. (FIRST: Please consider printing the year on the PCB & the gyro part number too!).

2) I'm using KWs gyro code and have read everything I can find. I have the gyro mounted on a wooden board with a compass rose on it. The chip is accurately mounted in the center with a pointer. After calibration, it largely seems to work. I can rotate it 180 degrees (fairly slowly) and get pretty close to 180 reported (actually 1800). But many times when I return it to zero, it will be 5-10 degrees off in either direction and from then on everything is off. Any idea how repeatable measurements should be on a desk ? on a robot (with all its vibration etc) ? Any suggestions ? Since I don't know what the chip is, the software is currently set to a adxrs150.

There is significant evidence that the max rate the gyro can turn must be fairly slow else the reported numbers will be way off. But even when I rotate it slowly, its repeatability can be off by 5% or more. Is that normal ?

Re: Gyro Repeatability, Expected Drift ?
 

Kevin's code implements a deadband. Although this is just fine
for using it to measure a turn, it is not so good for using the gyro
as a compass.

Using the gyro as a compass requires you to be entirely linear
with no deadband, and to carefully average the "no turn" output
(noise helps you here) and subtract the value using fixed binary
point arithmetic. Second order accurate time integration is also
a good idea in this case.

A drift of a couple of tenths of a degree during the 15 second
autonomous mode is achievable, but the drift is sensitive to
temperature and you either need to recalibrate, or compensate,
for that. What we do is check the drift now and then, and then
recompute the required average when the drift has picked up
due to temperature change.


Eugene

Re: Gyro Repeatability, Expected Drift ?
 

Yes, there is a deadband, but it only comes into play if the gyro's output is within a few DN of the bias point. As long as your 'bot rotates at a rate above a few DN, every sample is included in the integration (I would argue that every FRC 'bot rotates above this rate, which is less than a degree per second). So, unless I'm missing something (which is entirely possible :)), I don't see how it's a problem.

-Kevin

Re: Gyro Repeatability, Expected Drift ?
 

Kevin,

You are indeed missing something. By carefully averaging
the no rotation signal, you can obtain accuracy (on average)
that is better than the ADC quantization. This improved
accuracy shows up in the resulting time integral of the gyro.

I would happily share our gyro code with you if you would
like to explore it, use it, or make some version of it generally
available. I have learned a lot about PIC interrupts studying
your code, perhaps you have one small thing to learn by
studying mine. The code, however, also uses methods to
avoid race conditions that I remember, quite well, you don't
like.

Eugene

Re: Gyro Repeatability, Expected Drift ?
 

I certainly understand how some noise components can help improve resolution, but I just don't see how integrating gyro noise when the 'bot is known to be still can help. Yes, I realize a deadband would cause problems in applications where precise low angular rate measurements need to be taken, but that doesn't apply to many FRC 'bots.

Can you point me toward a paper or anything else that can help me understand your point? And yes, please send me any code you have that I can work with. I think we have a rate table at work and it might be fun to see if I can get some freebie time on it to take some data.

-Kevin

Re: Gyro Repeatability, Expected Drift ?
 

I'm not a fan of using the gyro for absolute angular position, not even over the short fifteen seconds of Hybrid mode. I do believe, however, that there are solutions that will let you do what you want with relative ease, at least over fifteen seconds:

A) Only use what the gyro actually gives you, the angular velocity. For example, for the relativly simple task of driving forwards, don't compare the angle to zero, compare the rate of change in the angle to zero. That way you don't have to deal with the integration.

B) In order to make turns, that do require the angle measurement, more accurate, you can look at the angle relative to where you're now. I'll give you an example. Say you've been driving roughly straight, and your angle is now 2 degrees. If you want to turn 90 degrees, set your target to 2+90 = 92, instead of to ninety. Now lets say you turned your about 90, drove straight again, and due to some drift, you're now around 110 degrees. You want to turn ninety again, so you should probably set your target to 110+90 = 200, instead of 180. I imagine this might work better.

Any thoughts?

Re: Gyro Repeatability, Expected Drift ?
 

There is an old white paper posted on CD
http://www.chiefdelphi.com/media/papers/1449
as noted in the white paper, this game is relatively
standard in the signal processing business.

Assuming that you have a gyro that has inherent noise
that is larger than the quantization error, for a stationary
robot there will be a sequence of random (integer) values
returned by the ADC. What you want is the average and
this is not an integer. Obtaining this average, in suitable
precision, is the goal of sampling the gyro for a suitable
length of time while the robot is known to be still.

We represent the average in binary fixed point, a 32 bit
value in 256ths, so to speak. We then use this average
as the zero value for our time integration. It is very
straight forward to do, using the trapezoidal rule we
just shift the old value and the new value up by the right
number of bits before we subtract the average.

The resulting accuracy is good enough that the temperature
dependent drift of the gyro can become significant.
We address this by watching the drift of the integral and
re-measuring the required average when the drift becomes
larger than we want. Another approach is to read the temperature
output signal provided and compensate.

I'll package our code for this year's robot in a zip file and
put it in a place accessible to you and send you an email
when I have done that.

Re: Gyro Repeatability, Expected Drift ?
 

We'd be interested in seeing this code as well. We're using the gyro code from WPILib, but it's apparently unsuitable for anything other than just driving straight. We finally just gave up on using the gyro for turns and now count gearteeth.

Re: Gyro Repeatability, Expected Drift ?
 

Ouch. I was hoping there would be a simple answer like yes this is normal or no its defective or something !

Thanks for the suggestions on how to handle it. yes I would love to see the code too.

Being a brand new user of gyros (haven't even had the time to figure out what technology they are based on, obviously not a spinning top), I'm obviously trying to run up the learning curve as fast as possible.

I'm hoping the lack of repeatability may not be a show stopper for the 15 seconds. But I am concerned the rate of the First gyro may be too slow. Its probably too late for us to get a 300 deg/sec one.

Are many teams able to do relative extreme navigating using the gyro (and perhaps the gear tooth for straight travel) ? By extreme, I mean, at least one 90 degree turn or better still three 90s (ie one loop around the course) ?

Kevin, is it possible for you to give a 20 word description of this deadband, its magnitude and how it comes in to play for repeatability ?

Thanks

Re: Gyro Repeatability, Expected Drift ?
 

Our robot is capable of doing repeatable 90deg turns just using the gear teeth sensors. It's not perfect, and it depends on traction, but we couldn't get the gyro to behave reliably. We were consistently getting 3 lines, and had the IR worked at a greater distance we could have hit 4.

Re: Gyro Repeatability, Expected Drift ?
 

Team 435 can do a full lap plus in automode using the KoP gryo for both the turns and maintaining alignment while driving straight. We are using a modified version of Kevin's code. (QuickADC and only reading the gryo once every 26ms.)

Last year we were unsuccessful with using the gryo, the robot's momentum would carry it past the 90 turn and we were never able to get a consistent turn amount.

Re: Gyro Repeatability, Expected Drift ?
 

What sample rate are you running at?

In 2005, we ran many tests with sample rates from 200hz to 12800 hz. While we have since lost the raw data from the tests, the results were that we saw improvements in performance up to 1600hz and beyond that there were no noticeable improvements. We have since always used 1600hz and get results that are repeatable to within the accuracy of our measurement method.

Re: Gyro Repeatability, Expected Drift ?
 

Dr. Brooks' marklars are wise and true :)

One of the best thing that you can do to help reduce the drift is use a very large average during disabled mode to get the sensor bias, and don't throw out resolution when you're done with the average.

I think I posted a similar example in a different thread within the last couple months, but here is an example of what you want to do.

- assume you want to use a 32-bit variable for your integral.

- Let's assume we want to use a 64 sample average to get the sensor bias. Use the following code to calculate your bias (do this code ONLY in disabled mode).

- Once disable mode is over, the above angularRateBias value contains the bias of the sensor. Just note that it is a 64 sample SUM, but you can think of it as the average * 64. At this point you DO NOT want to divide by 64, since you would then be throwing out the "decimal portion". Just multiply you A/D sample by 64 to bring it up to the same resolution of the bias value. See the following code:

Now you have a nice integral with 6 bits worth of fractional-resolution. If you want your fractional portion to be 7 bits, use 128 samples in the average, etc.

Re: Gyro Repeatability, Expected Drift ?
 

Well, let me just say the KOP isn't very good and that you'd be better off using a ADXRS300 for this application.

You could probably overnight one from SparkFun.

Yes, quite a few. Team 1024 sent me this link to a match at Chicago where they do 1.5 laps in autonomous.

This is the code we're talking about:
If the turning rate is very, very small (i.e., less than a degree per second) the data is thrown away and not used in the rate or angle calculations. This can improve the angle estimation because we're not including (actually, integrating) the measurement noise while the 'bot is not rotating. How do I know the 'bot isn't rotating? Well, I think it's a safe bet that most, if not all, FRC 'bots are incapable of rotating at these rates. This has no effect on repeatability (someone else mentioned that these gyros may have a problem where the sensitivity may be different between rotating CW versus CCW, which may be what you're seeing). Using my code and a pretty good Silicon Sensing Systems' CRS03-02 gyro, my Vex 'bot can drive the edge of a 4' x 4' square for twenty minutes and not deviate more than a few degrees over that period <grin>.

Now, Eugene is suggesting (I believe) that I don't need a deadband if I use a higher resolution bias value in my calculations and he may be right. I'm already oversampling the signal, so I don't know if I can really do much better without using a better ADC.

Eugene is also using trapizoidal integration, which works great at lower sampling rates, but doesn't help much (I suspect) at the high rates I sample the gyro at. I have a version that uses trapazoidal integration, but I haven't taken the time to do much testing (I wiil though).

Sorry, it's a few more than twenty words <grin>.

-Kevin

Edit: Okay I just read Chris' posting and I believe we're on the same page now. I'm already oversampling the gyro output to reduce the effects of gaussian noise sources and to gain resolution through interpolation, which is what Chris discusses in his posting. For the bias calculation, I use a circular buffer to store the last sixty-four Gyro rate updates (each update contains the average of many gyro samples) and when Stop_Gyro_Bias_Calc( ) is called (presumably just as autonomous period starts), I add up those sixty-four samples and use that value for the bias. The difference is that I don't retain all of those ~18-bits for use in my calculations. I only retain what theoretically makes sense. Classic textbook oversampling and decimation theory states that for every extra bit of resolution, a signal must be sampled four times and the results added together (this is the oversampling part) and then divided by two (the decimation part). This is exactly what I do in my code.

Now is it possible that I may be discarding valid data when I do the decimation? My understanding of the theory says no, but there could be some aspect of the theory that I don't fully understand. Either way it'll be fun to try it out to see if I can wring a little more performance out of the FRC gyro.

-Kevin

Another edit: I Googled and found an excellent application note that discusses the theory behind my code. It's for Atmel AVR microcontrollers, but it's also applicable to the PIC in the FRC robot controller.

-Kevin

Re: Gyro Repeatability, Expected Drift ?
 

If you carefully tune the gyro, with no deadband, and use it as a
compass; you can feed the error in the heading back into the
motor power. It keeps the robot on track when it gets bumped,
and it automatically corrects for overshoot in turns.

Eugene

Re: Gyro Repeatability, Expected Drift ?
 

We do our averaging to get the bias in the pit where we can be sure
that the robot is not disturbed while the data is being taken. The
resulting number is then hard coded.

I will be heading to SanJose this evening, but I can post
snippets of the code I use from there and will be happy to do so.


[quote=Chris Hibner;717147]

One of the best thing that you can do to help reduce the drift is use a very large average during disabled mode to get the sensor bias, and don't throw out resolution when you're done with the average.

[\QUOTE]

Re: Gyro Repeatability, Expected Drift ? ADXRS300?
 

re sparkfun's ADXRS300.

In light of the lack of time and my inexperience, I need to ask a dumb question. Is it as simple as hooking up VCC, GRD and RateOut as per the FIRST one, change the def in gyro.h and go ? (or is there any other hardware etc needed ?

Re: Gyro Repeatability, Expected Drift ?
 

Thanks everyone.

Dr Brooks:
- would greatly appreciate your code spinnets.
- what gyro chip is your team using ?
- given you calculate the bias in the pits and hard code it, am I correct that the bias is individual chip by chip specific and is temperature specific but once in a stable temperature, it can be calced and hardcoded for the duration of the regional ?

Kevin, thanks for the clear coverage on the deadband. I can see why you do it. We are looking closely at the Sparkfun unit. We are just waiting for clarification as to whether using it is as simple as connecting the 5v, grd and rate to AI 1. Unfortunately due to our location, it will cost us over $60 in shipping alone :(

Re: Gyro Repeatability, Expected Drift ?
 

Looking at their schematic, it should be that simple.

I'll tell you what, if you're not happy with the performance of the gyro, I'll reimburse your team for the cost of the gyro plus shipping (yes, I'm serious :D).

-Kevin

Re: Gyro Repeatability, Expected Drift ?
 

We do ours immediately before every match by using the disabled_mode flag. In other words, we're running a moving average right up until they enable the robots. Since everyone is required to be off the field for the last few seconds before the match start, you're pretty much guaranteed to get have the robot undisturbed and still, and you get the bias as close to what you're going to have in the match.

The code is more or less:

Re: Gyro Repeatability, Expected Drift ?
 

Since you are in Canada, you may want to instead order the ADXRS300EB from www.digikey.com. Click on the Canadian flag to get Canadian pricing. (Looks like $58 Can.) Digikey will be able to ship to you from a Canadian warehouse, which should expedite the shipping and cost less than having the product shipped from the USA.

The ADXRS300EB is essentially equivalent to the SparkFun card. We placed ours in a standard 20-pin IC socket in order to avoid soldering directly to the board.

Disclaimer: I have no association whatsoever with Digikey, other than having ordered an ADXRS300EB earlier this week so that we'd have two -- one to use on both of Team 1519's two robot configurations. It arrived in a couple days as expected.

Best regards,
--ken

PS: For what it's worth, the 2.25 laps (9 lines) of autonomous in 15 seconds that we do with Speed Racer uses Kevin's gryo code with an ADXRS150, used "as a compass." There are three completely separate runs in the video. We're not sure how much of our error is due to using only a 150-degree/second gyro; we think that most of the trouble we have with driving a straight line is due to the "steering lag" in the closed loop control. For bias calibration, we use Kevin's routine while the robot is disabled as he describes above.

Re: Gyro Repeatability, Expected Drift ? ADXRS300?
 

Yes, it is that simple.

BTW, we are sampling at 1600Hz and taking a result every 32 updates for a total of 50 updates/sec using the ADXRS300. (These are set in the adc.h file)We are getting excellent results.

Re: Gyro Repeatability, Expected Drift ?
 

Not a bad way to go, but we average for about 15 seconds at 150hz.

We do check the drift of the integrated gyro in the pit and
redo the average whenever it starts drifting too much.

Eugene

Re: Gyro Repeatability, Expected Drift ?
 

I just noticed that unless it was in a PM, nobody ever answered this original first part of your question.

The 2006 KoP gyro was on a dark green PCB. There were two mounting holes in the center of the board, with the silkscreened lines "YRG" and "RevNC" on it. The most distinguishing characteristic of this board, however, was that the silkscreen for the connections for J21 and J22 were INCORRECT. J21 read "G 5 T" and "B W R". (It should have said "B R W".) Similarly, J22 read "G 5 R" and "B W R" but should have said "B R W". The actual gyro chip used in 2006 was an AD22304, which is an 80-degree/second gyro, with the "T" output varying by 12.5 mV per degree per second of rotation.

The 2007 KoP gyro was on a light green PCB. It has a similar pair of mounting holes in the center, but the silkscreen between the mounting holes said "YRG" "BD". The silkscreen for the output connections (J9 and J10) for this board contain the correct "G 5 T" "B R W" and "G 5 R" "B R W". The actual chip used in 2007 is an ADXRS150 which is a 150-degree/second gyro, with the "T" output varying by 12.5 mV per degree per second of rotation.

The 2008 KoP gyro (as you probably already know) is on a red PCB.

Which of the older gyros are you actually using?

NOTE: Since the 2006 KoP AD22304 gyro has the same "sensitivity" as the 2007 KoP ADXRS150 gyro, they will both work with the same #define in Kevin's code (#define ADXRS150) although the 2006 gyro will saturate more easily on high rate turns.

Re: Gyro Repeatability, Expected Drift ? ADXRS300?
 

Interesting. In adc.h, we are using ADC_SAMPLE_RATE_800HZ and ADC_SAMPLES_PER_UPDATE_1. I presume that since we call "Process_Gyro_Data()" in our "Spin" loop that we are getting 800 updates/sec in our integration of the gyro angle. (At least we think we're getting that many updates per second; we haven't actually instrumented the code to see if our "spin" loop is keeping up.) Now I wonder if our lack of averaging is hurting us. (However, we needed to turn off the ADC averaging in order to get more predictable results from the absolute magnetic encoders we are using. Strictly speaking, however, I wonder if that's the correct thing to do...)

Re: Gyro Repeatability, Expected Drift ?
 

If you look at the output of the gyro using a scope or spectrum analyzer, you'll notice some significant fourier noise products above your 75Hz Nyquist frequency. This noise is aliased back into your 75Hz bandwidth, and certainly isn't Gaussian in nature. You might want to up your sampling frequency to the ~1600Hz sweet spot.

-Kevin

Re: Gyro Repeatability, Expected Drift ? ADXRS300?
 

Depending on what else is executing, the spin loop may be fast enough to keep up, but it's probably marginal. I would use at least a x16 oversample to gain a few more bits of resolution and still have a 50Hz update rate.

-Kevin

Re: Gyro Repeatability, Expected Drift ?
 

Yes, the ADXRS300EB will work too, but requires some additional soldering, and mounting is a problem too. The SparkFun board is almost ready to go and can be attached with double-sided foam tape.

-Kevin

Re: Gyro Repeatability, Expected Drift ?
 

Kevin,

Our gyro is set for a 40hz bandwidth, as I recall, and
it is working absolutey great. If I had a problem I
would borrow a scope and sort it out.

The first thing I would do to improve things would be
to add temperature compensation, and then power supply
voltage compensation, but these improvements do not appear
to be required for our use.

Eugene

Re: Gyro Repeatability, Expected Drift ?
 

Our gyro works great... and never ceases to amaze me that it functions at all.

I mean... think about it for a minute. It's a little teeny piece of silicon, and who knows what else, and it knows its spinning. Amazing!

Gotta hand it to those Analog Devices guys...

And thanks to Kevin for speeding all of our development schedules along! :D

...

Hope you guys like the new and improved 1024 hybrid mode this week. Should be quite a show.

That, and... I think we've finally got enough complicated (messy) homebrew circuitry to make the display stop blanking out all the time now... :o

If any of you are at BMR and would like to discuss Hybrid mode, I'll be happy to discuss ideas/concepts with you. Just ask anyone on 1024 for "Q" and I'm sure they'll direct you.

-q

Re: Gyro Repeatability, Expected Drift ?
 

Sorry for the delay. Trying to hold down a job and also get ready
for the San Jose Regional keeps you busy.

We are using the SparkFun mounting of the ADXRS150. We also
have one of the IC style mountings from digikey on our test mule,
but we bought the SparkFun rendition this year to avoid etching
a PC board during a busy build period.

All you have to hook up on the SparkFun unit is 5v, signal, and gnd.
The other outputs support advanced compensation methods.

The biggest effect on the bias is the temperature. The temperature
of the autoshop where we build and test the robot is different than
that at a regional, so one has to recalibrate the bias if one is not using
temperature compensation. There is also power supply voltage
compensation, but the 5 volt supply should be pretty well regulated
unless there are large loads placed on it.

I have not had any time to package any code up, but here are
some nippets on how we do things. Note the conditional compilation
for the timer interrupt handler. One calculates the integral,
the other calculates the sum of 256 samples. To avoid doing
many sums and averaging, you can do 2560 and then divide by
10, rounding.

/* Initialize_Timer_1() sets up the timer used to
control the time integration for the rotational rate gyro.
Called from User_Initialization() in user_routines.c.
Refer to Kevin Watson's "frc_interrupts" code for the
details and additional examples of other timers. Kevin
also has cached copies of the PIC Microcontroller documentation
on his web site at http://kevin.org/frc/. If you contemplate
any adjustments you will need to study this documentation carefully.
The only changes we recommend to this routine are to select
different prescaler values in order to slow down the interrupt
rate if desired. Out of respect for Nyquist, you should not drop
the interrupt rate below twice the bandwidth of the gyro.
*/
void Initialize_Timer_1(void)
{
/* Initialize the 16 bit timer register.
*/
TMR1L = 0x00;
TMR1H = 0x00;

/* Set the prescaler for a 10 MHz rate. With the interrupt happening on the
overflow of a 16 bit counter, the interrupt rate is 10MHz / 2^16, or 152.59 Hz.
The timer interrupt rate can be reduced by a factor of 2, 4, or 8 by picking
one of the other prescaler values.
*/
T1CONbits.T1CKPS0 = 0; // T1CSP1 T1CSP0
T1CONbits.T1CKPS1 = 0; // 0 0 1:1 prescaler (clock=10MHz/each tick=100ns)
// 0 1 1:2 prescaler (clock=5MHz/each tick=200ns)
// 1 0 1:4 prescaler (clock=2.5MHz/each tick=400ns)
// 1 1 1:8 prescaler (clock=1.25MHz/each tick=800ns)
//
T1CONbits.T1OSCEN = 0; /* Leave the timer 1 internal oscillator disaled. */
T1CONbits.TMR1CS = 0; /* Use the internal clock. */
T1CONbits.RD16 = 1; /* Do timer 1 register operations in one 16 bit access. */
IPR1bits.TMR1IP = 0; /* Set interrupt priority to low. */
PIR1bits.TMR1IF = 0; /* Clear any existing interrupt. */
PIE1bits.TMR1IE = 1; /* Enable interrupt on overflow, a transition of the counter from FFFF -> 0. */
T1CONbits.TMR1ON = 1; /* Enable the timer. */
}

static volatile signed long GyroIntegral = 0; // in 256ths
static volatile unsigned char GyroIntegralSentinel = 0;
static volatile unsigned long OldGyroValue = 0;
static volatile int AverageCycleCount = 0;

/* The value for GyroAverage is obtained by compiling the code
to sample and produce the average upon the trigger pull. You
sample the average a number of times and average the results to
produce the value that is hard coded here.
*/
static volatile unsigned long GyroAverage = 131419; // in 256ths

/* Timer_1_Int_Handler() handles that interrupt based calculation
of the average of the gyro signal. A sentinel is used to inform
the interrupt handler that the gyro integral is being zeroed by
user code.
*/
#define GYROINPUT rc_ana_in01
#ifdef GYROAVERAGE
void Timer_1_Int_Handler(void)
{
if(GyroIntegralSentinel == 0) {
if(AverageCycleCount < 256) {
GyroIntegral += Get_Analog_Value(GYROINPUT);
AverageCycleCount += 1;
}
}
}
#else
void Timer_1_Int_Handler(void) {
if(GyroIntegralSentinel == 0) {
unsigned long NewGyroValue = Get_Analog_Value(GYROINPUT);
GyroIntegral += ((OldGyroValue + NewGyroValue) << 7) - GyroAverage;
OldGyroValue = NewGyroValue;
}
else {
OldGyroValue = Get_Analog_Value(GYROINPUT);
}
}
#endif

/* GetGyroIntegral() returns the current value of the time integral
of the rotational rate gyro. As interrupts are active, the value read
is reliable if two successive reads produce the same value.
*/
signed long GetGyroIntegral(void) {
signed long Old, New;
Old = GyroIntegral;
while(Old != (New = GyroIntegral)) {
Old = New;
}
#ifdef GYROAVERAGE
return Old;
#else
return Old / 10000L;
#endif
}

/* ZeroGyroIntegral() zeros the average of the rotational rate
gyro signal that is calculated via the timer interrupt.
A sentinel is used to inform the interrupt handler that the
values are in the process of being zeroed by user code.
*/
void ZeroGyroIntegral(void) {
GyroIntegralSentinel = 1;
GyroIntegral = 0;
AverageCycleCount = 0;
GyroIntegralSentinel = 0;
}


The interrupt handler setup is what you would expect:
#pragma interruptlow InterruptHandlerLow save=PROD,section("MATH_DATA"),section(".tmpdata")

void InterruptHandlerLow ()
{
unsigned char int_byte;
if (PIR1bits.TMR1IF && PIE1bits.TMR1IE) { /* Timer 1 */
PIR1bits.TMR1IF = 0;
Timer_1_Int_Handler();
}
else if (INTCON3bits.INT2IF && INTCON3bits.INT2IE) { /* The INT2 pin is RB2/DIG I/O 1. */
INTCON3bits.INT2IF = 0;
Int_1_Handler();
}

The setup of the timer gets put in User_Initialization


Initialize_Timer_1();

Putdata(&txdata); /* DO NOT CHANGE! */


And, finally, some code in the main packet loop allows you
to print the value of sum, or integral, and reset it

First, a useful function for printing longs
#define RLEN 10 /* Maximum decimal digits for an unsigned long. */

/* The function puln(unsigned long i, unsigned char n)
prints "i" in decimal format, using leading zeros to fill
out a minimum field width of "n" characters.
*/
void puln(unsigned long i, unsigned char n) {
unsigned char result[RLEN]; /* Stores the result digits, as numbers. */
unsigned char reversed[RLEN]; /* Storage for the digits as they come off. */
char rpos; /* Index for reversed array. */
char rindex; /* Index for result array. */
int j;

/* The minimum field width is one.
*/
if(n == 0) {
n = 1;
}
/* Use remainder and divide in a loop to peel
off the digits, least significant first.
*/
rpos = 0;
while(i > 0) {
reversed[rpos] = i % 10;
rpos += 1;
i /= 10;
}
/* At this point the digits are in the reversed
array and rpos records the count. If rpos is zero,
the argument was zero. We must first place the
required number of leading zeros in the result.
*/
rindex = 0;
while((rindex + rpos) < n) {
result[rindex] = 0;
rindex += 1;
}
/* Fill in the digits, reversing the order.
*/
while(rpos > 0) {
result[rindex] = reversed[rpos-1];
rindex += 1;
rpos -= 1;
}
/* You gotta just love the fact that printf() on the
RC can't handle a character string in data memory!
Don't forget the cast to (int) for the RC...
*/
for(j = 0; j < rindex; j += 1) {
printf("%d", (int)result[j]);
}
}

/* Print a signed long.
*/
void pl(long i) {
if(i < 0) {
printf("-");
i = -i;
}
puln(i, 1);
printf("\r");
}

/* Print an unsigned long.
*/
void pul(unsigned long i) {
puln(i, 1);
printf("\r");
}

/* The function void pfp(long i, unsigned char bits, unsigned char digits)
prints a binary fixed point value in decimal format. The arguments are:
i, the integer holding the fixed point value; bits, the number of bits to
place after the binary pont; and digits, the number of digits after the
decimal point to print.
*/
void pfp(long i, unsigned char bits, unsigned char digits) {
long intpart;
long mask;
long powten;
unsigned char j;

/* If the argument is negative, print the sign and work
with the absolute value so that shifts give us a divide.
*/
if(i < 0) {
printf("-");
i = -i;
}

/* Shift the argument down to obtain the integer
part, and turn the result over to puln() to handle.
*/
intpart = i >> bits;
puln(intpart,1);

printf(".");

/* Construct the mask for the fractional part.
*/
mask = 0; /* All zeros. */
mask = ~mask; /* All ones. */
mask <<= bits; /* Shift in bits zeros. */
mask = ~mask; /* Flip to get bits ones. */

/* Use the mask to obtain the fractional part.
*/
i &= mask;

/* Convert the fraction to a decimal fraction.
*/
powten = 1;
for(j = 1; j <= digits; j += 1) {
i *= 10;
powten *= 10;
}
i >>= bits;

/* At this point, we print the decimal
fraction with the correct number of digits
using leading zeros.
*/
puln(i, digits);

/* And finally, the optional newline.
*/
printf("\r");
}


And then using it to print the sum, or integral
#ifdef NOTDEF
if(p3_sw_trig == 1) {
printf("trig pressed\r");
ZeroGyroIntegral();
}
if(counter % 40 == 0) {
printf("Gyro Sum = ");
pl(GetGyroIntegral());
}
#endif

I never define NOTDEF by convention, and if I want the
code in I change ifdef to ifndef

In this case, if the named trigger is pressed, the gyrointegral,
or the sum is zeroed. In the case of the integral, you can then watch
the drift. It is an integer in roughly tenths of a degree.
In the case of the sum, it steadily increases until the count
in the interrupt handler is reached, and then you hard code
the number into the integrator. We usually use the average
of 10 or 20 samples, and compute the average with a calculator.
This can be more automatically done by changing 256 to 2560
in the timer interrupt handler and then dividing the result by 10.
You could take it to its limit by using 25600 samples and dividing
by 100, rounding the result.

It is all pretty straight forward. Check the drift perhaps a couple
of times a day, and if the drift gets to be too much for you,
redo the calibration. A "big" drift is perhaps one degree, or
at most two, during the 15 second autonomous period.
By recalibration you can reduce the drift to a tenth of a degree
or so.


I have had time to look for the Amtel oversampling documentation
and look at it this evening. The goal of that approach is to improve
the resolution of the direct gyro signal by oversampling, using the
noise to produce a higher resolution average. In essense, we
are playing the same game with the integration approach laid
out above and also suggested many times by Chris Hibner.
One need not oversample so much to exploit the technique when
what you want is the integral, and in fact there is a point of diminishing
returns due to the increased correlation between successive points.

If what I wanted was the best possible direct rotation rate signal,
I would use the Amtel approach that Kevin has coded, but since what
I want is the integral, the strategy shown above is, in my view, the best one
and it does not require one to burden the PIC processor with a high
interrupt rate.

Gotta get some sleep,
it will be a long day tomorrow.

Eugene

Re: Gyro Repeatability, Expected Drift ?
 

Thanks for the outstanding heads up on this stuff.
I waited one day and now both Sparkfun and Digikey went out of stock on the ADXRS300 stuff. But Digikey is due back soon.

Our Robot (in quarantine) currently has the 2008 gyro. A test robot I believe has the 2007 and I am testing at home with which is now clear to me to be the 2006 gyro. It sounds like the 2007 and 2006 have twice the max rate of the 2008 so maybe we should use them on the robot. However, it is the 2006 that is having the repeatabilitity issues on a compass board.