Gyroscope saturation?

[kaszeta]

Originally Posted by EricS-Team180

We've experimented with the 75, 80 and 150 deg/sec yaw rate sensors, in the past, and have always concluded that we needed to purchase a 300deg/sec sensor, to keep up with the turn-rate capability of out 'bots.

I used to get them right from AnalogDevices, but these past 2 years, they show that they (their evaluation boards) won't be in stock until April

There are plenty of other places to get Analog Devices gyros nicely mounted on evaluation boards. I've bought some nice 300 deg/s ones from Sparkfun.com, for example.

[EricS-Team180]

yeah..sorry... I should have said that I used to get them for $20 cheaper direct from AnalogDevices. I think I paid $70 for the SparkFun board last year. I also looked at a lot of yaw rate controllers from r/c aircraft catalogs. But they are controllers, not just sensors.

Anyone else take a look at what the r/c world has to offer? ...just curious
Eric

[FreakyAntelope]

My team has always been a little bit scared of doing this because of the gyroscope values drifting. Would one of these (300 dps) gyroscopes allow you to track your orientation over a 2 minute period without introducing too much error?

- Toby

[kaszeta]

Originally Posted by FreakyAntelope

My team has always been a little bit scared of doing this because of the gyroscope values drifting. Would one of these (300 dps) gyroscopes allow you to track your orientation over a 2 minute period without introducing too much error?

Team 95 has used gyros for years, and aside from the above caveat that you can pick up errors from collisions, the system has worked very well for us.

[EricS-Team180]

Right On Kaszeta.

The first year we used an AnalogDevices 300deg/sec yaw rate sensor was in 2004. We had a holonomic chassis that year. At first, the chassis was not easy to drive. The wheels were small and on irregular surfaces, they would not all be in contact with the floor. This tended to make the 'bot spin and drift while trying to drive straight. The first thing we did was to use the yaw rate signal to add counter spin to our drive train, when the driver was requesting straight motion without rotation. (...just a simple proportional control...a gain times the sensed yaw rate )
Next, we used a trapazoidal integration to get orientation from yaw rate. That was in our drive code that we wrote to allow the chassis to move in the direction the driver moved the stick, regardless of which way the 'bot was oriented. The kicker here, is that we did all this in the 38hz main loop. ...really slow when I now read that Kevin Watson's talking about sampling rates over 1000hz

What we found was that our orientation was off about 1.5deg for each full rotation of the 'bot. We had a reset button on the OI that year. If it got too funky for the driver, he set the 'bot facing straight up-field and reset the orientation.

Now, we do see the sensor value drift around the neutral point. So we just put a small deadband around 0 yaw rate - say +/-5 counts and forget about the small loss in sensitivity.

The yaw rate sensor is your friend. Get a good zero yaw rate reading while in disabled mode, and for the next 2:15, have some fun!

[ubergeek5075]

Originally Posted by EricS-Team180

The kicker here, is that we did all this in the 38hz main loop. ...really slow when I now read that Kevin Watson's talking about sampling rates over 1000hz

I remember last year there was some talk about upping sample rated on gyros and accelerometers to somewhere near the rate you say Kevin's talking about. However, I can't find a thread or anything pertaining to fast analog sample rates. I'm glad that I'm not the only one that heard of that, lol. Could you by any chance point me to something concerning that sampling?

[Guy Davidson]

Originally Posted by EricS-Team180

...really slow when I now read that Kevin Watson's talking about sampling rates over 1000hz

Wouldn't that be superfluously fast? With 300 deg/sec over a range of 1024, which is truncated to 512 because of a direction, you end up with 300 deg / 512 values = around .6 degrees per increment. If you're going at the maximum rate, of 300 deg/sec, going .6 degrees will take you .6/300 = .002 of a second to go one tick. That means that hypothetically, querying at 500hz (1/.002) will be enough. And that's if you care about the tiniest turn. However, that might not work anyway, due to the fact that ADC conversions have noise.

The reset button sounds like a great idea and something we'll probably implement if we find ourselves using a gyro during the user controlled mode (which is not a given seeing as we are not building a holonomic drive train).

We'll probably implement a gyro on our robot this year to help with accurate turning, especially during hybrid.

[eugenebrooks]

Guy,

ADC conversion noise is your friend.

Eugene

Originally Posted by sumadin

Wouldn't that be superfluously fast? With 300 deg/sec over a range of 1024, which is truncated to 512 because of a direction, you end up with 300 deg / 512 values = around .6 degrees per increment. If you're going at the maximum rate, of 300 deg/sec, going .6 degrees will take you .6/300 = .002 of a second to go one tick. That means that hypothetically, querying at 500hz (1/.002) will be enough. And that's if you care about the tiniest turn. However, that might not work anyway, due to the fact that ADC conversions have noise.

The reset button sounds like a great idea and something we'll probably implement if we find ourselves using a gyro during the user controlled mode (which is not a given seeing as we are not building a holonomic drive train).

We'll probably implement a gyro on our robot this year to help with accurate turning, especially during hybrid.

[Guy Davidson]

Originally Posted by eugenebrooks

Guy,

ADC conversion noise is your friend.

Eugene

My friend because it makes such measuring rates unuseful, and therefore helps keep the processor under a lower load than if they were? Or for another reason I'm currently missing?

Has it even bee / is there a good way to quantify ADC conversion noise? So that I might be able to know what's the minimum useful sampling rate?

[eugenebrooks]

Your friend, if the amplitude is large enough, because it helps you with the quantization error, making the higher sampling rate useful by producing an average. If really old white papers are still laying around on CD, I believe that there is a white paper on the topic.

Eugene

Originally Posted by sumadin

My friend because it makes such measuring rates unuseful, and therefore helps keep the processor under a lower load than if they were? Or for another reason I'm currently missing?

Has it even bee / is there a good way to quantify ADC conversion noise? So that I might be able to know what's the minimum useful sampling rate?

[RyanW]

Originally Posted by EricS-Team180

The yaw rate sensor is your friend. Get a good zero yaw rate reading while in disabled mode, and for the next 2:15, have some fun!

How exactly would I adjust the program to get a reading while in disabled mode? I don't want to waste too much of the hybrid period calibrating my gyroscope, but I'm not sure when else I could set it...Also, how would I know when to stop sampling?

[kaszeta]

Originally Posted by RyanW

How exactly would I adjust the program to get a reading while in disabled mode? I don't want to waste too much of the hybrid period calibrating my gyroscope, but I'm not sure when else I could set it...Also, how would I know when to stop sampling?

If you're using Kevin's Gyro code from previous years (vs his new mcc18 3.0 code), it should be running anyways, since default_routine() gets called while you are in disabled, it just won't let you set outputs.

If you're using the new code, just put the code in disabled().

[Joe Ross]

Originally Posted by sumadin

My friend because it makes such measuring rates unuseful, and therefore helps keep the processor under a lower load than if they were? Or for another reason I'm currently missing?

Has it even bee / is there a good way to quantify ADC conversion noise? So that I might be able to know what's the minimum useful sampling rate?

This white paper should help you understand: http://www.chiefdelphi.com/media/papers/1449

[EricS-Team180]

ubergeek5075

I read it here: post #94 in Kevin's post about the v3.0+ code

Actually, we want to experiment with accelerometers this year, where higher sampling rates will certainly pay off.

RyanW, kazeta's right on again. We typically put the Get_analog function call in Default_routines. Then we'll call our gyro function(s). We pretty much "roll our own" functions, but check out Kevin's routines. ...good stuff

Eric

[Guy Davidson]

Originally Posted by Joe Ross

This white paper should help you understand: http://www.chiefdelphi.com/media/papers/1449

I see. It makes sense. However, the principle questions to me is, is it really worth it to lose sampling rate for sampling accuracy? I guess I need to decide if the samples are accurate enough for me or not.