Finding the best IMU

We at Blue Cheese are having an interesting problem. We’re trying to confirm our encoder measurements on our arm with an IMU, but our chosen IMU (the CTRE Pigeon IMU) has given us a few problems.

In order to get measurements, the imu has to be relatively flat upon startup, and in order to be legal, our arm has to start at a rather steep downward angle. We tried offsetting this with an angled mount, however the angle offset causes the IMU to flip over when the arm goes above around 20° above the horizontal. This causes the pigeon to behave strangely (the largest problem being lag).

In short, we’re looking for another IMU, one that either has a valid reading range larger than the Pigeon’s 180° or doesn’t require the same “levelness” during calibration as the Pigeon.

A Clarification
We already use an encoder. Our control system converts desired heights of the tip of the arm into angles, then into encoder setpoints. We use Motion Profiling to then move the arm to those encoder setpoints. Our problem is that, while more reliable than IMU’s, encoders aren’t always reliable (they’re subject to damage or electrical malfunction, for example). The IMU has been (and should be) acting as a failsafe – to prevent catastrophic failure.

1 Like

Couldn’t you confirm your encoder measurements with a bit of math for ticks per revolution and a protractor? For measuring rotation around shafts, encoders are superior to IMUs in this case because they don’t drift (assuming you geared the mechanism properly to avoid exceeding how fast the ticks can be counted and a functional encoder has been mounted correctly).


we are doing that already, we are looking for additional feed back to ensure our position. We added gas shocks to the arm to help with the torque.needed to move the arm. We also reduced the weight of the arm by several pounds. With the addition of the shocks and the backlash of the gearboxes we have a decent control of the arm(but there is the issue with being on one side or the other of the gear box). We are trying to get better control with more feedback so we know exactly where the arm is. The backlash is great enough that the arm can move several degrees before the encoder on the gearbox notices it.

I’m assuming you already tried fixing this in hardware? Fixing hardware problems in software is generally a bad idea, and backlash is especially something that causes lots of headaches in controls since it’s a nonlinearity (speaking from experience). It’s better to fix the source of the backlash instead.

You could have a complementary filter between your encoder and gyro to include the nonlinearity but compensate for gyro drift, but I really, really don’t recommend it.

IMU’s deal with this without software. That’s why we were looking into one.

You’re still going to run into accuracy issues; no gyro is perfect, and filtering can only get you so far (that is, the filtering the IMU does internally). This is an arm rotating around a shaft, not a missile, so an IMU really does feel like the wrong tool for the job here. I know that’s probably not what you want to hear.


we are open to suggestions. My first thought is to change which axle we are reading from but the IMU appears easier to add than changing things mechanically.

Showing what we have right now:

To avoid backlash, you really want to make sure the gears mesh well (axles need to be positioned so the edge of the gears’ pitch diameters meet), and that any chains between the motor and arm sprocket or whatever are properly tensioned.

It’s a high ratio gearbox so a small backlash mean several degrees on the arm.

Colocating your encoder where the arm actually rotates around (that is, after where any backlash is, so probably on your top sprocket), would help you measure the actual position of the arm, but that still doesn’t help you control it any better because your motor is before the backlash. Your controller will chatter as it tries to converge to your desired angle.


understood, we are looking for an IMU as a check on the angel so we don’t do this:

Is your goal to determine if the sensor broke during the match? That seemed to rotate way farther than backlash would allow.

sort of, we are just looking for something to increase the control we have. what you saw what a mechanical failure that we have remedied. Again, we are looking to increase the accuracy of the control we already have. The addition of being able to see when one sensor fails so we can go to a manual control is also a bonus.

For determining if a sensor fails in hardware, you’d be better off having two encoders that need to agree. Alternatively, if you use motion profiles for your arm, you could assume the arm follows it relatively well (a good assumption for a well tuned controller following a profile) and stop everything if the software notices the error got larger than it ever should under normal operating conditions.

As previously stated, adding a gyro won’t help you control for backlash better, it’ll just let you observe it. PID control is a linear controller, so it can’t compensate for nonlinear effects like backlash. Friction, another type of nonlinearity, can be dealt with using a feedforward, but backlash is way too nonlinear. Integral control won’t save you here either because it’s reactionary and will just add input lag to the system. You can think of backlash like a nondeterministic delay to your control inputs when switching directions.

IMHO your using the wrong tool and strategy for the job. What we do is try to put the CTRE mag encoder as close to the output of any mechanism and use the pwm absolute position to figure where it is at during bootup/enable period. Then we use the incremental portion after the initial boot for higher resolution and speed. During operation we check the “health status” of the encoder via the CTRE libraries. If the encoder ever fails we go into manual mode.

You could probably go one step further and verify location of the absolute position against a limit switch or hall sensor.


If you’re looking for something other than an encoder to use, what you’re really looking for is an inclinometer, not an IMU. But again as others have said, this will not provide you as much control as the encoder already does because more than likely your encoder will have a much better resolution than almost any inertial sensor, at least out of those legal for use in FRC.

Wilson - The Bosch BNO055 IMU does not have a startup orientation restriction. AdaFruit has it on a breakout board for ~$35. It requires some software dev to interface, unless you integrate an Arduino, or use our LabVIEW driver code.

Yes backlash is nonlinear, but you may be able to manage it before involving the PID (assumed here). If the arm has a home position, sense that. At movement initiation, remove lash with a motor command until home sensor trips (not at home). At that point use PID for position control. You’re separating control of non-linear from linear portion of system. Can use second and third homes to extend utility. May work for you, just ideas.

An IMU can be used as an inclinometer, by orienting an axis (say, pitch) along your axis of movement. An inclinometer solely based on an accelerometer is not recommended, as it will detect robot movement and garble your control signal.

Fixing issue mechanically is better, and preferred. Sometimes you can’t, easily.