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