We are trying to use 2 color sensors on our robot to detect the tape and align ourselves in this game. Our dilemma is that the Roborio only has one i2c port. Is there a way we can wire two devices to this one i2c port and read from both independently?
1 Like
I2C is designed to be a bus with multiple slaves. See https://i2c.info/. However, each slave must have a unique address. Does your color sensor allow you to change the address?
3 Likes
The RoboRIO has two I2C interfaces, one on the pins marked on the case, the other in the MXP expansion port. I know it’s possible to access the latter through a NaxV, which breaks MXP out into individual pins, but I don’t know if it’s possible to directly plug into the MXP pins, since some have multiple functions.
We have tested with two identical I2C devices having the same (hard to change) I2C address, one into the onboard I2C and the other into the MXP I2C (via the NavX pins) and seen them both work at the same time. We’re still having a few problems but we think they’re unrelated to this discussion.
I was talking with a coworker about this, and you either need separate I2C interfaces, or one of these: I2C Multiplexer
As a side note we are currently working with another team to debug using the adafruit color sensor over I2C . I think our implementation does not work, does anyone have a working one for us to reference?
I2C devices have addresses. If you are using multiple (different) I2C devices with different addresses, there is no issue.
Some I2C sensors have a setting or pin for address (this usually toggles the least significant bit). If you want to use multiple I2C sensors of the same type, using the address pin can be an elegant hardware solution. The data sheet for your device will tell you if there is an address pin.
If your color sensor does not have an address pin, as mentioned above the RoboRio has 2 I2C ports
If you don’t want to use the other I2C port, you may also consider using or creating a multiplexer out of logic gates (IMHO this would be a fun exercise).
I don’t have one of the color sensors, but I’ve done a small bit of I2C work.
First question: Did you read the spec sheet?
Second question: are your signal wires longer than ~3ft?
Wires are 1.5 ft, and I think I have gone through most of the manual. The chip is acking the 0x29 address but the values being returned for registers are wacky. Gonna hook up a scope tonight to see what’s what…
This isn’t true… you just need to get all your devices to use different addresses. It’s just like setting up 16 TalonSRXs with 16 different CAN IDs so that you can talk to each of them independently. However with a lot of smaller I2C devices, this is configured by bridging solder gaps on the PCB.
1 Like
My reply is a specific reply to I2C devices that only have a single, non-configurable address.
Has anyone finished successfully using two I2C devices with the same address?
We haven’t started to try the interface but are interested in using two of the RevRobotics 2m distance sensors this year - hard coded to 0x52.
We read everything above - and since we do use a NavX, mostly wondering if using the NavX breakout plus the other RoboRio I2C worked…or if we should be looking into muxing right now.
thanks!
Did you end up implementing a Multiplexer? If so, can you help a rookie team? FRC Team 8002 would like be able to use 3 Rev color sensors.
FYI - Team 1967 here - we were able to utilize two of the color sensors without a multiplexer by using the 34-pin expansion connector. Others here have mentioned theory and/or noted success, but I’ll add to it a photo of our prototype connections and also note the following regarding software:
The Color sensor has a constructor argument asking for an I2C “port” - this port is either the onboard port that most people use in the upper left of the roboRio or it is the expansion connector I2C port. The expansion connector is known as “MXP” and in Java, the two enumerated values used in the constructor are either:
I2C.Port.kOnboard
I2C.Port.kMXP
Please see the warnings regarding use of the onboard I2C port. It may work for you, but fail for others, or fail unpredictably. I would recommend looking at the alternatives linked to under the known issues page.
1 Like
Peter - thanks so much for this warning. I’m pretty shocked that this is the case as prior years have had no such timing related lockups. Super bummed. We’re considering using the I2C multiplexor, but that’ll be a bunch of custom programming for it and for re-implementing the Rev Robotics Color sensor code too. ICK. And the other workarounds of using “Pi” aren’t very happy workarounds late in the implementation game.
1 Like
The Pi Pico solution is quick and easy. The link takes you to a GitHub repo with a canned image for the Pico and a RoboRIO library to use the serial port to talk to it. The Pico can be purchased off Amazon for ~$8 and get to most places next day.
1 Like
Thanks again for that detail, Peter. It is pretty well laid out for us, but we’re in the final hours and it feels ambitious to put on the team.
One more question - does this I2C onboard issue NOT happen on a roboRio-2 hardware unit? We do have the older models and the brand new one so we are hoping we have a way to avoid the issue, possibly??
We went from the
pico in a box to reading color in 30 minutes. The solution provided is absolutely amazing and worked flawlessly.
1 Like
It happens on both. As the article Peter linked, the rate at which it happens can vary widely between different roboRIOs. So you may determine the risk is acceptable based on how your setup behaves.
Any concept if simply reducing the read frequency to much lower rates like twice a second aids in mitigation?