Gyro not accurate - Problem


without calibrating the gyro too much, just by letting it calculate bias and then moving it (connected to a solid block of wood) 180 degrees and back, we saw that the gyro does not return to zero and actualey is off by 200-500 “numbers” each time (have not calibrated to radians or degrees yet).

so after one turn and back, instead of being at zero or very close it is around 500 and then after doing it again it will be at 700 or 300…

anything I can do to make it more accurate??


If you try to turn the gyro faster than its maximum rated rotational velocity, you will saturate the output and your counting will be off.

The kit gyro is good for +/- 80 degrees/second, which is actually quite slow for a turning robot.

What do those numbers (the error) come out to in degrees?

and how are you turning the block of wood so it returns exactly to where it started?

does the gyro output drift while its sitting still?

I think the max rotational velocity is the main issue. I will try and rotate it more slowly to see if this solves it.
can anyone point to other sensors which are compatible but have a higher max rotational velocity limit?

Analog devices has pretty much cornered the market for MEMs solid state gyros.

They have several. The ADXRS300 will track up to 300°/S. I have not looked at the gyro that is included in the kit of parts this year. The ADXRS familiy has analog outputs that must be handled as analog signals into the robot controller.

Thanks Ken,

I have heard that there are two types of gyros, one that tells you angular speed, and one that tells you angular position.

correct me if i’m wrong, but wouldn’t an angular position gyro work better for our purposes and be simpler?


Im not aware of a solid state MEMs gyro that gives angular position.

The NS ADXRSxxx devices output angular rate (degrees / second). This is exactly what you want for motion control feedback if you have an input that is commanding desired degree/S turn rate (ie, a joystick)

you simply compare the joystick input to the sensor output to see if the bot is turning as fast as the driver is commanding it to turn. That is your error signal for a feedback PID loop.

The same sensor can be integrated to get relative compass heading. Its simple to do.

assuming you scale the yaw rate sensor down to 8 bits, you would have a 16 bit variable, initialized to 32,000. Then on every loop through your code read the sensor, add it to that HEADING variable, and subtract 128 (for the zero reading offset)

then as your bot turns one way, the HEADING variable will increase, and decrease when turning the other way.

you can also let the bot sit still for a few seconds at power-up, and read the ‘not moving’ output of the sensor. That will be your zero point (might be 126 or 130… instead of 128). This way you compensate for drift, and you have control over the ‘calibration’.

If there are MEMs gyro chips that output heading, Id be interested in seeing the spec sheets. I know there are magnetic sensors that work that way, they tell you which way magnetic north is (in 3 dimensional space).

This is a really good (hint) suggestion. Remember that you have power to your robot when you set it up for autonomous. There is no reason to wait for the referee to turn on your motor controls to “fire up” and set the “not moving” value of the gyroscope. (Thanks to the Titan Robotics Club, FRC 492, for teaching us about this in the off-season.)

Just be careful not to move your robot around the starting zone once you’ve powered up if this is the case :wink:

when the robot is powered but disabled by FIRST field control system at the start of the match, the inputs are still being fed to the robot, the inputs from the user interface, and any analog or digital inputs on your robot itself. Only the outputs are disabled, that is what keeps the robot from moving until auton mode is started

so you could have your bot look for the auton or regular play bits to not be set yet, and use that time to calibrate your sensors. Your bot will always see several seconds of ‘disabled time’ after its been turned on, and before auton modes starts.

Is calibrating before auton legal?

And wouldn’t the judges moving the bot fudge the calibration?

No, it’s not illegal. Only driving away while disabled would be illegal.:ahh:

Actually the calibration on powerup should help if the referees decide to reposition your robot. Your robot will know when it gets moved and be able to correct for it. Calibration need only take a second and should be over and done with long before the referees get around to deciding to move it.

yeah, but you need to control when that ‘second’ is - so your team is not bumping the robot while turning the power on, and the ref is not moving the bot…

the second before the match starts would be best - you could calibrate continuously, and keep the last result when auton = T.

What we did in 2003 and 2004 for auto-calibrating the gyro was pretty simple: our custom circuit sampled the gyro for it’s “center” position after a 5 second delay when powered on. (Note that the gyro’s “center” position can be different every time you power it up!). So, setting up on the field was simple: just make sure the robot is off when you move it onto the field, position the robot, then as the last step before the team members leave the field to go to the driver’s station, power on the robot. That ensures that it’s not moving 5 seconds later when the gyro is sampled.

Finally, while disabled we’d keep zeroing out the integral that was used as the heading - this prevents it from drifting as the robot sits there before the match began.

I don’t know if this is an issue with the gyro from the KOP, but we use an ADXSR150 in a Robo-Magellan robot and found that the gyro gives different values when rotating clockwise vs. counterclockwise. So, when doing integration/averaging we use different denominators for values above and below the centerpoint.

Until we did this, it was impossible to rotate one way and back and get a angle value close to the starting value.

whoa! something was not right there. The ADXRS chips should output a + or - signal within their specs, regardless of which way it was turning.

Its possible there was something else wrong with the way the chip was implemented in your system: the analog circuit? filtering? the ADC converter?

The ADXRS chips have been used in systems where the measured total (compass) error is on the order of degrees per hour. They are normally excellent and very accurate.