NavX Micro Gyro blocking other sensors on Modern Robotics Device Interface Module

[chen.mi...@bloomfield.org]

Our team is using the Navy Micro on a Modern Robotics DIM and we needed to put a range sensor on the same module. We found out that the range sensor couldn't return any data back to the robot controller. We then moved the range sensor onto a second DIM and the sensor worked fine on that module. We believe this is caused by the NavX Micro blocking any other sensor not the bus and if there is a fix to this problem.

Thanks,

Michael

[admin]

Hi Michael,

First, I wanted to review w/you the navX-Micro communication model with a CDIM, and how much bandwith that takes - and then discuss some ideas for troubleshooting the issue you are encountering.

** navX-Micro/CDIM Communication Summary **

Forgive me if this is already information you know, but I thought it'd be good to make sure how it works is clear.

The navX-Micro I2C communication usage is as follows:

- 50 times a second, a 26 byte I2C read transaction occurs. 

At the I2C protocol level, each I2C read transaction occurs as a 2-byte write (the device address, and the starting register to read from), then a 26-byte read (the data from the sensor)

- The Core Device Interface Module (CDIM) has a single I2C bus running at 100,000 bits per second

So therefore, the navX-Micro USB usage in bits/second is:

- 50 time/second * 8 bits * (2 write bytes + 26 read bytes) = 11,200 bits per second.

And, because there is some additional overhead that can take up to 20 bits/transaction, the total bits/second used to communicate with navX-Micro is (50 * 20) + 11,200 = 12,200.

For a 100,000 bits/second CDIM I2C bus, that means navX-Micro communication consumes 12.2% of the bus.  Since the CDIM has 6 I2C slots (all on the same 100,000 bits/second bus) the navX-design is to consume no more than it's fair share - one sixth of the bus (which is 16.6%).

Two other points are also important:

- Any I2C device like navX-Micro is a 'slave' - it will only send data on the bus when it is requested to by the 'master'.

- I2C transactions don't occur simultaneously, they occur one-at-a time.

** Troubleshooting **

Based on the above, because the I2C devices connected to a CDIM are I2C slave devices, it's not possible for the I2C devices themselves to place too much data on the bus - because they only place data on the I2C bus when they are requested by the 'master' (the FTC robot software).

And, because the navX-Micro libraries are designed to request no more than 16.6% of the bus, the navX-Micro libraries will not request nearly enough data to fill the bus.

Given all that, here's some input on how to troubleshoot this:

First of all, it's crucial to make sure that the navX-Micro 7-bit I2C address (0x32 [hex] / 50 decimal) is not the same as the range sensor.  The Range Sensor datasheet indicates the default I2C address is 0x28, but according to the datasheet it also has a I2C 'address change option' - so because of that option, make sure that the Range Sensor address doesn't collide w/the navX-Micro.

Next, it's important to ensure that your robot software is not taking so much CPU that the driver for the Range Sensor (from FTC) that runs in your software application doesn't get a chance to run properly.

If none of that helps, please check to see that you have the latest libraries from FTC.  It's always possible that there's been a recent change to the FTC CDIM driver that might have a problem.  The last time we were aware of such a problem was a little over a year ago, and the fix at that time was to update to the new version.  And we haven't heard anything recently about such a problem from any other FTC teams.  But it's worth checking.