3

I'm building an architecture for a large scale robot (3x3meters) and I would like to build a specific architecture around I2C differential to control motors drivers (this should be noisy).

My problem is, in order to avoid high cost cables and connector, to build kind of star I2C network using PCA9615. Since star network are not really recommended on RS485 for instance, I guess so it should not be ok with differential I2C.

So my idea is to split network like this: I2C network

My main board will collect all feedback from several PCA9615. All twisted lines will be maximum 3m long.

I guess using a I2C switch will solve my solution (for example TCA9548A).

But since I don't have experience in I2C network, I rather ask ;)

So my question is: could it work? Is there a simpler solution?

Thanks a lot !! :)

Note: If I'm not clear enough, please feel free to reprimand me.

robotsmith
  • 50
  • 4
  • 5
    Why not use CAN or CAN FD? I2C causes a lot of problems and 3m is not little for I2C. – CFCBazar Oct 07 '20 at 08:26
  • 2
    Yes, I2C is a trouble maker, especially for wiring longer than 30cm. I think RS485 motors/servos is a good soltuion. – tlfong01 Oct 07 '20 at 09:31
  • 2
    yeah, I finally bit the bullet and started converting all my robot comms over to CAN from I2C. After stubbornly clinging to I2C for far longer than I should have. For communicating with multiple devices on a potentially noisy bus, it seems like it's the only way to go. – Ocanath Oct 07 '20 at 14:37
  • 2
    Hi thanks for your answers. Well my driver supports I2C, UART and have some GPIO for reset and fault. In addition, I'm working with an engineer that seems to prefer I2C (high refresh rate), but I'll check with him if it is not too much work. I do agree...CAN seems simpler and better for this application. – robotsmith Oct 07 '20 at 14:59
  • Consider a 10BASE-T1S Ethernet bus. – TimB Jan 27 '23 at 03:01

3 Answers3

7

You'll find that modern cars are essentiall 2.55m × 3m robots containing a human driver.

The guys producing millions of them have agreed to use CAN, because the combined cost of cabling + CAN-capable controllers + connectors is cheaper than the effects of having the unreliabilty of rolling something based on I²C or their own bus inventions. Use CAN.

Low-Speed CAN is specified to work in star topologies, or mixtures of stars and long buses:

CAN Bus topology Figure by EE JRW

It works over the cheapest of all data cabling: 120Ω Twisted pair, aka "cheap network cables". The fact that even shielded network cable with high bandwidth is cheap is undeniably a large plus in applications with multiple motors in large devices that might even see RF ground differences.

CAN-capable microcontrollers cost 2€ in single quantities, so I'll go with: if you need to connect I²C devices, keep I²C short and linear, and connect them to such a microcontroller close to their position, and then connect that via CAN. This, by the way, also isolates faults very effortlessly, and makes writing a controller easier: your central node can issue "high-level commands" to the CAN microcontrollers (like: Drive the motor until you hit the stop switch or temperature increases beyond 80 °C) instead of having to do a load of I²C commands centrally. Makes debugging easier, and atop of that, easier to mentally divide development workload – you know can be either in the mindset "low level hardware driving" or "high level control design", but don't have to do both at once. You can even have a set of "CAN node" engineers and a set of "control engineers" and they only have to agree on a simple set of commands. Yay!

Marcus Müller
  • 88,280
  • 5
  • 131
  • 237
  • 2
    Yes! Also, for a project this complex, find a reliable local mentor if you can. You will learn much more than seeking advice randomly via the web. Because sometimes “you don’t know what you don’t know”. – Mark Leavitt Oct 07 '20 at 14:34
  • 1
    Thanks a lot for the proposition. I actually think that might be better and more robust. The only thing that concern me is the refresh rate of maximum 40 to 125kb/s for the low-speed ISO 11898-3 infrastructure. I hope that satisfy the engineer I'm working with. – robotsmith Oct 07 '20 at 15:04
  • 2
    @Robotsmith that rate is little if you need to e.g. poll a lot of sensors over a single I²C bus. It's plenty for most control jobs, especially if the MCU nodes *aggregate* information and for example only alert the controller to *changed* or *critical* state, on their own, instead of having been asked for every single sensor measurement every time. – Marcus Müller Oct 07 '20 at 15:06
  • 1
    @Robotsmith another aspect: that's *one* CAN bus. CAT5 cable has *four* pairs of cable... – Marcus Müller Oct 07 '20 at 15:07
  • 1
    @MarcusMüller Sure, I also think that could work, specially since the MCU is close to the driver in this topology. Handling fault, reset and higher level command (e.g. ramp acceleration, add another sensor) should convince my colleague. – robotsmith Oct 07 '20 at 15:20
  • 1
    @Robotsmith exactly! Local emergency/fault handling can be a really big thing, too. – Marcus Müller Oct 07 '20 at 15:21
  • @MarcusMüller, Approved ;) Thanks a lot! – robotsmith Oct 07 '20 at 21:38
  • @robotsmith a couple of years later: came across this older post of mine; out of curiousity, how did things work out? – Marcus Müller Jan 27 '23 at 09:20
0

CAN can work, but so can I2C and it is a mistake to say it will never work. If you understand what you are doing and understand integrity problems and how to avoid them, you have a fair chance of success.

Philips (today NXP) did two larger books on I2C that actually tell how to do this correctly. Unfortunately I don't have mine anymore, so the titles are out of my memory, but you might be able to find them on NXP's website.

You can also cheat over longer distances, by using Ethernet as carrier. Then you could go for 100s of meters with I2C.

ocrdu
  • 8,705
  • 21
  • 30
  • 42
Klavs Rommedahl
  • 1
  • 1
    Your answer could be improved with additional supporting information. Please [edit] to add further details, such as citations or documentation, so that others can confirm that your answer is correct. You can find more information on how to write good answers [in the help center](/help/how-to-answer). – Community Oct 28 '22 at 06:33
  • 1
    If you convert I2C transactions to Ethernet at some point, it simply removes the need for long I2C bus, but you can't extend I2C transparently through Ethernet because I2C transmitter needs data back in real-time. So it would be better to just send an Ethernet packet to request the MCU to do some I2C transaction. And you can't extend Ethernet directly few hundred meters, unless you use fiber, copper is limites to 100 meters. – Justme Oct 28 '22 at 07:32
0

I²C is fine for fetching some temperatures or EEPROM data on a PCB. But getting fancy with I²C is asking for trouble.

I've also used those PCA9614/5 chips. But I considered them as a necessary evil. In my case it was about handling non-critical data: A change to the physical design of a product made it necessary to use those differential transceivers, because it wasn't practical to change the already existing and certified firmware.

I would strongly discourage you from using I²C to handle critical features of a product like controlling motor drivers of a robot.

Because of its architecture, I²C has the tendency to hang itself when a slave is in an unexpected state due to a firmware bug or an EMI event, for example.

I²C is simply not an inherently robust bus system.

Most problems can be handled with very careful firmware design, of course. But like I said: It's asking for trouble.

feynman
  • 2,466
  • 3
  • 10