An IMU is only as good as how it is mounted and configured. A perfect gyro on a vibrating, loose bracket will give you garbage. This lesson is the practical checklist.
Mounting#
- Mount it flat and rigid. The device should be parallel to the floor and bolted to a solid part of the frame, not zip-tied to a wire bundle. Vibration and flex add noise that integrates into drift.
- Keep it near the center of rotation when practical and away from large vibration sources (like compressor pumps) and strong magnetic fields (the magnetometer in 9-DOF units can be disturbed by motors and steel).
- Note the orientation. If the chip is mounted sideways or upside down, the axis you read for yaw changes. The Pigeon 2.0 lets you store a mount-pose orientation; otherwise account for it in code.
Calibration — know your device#
Calibration steps depend on the specific IMU, so read its docs:
- Boot/bias calibration: Some IMUs (for example the older NavX/NavX2 and the original Pigeon) sample their zero-rate bias at startup; for those, hold the robot completely still during boot, or the bias is wrong and drift is worse. WPILib's analog gyros expose a
calibrate()step done on a stable surface. The Pigeon 2.0 is different: it requires no boot or temperature calibration and does not need to be still at startup. - Mount calibration (Pigeon 2.0): Run the one-time mount calibration in Phoenix Tuner X after the device's placement is finalized so its axes line up with the robot.
- Level/offset setup: For devices that support it, set offsets so pitch, roll, and yaw read zero when the robot sits flat.
Zeroing heading#
There is a difference between the gyro's internal calibration and your field heading. At the start of a match you typically reset/zero the heading so the robot's current facing maps to a known field angle (e.g., set the pose/heading from your autonomous starting position). Provide a driver button to re-zero in case of a mid-match disturbance, but be careful: re-zeroing during teleop can confuse field-oriented drive.
Validate before you trust it#
Never assume the sign or scale is right. Quick checks:
- Spin the robot exactly 360 degrees by hand and confirm the reported yaw changes by ~360, in the CCW-positive direction WPILib expects (invert if not).
- Let the robot sit still for 30-60 seconds and watch the heading on telemetry — a good modern IMU drifts only a fraction of a degree; large drift means a mounting or configuration problem.
- Drive a straight line and confirm field-oriented controls feel correct.
These five minutes of validation prevent the classic 'the robot drives sideways in autonomous' disaster.
the part worth keeping
Key takeaways
- Mount the IMU flat, rigid, and away from vibration and strong magnetic fields; configure its mount orientation.
- Calibration depends on the device: some IMUs need stillness for boot bias; the Pigeon 2.0 needs no boot/temperature calibration, only an optional one-time mount calibration in Tuner X.
- Validate by spinning 360 (check CCW-positive ~360), watching still-drift, and confirming field-oriented drive before trusting it.
Programming, Controls & SensorsGyros, IMUs, and Orientationlesson 2 of 3
Keep going
Take the quiz+10 XP with an accountMore in Gyros, IMUs, and Orientation
where this came from
Sources and corrections
This lesson is AI-assisted: drafted from primary sources, then reviewed and edited by hand. Errors still get through. When one is reported we fix it and write down what changed, in public, in the corrections log.
sources and further reading
- v6.docs.ctr-electronics.comCTRE Pigeon 2.0 Calibration (Tuner X)
- docs.wpilib.orgWPILib: Gyroscopes (software)
clipped to this lesson
Articles that go further on this
The lesson gets you through the topic. These go wider on it, and they read in one sitting.
- 13 min readFRC Swerve Module Offsets: Calibration & Backwards WheelsZero your FRC swerve module offsets correctly, and fix wheels that spin backwards, modules that fight each other, and field-relative drive that feels rotated./blogread it
- 15 min readFRC Odometry and Pose Estimation: Field-Centric Control with WPILibHow an FRC robot tracks its field position with WPILib: wheel odometry vs pose estimation, gyro heading, fusing AprilTag vision, and field-centric driving./blogread it
- 17 min readFRC Sensors Explained: Encoders, Gyros, Beam Breaks, and Limit SwitchesA practical FRC guide to encoders (quadrature, absolute, CANcoder, through-bore), gyros (NavX2, Pigeon 2.0), limit switches, beam breaks, and current sensing./blogread it
answer sheet
Lesson quiz
All 4 right completes the lesson. Miss one and only that question comes back, anything you already answered correctly stays banked.
0 of 4 answered
01For an IMU that samples its zero-rate bias at startup (like the older NavX or original Pigeon), when should that boot calibration run?
02Why should an IMU be bolted flat and rigid rather than zip-tied to a wire bundle?
03What is distinctive about calibrating the Pigeon 2.0?
04How do you validate an IMU's yaw sign and scale before trusting it?
Answer every question to submit.
All 51 lessons in Programming, Controls & Sensorsopenclose
01 / prerequisites
02 / foundations-tools-and-first-program
03 / robot-program-and-command-based
04 / motors-and-control
05 / autonomous-trajectories-simulation
06 / sensing-fundamentals
07 / encoders
08 / gyros-imus-orientation
09 / closed-loop-control
10 / vision-pose-estimation
11 / worked-examples-mini-projects
- Not read yet:Mini-Project: A Closed-Loop Elevator with Motion Magic
- Not read yet:Mini-Project: A Velocity-Controlled Shooter on REVLib
- Not read yet:Mini-Project: A Teleop Swerve Drive Subsystem
- Not read yet:Mini-Project: An Autonomous Routine with PathPlanner
- Not read yet:Mini-Project: Vision-Aligned Scoring with Limelight
12 / common-mistakes-troubleshooting
13 / advanced-techniques-case-studies
- Not read yet:State-Space Control and Kalman Filtering
- Not read yet:Log Replay Architecture with AdvantageKit
- Not read yet:Advanced Pose Estimation: Multi-Tag Fusion and Standard Deviations
- Not read yet:Robot Coordination, Alerts, and Operator Feedback
- Not read yet:Case Study: Hardening Software Before an Event