Navx reset problem

So, we are using the NavX MXP to control the robot rotation and we are getting strang readings.
After calling reset() to reset the yaw angle the result of getYaw() is still the last value (even sometimes for two cycles untill its resets) and only then reset to 0.
The weirder part is that the getAngle() method can return 0, then back to the last value and then 0 again or just like the getYaw() method.

We are using java with: com.kauailabs.navx.frc:navx-java:3.1.344.
We tested the code with several different projects so its not our bug, I will also attach just incase the source code which I used for debugging this (3.9 KB)

Thanks in advance!

Are you just trying to reset the current yaw to 0? If so, use zeroYaw(). When you call reset() you actually trigger a recalibration, during which, per the documentation for isCalibrating(), “the yaw, pitch and roll values returned may not be accurate.”

Edit: See corrections and clarifications from slibert below!

But looking at the source code it seems that reset() just calls zeroYaw() so its basically the same thing. So I guess there is no way to reset the gyro without reclibrating?

Hmm, just looked at the source myself, and you are correct. That is very interesting, and very not what I would expect based on the documentation. There may not be a way to zero yaw without recalibrating.

Looking at last year’s code, we only called zeroYaw() in RobotInit(). We found that the drift over the course of a match was small enough that we never needed to zeroYaw() during the match. Are you finding that the yaw angle is drifting too much over time, or are you trying to periodically change the definition of “0 yaw” to the direction the robot is currently facing?

Edit to add: If you call isCalibrating() right after reset() or zeroYaw(), does it return true?

Well, we are just trying to change the definition of the current robot angle to 0.
But if we won’t reset it we need to set the PIDController to continuous input with bounds of 180 to -180 and it’s will work?
Cause the PIDConroller uses the getYaw() method which also implementing bounds of 180 to -180.

Ammm, actually no, its constantly returning false, maybe its not preforming a calibration?

Yes, this should work. If you need the robot to turn to a specific angle relative to the original heading of the robot, use that as your PID setpoint. If you need the robot to turn a specific number of degrees from its current position, you can add your desired rotation to the current yaw reading, but you may have to catch when you’re passing through the -180/180 discontinuity and figure out the arithmetic for this case.


Well the PIDController have a support for that so thats ok I guess.

If someone from kauailabs could refer to this thread it would be nice :slight_smile:

getYaw() takes up to 2 * the update period to take effect, because the resetting of the yaw to zero is handled on the board; a message is sent to the board to reset the yaw angle, and the effect of that command to reset the yaw isn’t reflected in the buffered yaw data on the RoboRIO until the next update is received after the yaw angle is updated.

So after restting/zeroing the yaw, you’ll need to delay 2 * the update period before accessing the yaw angle. This avoids any race conditions where a new update is received after the reset was requested and the next update containing the reset data.

And there is no correlation between reset/zero Yaw and board calibration. In fact, it is not possible for robot applications to request recalibration to occur. For reference, please see - this describes the three possible calibration phases which occur, and when they occur.

1 Like

When you call reset() you actually trigger a recalibration, during which, per the documentation for isCalibrating(), “the yaw, pitch and roll values returned may not be accurate.”

This statement is not accurate. reset() does not trigger a recalibration.

1 Like

Ahh seems a bit silly, think we will keep using ‘getAngle() + setPoint’ with no reseting.

But, if the reset would be reflected in the buffered data on the RoboRIO it will make more sense :confused:


I’m planning to look into this over the weekend; if things go as I expect, we can release a navX RoboRIO library version that implements the reset in software rather than at the board level. This should work for typical FRC use cases like you are a describing (there are some advanced use cases involving quaternion histories in SF2 that may not be compatible with this approach, but I don’t think you’ll experience troubles). And it would remove the need for any delay as the data pipeline catches up to the changes to the yaw angle. I’ll keep you posted.

Sounds great, thanks!

Hi slibert - any update on this?


We are in the testing phase now, hope to have a release by Friday.

The navX-Sensor RoboRIO Libraries for C++ and Java (version 3.1.365) have just been released, which enhance the performance of the ZeroYaw() and Reset() functionality. The reset now takes effect instantaneously, using “Software-based Yaw Reset” behavior. Logging information is available, accessible via the RioLog or the Driver Station “Message Console”.

You can use either the online or offline installation methods to install the libraries, as described on the C++ and Java pages, accessible from the RoboRIO Library Software page.

Note: if you are using USB to communicate with navX-MXP, you are strongly encouraged to update the sensor firmware to the latest 3.1.365 firmware, as this enhances the ability for the RoboRIO AHRS class to detect when a board connected via USB is in the “Startup Calibration” state. For reference, sensor calibration is detailed here.

Also, as always, note that resetting yaw does not take any effect when the board is in the “startup calibration” phase. The robot application software can always use the IsCalibrating() method to know when the startup calibration is in progress and completed. The logging information will give you more insight into that.


Thank you!! Your work is much appreciated!