I was thinking about using this years gyro in the KOP to keep our robot driving straight, but a mentor expressed to me that the gyro would have problems detecting the slow rate of turn we have. He said that the gyro was better at detecting drastic turns like 90 degrees.
You teams that have used the KOP gyro before, can you tell me how realible and sensitive it is for detecting turns and for keeping the robot in a straight path?
Much appriecated,
Alex
we’ve been using 300deg/sec analog devices gyros since 2004. We’ve had great success with them for driving straight. We’ve also integrated the signal to give an angular orientation. Since the k.o.p. gyros will saturate at lower turn rates, we have not used them, but for aiding in straight driving, I see no reason not to try them. We sample the gyro during disabled mode and let a neutral point value settle out. This becomes neutral for the next 2min and 15 sec. We typically take the average of the current and last pass readings and use that, minus, the neutral point, as the error. Then with a multipler (proportional gain) like 1/4 * the error , we add the delta value to the motor pwm on the side it is drifting towards.
We just read the gyro in the main loop (38hz), and it works like a charm.
if you use the KOP gyro, a quick decelleration will throw the integration of the signal WAY off. be careful. Personally, i dont really trust the gyro for absolute positioning, though it does help drive straight.
Agreed, our team used the gyro for driving straight last year, and it worked very well.
Your mentor is correct, in that the gyro probably isn’t good for, say, automating subtle turns with high precision, but we have had no problem using it to keep the robot from drifting off to one side when it shouldn’t.
As long as you’re on the topic, where did you go to learn how to use the gyros? Is there another way besides using Kevin’s code? Like always, the simplest solution will be the best 
and I find that Kevin kind of goes overboard with his code (hence the need to all but re-write the default code).
Demothesis
Really… you need almost all of the ‘overboard’ code he writes. If you’re planning on integrating rate of rotation up to absolute angle with any kind of repeatability, you MUST have extremely precise sampling timing so that you don’t under or over integrate a specific sample of rotation rate. Any variations in the sample rate will cause erroneous headings.
The reason kevin’s code looks so confusing at first is that it allows the analog converter to run in a hardware triggered mode. This way, as much of the time critical sampling as possible is done on a hardware only basis, to cut out any possibility of interrupt overhead causing a variation in sampling interval.
It’s a really great system… that would be even greater if the processor in the FIRST controller had DMA like some of the newer/fancier Microchip processors… imagine hands-off gyro oversampling that only bothers to interrupt your code after all the samples have been taken, since they were directly recorded to RAM by the DMA.
-q
There is no need to rewrite the default code… kevin’s code just requires an initialization call in the init function, and an ADC processing call in the fast loop. nothing really big.
To learn how to use a YRG, you need to mainly read the manual, and understand that every gyro is essentially different. Each gyro has its own ‘zero’ point, and this point varies with temperature. Thats why it is required to ‘calibrate’ the gyro’s zero point when you turn the robot on. basically all this does is average all the zero samples together to get the absolute midpoint.
Next you have to understand its a RATE sensor, so in order to get an absolute position, you need to integrate. this means you have to esentially keep a running summation of all the values returned from the gyro (minus its midpoint) times time.
thats all there really is to it… kevin does a couple of other things like degrees-to-radians and sampling/deadzone modifications for different gyros, but thats just to deal with the consumers of his code that have different hardware.
We were just discussing this issue. Our team really needs help in this area. Who makes a dependable gyro and sensors for track position and where to get it these items? And helpful hints for putting it all together. This is my first post, so excuse the lack of zest… Dave
I hate to hover/monopolize but… well I was in the area. :o
You can’t go wrong too easily with the ADXRS150EB. This product will soon become unavailable due to (i think) RoHS/Pb-Free conversion, but should be replaced by the soon to be activated part: EVAL-ADXRS613.
Other than that, look to Kevin Watson’s awesome code library for the 18F8722 processor. He has a driver already all boxed up and ready to run the whole gyro. It can be used straight out of the box with the gyro, or can be easily modified to fit pretty much any application for sensor data integration over time you can come up with (i.e. getting velocity from an accelerometer).
If you need anything more specific, just post/PM/see us in Atlanta.
-q
p.s. I just realized you said position too. For that, look to grayhill or my favorite, U.S. Digital. They have some economical yet robust encoders that are great for FIRST. Couple these with an appropriately sized spring coupler to increase life/reliability.
For driving straight, you don’t actually need to integrate the gyro output. While that method results in more intuitive controls code, you can re-arrange your controller to accept the non-integrated gyro rate.
Consider the following pseudo-code:
Left_Motor[n] = Left_Motor[n-1] + Gain*(heading[n] - desired_heading)
Right_Motor[n] = Right_Motor[n-1] - Gain*(heading[n] - desired_heading)
Where “n” is a time index.
This is essentially two proportional velocity controllers with the gyro angle (integration of the rate) as the process variable.
We can differentiate (in a discrete sense) both sides of these equations!
Left_Motor[n] becomes (Left_Motor[n] - Left_Motor[n-1]).
Left_Motor[n-1] becomes (Left_Motor[n-1] - Left_Motor[n-2]).
heading[n] becomes rate[n], and desired_heading (a constant) becomes desired_rate (which is zero).
Repeat for the right side.
So now,
Left_Motor[n] - Left_Motor[n-1] = Left_Motor[n-1] - Left_Motor[n-2] + Gain*rate[n]
You can do some algebra and re-arrange to get:
Left_Motor[n] = 2*Left_Motor[n-1] - Left_Motor[n-2] + Gain*rate[n]
Look weird? Absolutely. But will it work correctly? Yes.
You do probably will want to filter the rate[n] input since Kevin’s oversampling and heading calculation essentially accomplishes this for you (integration can be considered a low-pass filter).
I haven’t tried this method myself, as Kevin’s code saves us a lot of time and works great, but if you really want to DIY, this will let you cut out the hardware ADC.
General Note: This method of differentiating both sides of a controls difference equation is a powerful tool, and is a good way to derive control equations that you hadn’t thought of before! Just beware that integration is usually a GOOD thing in control systems and you usually don’t want to remove it without a compelling reason. But if you, for example, remember the position version of a PID equation, you can quickly generate the equivalent velocity control PID equation using this method.
Abwehr: I understand your code, but in essence it is only correcting for a rate. Sure, it will get the ‘drive straight’ stuff done, but if the robot gets knocked off course it wont know where to go to.
Given the depth of your post though, i think you already know this d=
We had something similar implemented in our code for the purpose of having the robot ‘turn’ or ‘arc’ at a predictable rate… it was good except for the jitter.
Actually, it will return to the same position (assuming that the rate signal is not jittery :)).
Try it out in excel, and you’ll see that you are actually performing integration implicitly.
Make one column a time index (n) 1, 2, 3,… (A)
Make one column a detected gyro rate (random numbers if you want). (B)
Make one column the gyro heading (i.e. =SUM(B[1]:B[N])). (C)
Make two columns for the outputs under the different algorithms (D and E)
D, the original algorithm, would be =D[N-1] (or 0 for the first cell) + Gain*C[N].
E, the non-integrating algorithm, would be =2E[N-1] - E[N-2] + GainB[N].
Fill in 0 for E[N-1] and E[N-2] where those values would be outside the bounds.
Columns D and E will be identical.
The problem with this simplification is it essentially assumes that a 38Hz integration gives valid data. Like I said in the above post, this method is a sort of numerical curiosity - it would throw out all of Kevin’s oversampling and timer-based ADC code and the benefits that that brings.
I agree, that is a numerical curiousity. I guess ill actually have to do the math out to see that one then.
This was our first year using a gyro. We used the one from the KoP. We used it to help keep the robot on the “straight and narrow”, and it worked okay… at least in conjunction with two other advances (well, they were advances for us).
One: the joystick code was retuned using a lookup table to approximate exponential readings (ie, very little turning when the stick is near centre, but full readings when near the edges.)
Two: we used the IFI USB Chicklet attached to a Logitech game controller. The game controller has two analog joysticks, one for each thumb. We use one thumb for forward/reverse and one for left/right. By seperating the two we no longer have to worry about accidentaly making the robot turn when we are trying to drive straight.
In any case, as far as learning to use the gyro, just hook it up to an analog input and use printf statements to show you the readings so you can get a feel for it. Yes, you can turn the KoP gyro slowly enough that it won’t show any readings… but is that EVER a slow turn. Then stick it to your robot and experiment with some of the code samples as posted above.
Adding stuff like the gyro not only makes your robot easier to drive, but helps you to explain to people the differences between tele-operated mode, where the robot makes decisions based on your input, and plain old radio controlled toys where the toy follows your decision mindlessly.
Jason