Navx Trouble - inconsistent connection

[techplex]

We have a NavX IMU connected via USB to the RoboRio. From time to time we seem to be loosing comminucation with the NavX. Watching the Update counter on the smart dashboard shoes hiccups along the way. Furthermore watching the isConnected() on the smart dashboard shows random disconnects.

We are at a loss. Its clear that the gyro(Yaw) reading is much less noisy. But for some reason when we execute turns using a PID controller and the Navx we get unpredictable results. Often the turn operates as we expect. However a fair amount of the trials we get a haywire result.

Our current robot code:
https://github.com/TechplexEngineer/fred2

Where the AHRS imu is instantiated:
https://github.com/TechplexEngineer/...Drive.java#L83

Using the imu in a PIDCommand for turning:
https://github.com/TechplexEngineer/...urn_angle.java

[slibert]

Originally Posted by Techwiz

We have a NavX IMU connected via USB to the RoboRio. From time to time we seem to be loosing comminucation with the NavX. Watching the Update counter on the smart dashboard shoes hiccups along the way. Furthermore watching the isConnected() on the smart dashboard shows random disconnects.

We are at a loss. Its clear that the gyro(Yaw) reading is much less noisy. But for some reason when we execute turns using a PID controller and the Navx we get unpredictable results. Often the turn operates as we expect. However a fair amount of the trials we get a haywire result.

Our current robot code:
https://github.com/TechplexEngineer/fred2

Where the AHRS imu is instantiated:
https://github.com/TechplexEngineer/...Drive.java#L83

Using the imu in a PIDCommand for turning:
https://github.com/TechplexEngineer/...urn_angle.java

The first thought that comes to mind is that the electro-mechanical connection between the USB cable and the navX is somehow loose, and that the actual motion of the robot during the rotational move is sufficient enough to dislodge it. The actual behavior you should expect in this case differs in this way:

a) If you are also connected to the navX MXP via the MXP connector as well as the USB, you have two sources of power to the navX MXP (the 5VDC on the USB cable, and the 5VDC on the MXP power rail). In this case, the navX MXP will stay powered even if the USB connection comes loose.

b) If you are NOT connected via the MXP connector when you use the USB connection method, the board can actually get reset if the USB cable shakes loose momentarily.

I'm assuming you are using configuration b). To verify that a reset is what's causing the disconnect, when the disconnect occurs immediately look at the navX MXP and see if it's 3.3V Power LED and the S1/S2 LEDs go out momentarily. If they do, the navX MXP is losing power. The navX MXP takes about 3 seconds after it gets reset before it starts sending out data again.

It's possible you can't look at the robot when it's in this state. In that case, another way to tell a reset has occurred is if the navX MXP isConnected() returns FALSE for awhile, and then after it comes back the IsCalibrating() is TRUE for awhile (typically, 15-20 seconds). This will tell you for sure that the navX MXP is getting reset.

If the cable is indeed the issue, please consider using a zip tie or other means to provide strain relief for the cable assembly so that it can't move during a robot rotation.

Aloha,

- scott

[slibert]

Originally Posted by Techwiz

Our current robot code:
https://github.com/TechplexEngineer/fred2

Where the AHRS imu is instantiated:
https://github.com/TechplexEngineer/...Drive.java#L83

Using the imu in a PIDCommand for turning:
https://github.com/TechplexEngineer/...urn_angle.java

One note after reviewing the code is that the bitrate for the SerialPort when communicating with the NavX MXP should be 57600. The referenced code (Drive.java) is opening the serial port at 9600 bits/sec currently.

[techplex]

You are correct we are using optionB where the NavX is connected via just a USB cable.

To test to ensure that the USB connection, we connected the NavX to the MXP port on our RoboRio and noticed the same connectivity issues.

To try to further explain, isConnected() will sometimes return FALSE and get stuck in the FALSE state. Usually a robot power cycle fixes this. However much more often the isConnected() alternate between TRUE and FALSE. Readings from the NavX stop being updated and the getUpdateCount() value stops increasing momentarily.

We are unable to observe the lights on the NavX when we believe it is becoming disconnected. We are relying on the isConnected() and isCalibrating() as reported to the smartdashboard.
https://github.com/TechplexEngineer/...obot.java#L105

When we do notice isConnected() retuning FALSE, isCalibrating() doesn't usually change to TRUE.



We changed the baudrate to see if a lower speed would make a difference. We did not notice a change. I'll make sure that gets back to 57600.

[slibert]

Originally Posted by Techwiz

You are correct we are using optionB where the NavX is connected via just a USB cable.

To test to ensure that the USB connection, we connected the NavX to the MXP port on our RoboRio and noticed the same connectivity issues.

To try to further explain, isConnected() will sometimes return FALSE and get stuck in the FALSE state. Usually a robot power cycle fixes this. However much more often the isConnected() alternate between TRUE and FALSE. Readings from the NavX stop being updated and the getUpdateCount() value stops increasing momentarily.

We are unable to observe the lights on the NavX when we believe it is becoming disconnected. We are relying on the isConnected() and isCalibrating() as reported to the smartdashboard.
https://github.com/TechplexEngineer/...obot.java#L105

When we do notice isConnected() retuning FALSE, isCalibrating() doesn't usually change to TRUE.



We changed the baudrate to see if a lower speed would make a difference. We did not notice a change. I'll make sure that gets back to 57600.

Hi Blake,

Thanks; I'm suspicious of some interaction between the Roborio navX MXP Library and your robot code, though I don't see anything obvious by reading the code. If you just run the Java navX MXP Sample Code, do you see these random disconnects?

If the sample code also exhibits this issue, I'll send instructions for two tests to run which could identify a faulty USB cable or navX MXP board.

[techplex]

Scott,

I've loaded the test code found:
https://code.google.com/p/navxmxp/so...eRobotExample/

And we are still seeing random disconnects.

Did you have more suggestions for us to try?

[slibert]

Originally Posted by Techwiz

Scott,

I've loaded the test code found:
https://code.google.com/p/navxmxp/so...eRobotExample/

And we are still seeing random disconnects.

Did you have more suggestions for us to try?

Yes, continuing along the trouble-shooting tree, there are two tests to try:

(a) test on the Roborio w/sample code using a different serial port (not USB)

- This is easy to do, simply connect the navX MXP to the RoboRio MXP port, and change the port identifier to kMXP instead of kUSB. Using the sample code, test if the random disconnects are still occurring.

(b) test the navX MXP itself using the navX MXP UI

- Hook up the navX MXP to a PC using the USB cable, and run the navX MXP UI. Observe the displayed values (e.g., "Yaw") for awhile, and see if you see delays in the update of these values. If there are observable interruptions in the updates, then this could indicate an issue w/the navX MXP board itself.

[techplex]

a)
Okay I just tried the NavX plugged into the MXP port and see the same disconnects.

b.)
I am unable to start the navX MXP UI due to the following error:

Catched FileNotFoundException: C:\Users\R2D2\Desktop\navx\navXMXPUI\application.windows64\lib\gluegen-rt-natives-windows-i586.jar (The system cannot find the file specified), while addNativeJarLibsImpl(classFromJavaJar class com.jogamp.common.os.Platform, classJarURI jar:file:/C:/Users/R2D2/Desktop/navx/navXMXPUI/application.windows64/lib/gluegen-rt.jar!/com/jogamp/common/os/Platform.class, native JarBaseName gluegen-rt-natives-windows-i586.jar): [ file:/C:/Users/R2D2/Desktop/navx/navXMXPUI/application.windows64/lib/gluegen-rt.jar -> file:/C:/Users/R2D2/Desktop/navx/navXMXPUI/application.windows64/lib/ ] + gluegen-rt-natives-windows-i586.jar -> slim: jar:file:/C:/Users/R2D2/Desktop/navx/navXMXPUI/application.windows64/lib/gluegen-rt-natives-windows-i586.jar!/
Exception in thread "Animation Thread" java.lang.UnsatisfiedLinkError: Can't load library: C:\Users\R2D2\Desktop\navx\navXMXPUI\application.windows64\gluegen-rt.dll
        at java.lang.ClassLoader.loadLibrary(Unknown Source)
        at java.lang.Runtime.load0(Unknown Source)
        at java.lang.System.load(Unknown Source)
        at com.jogamp.common.jvm.JNILibLoaderBase.loadLibraryInternal(JNILibLoaderBase.java:551)
        at com.jogamp.common.jvm.JNILibLoaderBase.access$000(JNILibLoaderBase.java:64)
        at com.jogamp.common.jvm.JNILibLoaderBase$DefaultAction.loadLibrary(JNILibLoaderBase.java:96)
        at com.jogamp.common.jvm.JNILibLoaderBase.loadLibrary(JNILibLoaderBase.java:414)
        at com.jogamp.common.os.DynamicLibraryBundle$GlueJNILibLoader.loadLibrary(DynamicLibraryBundle.java:388)
        at com.jogamp.common.os.Platform$1.run(Platform.java:203)
        at java.security.AccessController.doPrivileged(Native Method)
        at com.jogamp.common.os.Platform.<clinit>(Platform.java:173)
        at javax.media.opengl.GLProfile.<clinit>(GLProfile.java:82)
        at processing.opengl.PJOGL.initSurface(PJOGL.java:238)
        at processing.opengl.PGraphicsOpenGL.initPrimary(PGraphicsOpenGL.java:5988)
        at processing.opengl.PGraphicsOpenGL.requestDraw(PGraphicsOpenGL.java:1600)
        at processing.core.PApplet.run(PApplet.java:2177)
        at java.lang.Thread.run(Unknown Source)

[slibert]

Originally Posted by Techwiz

a)
Okay I just tried the NavX plugged into the MXP port and see the same disconnects.

OK, just to verify, when you did this, you changed the Serial port used in the code from:

serial_port = new SerialPort(57600,SerialPort.Port.kUSB);

to:

serial_port = new SerialPort(57600,SerialPort.Port.kMXP);

[slibert]

Originally Posted by Techwiz

b.)
I am unable to start the navX MXP UI due to the following error:

Catched FileNotFoundException: C:\Users\R2D2\Desktop\navx\navXMXPUI\application.windows64\lib\gluegen-rt-natives-windows-i586.jar (The system cannot find the file specified), while addNativeJarLibsImpl(classFromJavaJar class com.jogamp.common.os.Platform, classJarURI jar:file:/C:/Users/R2D2/Desktop/navx/navXMXPUI/application.windows64/lib/gluegen-rt.jar!/com/jogamp/common/os/Platform.class, native JarBaseName gluegen-rt-natives-windows-i586.jar): [ file:/C:/Users/R2D2/Desktop/navx/navXMXPUI/application.windows64/lib/gluegen-rt.jar -> file:/C:/Users/R2D2/Desktop/navx/navXMXPUI/application.windows64/lib/ ] + gluegen-rt-natives-windows-i586.jar -> slim: jar:file:/C:/Users/R2D2/Desktop/navx/navXMXPUI/application.windows64/lib/gluegen-rt-natives-windows-i586.jar!/
Exception in thread "Animation Thread" java.lang.UnsatisfiedLinkError: Can't load library: C:\Users\R2D2\Desktop\navx\navXMXPUI\application.windows64\gluegen-rt.dll
        at java.lang.ClassLoader.loadLibrary(Unknown Source)
        at java.lang.Runtime.load0(Unknown Source)
        at java.lang.System.load(Unknown Source)
        at com.jogamp.common.jvm.JNILibLoaderBase.loadLibraryInternal(JNILibLoaderBase.java:551)
        at com.jogamp.common.jvm.JNILibLoaderBase.access$000(JNILibLoaderBase.java:64)
        at com.jogamp.common.jvm.JNILibLoaderBase$DefaultAction.loadLibrary(JNILibLoaderBase.java:96)
        at com.jogamp.common.jvm.JNILibLoaderBase.loadLibrary(JNILibLoaderBase.java:414)
        at com.jogamp.common.os.DynamicLibraryBundle$GlueJNILibLoader.loadLibrary(DynamicLibraryBundle.java:388)
        at com.jogamp.common.os.Platform$1.run(Platform.java:203)
        at java.security.AccessController.doPrivileged(Native Method)
        at com.jogamp.common.os.Platform.<clinit>(Platform.java:173)
        at javax.media.opengl.GLProfile.<clinit>(GLProfile.java:82)
        at processing.opengl.PJOGL.initSurface(PJOGL.java:238)
        at processing.opengl.PGraphicsOpenGL.initPrimary(PGraphicsOpenGL.java:5988)
        at processing.opengl.PGraphicsOpenGL.requestDraw(PGraphicsOpenGL.java:1600)
        at processing.core.PApplet.run(PApplet.java:2177)
        at java.lang.Thread.run(Unknown Source)

This error is typically seen due because the navX MXP UI can't find the version of Java it needs.

Please make sure java of the correct version and matching 32/64-bit flavor is installed on this system. If you're running the 64-bit version of the navx MXP UI, you need the 64-bit version of java installed, and vice-versa for 32-bits. This is discussed in the "Instructions for Installing/Running the navX MXP UI" section of the navX MXP UI wiki page.

[techplex]

a.)

I can confirm that we tested the NavX connected via USB and via the MXP port and the only code change between the two was

serial_port = new SerialPort(57600,SerialPort.Port.kUSB);
-- to:
serial_port = new SerialPort(57600,SerialPort.Port.kMXP);

b.) We tried the Navx with the NavX UI and did not seem to have the same disconnect issues.
We then reconnected the NavX to the RoboRio and continued to have the same disconnect issues.

I'm beginning to think its a bad board. I tried changing the update rate from 50 to 60 to 30 and saw no difference in the disconnects.

Thoughts?

[slibert]

Originally Posted by Techwiz

a.)

I can confirm that we tested the NavX connected via USB and via the MXP port and the only code change between the two was

serial_port = new SerialPort(57600,SerialPort.Port.kUSB);
-- to:
serial_port = new SerialPort(57600,SerialPort.Port.kMXP);

b.) We tried the Navx with the NavX UI and did not seem to have the same disconnect issues.
We then reconnected the NavX to the RoboRio and continued to have the same disconnect issues.

I'm beginning to think its a bad board. I tried changing the update rate from 50 to 60 to 30 and saw no difference in the disconnects.

Thoughts?

Sorry for the slow reply, Blake, we just returned from the Hawaii Regional. Thanks for taking the time to run these tests. I agree the best thing to do now is to return the board for a replacement.

Once I get the board I'll debug it; it's possible you've helped us discover a board failure mode that our factory QA tests are not currently covering. Since we use the navX MXP UI as our primary board validation engine, and that's working OK for you, what we learn could help us improve our process and quality.

Please accept my apology for the inconvenience you've encountered as a result of this; please let me know immediately if you have any further troubles - you can reach me at scott@kauailabs.com.

Aloha,

- scott

[MrP_Hack]

Was there ever any resolution in regards to this issue. We purchased two NaxX MXP Boards last year but did not use them until this year. We are seeing disconnects as well. We have boards plugged into RoboRio and also tethered with USB just to make sure. Any assistance would be greatly appreciated. I would be more than happy to get additional details from our Programming Team Leads and Mentors.

[slibert]

Originally Posted by MrP_Hack

Was there ever any resolution in regards to this issue. We purchased two NaxX MXP Boards last year but did not use them until this year. We are seeing disconnects as well. We have boards plugged into RoboRio and also tethered with USB just to make sure. Any assistance would be greatly appreciated. I would be more than happy to get additional details from our Programming Team Leads and Mentors.

The NavX-MXP 2.0 firmware, released in late 2015, fixed an issue with intermittent connectivity under certain conditions, and should address this issue. Instructions for updating the firmware are here: http://navx-mxp.kauailabs.com/suppor...ting-firmware/