Reducing Drift in KOP Gyroscope

[TogetherSword8]

I have done some digging into why our autonomous code didn't work last year and discovered the drift that I found was referenced in some other parts around this forum, and i think it is in all KOP Gyroscopes.

Does anyone know the best way to reduce this drift besides make its mount completely level? because I cannot find any other way, and I don't know how to go into it to see if there is any settings to change.

Thanks for any help or ideas

[Joe Ross]

What is the magnitude of the drift you are seeing?

[nathan_hui]

The quick and almost useless answer is sensor fusion/Kalman filters (It's useless because it's not a simple answer).

Are you just using the gyroscopes? Gyroscopes are inherently susceptible to drift (There's no perfect sensor for any application, only the most optimal). You theoretically can use a set of accelerometers to zero out the gyroscopes continuously, and as another set of data to measure robot orientation. Could also use your wheel encoders to tell you when you're stopped.

See http://stackoverflow.com/questions/1586658/combine-gyroscope-and-accelerometer-data for more information, or search Kalman Filters, Sensor Fusion.

[sur]

Are you just using the gyroscopes? Gyroscopes are inherently susceptible to drift (There's no perfect sensor for any application, only the most optimal). You theoretically can use a set of accelerometers to zero out the gyroscopes continuously, and as another set of data to measure robot orientation.

An accelerometer won't give you heading. If the acceleration on your robot is mainly due to gravity, then you can look at the magnitude of acceleration in each axis to measure tilt. You could use a magnetometer to measure heading and combine it with the gyro, but you might have to make sure you don't get noise from the motors. See http://robotics.stackexchange.com/questions/442/how-can-the-dynamic-effects-of-motor-current-on-a-digital-compass-be-characteriz for some information on magnetic shielding to prevent this.

[z_beeblebrox]

What about averaging the heading from multiple gyros?

I heard from a member of 1717 that doing this helped them a lot.

[nathan_hui]

An accelerometer won't give you heading. If the acceleration on your robot is mainly due to gravity, then you can look at the magnitude of acceleration in each axis to measure tilt. You could use a magnetometer to measure heading and combine it with the gyro, but you might have to make sure you don't get noise from the motors. See http://robotics.stackexchange.com/questions/442/how-can-the-dynamic-effects-of-motor-current-on-a-digital-compass-be-characteriz for some information on magnetic shielding to prevent this.

True. It won't give you heading. But it will tell you when you're not moving. And that's the key to preventing the gyros from drifting. If you're not moving, the gyro shouldn't be moving either. If you have two accelerometers and you know the distance between them, you can calculate the amount of turn. Magnetometer may or may not work - you're in an environment with way too many motors and ferromagnetic materials (i.e. screws). Shielding also only does so much. In the end, you'll probably end up running a software filter over the data anyways.

[Ether]

True. It won't give you heading. But it will tell you when you're not moving.

An accelerometer does not tell you when you're not moving. It tells you when you are not accelerating.

[sur]

True. It won't give you heading. But it will tell you when you're not moving. And that's the key to preventing the gyros from drifting. If you're not moving, the gyro shouldn't be moving either. If you have two accelerometers and you know the distance between them, you can calculate the amount of turn. Magnetometer may or may not work - you're in an environment with way too many motors and ferromagnetic materials (i.e. screws). Shielding also only does so much. In the end, you'll probably end up running a software filter over the data anyways.

This thread (http://www.chiefdelphi.com/forums/showthread.php?t=81534) seems to suggest that the HiTechnic sensor is pretty accurate.

But to answer OP's question more directly, I don't think you should be seeing much drift during a single match. The gyro should be mounted as level and close to the center of the robot as possible, since it measures rotation around the axis perpendicular to its board:

The angular rate sensor (gyroscope) using Analog Devices part number ADW22307 detects angular changes about the board’s top surface axis.

from http://www.andymark.com/product-p/am-2067.htm.

[TogetherSword8]

But to answer OP's question more directly, I don't think you should be seeing much drift during a single match.

The problem that we had this year was it drifted prior to the match, and our initial driving based on the gyroscope angle was off, because it drifted a different amount depending on the time from robot placement to when they actually started the match.

I have thought about putting in a software cancel, would something like that be a if encoders are not moving, keep angle the same, and count the accumulation in the code instead of letting the gyro do it itself, and reset the gyro every iteration? That is the only way i could think of doing it.

[Ether]

The problem that we had this year was it drifted prior to the match, and our initial driving based on the gyroscope angle was off, because it drifted a different amount depending on the time from robot placement to when they actually started the match.

Simply reset the gyro at the start of the match.

count the accumulation in the code instead of letting the gyro do it itself

The gyro itself does not do any accumulating. That is done in the FPGA, which probably does it much more effectively that you could do in your code.

Some teams have added a manual reset function that the driver can activate by simply pressing a button when the bot is at the zero position any time during a match.

[Gdeaver]

Our team is looking at using a gyro on the bot next year. The gyro we are looking at using walks down .01 degrees every 2 to 3 seconds. How does this compare to other gyro's teams have used? At begin autonomous just zero the gyro accumulator.

[otherguy]

Our team is looking at using a gyro on the bot next year. The gyro we are looking at using walks down .01 degrees every 2 to 3 seconds. How does this compare to other gyro's teams have used? At begin autonomous just zero the gyro accumulator.

That's similar to what I have seen.
If you consider the duration of the autonomous period (15 sec.) and assume a drift of 0.01 degrees every 2 sec. (the worst case of what you reported) you're going to accumulate a total drift of 0.075 degrees. If you can't handle that kind of error, you're doing something wrong.

A good rule of thumb to follow with the gyros, reset/zero them any time you know you are stopped (beginning of autonomous). This will reduce the effect the drift has on your reported heading.
Also, make sure that your sits still after you turn it on (make sure your drive team understands this). The gyro is calibrated during this time and movement will affect the magnitude of drift you see. Try shaking it around when power is applied to the cRIO and see what happens.

[Ether]

If you ... assume a drift of 0.1 degrees every 2 sec. (the worst case of what you reported)


Typo. He reported .01 degrees every 2 (or 3) sec.

[Gdeaver]

The gyro we will be using is a Invensense MPU-6050 on a break out board from Sparkfun. The MPU6050 has an on chip motion processing engine and output in quaternions. It takes allot of code to bring up the chip. We are using an Arduino Uno to handle this. We mounted the break out board on a Arduino Proto typing board. We then use the Arduino Ethernet shield to transfer the the data to the c-rio using UDP. The Arduino takes the quaternions and calculates the gravity corrected Yaw, pitch and roll. We also have put single channel encoders on the 2 rear wheels. Hopefully this will give the students enough input to actually do some autonomous navigation. Our swerve drive does not like to go straight and has given us lots of problems in the past. The gyro will also be used to develop field centric swerve control. The students will have a full plate this fall. Work begins next week. As a back up to acquire a high resolution X and Y motion, we have looked at a lazer gaming mouse with a ADNS9500 chip in it. Tracks good on carpet.

[Hugh Meyer]

When the robot starts up the gyro runs a bias measurement and calculation. During this time the robot must be absolutely still. This process is measuring the offset in the device, which when integrated translates to drift.

We tell our drive team to start up the robot at the last possible moment and make certain that the robot is not bumped or disturbed during this initialization time. The compressor cannot be running during this time if you want the best result.

Kevin Watson has some really good code and information about this on his website kevin.org. Look in the FRC code section. It is code from the old IFI controller, but it is very educational.

http://kevin.org/frc/ Look in the frc_gyro.zip file.

Another helpful trick is to mount the gyro on a mass and mount that in foam. We use a one pound piece of aluminum and some foam that hard disk drives are often packaged in. This acts as a low pass filter and helps smooth out the data. See the attached photo for our arrangement.

Keep working with the gyro and accelerometer. You can do some really cool stuff once you understand these devices. Have fun!

-Hugh

[Jared Russell]

If you make some modifications to the WPIlib Gyro class code you can add the ability to re-calibrate the gyro via a button press on the driver station during the Disabled state before the match starts. All MEMS gyros are sensitive to heat, and they self-heat once they are on. If you turn on the robot and the MC takes a while to start the match, there is a good chance that the initial calibration will be quite a ways off by the time the match starts. Recalibrate at the last possible moment, and also zero the accumulated heading at this time, and you'll be in good shape.

Averaging multiple gyros can help, but not eliminate, the drift issue. Pretend you have N identical gyros on the robot. As N approaches infinity, you can basically eliminate any random errors that accumulate over time. But, you cannot remove systemic errors (errors that are common to all of the gyros). Systemic errors include nonlinearities, thermal sensitivities, cross-axis sensitivities, alignment errors, etc. To reduce systemic errors, you generally need a better gyro. There is a reason (well, multiple reasons) that NASA does not use the FRC KOP gyro on their spacecraft. With inertial sensors, you often get what you pay for. The good news is that, for FRC applications, the KOP gyro is usually fine for 15 seconds of autonomous mode. If you want to do field-centric control for a holonomic drivetrain, it might be worth spending $50 or so on a superior gyro.

Fusing a gyro with encoders (via a Kalman filter or other techniques) helps in a few specific cases. Namely, you gain the ability to do a "zero velocity reset". In other words, if you KNOW you aren't moving (because the encoders aren't changing state), you can disregard any gyro movements during these periods. In general, though, the complexity of an extended/unscented Kalman filter will outweigh the benefits in 99%+ of cases.

[stevethetinker]

We (1288) have used gyros in some years. The stability of the KOP gyro was not an issue. They have been good enough for the autonomous period. The 2010 robot had a gyro, but was not used in competition. I have since been working with that robot developing a better drive system. The gyro drifted enough to be a problem. It would drift 10 degrees or more in just a minute or two, which was a big problem for field-oriented drive controls. I replaced it with a new gyro from Andymark and the drift is much less. I'd say your 0.01 degree per 2-3 seconds is good for this technology. As noted in other posts, these gyros are temperature sensitive. There is an on-chip temperature sensor that you can access through another analog input. The hard part is measuring the temperature-drift equation. Once you have that you can compensate for most of the drift.