Last year our team got a Navx MXP to use as our gyro, it worked fine with labview and we could read values when running through robot main. However, this year we aren’t able to read anything from it. We have it connected to the roborio through the MXP port and it appears electrically it’s working(It has lights lit up). We updated the firmware to the newest download and are using th e latest library(v2). But no matter how we initialize the gyro or what VIs we use to read data from it, it just reads out zeros. If anyone has encountered something similar or has any ideas, we’d be very grateful!
Have you tried the Example VI? (Examples/Functions/navX Example v2.vi)
How are you initializing the navX?
Are there any errors reported by the VIs? by the processing loop (navX Library v2/IO/Internal/Z900_navX_Internal_Error.vi)?
We have tried using the example vi. Both through copying how it initializes and reads from it and by just running the project. It just read 0s both ways. We’ve tried initializing with ic2, spi, and serial to see if any work and we haven’t had any luck. And would errors pop up or are they stored somewhere?
You would need to use navX Library v2/IO/Internal/Z900_navX_Internal_Error.vi to see if the internal loop is reporting errors. Is the Connected boolean true or false with the report of 0s? Are you able to use the desktop apps that come with the navX repo by kauailabs to read the values?
We had an issue with the NavX we purchased over the summer. It would run for a few seconds and then read all zeroes. It would only work again if we power cycled our robot. We sent it in and they are sending us back a new one. Your mileage may vary.
Can you pin down what changed to make it stop working?
Also, here are some specific things to try:
A) If you think the problem happened after updating the firmware, it’s remotely possible something went wrong during that process - in which case you might try re-downloading and installing the latest build, and re-updating the firmware.
B) Also, when the board is first powered on, all 4 leds turn on for a second, then all but the red power led are on as the board begins initialization; then after it initializes, the green S1 and S2 leds should come on. Do both of these LEDs come on and stay on?
C) The other test is, as Caboose mentioned: can you use the navXUI on a PC to display the sensor data?
So after you perform A), let us know if C) is successful and if B) shows both S1 and S2 leds on.
P.S. Can you please also indicate the version of RoboRIO firmware you have installed?
I’ll try these suggestions this afternoon when I have access to the electronics. We have already tried redownloading and reupdating the firmware with no results. I’m positive that both green lights stay on, although if I remember correctly, there was also a red light staying on. I’ll have to check later. I’ll be sure to check the internal error as well. And the connected boolean was also false, I forgot that we had tried that.
We are able to read using NavXUI. All lights light up as they should, and we’re using v19 of roborio firmware. We found an error outputting in driver station, it’s giving “ERROR -44007 FRC: The RefNum you are trying to Get does not exist in this RefNum Registry. navX Library v2.lvlib:Z900_navX_RefNum_Get.vi” So it appears that for some reason the refnum isn’t ever actually getting set in begin?
Edit:
We also just tested it over usb by plugging it into the roborio usb port. No luck with that either.
I’m not sure why you’re getting this error connecting to the sensor using LabVIEW.
However, we can send another board and have you return the one you’ve got - if you’d like to do that, please contact [email protected] with a reference to this chiefdelphi post and we’ll get you started on that. I’m a bit concerned that since the board is passing all of our usual “is it ok” tests - and thus that even after replacing the board you’ll still see the issue you’re seeing now accessing it from LabVIEW - but am happy to process the swap for you.
While that would be great if it would fix it, I’m not sure it would. We have two boards (1 for a practice bot), and neither are working. It must be something with software. Maybe we’ll try the example code with another computer.
Did you disable your console out? You can do this through the roborio website. I remember having issues reading values from the navx due to “console out” being on (using navx through USB port)
I’ll definitely check that tomorrow.
I sent Kauailabs an email and got this response:
Once the RoboRIO firmware got updated to the 2016 firmware version, the USB connectivity to the navX-MXP stopped working. We still don’t have any word on a resolution to this issue, and unfortunately I’ve been informed that this isn’t a high priority issue from the WPI/National Instruments perspective (since the serial over USB support is not ‘official’).
For that reason, we’re encouraging teams to use the SPI interface, or if that isn’t feasible to use the I2C or TTL UART interfaces.
We do still recommend that the USB cable between the RoboRIO and the navX-MXP be left connected, because this will ensure that the navX-MXP power is maintained even if a RoboRIO stage 2 brownout occurs. More info on that is discussed in item 2 in the navX-MXP Best Practices page.
- scott
Alright, we got it working. Turns out it was something stupid we did. We were using a setref vi in begin and get ref where we wanted to use it. Turns out you should just alter begin and where you want to use it and make the output of the open vi an output of begin and an input of the vi you want to use it in.
Modifying the project framework (e.g. by adding an output to Begin) is usually a bad idea. Using the Refnum Set/Get functions is preferred.
The -44007 error you were getting suggests that you had spelled the name of your NavX reference differently in the two places.
It’s too bad about the USB not working. We used that to get the navX into a good location on the robot, where we could not fit the roboRIO.