Gyroscope saturation?
 

We are planning on using the gyro angle to offset our cartesian coordinate plane so that when the operator presses the joystick away from himself, the robot always moves away from the operator regardless of robot orientation.

However, this years 80 degrees per second gyro has me a bit worried. It's tough to do by feel, but it sure seems like our robot can pull a 90 degree turn in less than 1 second by rotating.

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

I considered purchasing last year's gyro but I can't find anywhere to do so.

Re: Gyroscope saturation?
 

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

Re: Gyroscope saturation?
 

I believe we have the same gyro as last year. If I am correct, it was also an 80 deg/sec gyro.

Try looking on SparkFun for a gyro. About $70 should get you a 150 or 300 deg/sec gyro.

Dang it Kevin, you beat me to it.

Re: Gyroscope saturation?
 

Bilbo, read this year's sensor manual. We have a new gyro. Last year's was 150 dps - so I wasn't terribly worried about saturating it with quick turns.

Thanks guys. I think I'll do both the code and purchase a higher dps one just to be sure. Better safe than sorry when it comes to the drivetrain.

Kevin, I'll admit that most of the words they're using on the specs page are foreign to me (mechanical engineer doing controls, go figure). Will the ADXRS300 simply "drop" in place of the KOP gyro using your same code?

Re: Gyroscope saturation?
 

I did! That's how I know the actual part number I have on the gyro from last year (AD22304) is identical to the part number on the gyro we got in the KOP this year.

Re: Gyroscope saturation?
 

Should work just fine. Just select your new gyro from the list in gyro.h and compile. Let me know if you have any problems.

-Kevin

Re: Gyroscope saturation?
 

That's odd. I haven't had a chance to look at the old gyro (it's buried in the old robot off doing demos at bowling allies...). But the sensor manual says it's different from last years. Wouldn't be the first time one of First's manuals was wrong though!

Re: Gyroscope saturation?
 

The sensor manual states that last year's sensor was ADXRS150, this year's AD22304, having a dynamic range of 150 d/s and 80 d/s respectively.

No, the manuals are never ever wrong...:yikes:

Re: Gyroscope saturation?
 

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.

Re: Gyroscope saturation?
 

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 ?

Re: Gyroscope saturation?
 

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.

Re: Gyroscope saturation?
 

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.

Re: Gyroscope saturation?
 

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.

Re: Gyroscope saturation?
 

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

Re: Gyroscope saturation?
 

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.

Re: Gyroscope saturation?
 

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.

Re: Gyroscope saturation?
 

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

Re: Gyroscope saturation?
 

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

Re: Gyroscope saturation?
 

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.

Re: Gyroscope saturation?
 

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 :cool:

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!

Re: Gyroscope saturation?
 

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?

Re: Gyroscope saturation?
 

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.

Re: Gyroscope saturation?
 

Guy,

ADC conversion noise is your friend.

Eugene

Re: Gyroscope saturation?
 

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?

Re: Gyroscope saturation?
 

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

Re: Gyroscope saturation?
 

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?

Re: Gyroscope saturation?
 

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().

Re: Gyroscope saturation?
 

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

Re: Gyroscope saturation?
 

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

Re: Gyroscope saturation?
 

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.

Re: Gyroscope saturation?
 

Eric and Kaszeta - thanks! That helps a lot...I am using Kevin's current gyro code, so that should work.

I'm learning so much more about programming this year - kind of funny that as we switch from autonomous to hybrid, our team is using more sensors and more intelligent code...

Re: Gyroscope saturation?
 

The trapezoidal integrator is important in order to filter out the noise. Below is post that goes into more detail.

http://www.chiefdelphi.com/forums/sh...3&postcount=32

Re: Gyroscope saturation?
 

At 38Hz (the RC control rate) trapezoidal integration is a very important tool to better approximate the integrated area. However, I suspect that sampling at much higher (~1000Hz) rates you can do a much better job of estimating the area using simple rectangular integration because the Riemann delta x values are much smaller (and you're well above the Nyquest response of the gyro).

This looks like a cool visualization aid:
http://www.vias.org/simulations/simu...iemannsum.html

And for those who haven't learned about Riemann sums in school yet, here's the pretty cool Wikipedia page (ignore the scary math and have a look at the images):

http://en.wikipedia.org/wiki/Riemann_sum

For the student that wants to learn even more:

http://en.wikipedia.org/wiki/Integral

-Kevin