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