EZB Disconnecting
An unwanted EZB disconnection is when ARC disconnects from the EZB without notice. In many cases, ARC may lock up and stop responding.
ARC release candidates run stress tests on several virtual machines before being released to the public. The most significant stress test for reliability uses ARC to control four robots 24/7 connected to Exosphere. Many people do not know that Synthiam's Exosphere robots are performing reliability/efficiency/stability tests for ARC. These robots perform multiple cameras with tracking, Wi-Fi and USB connections, NMS, and more. The Exosphere test robots are always online, so people worldwide use them at all times of the day. Generally, you can dismiss ARC core as causing disconnection/freezing issues.
1. Power
This is the first item to check because it is generally the most common problem with DIY robots. Robots that use motors and servo motors will often draw high currents. Sometimes, these robots draw more current than what is available from the battery or power supply.
- How many amps is the robot drawing? Check for the current draw of average use and peak use.
- How many amps is the power supply rated for? Verify the power supply provides enough current based on the measurement in the previous step.
- Are motors and servo motors directly connected to the EZB power pins? Some EZB controllers, such as the EZ-Robot IoTiny or EZ-B v4, have power pins for convenient connections. However, due to the small traces of these EZB controllers, they might not provide the current necessary and brown-out. A brown-out is when the EZB does not get enough power and shuts down or locks up.
2. Wi-Fi Connection
Some EZB controllers are connected via Wi-Fi, such as the ESP32, EZ-Robot IoTiny, and EZB v4. While Wi-Fi is convenient by not requiring wires, it is the second most common cause of disconnections. The Wi-Fi connection should operate over a channel that is not saturated and provides the most stability and throughput.
*Note: We recommend using a USB EZB connection rather than Wi-Fi for robots in production environments.
- Check for the Wi-Fi channel saturation? Use THIS TOOL to check and use a less saturated channel. If possible, consider hard-wiring the EZB to the PC.
3. Communication Timeouts
Sensors and peripherals connected to the EZB may require bi-directional communication. In many cases, this is most prevalent with i2c devices that need START and STOP acknowledgments while reading/writing data. Some I2c devices may time out when a connection is unstable due to a loose connector, electrical interference, or communication noise. The time-out could dramatically slow the EZB communication, which ARC will appear to have locked up. Or, ARC may entirely freeze while waiting for a response from an unresponsive EZB due to a communication timeout with a peripheral/sensor.
- Are there any i2c devices connected to the EZB? (i.e., RGB Eyes, Compass, Accelerometer) If so, ensure the wiring and connectors are secure. I2C devices with poor wiring/connections can lock up many microcontrollers.
- Common disconnects are reported from EZ-Robot JD Humanoid products when the RGB Eyes connection is loose or faulty. This causes the EZB controller to lock up while sending I2C commands. If using an EZ-Robot product with RGB Eyes, have you checked the cable connection to ensure it is secure?
4. ARC Project
Lastly, examine the project for issues that may cause disconnections. In some circumstances, many scripts looping and reading/writing data can cause a lockup or disconnection. This happens when the data channel is flooded with requests, most commonly over Wi-Fi-enabled EZBs.