During yesterday at tournament, our navX gyro sensor stopped returning values, causing our drivetrain PID to malfunction. The navX is protected by a plastic casing and is still directly plugged into the roborio. Are there any reasons that could cause the navX to stop functioning like this? We have been using it for over 4 weeks, and it has been working fine.
Have you connected it to the rio via a USB cable? This will help to prevent RIO Stage 2 brownout from affecting the chip.
http://www.pdocs.kauailabs.com/navx-mxp/support/troubleshooting/
The roborio is currently plugged in directly to the roborio through the custom electronics port and is using spi. When we tested it in the pit, it still wasn’t returning values and the battery was at 12.8 volts.
Please contact Scott, at Kauai
We had an odd occurrence at Waterford where when we connected to the field, we would not get telemetry data, but when we ran on the practice field, everything worked. I replaced the Navx with a second unit, I had, on Friday at Waterford, we also added an old gyro, and rewrote our autonomous scripts, to use the gyro data. We ran all day Saturday with program working off gyro, while logging the navx data too.
The Navx worked all day Saturday in logs.
The suspect board, was found to have an old firmware, but Scott said that should not have been a problem.
We have not used that board on our comp bot, but it is on our practice bot.
We ran our second event at Marysville last weekend, and the Navx worked all weekend.
There is a tech note, to use a USB cable from the roborio to the navx, to prevent brownouts from taking the Navx down, if you do not have that installed, I would suggest that you do.
http://www.pdocs.kauailabs.com/navx-mxp/guidance/best-practices/
Are any of the LEDs on the navX lighting up at all? If none of the LEDs light up at all, even at initial power-on, then the navX is not getting power. The most likely cause of this is swarf in the various pins of the roboRIO, which can result in shutting down power to the output rails of the roboRIO, including the MXP port.
We had the above problem at one point. Vacuuming out the swarf that had fallen into the unused roboRIO I/O pins fixed the problem for us. As insurance against future occurrences, we taped over all the unused roboRIO output pins to help keep debris out of the roboRIO.
This is repeating the fine advice given by others, but the most likely issue is that the 5V power source to the navX-MXP, provided by the RoboRIO via the MXP connector, was cut due to a Stage 2 brownout. A related failure condition is the 5V power source was cut due to a short circuit that the RoboRIO detected as a current surge.
In each of these cases, the navX-MXP would lose power, and then begin re-initializing once power was restored. In the case of a stage 2 brownout, power could be restored as quickly as 100ms later, it just depends upon the conditions.
As discussed in the “Best Practices guide”](http://www.pdocs.kauailabs.com/navx-mxp/guidance/best-practices/), using a USB cable to provide backup power in case the RoboRIO cuts the MXP power will address this issue.
Here at Kauai Labs, we have this year seen a few times a more fatal issue. Due to excessive current draw on the expansion IO pins, one of the expansion IO power (3.3V/5V depending upon the jumper setting on the navX-MXP) traces, or the ground return trace, can become damaged. This may cause the MXP power source to the navX-MXP processor to no longer work (a USB cable would fix this), and also mean that the power to anything connected to the Expansion IO pins on the navX-MXP would not work. If you see visible evidence of a burnt trace on the navX-MXP, please let us know ([email protected]) and we’ll work with you to replace your board.
Aloha,
- scott
I’ve also had problems with the NavX randomly dying (plugged in both MXP and USB).
As such, we have a kit of parts gyro on the robot as a backup (that we can switch to at any time) because we can’t always trust that the navX will get us through the match.
This week, it behaved pretty well, except for one match, where it was completely dead the whole match, and then was fine again upon reboot. No idea why.
Cory, we’d like to get to the bottom of what’s going on here. Since I’m aware from our previous conversations you’ve followed all of the documented best practices, if you’d like we can send you a replacement navX-MXP to try; just contact [email protected] and we’ll get that started for you.