Problems with NavX-Micro

[Richard Corn]

I have been using the NavX-MXP on RoboRio successfully. Now testing the NavX-Mini connected via USB. Using SerialPort.kUSB. After adding a one second delay after creating the ahrs instance, I am connecting to the mini. The firmware version reports as 3.0.

So this looks good until I start moving the robot and looking at yaw readings. The getYaw and getAngle functions return zero regardless of movement, that is the readings do not update. 

[admin]

Hi Richard,

There are a few follow-up questions that might help narrow down what's going on:

- What language is being used (C++ or Java)?

- What, if any, other USB devices are connected to the RoboRIO's USB ports?

- Does your robot code access a USB camera?  If so, when does this initialization occur (relative to the initialization of the AHRS instance)?

- Which of the two USB ports on the RoboRIO is the navX-Micro connected to?

- When 0 is being returned from the getYaw() and getAngle() methods:

   - are the green S1 and S2 leds on the navX-Micro circuit board both solid on?

   - what value (true or false) is being returned from the AHRS instance "isConnected()" method?

- scott

[Richard Corn]

Java.

3 USB cameras.

NavX initialized first, with 1 second delay before moving to camera initialization.

Right now, one camera is in one of the ports (I don't know how to determine which port is 1 or 2, never had to worry about that) and a USB hub with two cameras and the NavX are plugged into the second USB port.

Don't know about the leds. I will have to check that when I am next in robot lab.

isConnected returns True.

[admin]

There are several issues that've been reported w/RoboRIO USB port conflicts that are likely coming into play here:

1) One of the authors of the WPI library has indicated that the USB serial port enumeration (which locates the USB serial device using an identifier like 'kUSB') may not work correctly when a USB hub is used.

2) When USB cameras are used, we have found that the WPI library call to open the USB serial port may fail unless there is a 1-second delay after opening the USB camera before initializing the AHRS instance (which opens the USB serial port).

So based upon these known issues, the recommendation is:

- Move the navX-Micro off of the USB hub, and into the top-most of the two USB ports on the RoboRIO.

- In the robot application, first initialize communication to all USB cameras, then wait 1 second, then initialize the AHRS instance.  It sounds like your initialization order is different.

We have never tried the exact configuration you are using, which is unique in two ways:  3 cameras are involved, and a USB hub is involved.

We have heard of 3 USB cameras being used, but the solution other teams have taken is to route them all into a Raspberry Pi, and then either perform vision processing on the Raspberry Pi, or route the video streams to a MJPG streamer on the Raspberry Pi (to view them at the Driver Station).  So since this is a configuration that's new to us, please let us know your findings.

P.S.  You also have the option to communicate w/the navX-Micro via I2C, although USB should work.

[Richard Corn]

I will work on the suggestions you have made. A couple of questions:

1) I open the navx first, wait 1 sec, then the cameras based on a post to chief delphi. Do you believe it matters which order you open the USB devices as long as there is a delay between the opens?

2) Can you tell me about what happens when you select a serial port with kUSB as opposed to kUSB1 or kUSB2? I assumed that kUSB would search for the device on either port. That would seem to follow given that you can identify the ports by number and kUSB does not. 

3) If you use kUSB1, does that mean that only that port is accessed to locate the NavX? If you know of any doc that describes the USB ports and this kUSB<n> business please point me to it, I'd like to understand what is going on here. I have assumed to this point that the RoboRio did not care which physical port you plugged something into, that it saw USB as single channel so to speak with the two ports essentially merged.

4) Is the top most USB port #1?

I plan to try I2C as well USB with the micro.

Just FYI, I know many people put their vision and camera processing on co-processors. We run our cameras and vision on the RoboRio and have yet to have any problem doing so.

[admin]

1) I open the navx first, wait 1 sec, then the cameras based on a post to chief delphi. Do you believe it matters which order you open the USB devices as long as there is a delay between the opens?

We've only verified that the open camera first, then USB serial port after 1 second delay scenarios works (it succeeded 100 times out of 100 in our testing).  It's just a guess at this point, but the thought is that the opening/initialization of the cameras introduces significant USB IO and somehow that IO is interacting w/the USB serial IO used to communicate w/navX-Micro - and thus the 1 second of delay after opening the cameras avoids this case.  Based upon that thought the concept is to let that startup camera IO complete before interacting w/the USB serial port.  

Note that in the case where the USB cameras are opened/initialized first w/out any delay before opening the USB serial port to the navX-Micro, the common failure mode is the USB serial port fails to open correctly, and there is a message output to the driver station logs by the navX-MXP/navX-Micro library for the RoboRIO.

2) Can you tell me about what happens when you select a serial port with kUSB as opposed to kUSB1 or kUSB2? I assumed that kUSB would search for the device on either port. That would seem to follow given that you can identify the ports by number and kUSB does not. 

Per discussions w/WPI, only kUSB actually works.  kUSB1 only works w/the first  (top-most on the RoboRIO) serial port, and kUSB doesn't work at all (known issue).

I understand that only kUSB performs scanning for USB devices, so I think that's the only case that has a chance of working when an external USB hub is involved (that's just an opinion, based upon discussions w/WPI).

3) If you use kUSB1, does that mean that only that port is accessed to locate the NavX? If you know of any doc that describes the USB ports and this kUSB<n> business please point me to it, I'd like to understand what is going on here. I have assumed to this point that the RoboRio did not care which physical port you plugged something into, that it saw USB as single channel so to speak with the two ports essentially merged.

See above.  Our testing has shown that the kUSB1 and kUSB2 identifiers don't work.  There is a FIRST alum working w/WPI in this area, his name is Thad House and you might want to contact him (his ChiefDelphi name is "Thad House") to see if there are more details.  He has commented to me previously in email regarding USB hubs and behaviors in this area, so he might be able to shed more light on approaches in that area.

4) Is the top most USB port #1?

In this diagram, it's the top-most of the two USB Type A (rectangular) USB ports.

[Richard Corn]

So I moved the usb cable to the Micro to port 1 on the RoboRio and put all of the cameras on the usb hub plugged into port 2. I initialize the micro first followed by 1 second delay and then move on to other init tasks which includes starting the camera server which publishes one camera feed at a time to the DS and our vision code. Changing to the usb port instead of the hub seems to have fixed the problem. Two observations:

1) The micro seems to drift more than the NavX-MXP.

2) The micro returned 1.0 as the firmware version. Earlier, it returned 3.0. I'm not sure what to make of that. Will install your firmware update tool and check it that way to be sure.