"warning: problem with navx"

[FTC Team 4962 The Rockettes]

Here is the setup: 

- navx plugged into expansion hub 2 (the daisy-chained one) with level shifter. 

- Pins switched on the cable to make them match.

- SDK 3.5

- hub firmware 1.7 (whatever the brand new one is)

We can repeat this pretty easily -- just run the SDK example code a few times and it crashes out.  you have to unplug/replug the navX to get it to work again, but then it crashes again almost immediately.

It resulted in a really interestingly bent jewel arm.

We tried a different navX and a different cable with the same result.

We thought it might be due to the nasty SDK bug going around where controller 1 and 2 suddenly stop talking to each other, but it seems to be independent of that.

Log file from robot controller is attached.

[admin]

I'm assuming you had the navX-Micro working for awhile, and now you are having a problem.  Is that right?

In that case, I'd like to understand what has changed since it first worked.  I haven't heard of the problem before, so it seems you either have a new configuration (perhaps the two daisy-chained REV Expansion Hubs?) or a new issue has been introduced into the FTC libraries.  As a note, FIRST provides all of the libraries you are using, including the KLNavXMicro class, so if there is a software issue that's been introduced FIRST would be the one to provide the solution.  We're here to help, but actual changes in the libraries you're using would need to come from FIRST.

From the logs (all items with "navX" in the text), it appears a lot of time is being spent waiting for calibration to complete.  This suggests I2C communication with the device might not be working correctly.  As to your current configuration - I'm curious why the navX-Micro was placed on the secondary hub, this seems like a bottleneck for communication, first over I2C to the directly-connected hub, and then over RS485 to the hub at the head of the chain.  navX-Micro is designed for rapid communication and it would most ideal if navX-Micro communication did not have to go through this bottleneck.

I'd also comment that the newest technology component in this mix is two interconnected Rev Expansion Hubs.  I'm not aware of anyone yet who's been able to purchase more than one hub, so I'm not aware of anyone else using this configuration.  Here at Kauai Labs, we haven't able to buy yet even one Expansion Hub (priority goes to FTC teams, and they're out of stock now).  So with no other evidence to back it up, I have to say I'm suspicious of this dual hub configuration - but I don't have a way to prove it so take that with a grain of salt.

At a minimum, I'd recommend moving navX-Micro to the hub that's directly connected over USB to your robot controller.

Another alternative is to add the Core Device Interface Module, which has been known working for several years now.  We can definitely help you with that.

What I can do is contact some technical folks at FIRST to let them know of the problem after I understand what's changed and what has been attempted to diagnose it - but I'd encourage your team to do so to, because your configuration is something we don't currently have access to, and you'll likely be able to give them more precise information than I.

[FTC Team 4962 The Rockettes]

Thanks for the reply. 

Yes, the navX-Micro has been solid for the last two years (through the CDIM), so the new items are the two REV Expansion Hubs.

I believe the only reason it was plugged into the daisy chained hub was due to cable length (no long cables available), so we can test that now that the competition is past and try to get some longer ones.

We bought the hubs directly from REV as soon as they came out over the summer, before there was a limitation, so fortunately were able to get 2 for each of our teams.

We'll let you know what we find out - thanks for the ideas!

[admin]

Do you have any new information on this topic you can share with the community?

Thanks,

- scott