Inertial Sensor not counting 360 degrees properly

Mounted sensor as vex-precision flat and straight as possible.
Aligning robot to wall. Allowing for the 2 second calibration.
We rotate robot clockwise 360 degrees then align to wall again. We got these values:

Start: yaw=0 heading=0 rotation=0
1st 360: yaw=-3 heading=356 rotation=356
2nd 360: yaw=-6 heading=353 rotation=713
3rd 360: yaw=-10 heading=349 rotation=1069

We then turn robot 3 times counter clockwise and align to wall and all 3 values return to 0, which makes us believe this has nothing to do with drift / vibration / bad initial self-calibration (tried several times).

Do we have a defective sensor (just one, can’t compare) and is this fixable through firmware / calibration tricks?


Is your sensor mounted on a piece of metal that is not completely straight?

Maybe try using a rubber link?

With the inertial it is kind of difficult to use rubber links, you have to mount the sensor to a piece of metal and then mount that to the chassis with rubber links.

dont do that, vibrations will magnify with a rubber link and any collision will send it shaking, screwing up your reading

We have it sandwitched between 2 pieces of metal with some rubber mesh in between. Problem is not vibration, the numbers are super consistent and clean, there is no drift and no spikes. Just the internal math seems wrong. A full circle is always missing 3-4 degrees. Like I said, we spin it back and it returns to 0 perfecly fine, but a full rotation is registered as 356 degrees instead of 360.

1 Like

Simple solution is to just scale the values to 360. Multiply heading by 360/356.5

This is assuming that the error accumulates consistently throughout the turn so you should test 90 and 180 degree turns, expecting roughly 1 degree and 2 degree error respectively.

Another recommendation is to test different types of turns: clockwise, counterclockwise, and swing turns. Maybe it will shed some insight on what is happening.

You mentioned aligning to the wall specifically before and after 3 turns. Maybe align to the wall after each rotation instead of after all 3.

Third idea is to try to fix your setup so that yaw = 0 throughout the revolutions. Maybe that is affecting the values.

Fourth Idea: the error is just accumulating very consistently forwards and backwards. Go with the scaling solution and move on.

Take the IMU off the robot and try doing a full factory cal


@jpearman: James, thanks as usual, factory calibration was the thing I was looking for (and I promise to get better at searching the forum). I did the factory calibration and it did not solve the strange issue. It is not a life-and-death situation (this is a test bot) but curiosity is high. I filmed our experiment as described in the original post:

1 Like

Out of curiosity, try placing the inertial sensor in a new orientiation, ie, place the sensor so the cable is facing up or down. I am assuming you are using a get yaw method of some kind. The IMU sensor is unique in that it automatically will redefine what axis is “yaw” according to gravity. It is possible that one axis of the actual sensor chip is experiencing an issue.

If you reorient the sensor that may help. In addition, try moving the port you are using for the sensor. Our team observed that some ports caused unexpected behaviors with the sensor and others did not.

What’s worked for me is to multiply the readout by a constant around 1.2 percent. It’s very consistent in it’s error so that worked for us.

A constant is indeed what we use as well and we actually love this sensor for its consistency. We also love it for its temperature correction (not sure if this is done at chip level or at VEX firmware level but it’s noticeably there) - rate sensors (basically accelerometers that sense spin) are notoriously sensitive to temperature fluctuations, this one is very stable, reads the same for a robot in a 36F garage as for when moved into a nicely heated room.

Just wanted to bring this up in case there is a simple calibration method to fix it or some firmware fix (this thing has nonvolatile memory on board and a Cortex chip), because although no expert in MEMS rate sensor operations but this seems to be more of an internal math thing. Also, I’m convinced many people don’t even notice this error as for our robots gyro assisted turns within +/- 1-2 degree range are “good enough” but if you want your auton to run around the entire field and have some precision, it matters.

1 Like