navX reset button constantly pressed

We’ve been having some issues with our navX mxp’s lately.

We got one of them to successfully flash firmware and connect to the robot, but it hasn’t been working through i2c and spi, and only through the SerialPort option. Is there any explanation for why this might not be working? We’d like to leverage the speed of the i2c and spi interfaces.

In additon, while it has connected to the robot through SerialPort, it seems that something is causing the reset button to be consistently pressed.


We’ve made certain that there isn’t anything pressing on the button while it’s on the robot, as well as that the mxp port and the navx board are clear of anything conductive.

Our implementation can be found here

In a similar vein, we’re having another issue with our other navx where it doesn’t show up over USB.
The red power led lights up, implying that it’s in firmware update mode, but it shows up this in device manager.


The update firmware option in the navx firmware update application is also greyed out.

This code to zero the yaw:

    if (ahrs.isConnected) {
        while (!yaw.around(0.0, 1.0)) {
            ahrs.reset()
        }

can be improved. navX-MXP yaw should only requested to zero once, and it takes a moment before the zeroing takes effect. Putting that together, not only is the while loop not necessary, it can actually end up lengthening the time it takes for the yaw zeroing to complete (e.g., if the 2nd request to reset() occurs before the first has finished).

Is there any explanation for why this might not be working? We’d like to leverage the speed of the i2c and spi interfaces.

SPI is definitely the best protocol for communicating with navX-MXP. Please send details on what is not working so we can help.

Also, if you haven’t already, ensure the dip switch that enables SPI communication is on the “ON” position.

navX-MXP should show up either as a USB device (in firmware update mode) or as a USB serial port (in normal operating mode).

  1. When your screenshot was included, what mode was the sensor in?

  2. If you right click on the USB devices in the windows device manager to bring up the properties, what information is displayed on the details tab for the “Hardware IDs” parameter?

Any suggestions for a way to make sure the gyro is zeroed before autonomous starts? Or is that not needed?

As for SPI, when we were using SPI and I2C we got a message that the library was instating the connection, then immediately after that it printed “navX-sensor DISCONNECTED!!”. We didn’t know about the dip switch, we’ll have to check that.

It’s recommended to review the Gyro/Accelerometer calibration docs.

It’s also recommended to review the Best Practices.

Reviewing those should give you a sense for how to handle this. Feel free to followup with questions if anything’s not clear.

As another reference, the standard implementation for zeroing yaw can be found in this example.

Am I missing something? The code you linked seems to show the NavX being reset when a button is pressed, which would cause the reset method to be called multiple times (unless you’re really fast with the button press).

We removed the loop for resetting the NavX, but still have similar issues to before. Is it possible that something physical on the board is making the NavX think the reset button is pressed when it is not? The button itself seems to be fine (it clicks like normal and doesn’t get stuck).

We noticed this behavior today when attempting to verify that the sensor was reporting yaw correctly. The robot was disabled and being turned by hand at a roughly constant speed, and we printed angle values to see what it reported:

Just before the top of that image it was steadily decreasing from 0 to -5 degrees, then suddenly it makes a jump from ~-14 to ~-100 degrees. I would suspect this has something to do with the NavX deciding to reset around this time. Is this a reasonable thought? We’re not calling the reset function from code at all while the robot is disabled (but feel free to double check that in our code).

Tomorrow, we will check to see if it does the random reset behavior if we don’t turn it at all.

It’s important to get SPI (or alternately I2C) working when connecting to the MXP port.

In the example log that you recently posted, is the sensor configured for SPI?

I’m not sure, we’ll check that tomorrow. Are you saying that the type of error we’re seeing could be caused by not configuring the sensor for SPI? I’m asking because we’re somewhat tight on funds looking forward, and I want to see if we need to purchase another NavX.

EDIT: Just pulled up a picture of the NavX online, and I know that we haven’t removed the tape from the switches that mark UART and SPI. I think this means we haven’t disabled SPI?

TTL UART is an older style interface, not used often, slower and the communication protocol is more complicated. SPI and I2C should be and are what FRC teams use.

If you get that resolved I believe this issue will disappear.

What do the rio logs say when SPI communication is attempted?

Not necessarily - ensure that the SPI switch is completely slid to the ON position. You can remove the tape - it’s only there to protect the switch during soldering at the factory.

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