NavX GetYaw, GetAngle, and Quaternion values are wrong/inconsistent/buggy

Rather than attempting to use clever prose to work them all into a few sentences, I’ll just give a list of things that don’t work, then some context :slight_smile::

  1. navX (AHRS).GetYaw(): Returns values that hover around 88 and don’t change until the robot rotates around 180 degrees, then starts hovering around -90-something.
  2. navX.GetAngle(): similar incontinuity (I’ll edit this when I test again)
  3. Quaternion values (x * w * 360): reports angles in the range of [-90, 90], if you go above (say, 100) it loops backwards, so 100 is 80, 110 is 70, 120 is 60, etc. Otherwise, however, this angle is very continuous and useful.

This is, of course, in reference to an FRC robot using a NavX MXP, one which needs to rotate to an angle during autonomous. Does anyone know why this might happen?

If I didn’t provide enough information, please tell me; I did not include a code snippet because it would be a single line containing a shuffleboard command that sends a number to the DS. (int)(360 * navX -> GetQuaternionX() * navX -> GetQuaternionW()) + 90; is the exact code we use for quaternion, and it works well except for the issue above.

Thanks in advance!

We have had good success using the GetAngle() method. Try plugging it into your computer and reading it with the NavXUI; does it report accurate values then?

Couple of questions to start:

Is this navX-MXP or the navX2-MXP?

What orientation is the sensor mounted in? The typical orientation is Z axis up (as shown on board silkscreen). If it’s not in that orientation, I could imagine behavior like you mention. For non-typical orientation mounting, see the Omnimount section at Kauai Labs navX-MXP - 9-axis IMU for FIRST Robotics

I believe it’s a NavX2-MXP; I’m not sure what the distinction is. How do I find this?

The same thing does happen (wild fluctuation), but somehow it is able to draw the graphic accurately, so at least the quaternion values should be accurate.

The boards are very similar, however there’s a silkscreened name on the top of the board, it says either “navX MXP” or “navX2-MXP”. Here’s a photo of what a navX2-MXP looks like:

If it is a navX-MXP board: be sure you’ve followed the Omnimount instructions - if you’ve mounted it in a nontraditional orientation.

If it is a navX2-MXP board, update the firmware to version 4.0.433. This update is available for download via the “Download” button on the navX2-MXP sensor software page . Instructions for updating the firmware can be found here .

Next, follow the omnimount instructions if it’s mounted in a non-traditional orientation.

Finally, it’s highly-recommended to perform Gyro Scale Ratio Factor calibration, using the navXConfig utility’s Sensor Fusion Tab; this is discussed in the article “Optimizing Accuracy of a Generation 2 navX-Sensor ”.

The basic order of operations for navX2-MXP is:

  • update navX2-MXP firmware
  • run Factory Calibration (with sensor is final mounting orientation)
  • perform Gyro Scale Factor Calibration as described above.

By following this, the yaw angle displayed in the navXUI should be as expected.

Note that the yaw angle displayed in the navXUI is internally derived from the quaternion. So the two should track each other.

For reference, here’s the conversion from quaternion to yaw, pitch and roll (in radians):

// yaw: (about Z axis)
data[0] = atan2(2*q -> x*q -> y - 2*q -> w*q -> z, 2*q -> w*q -> w + 2*q -> x*q -> x - 1);
// pitch: (node up/down, about X axis)
data[1] = atan(gravity -> y / sqrt(gravity -> x*gravity -> x + gravity -> z*gravity -> z));
// roll: (tilt left/right, about Y axis)
data[2] = atan(gravity -> x / sqrt(gravity -> y*gravity -> y + gravity -> z*gravity -> z));

Most don’t use the quaternions to convert to yaw angle, since this is already done for them in the result returned from getYaw().

The navXUI displays (in the board info window) the orientation. The default is “Z-up”. This corresponds to the traditional board orientation.

Does the board info indicate a yaw (gravity) axis orientation that matches how the board is mounted?

Mismatches in this area can cause symptoms similar to the wild fluctuation you are talking about - because if the axis the motion processing algorithms think is the “gravity” axis is not, it will make unwanted adjustments to the measurements.

Thank you to everyone who helped! The issue was solved by factory calibrating the NavX in the position it will be mounted on the robot; now we get consistent [-180, 180] angle values and are able to accurately rotate-in-place.


This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.