That is a really nasty reply/problem. It can't be true that if there is a glitch somewhere in an I2C message the whole robots hangs without a capability to error intercept. It is also not the case for other (SW) platforms. Anyway to repair this?

At the moment a glitch in any of the I2C connections hangs the robot/EZB/ARC. That should not be the case. Some form of try-except capability should exist. Or some other means to be able to ignore/timeout a corrupt message.

We’ve moved your feature request to a comment, as the explanation highlights that this is not an issue related to Synthiam ARC. The behavior you’re experiencing stems from the hardware being used - specifically, the EZ-Robot EZB.

The EZB can hang if there’s a communication fault over the I2C bus. In such cases, the red LED remains lit, and the device becomes unresponsive until rebooted. This is a known behavior of the EZ-Robot EZB and does not occur under normal conditions when I2C wiring is correct and stable.

If you intend to proceed with a setup that involves somewhat unreliable I2C communication and want to mitigate it using a hardware timeout, this would require switching to a different EZB that supports such functionality. Most Arduino-based firmwares with I2C support include hardware timeout capabilities. However, please note that applying a timeout may leave the connected I2C device or sensor in an undefined state if the communication sequence is interrupted - this would be an additional consideration to address when evaluating alternative EZB hardware.

We recommend thoroughly inspecting your I2C wiring to eliminate communication errors, even if you opt to move to a different EZB. The I2C protocol is susceptible to issues from electrical noise, especially near relays, motors, or switching power supplies. It also has strict requirements around voltage levels and pull-up resistors on the data (SDA) and clock (SCL) lines. Compared to UART, I2C demands more precision in wiring and layout, which makes physical issues easier to detect but also more critical to resolve.

Keep in mind that even with an EZB that supports I2C timeouts, relying on that feature introduces additional latency, as the EZB must wait for the timeout to expire before it can continue processing further commands.

If you can provide information about the I2C sensors you are using, we can provide guidance.

Yeah support is correct about that hardware limitation of the ezrobot ezb. The ezrobot revolution robot JD uses the i2c for its eyes. With a reliable electrical connection, it won’t ever lock up. But, I believe by using one of the other ezb’s such as arduino, some support a hardware timeout.

but keep in mind that a hardware timeout might take half a second or what ever the sensor needs. So that’ll block any other commands.

It would be easier and more reliable to fix the root issue. As support said, we can help diagnose the electrical issue if you share more info about the i2c schematic.

I’d recommend creating a new question though. Because Athena will get confused that this thread started about Python sleep commands and now it’s about i2c