|
|
|
![]() |
|
|||||||
|
||||||||
![]() |
| Thread Tools | Rate Thread | Display Modes |
|
#1
|
|||
|
|||
|
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 ? |
|
#2
|
|||
|
|||
|
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 |
|
#3
|
||||
|
||||
|
Re: Gyro Repeatability, Expected Drift ?
Quote:
), I don't see how it's a problem.-Kevin |
|
#4
|
|||
|
|||
|
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 |
|
#5
|
||||
|
||||
|
Re: Gyro Repeatability, Expected Drift ?
Quote:
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 |
|
#6
|
|||
|
|||
|
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? |
|
#7
|
|||
|
|||
|
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. Quote:
|
|
#8
|
||||
|
||||
|
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.
|
|
#9
|
|||
|
|||
|
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 |
|
#10
|
||||
|
||||
|
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.
|
|
#11
|
|||
|
|||
|
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. |
|
#12
|
||||||
|
||||||
|
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. |
|
#13
|
||||||
|
||||||
|
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). Code:
tempAngRate = Get_Analog_Value(angRate);
angRateBias = (angRateBias - angRateArray[angRateBiasCounter]) + tempAngRate;
angRateArray[angRateBiasCounter] = tempAngRate;
angRateBiasCounter++;
if (angRateBiasCounter > 63)
{
angRateBiasCounter = 0;
}
Code:
angRateValue = Get_Analog_Value(angRate); robotHeading += (s32)angRateValue*(s32)64 - angRateBias |
|
#14
|
||||
|
||||
|
Re: Gyro Repeatability, Expected Drift ?
Quote:
Quote:
Quote:
Quote:
Code:
// get the latest measured gyro rate
temp_gyro_rate = (int)Get_ADC_Result(GYRO_CHANNEL) - gyro_bias;
// update reported gyro rate and angle only if
// measured gyro rate lies outside the deadband
if(temp_gyro_rate <-GYRO_DEADBAND || temp_gyro_rate > GYRO_DEADBAND)
{
// process gyro data
}
else
{
gyro_rate =0;
}
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 Last edited by Kevin Watson : 12-03-2008 at 14:50. |
|
#15
|
|||
|
|||
|
Re: Gyro Repeatability, Expected Drift ?
Quote:
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 |
![]() |
| Thread Tools | |
| Display Modes | Rate This Thread |
|
|
Similar Threads
|
||||
| Thread | Thread Starter | Forum | Replies | Last Post |
| pic: Not what you expected | VanMan | Extra Discussion | 17 | 05-03-2007 19:34 |
| Preventing drift | Salik Syed | Programming | 4 | 21-02-2006 00:08 |
| Yaw Rate Sensor Drift? | phrontist | Control System | 13 | 19-08-2004 10:55 |
| More flipping then expected | cyberknights195 | General Forum | 6 | 07-03-2004 15:52 |