ANNOUNCING: navX MXP Robotics Navigation Sensor

[slibert]

Originally Posted by TylerS

It sounds like you guys were having the same issues we had today.

Are you also using LabView with SPI to communicate w/the navX MXP?

[Thad House]

We were able to successfully reproduce the issue. A very fast brownout was able to. If it was longer then about 20 ms it didnt happen, but shorter then that and it did.

[jojoguy10]

Originally Posted by Thad House

Has anybody had issues with their NavX's freezing the SPI and I2C Busses? We have been running it for a few days, and occasionally all reports will freeze and report nothing. Resetting the board does not fix this. The only fix is to reload the code on the roborio, which returns it to working condition. Has anybody else seen this yet? We are using LabVIEW.

And I thought it was just us.

We are using LabView and are having the same problem every now and then. It might be because of browning out? We'll have to do some quick testing.

[TylerS]

Originally Posted by slibert

Are you also using LabView with SPI to communicate w/the navX MXP?

Yep

[slibert]

Originally Posted by Thad House

We were able to successfully reproduce the issue. A very fast brownout was able to. If it was longer then about 20 ms it didnt happen, but shorter then that and it did.

Fascinating. Congratulations on some nice sleuthing...

Our LabView SPI longevity test has run 16 hours now w/no problems - glad there's an edge case identified we can chase down.

Using the RoboRio Brownout and Understanding Current Draw article as a reference, there are three stages of RoboRio brownout. Do you know which stage was reached in the case you've reproduced? It'd be interesting to know if Stage 2 (which would remove the power from the MXP 5V rail) was hit or not.

Also, could you please post the driver station logs that document the case when this occurs? That should help clarify the details of the scenario. The goal is to try to reproduce this behavior with a benchtop power supply, so the more info on the dynamics, the better. Once reproduced, we can run through various configurations and characterize the behavior more thoroughly.

[Thad House]

Originally Posted by slibert

Fascinating. Congratulations on some nice sleuthing...

Our LabView SPI longevity test has run 16 hours now w/no problems - glad there's an edge case identified we can chase down.

Using the RoboRio Brownout and Understanding Current Draw article as a reference, there are three stages of RoboRio brownout. Do you know which stage was reached in the case you've reproduced? It'd be interesting to know if Stage 2 (which would remove the power from the MXP 5V rail) was hit or not.

Also, could you please post the driver station logs that document the case when this occurs? That should help clarify the details of the scenario. The goal is to try to reproduce this behavior with a benchtop power supply, so the more info on the dynamics, the better. Once reproduced, we can run through various configurations and characterize the behavior more thoroughly.

I will check to see how low the battery voltage was getting when this was happening. I will also get the driver station logs later today. It seems like the NaVX is rebooting, because when we do the RoboRIO code restart, if we do it within 16 seconds, the navx reports its in calibration mode, just like it does on startup.

Note that this for us was not just limited to SPI. I2C had the same issue, but it happened earlier. I would guess that when it happened on I2C, it was because the pullups were being forced high by stage 1. I don't know if SPI has that same issue, but the issue seemed to happen with a much lower battery on SPI then I2C.

[slibert]

Originally Posted by Thad House

I will check to see how low the battery voltage was getting when this was happening. I will also get the driver station logs later today. It seems like the NaVX is rebooting, because when we do the RoboRIO code restart, if we do it within 16 seconds, the navx reports its in calibration mode, just like it does on startup.

Note that this for us was not just limited to SPI. I2C had the same issue, but it happened earlier. I would guess that when it happened on I2C, it was because the pullups were being forced high by stage 1. I don't know if SPI has that same issue, but the issue seemed to happen with a much lower battery on SPI then I2C.

The RoboRio will remove power from the MXP connector if the unregulated VIN to the RoboRio drops below 6.3V. And it appears the RoboRio I2C/SPI busses are getting wedged with really short brownouts (though it's going to take some time to rig up some equipment so this can be characterized further).

If the navX MXP power input is removed during operation this will cause a yaw angle discontinuity - since the currently calculated yaw angle is based upon in-memory calibration coefficients.

Fortunately, the navx MXP has a USB input, and has on-board circuitry to automatically switch over to the USB input for power and a capacitor to ride-over the switching period. A comprehensive way to allow the navX MXP to continue to operate even in the face of a RobRio Stage 2 brownout is to modify a power-only USB connector (5VDC and ground leads only), and connect it to one of the VRM's 5VDC outputs. The VRM buck/boost regulator configuration allows it to provide 5VDC down to a VIN of 3.6V [per graphs in datasheet], by which time the RoboRio would have completely shutdown.

Using this approach, the navX MXP will continue to be powered even when the RoboRio VIN drops below the level where the RoboRio has completely shutdown (Stage 3).

It's possible this step alone will not resolve the issue that the RoboRio I2C/SPI circuitry is stuck after it enters Stage 2 and removes power from the MXP power rail for a brief instant. That needs more testing.

Here's the recommendation for moving ahead, please let me know your thoughts:

(a) connect the navX MXP USB (mini-b connector) to a 500mA 5VDC VRM output

(b) we'll work on reproducing the I2C/SPI bus hangs when the RoboRio reaches brownout Stage 2 for very short (e.g., 20 ms) periods of time, and forward that info to National Instruments.

(c) If (b) persists even after (a) and we can't get a resolution from NI in time, switching to the TTL UART interface is another feasible approach.

[rich2202]

Originally Posted by slibert

A beta version of the navX MXP "Lid" enclosure

I suggest the following changes:

The blank part that covers the USB interface, put ground/power/signal markings like is on the roboRio

Use the roboRio style markings for the PWM port to mark the DIO/PWM port, including roboRio port numbers. Ditto for Analog ports. Maybe use letters AIN 4, AIN 5, AIN 6, AIN 7, AOUT O, AOUT 1, since there is not as much room.

[slibert]

Originally Posted by rich2202

I suggest the following changes:

The blank part that covers the USB interface, put ground/power/signal markings like is on the roboRio

Use the roboRio style markings for the PWM port to mark the DIO/PWM port, including roboRio port numbers. Ditto for Analog ports. Maybe use letters AIN 4, AIN 5, AIN 6, AIN 7, AOUT O, AOUT 1, since there is not as much room.

These are great suggestions. V4 of the beta navX MXP Lid Enclosure design files is now available.

If you're interested in printing the enclosure yourself w/a 3D printer, please visit the "Creating an Enclosure" page on the navX MXP wiki.

Those who prefer to purchase the enclosure can order it from Shapeways.

*** Change Summary ***

- Added GND/+/S labels to Expansion I/O pins (Digital/Analog) near the USB connector.
- Added numbering for each of the PWM/Digitial I/O and Analog pins.

[rich2202]

Originally Posted by slibert

These are great suggestions. V4 of the beta navX MXP Lid Enclosure design files is now available.

Nice. One more refinement: it would be helpful for the #'s to correspond to RoboRio Channel Address (# for programmers to use), and not the MXP Port Number (which most people don't care about).

[rich2202]

Seems like the USB port is a good option to provide backup power to the navX board.

Can you ask Andymark to stock USB to Stranded cables so that we can wire it to the 5v 500 mA port of the VRM?

The VRM is supposed to be able to supply stable power with battery voltage down to 5V. Is the navX board protected from reverse voltage on the USB Port? If not, it would be nice if you could do that in a future release.

Thanks.

[slibert]

Originally Posted by rich2202

Seems like the USB port is a good option to provide backup power to the navX board.

Can you ask Andymark to stock USB to Stranded cables so that we can wire it to the 5v 500 mA port of the VRM?

The VRM is supposed to be able to supply stable power with battery voltage down to 5V. Is the navX board protected from reverse voltage on the USB Port? If not, it would be nice if you could do that in a future release.
::
Thanks.

Actually, this seems like a simple, inexpensive option that also alleviates the reverse polarity concern. Here's one w/a built-in Mini-B USB connector.

We'll go ahead and test the Duracell charger (or one like it) to make sure it does the trick, and post the results on this thread.

[Alan Anderson]

Originally Posted by slibert

Actually, this seems like a simple, inexpensive option that also alleviates the reverse polarity concern. Here's one w/a built-in Mini-B USB connector.

Did you notice that those are batteries? Under <R20>, they aren't permitted on the robot.

[slibert]

Originally Posted by Alan Anderson

Did you notice that those are batteries? Under <R20>, they aren't permitted on the robot.

Ah, good point; so sounds like a modified USB cable fed by the VRM is the best option for those wishing to ride over a Stage 2 RoboRio brownout.

[protoserge]

Originally Posted by slibert

Ah, good point; so sounds like a modified USB cable fed by the VRM is the best option for those wishing to ride over a Stage 2 RoboRio brownout.

I don't think it would be cost-effective to inventory custom cables. Teams should be plenty capable of cutting one end off of a USB cable