Gyro and accelerometer doc trouble

I’m a mentor for a new team. I’m reading through the docs at and am confused about accelerometer and gyro support. It looks like we’ll want a gyro to assist with driving but I don’t see one to start with in the kit of parts. As I read through the WPILib section I get the impression that there was a standard gyro but you can’t order it from AndyMark. Do I understand that correctly?

Just trying to read the documentation is a bit confusing. There are a lot of references to past years and some go way back such as When reading that page I was curious about the wiring for the accelerometer so I tried to follow the link to ’ FRC component datasheet’ but that goes to an Oops page. Did past teams not find any use of accelerometer causing that page to just be left in docs but broken? Is there some other documentation we should be reading that is more up-to-date for 2019?

Thank you.

That Screensteps documentation looks pretty stale!

I don’t see any gyros in this year’s kickoff kit of parts (what you got in the totes).

Assuming you haven’t used all of your FIRST Choice credits, and the gyros didn’t sell out in round 2 (which is closed, but we won’t see what’s sold out till Monday) there are a number of gyros available through FIRST Choice:

Analog Devices’ documentation for these three gyros is available here:

I can’t speak to the usability of any of these, as we’ve happily used the navX MXP for the last few seasons: to buy:, vendor page:

All four of these options plug directly into your roboRIO either via the SPI or the MXP port, so you don’t have to worry about interfacing to analog inputs. Also, all four options have a pretty simple software interface: 1. create instance of vendor-provided class, 2. calibrate (if the vendor library doesn’t do this in the constructor), 3. use the “getAngle()” (or similar) method to get the robot’s yaw (relative to its original heading).

The first two FIRST Choice options and the navX MXP also have accelerometers which are accessible via methods provided by the vendor library. There’s also an accelerometer built in to the roboRIO that you can access via the BuiltInAcceleromter class (

Edit: add accelerometer info

1 Like

Fantastic. Thank you for the info and links.

My team (FRC2655) has used the ADIS16448 every year since it’s introduction and we’re upgrading to the ADIS16470 for this year. We haven’t had any issues with them and love them!

Full disclosure, I’m an engineer at ADI and wrote the user guides linked above, and my better half works in the group that develops the two IMU parts and he designed all three of these boards. (So, definitely reach out if you guys have any trouble with these sensors!)

1 Like

What’s the estimated drift rate on the ADIS16470? (I couldn’t find it in the docs - just that “[t]his sensor has the lowest drift of any ADI board for FRC.”)

Comparing the datasheets…

ADIS16448: 14.5 deg/hr in-run bias stability (1 sigma)

ADIS16470: 8 deg/hr in-run bias stability (1 sigma)

1 Like

I posted this in another thread, but drift on any device will rely heavily on the mounting, alignment, and environment of the sensor. The bias stability numbers listed in the device data sheets will hold true under ideal conditions (25C, low vibration, stable supply, etc.), but may not be attainable in systems such as FRC robots. This link further explains the influence of vibration and misalignment on gyro stability and eventually heading estimation.

I’m hesitant to put a number on what the estimated drift of our IMUs will be when used on FRC robots, but I can say that our IMU will be significantly less influenced by vibration (due to our angular rate gyroscope design), more stable over temperature (due to unique temperature calibration), and lower noise (rms noise due to proprietary MEMS designs) than IMUs designed around consumer-grade sensors.

As for comparing the 448 to the 470, the 470 will have much better stability, noise, and vibration rejection performance due to new sensor cores, improved calibration procedures, etc. Both IMUs have built-in gSensitivity (gravity sensitivity) compensation calibrated at the factory over temperature.


The Pigeon IMU from CTRE is another good option if you end up buying one. Easy connection via gadgeteer cable to a Talon, with minimal/negligible yaw drift (mind you, I haven’t compared to yaw drift on the others mentioned here).

Example with the Pigeon plugged into a Talon (there are other options for wiring):

TalonSRX talon = new Talon(0);
PigeonIMU pigeon = new PigeonIMU(talon);
double [] ypr = new double[3];
double yaw = ypr[0];
1 Like