CAN bus vs SPI about open_robot_actuator_hardware HOT 2 CLOSED

serial is simpler to develop and use. Can bus requires a library, and its a complex protocol. There are also different flavours of CAN to contend with. Thus deployment of CAN requires a number of decisions to be reached as to the exact flavour which engineering effort would be better directed to the electromechanical design of the robot which is the main focus of this project.
But I too think it would be better. CAN-FD/CAN Open would be the obvious choice if its supported by all the devices. If I get around to implementing my idea of refactoring the code into C++ then maybe I can look at that too. Meanwhile soldiering on trying to source the arts.

from open_robot_actuator_hardware.

It's true that CAN can be easier to work with, especially for the wiring part (number of wires, noise immunity). However, it also has its limitations and this is why we decided to switch to SPI instead.

• The CAN frequency is limited to 1Mbps. In the ODRI project, we use SPI from 6 to 8Mbps.
• The protocol is half duplex (you can only exchange data in one direction) instead the SPI protocol we implemented is full duplex, so the effective bandwidth is doubled.
• The CAN frames need to be encapsulated with quite some overhead (address, framing header etc.)
• The CAN frames are very short (8Bytes) making the header overhead even more problematic.
• The addressing of CAN in not implemented yet in the uDriver (only one uDriver per CAN channel) and we have no manpower to work on this.

We are considering other solutions (CAN-FD, and RS485 at 12Mbps) with the new version of the motor drivers (still under test): https://github.com/open-dynamic-robot-initiative/open-motor-driver-initiative
It was not possible to implement this with the older electronics.

Sorry for entering so late in this conversation.
Best,
Thomas.

from open_robot_actuator_hardware.