I’ve seen many talking about using gyro’s in the control system. Last year we only used banner sensors for counting distance and dead reckoning for autonomous. Some questions come to mind:
Is there enough sensitivity to use these for drift? Can the signal be integrated to provide actual position.
Which gyro’s would be the best to use for this purpose?
Can all this be done with just the FRC, or do some teams use auxiliary IC’s?
We were happy last year just to get the new system going and would like to improve our controls.
As far as I know, the best/“only ones allowed” gyros are the Analog Devices ones, ADXRS150 and ADXRS300. (I just checked Analog’s website and apparently they have a new 75°/sec model, let’s see if any official supplier stocks them.)
As the model name implies, they are capable of 150°/sec and 300°/sec, and as some people found out by the datasheet, resolution can be improved by a factor of 4 with a simple resistor network.
So, to answer your first question, they’re pretty sensitive - 150 and 300 degrees per second equals 25 and 50 RPM, respectively, and that’s pretty fast for a 'bot to turn (check team 419’s 2001 robot, that thing spun fast!). If your robot is hit, it may “turn” a bit faster than that, and you may lose track - take that into account.
It’s accuracy is good enough for the 15 seconds of autonomous operation. A simple integration of the angular rate will give you angular position - we tried using rectangular infinitesimal elements and achieved moderately accurate results, some teams reported using trapezoidal integration with better accuracy. Also, don’t forget to sample the signal at twice it’s frequency to avoid aliasing.
The answer to your third question is yes and yes. Some teams used only the Robot Controller, others turned to a separate processor. It will depend on how much processing power you need, but if you’re only integrating the gyros and calling relatively slow interrupts, you should be OK with the RC.
Whoah, long post… Hope I didn’t sound too confuse.
If you order one of the Analog Devices gyros make sure and get the part ending with “EB”. It will be either ADXRS150EB or ADXRS300EB. The part without the EB is just the sensor and it will be unusable on its own unless you have someone with a reflow oven and experience etching PCBs. Its tiny and the pins are on the botton. The EB parts (Evaluation Board) come mounted on a small PCB that will fit into an IC socket. They look sort of like a Basic Stamp. It uses very little current so you can power it directly from the robot controller.
I don’t know yet what the frequency response of these guy’s are, but I’d be surprised if the high frequency components contributed much at all to the basically DC position we are looking for, that is after integration. But it’s a good point either way.
Last year we got an Analog gyro and it was just a little black plastic case with three wires coming out (red, black, and white) that we could plug with into the control system. The problem is we don’t have it anymore and I don’t remember what model it was. Can anyone tell me? Thanks.
Also, can we get into the discussion of what type of output they give and how it should be programmed (pseudo code please) to do something like measure angle of turning?
My end goal would be to have a robot with shaft encoders on the wheels and something (gyro?) to measure what its angle is relative to the field. I know a gyro/accelerometer/whatever know’s its angle to gravity, but how can it be used to measure something like angle of turning when the turning plane is perpendicular to the pull of gravity?
I’m quite new at the whole gyro thing and have very little experience with programming so if the concept of making this happen was explained in simple terms, I’m sure it would greatly benefit many of us. Thanks in advance.
Download the latest white paper titled “An introduction to C programming for FIRST robotics applications (most recent version dated 11/20/04)” from the technical page on www.srvhsrobotics.org, and have a look at the section on Integrating a Rotational Rate Gyro that starts on page 35.
While I have never used a gyro with a FIRST robot autonomous system, I have some experiences with them.
First, a gyroscope will give you the angular velocity of the base platform. This will need to be integrated to obtain the angular position, if that is what you desire. Integration can be carried out by analog circuits (easy), an auxiliary microcontroller (harder), or software (easy).
The main problem with integration is noise. I had once built a mini-navigation unit and strapped it to a model rocket. But before I launched it, I did some testing on my desk. From just noise, I had the thing think that it was spinning at 15 rev/s in just 20 minutes. And that was just on a desk.
I have done some testing with closed loop steering and the old FIRST gyro. There are some people who like closed loop steering (me, for one) and some who do not. I found that it made a vast difference on a test platform, making driving more intuitive. But then again I’m not a driver.
A gyro is a great feature to have on a 'bot. They offer flexibility in terms of driving, autonomous systems, and other areas as well. One idea we once had was to mount a gyro sideways. The gyro would have given us angular tipping velocity (if we were tipping), allowing to compensate and not fall over. Now, we had wanted a gyro for normal navigation as well, so someone came up with a clever device that turned the gyro sideways whenever we were in an area where we might have tipped.
The gyros here, from Analog Devices, have excellent stats compared to our old FIRST ones. Use them well and your robot will achieve wonderous things.
Could you elaborate on this a little? Exactly how does the nyqyist theorum, bandwith, sampling rate etc relate to this application? How do you calculate the needed bandwidth for something like this. I don’t know much about such things but i would like to learn. It seems to me that bandwidth should’t be of all that much concern in this application as we are not doing anything related that relies much the spectral purity of the data, and the relevant data should be of relatively low frequency. IE: a physical system such as a robot will only change acceleration soo fast under normal conditions. Any data above a certian frequency is probably error and it seems it would be advantageous not to digitize this. While undersampling would help eliminate hf noise, it also creates problems with aliasing as you mentioned. It seems to me that too high of a bandwidth might actually be a bad thing because you would be digitizing more of the high frequency errors as well as the relevant data which it seems would be rather low frequency. Would i be correct in assuming this, or am i totally confused?
The simplest way to think about this particular situation is from the point of view that you are sampling the signal at discrete points in order to integrate the area under the curve as a function of time. It is most usefully done with the trapezoidal rule, but in any event it boils down to adding up the sampled points in some fashion.
Suppose now, that the signal is a sine wave at the maximum frequency the bandwidth of the gyro will support, and you sample at this frequency with the computer. The computer will periodically pick off the same point in the sine wave, and get whatever constant value your luck will deliver. It might be zero, but it might also be the maximum or minimum value, and the integral you would get would reflect this problem. You have a sine wave with an average of zero, but you are getting a bias in the time integral as if you are integrating a constant.
If you sample at twice the maximum frequency, you will get alternating negative and positive values, and no bias for the integral. If you sample at an even higher rate you will start correctly integrating the sine wave with precision. To obtain this desired result, you either increase the sampling rate used, or decrease the bandwidth of the gyro by adding a suitable capacitor.
