Strategies for prevent drift on Gyro

Our team utilizes the ADIS16448, and the drift from the gyro can be rather significant. We get the angle using the function imu.getAngleZ(). My first thought was to call imu.reset(); throughout the match, but that turns out to be problematic because it will throw the errorINVALID CRC when calling the angle.

Any strategies your team uses?

I mean, if imu.reset() doesn’t work, you could just simply create a wrapper around the IMU class that keeps a “zero” angle, and for each reading it just returns the sensor reading minus the “zero” angle. But since you’re using an IMU with a compass and accelerometer and everything, a Kalman filter might be able to give you very precise heading readings without drift. (Take it with a grain of salt as I’ve never done it myself, and the math behind it is quite complicated.)

Not to sound snarky, but we reduced drift by switching to a NavX gyro. It was definitely worth the investment. Sometimes the best solution to software is better hardware.


The ADIS16448 is at least as good as if not better hardware than the NavX, but the software (e.g. applied filtering / sensor integration) doesn’t seem to be as good.

Per the ADIS16448 spec: gyro in-run bias stability is 14.5 degress/hour (0.24 degrees/minute)

Per the NavX Technical Docs: gyro yaw angle accuracy of 0.25 degrees/minute when still, 1 degree/minute when moving

I wonder if the sensor integration software for the ADIS16448 is actually degrading the output accuracy due to interferences like motor magnetic fields. It may be worth trying to just get the gyro angle rather than the IMU fully sensor-integrated angle?

1 Like

Oops, mis-read the post as a ADXRS450, good catch.

So much for not sounding snarky.

On that note, follow the test procedure in Section 8.1 in Pigeon IMU. It’s general advice, even if you are not using Pigeon (using ADIS16448 instead).

That link appears to be broken, is this just me?

Oddly enough I tried pasting the same link Omar did and it broke itself. There’s something funky going on with Delphi’s linkage system.

You’ll find the document here:

1 Like

I guess that this is the correct link


cnc4’s got it. For some reason Delphi doesn’t like the apostrophe in the link. Looks like some kind of unicode / ASCII goofiness.


Can I ask if you’re using the Pitch/Roll/Yaw functions or the X/Y/Z functions? Whenever you use any of the getAngleX() functions on the ADIS16448, you are actually only reading the raw gyro data. We had built AHRS into the library which integrated the magnetometer (the Pitch/Roll/Yaw functions in the library), but the various metallic structures on a robot and magnetic fields generated by motors, etc. can have a negative impact on performance as you mentioned above, so we generally discourage teams from using the AHRS algorithms in the 448 library.

That being said, nothing is stopping you from implementing your own sensor fusion algorithms though. This article explains a little more on how different environmental factors can affect sensor performance. Bias Stability doesn’t always paint the whole picture - it’s just the best drift you can get out of a gyro under ideal conditions (think on a bench in a lab). I think it’s safe to say FRC is definitely not ideal considering you have vibrations caused by gearboxes, a compressor, and crashing into other robots (or, in the case of this year’s game, falling off of platforms). :wink:

What function should be called to get gyro angle with the AHRS implementation? Looking through them I can’t seem to make out which one.

It should be navX.getYaw()… something like that

The functions to use the AHRS calculations for the ADIS16448 would be getYaw() and similar (or Get AHRS in LabVIEW), assuming you set the proper yaw axis when you declared and defined your IMU object in code. The library defaults to using Z (roboRIO/IMU mounted flat horizontally on the robot) if you don’t specify one.

However, I want to re-emphasize/clarify what I mentioned earlier:

Directly quoted from the ADIS16448 FRC user guide (which can also be found here):

“Due to the size of typical FRC robots, AHRS calculations that rely on the magnetometer may be adversely affected by motors and metal objects close to the sensor.”

Since the AHRS implementation in the ADIS16448 library utilizes the magnetometer readings (not the accelerometer) as well as gyro readings, you might see negative impacts on performance when using the AHRS functions in this library if the IMU is not installed in an ideal location, away from motors and large metal structures. This can be a bit difficult in the context of an FRC robot. The AHRS algorithm in the ADI library is actually different from that used in the navX libraries. The navX documentation goes over the different sensor fusion methods and mentions why the use of a magnetometer to correct heading isn’t as suitable in FRC.

1 Like

@AlexBorca In case you are still using the ADIS16448 on your robot for this year, there’s an important update in Team Update 15. More info available in the following announcement:

By nature, all gyros drift, some worst than others.
The best solution would be to feed the gyro outputs into a Kalman filter along with all other navigation sensors, including accelerometers, a Navx if fitted with one and wheel encoders.
This is what most robotic navigators, such as the ArduRover or ROS-based robots, do.
I’m not sure the RoboRio has the computing power to handle a Kalman filter, or most of its variants, though.

Even the metallic structure of your typical institutional building will severely mess with the magnetic field in which the robot will attempt to navigate. So, yes, stay away from any algorithm that relies on compass/magnetometer readings.

The Rio definitely can handle a Kalman Filter

1 Like