Gyroscope saturation?

[Kevin Watson]

Originally Posted by Tom Line

Has anyone else had to deal with this, and does anyone think the robots can spin fast enough to saturate the gyro?

Yes, it's possible. Two potential solutions come to mind: 1) write some code that will monitor and record the peak values from the gyro. If you find that you have a problem, you can implement a control loop that will minimize the chance that the gyro will saturate. 2) Purchase another gyro like the ADXRS150 or the ADXRS300.

-Kevin

[kaszeta]

Originally Posted by Kevin Watson

2) Purchase another gyro like the ADXRS150 or the ADXRS300.

We've had relatively good luck using 300 deg/s gyros. It's not fool-proof, however, since you'd be surprised the sorts of short-duration high-turn rate impulses you get from robot collisions. Expect it to still drift, especially in a game like this year's.

[ubergeek5075]

Last year for our dynamic braking system, we wanted a feedback loop from not only the optical encoders on the wheels, but also the gyros. However, I have experienced the same problems with saturation during collisions, and even when our robot turned fast enough.

I remember something from last year when i was researching the gyro from the KOP, that it was 150dps. Even with that we still had that saturation problem.

I agree with the solution of lower resolution gyros, but with the budget of a small team, it may take some convincing.

Also, what resolution on the controller end were you getting? How many values / dps rotation ?

[Tom Line]

Uber, we haven't implemented a testbed for this year yet, so I don't have any data. This was all hypothetical, because I was pretty sure you can saturate the 80 dps gyro pretty easily. I'll go with the 300.

Can collisions really saturate this gyro? How far off would that knock the reading? It seems to me most collisions don't spin robots at high rates.

[JesseK]

You could also ask your team the question of whether or not the robot should turn 90 degrees in less than a second for this game. Aside from sudden impacts that turn you, I doubt you'll ever have the need to experience a quick turn on a holonomic robot -- you could instead simply side-step an obstacle.

[ubergeek5075]

Yes, collisions can cause saturation of the gyros, even if they result in turning the robot slowly. It's all physics, the collision results in an extremely high, however very short turn rates. Graphically speaking, the turn rate spikes, then drops down when your turn rate is constant. This results in some very odd data sometimes, depending on how long that spike lasts, and if you pick it up or not.

[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

Anyway, let me throw this out for consideration. Can the yaw rate sensor in the K.O.P be "over-clocked" (for lack of a better word) - to measure a wider range? I'd be willing to experiment with giving up some sensitivity, to get 300 deg/sec for the K.O.P sensor.

Eric

[Tom Line]

I seem to remember that by placing a resistor across the leads you can modify the dps, but reduce other functions. Look up and thoroughly read the manuals for each sensor - I think I saw it there.

http://www.analog.com/UploadedFiles/...s/ADXRS150.pdf

I believe it's the portion talking about changing the scale.

[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.