I2C Mux for multiple Sensors in FRC?

Hello, I’m trying to figure out if any other teams are using a I2C Mux on their robot? Our rookie team would like to use multiple (3 or more) I2C sensors with the same Address, but the robot is limited to 2 buses.

1 Like

That looks like a good solution to your problem. One thing to note is that you’ll use I2C to control that Mux.

Something you can do to help everyone else out - after you’ve determined your solution, please come back and post your results. By your other posts in various I2C threads, I can tell you’ve been searching for a solution on ChiefDelphi but since no one else bothered to revisit their thread all the knowledge they’ve gained is stuck in their heads. If they had posted what they learned, we might not have another I2C thread.

It looks like it should work. Our team has never (as far as I know) used I2C for sensors. Just out of curiosity what sensors were you planing on useing

Good places for these types of sensors would include color sensors looking for the lines on the field to help position the robot for scoring. Color or distance sensors for feedback on location of objects being picked up or carried by the robot. Distance sensors to slow the robot before slamming into a field element or hold the correct distance away from a field element. And lastly, a non-contacting feedback on the location of arms or elevators.

Robots are only as good as their feedback.


that is the whole point of robots though

I want them to smash robots… Not the field elements! :wink:

also with the color sensors, you can change them out for reflective light sensors and it is possible to wire them into the DIO ports of the rio

yea but you might have difficulty distinguishing between robots and field elements because they will probably look the same to the robot distance sensors. If you make it so it backs up and has a digital barier so it has to be a certain distance away and another robot comes at it and then your robot just backs up and then once it hits a field wall it breaks and dose not work

Agreed… It can sometimes be difficult, but that challenge is what makes it fun.

Example: Hold distance to wall if color sensor sees the white line on the field. All other cases, ignore the distance sensor.

Or:

Example: 2 sensors can be used to square the robot to an object or wall

The reason for the post is to find out if other teams have used multiple (Intelligent) sensors on a I2C bus? Or if it’s even possible?

try it and find out

not that I know of, maybe on crios where the stuff was different but IDK

The reason for the post is to find out if other teams have used multiple (Intelligent) sensors on a I2C bus? Or if it’s even possible?

I’ve done this, but not with FRC (if that matters to you), and yes, it’s possible to do what you’re proposing.

First, remember that many I2C components (such as your distance sensor) have configurable addresses, and that’s easier than using a multiplexer. Second, combining a GPIO with a power management pin can also enable a type of multiplexing, and that is also possible with your distance sensor.

However, neither of those options is available for your color sensor, and so we’re back to the multiplexer. At this point timing is everything, but you can do something simple such as sequentially cycling through the multiplexer channels on a schedule, or upon completion of the I2C transaction.

If you want to select channels dynamically, that will depend upon your architecture. You could use a combination of a “Current Channel” variable, and a “busy” flag for the I2C bus and manage your traffic based on that. Or you could do something like pushing your queries into a queue or a buffer, while ensuring that you route the responses appropriately as well.

I’m sure there are other approaches, but a lot of these decisions are application specific, and that should be enough to get you moving.

1 Like

Thank you for your help. I’m trying to see if a circuit board similar to board below has been used in FRC. For this chip, you kinda need to use dynamic addressing. So I’m assuming the team would need to make a class that will insert the dynamic address before each read and write?

First, I’d like to clarify that with I2C the address for each component is fixed (most often at the hardware level), and so “dynamic addressing” isn’t really a thing. But I think what you mean to say is that you’d like to use dynamic channel selection on the multiplexer, and so I can speak to that.

When I talk about dynamic channel selection, I mean that you would use that in circumstances when you need to call the sensor data on demand. The first alternative I presented would be to call the data on a schedule; For example, you might query your color sensor continually at 10Hz. The reason I brought up those approaches to the software architecture is that they each have different considerations for managing the timing of your communication through the multiplexer, and that timing matters a great deal.

The multiplexer itself is indifferent to the software that drives it. It always behaves in exactly the same way. I’m much more of a hardware guy than a software guy, so I can’t tell you whether to uses classes or constants or any of that, but I can give you an example of how to structure the communication.

I’ll start with the assumption that the bus is open. Let’s further assume that you want to read ‘Color Sensor 1’ and ‘Color Sensor 2’, which share the same I2C address. Your query structure will look something like this (please forgive my formatting):

I2C Start
Write Multiplexer Address Byte
Read the ACK from MP
Write MP Channel Select Byte for CS1
Read the ACK from MP
I2C Stop
I2C Start
Write Color Sensor Address Byte
Read ACK from CS
Read Data Byte from CS
Read ACK from CS
I2C Stop
I2C Start
Write Multiplexer Address Byte
Read the ACK from MP
Write MP Channel Select Byte for CS2
Read the ACK from MP
I2C Stop
I2C Start
Write Color Sensor Address Byte
Read ACK from CS
Read Data Byte from CS
Read ACK from CS
I2C Stop

So we have two distinct communication operations. The first is with the multiplexer, and the second is with the color sensor. So you’ll notice that all of your Color Sensor reads will be exactly the same, every time. They won’t ever change. But you’ll have a unique communication with your Multiplexer for each color sensor which is attached to it.

The I2C comms overhead should be handled by the driver, so in reality you’ll probably just have a series of writes and reads of bytes, without all of the starts and stops. I also assumed one data byte from your color sensor, but it could be more than that. I didn’t check the data sheet.

1 Like