You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
From Java, if I use the Microsoft Lifecam and use the default resolution (160 x 120) and navX-Micro on USB, communication seems to work OK. It also seems to work OK if the resolution is 320x240.
However, if the camera resolution is 640x480, the navX-Micro gets a communication error like this:
java.lang.NullPointerException
at com.kauailabs.navx.frc.SerialIO.run(SerialIO.java:174)
at com.kauailabs.navx.frc.AHRS$IOThread.run(AHRS.java:1253)
at java.lang.Thread.run(Thread.java:745)
java.lang.NullPointerException
at com.kauailabs.navx.frc.SerialIO.run(SerialIO.java:191)
at com.kauailabs.navx.frc.AHRS$IOThread.run(AHRS.java:1253)
at java.lang.Thread.run(Thread.java:745)
Via code inspection, while the navX SerialIO module is resilient to communication exceptions that occur after it has already connected, it appears that if communication cannot be established during initialization (line 174, line 191 as shown above), the navX SerialIO module will not reattempt communication after that point.
The text was updated successfully, but these errors were encountered:
After reviewing this futher I have found a workaround (which provides clues to what the underlying problem is) for Java (and likely C++) users of USB-connected navX-Micro.
First I was able to reproduce (about 5% of the time or so), when there is a Java program that uses the Microsoft HD LifeCam 3000 and also a USB-connected navX-Micro, that the navX-Micro library can't open the USB serial port when the robot application starts. On the Microsoft HD LifeCAM 3000, the test application uses CameraServer.getInstance().startAutomaticCapture() to start streaming from the camera to the dashboard.
After some time, I discovered that if navX-Micro communication is initialized first (by instantiating the AHRS class), then a 1 second delay is inserted, then the CameraServer is initialized - that the navX-Micro was always able to open the USB serial port. And this works whether the robot application is restarted or the robot application is rebooted. And this works whether the navX-Micro is connected to USB port 1 or 2. I've tested this with 80 successive reboots and 100 successive robot application restarts.
This suggests that somehow the opening of the Microsoft HD LifeCam 3000 stream can cause (if the timing is right) a USB serial port open request to fail every now and then. So the workaround is ensure the USB serial port open occurs and completes first.
From Java, if I use the Microsoft Lifecam and use the default resolution (160 x 120) and navX-Micro on USB, communication seems to work OK. It also seems to work OK if the resolution is 320x240.
However, if the camera resolution is 640x480, the navX-Micro gets a communication error like this:
java.lang.NullPointerException
at com.kauailabs.navx.frc.SerialIO.run(SerialIO.java:174)
at com.kauailabs.navx.frc.AHRS$IOThread.run(AHRS.java:1253)
at java.lang.Thread.run(Thread.java:745)
java.lang.NullPointerException
at com.kauailabs.navx.frc.SerialIO.run(SerialIO.java:191)
at com.kauailabs.navx.frc.AHRS$IOThread.run(AHRS.java:1253)
at java.lang.Thread.run(Thread.java:745)
Via code inspection, while the navX SerialIO module is resilient to communication exceptions that occur after it has already connected, it appears that if communication cannot be established during initialization (line 174, line 191 as shown above), the navX SerialIO module will not reattempt communication after that point.
The text was updated successfully, but these errors were encountered: