I’m currently working on a robotic arm that uses BLDC motor actuators. My goal is to create modular actuators similar to those used in the MIT Mini Cheetah.
At this stage, I am trying to determine the best communication system to use between each motor driver and the main controller board. The options I’ve considered are CAN, RS485, and Ethernet.
Each of these options has its own pros and cons, which seem relatively minor. Therefore, I would appreciate feedback from experts on which communication system would be the best choice. Additionally, I’d like to know if there is a widely adopted standard in this field.
Furthermore, if anyone could recommend a good resource for learning about creating custom drivers, that would be incredibly helpful.
At the end it will depend on the chosen MCU, but generally, Ethernet is more complex to implement on MCUs than the other two options, which typically require a cheap transceiver chip only and the rest is well supported by the MCU. Software overhead is probably also much higher for Ethernet, especially if you aim at ip protocols.
The VESC supports USB, CAN, UART, SPI, I2C
The ODRIVE supports USB, CAN, UART, Step/Dir, PWM
The Tinymovr supports CAN, UART, SPI
The Moteus supports CAN My v5 motor driver supports I2C, CAN
So it looks like CAN is the most popular interface in commercial motor drivers.
I think CAN is probably the best choice because it has many nice features:
Differential signaling for reliable long distance transmission.
Supports multiple devices on a single bus.
Arbitration and message priority which is implemented by hardware in CAN controllers.
CRC calculated by hardware, and optional auto retransmission if the message is received corrupted. Also handled in hardware.
The hardware used is cheap and widely available. Many STM32 microcontrollers have integrated CAN controllers, and CAN transceivers such as the TJA1462 can be purchased for less than $2.
However there are a few downsides to CAN:
Message length can only be 0, 1, 2, 3, 4, 5, 6, 7, 8, 12, 16, 20, 24, 32, 48, 64 bytes, no other values are allowed, leading to inefficiency if needing to send a different length message. This is for CAN FD, for Classic CAN the values higher than 8 bytes are unavailable so it is even worse.
The arbitration sequence is limited to 1Mbps and is quite long, leading to less efficiency when sending short messages.
The maximum speed of the data phase in CAN FD is 8Mbps, which is lower than Ethernet and RS485.
The other downside might be chip availability of CAN transceivers for small production scale.
It might be a ghost from the past, but some car manufacturers had to stop production because of that.