Repository navigation
CAN bus and interface
The Controller Area Network (CAN) bus is a communication system that allows multiple electronic devices to exchange data over a shared communication network. It is commonly used in robotics, automotive systems, and industrial automation because it is reliable, supports multiple devices, and is designed to operate in electrically noisy environments.
On the rover's robotic arm, CAN is used to communicate with the actuators that control the arm's joints. Rather than requiring a separate communication connection for every actuator, multiple actuators can communicate over a shared CAN bus.
A robotic arm typically contains multiple actuators, each responsible for controlling a joint or movement. The controller needs to send commands to these actuators and receive feedback, such as position or status information.
CAN provides several advantages for this system:
- Shared communication network
- Reliable Communication
- Message-based Communication
- Robustness
- Support for multiple actuator interfaces
A CAN network consists of devices connected through a shared communication bus. In the robotic arm, these devices include the main controller and the actuator controllers.
The controller transmits CAN frames containing an identifier and a payload. The identifier helps determine the message's meaning and priority, while the payload contains the data being transmitted.
For example, the controller might transmit a command to move an actuator to a target position. An actuator can also transmit feedback about its current position or operating state.
CAN uses message arbitration to determine which message is transmitted first when multiple devices attempt to transmit simultaneously. This allows communication to be coordinated without requiring a central device to schedule every individual transmission. Essentially the lower ID node wins with simultaneous messages and has dominant bits (0) overwrite recessive bits (1) when this occurs.
The physical CAN network typically uses two signal wires, CAN High (CAN_H) and CAN Low (CAN_L) which carry differential signals. A correctly wired network also requires appropriate termination resistors, generally 120 ohms at each end of the main bus.
The robotic arm uses two actuator types with different communication protocols:
- Avatar Robotics actuators: Use CANopen, a standardized communication protocol built on top of CAN.
- CubeMars actuators: Use a manufacturer-specific CAN protocol.
Although these actuator types use different software interfaces, they can share the same physical CAN bus if their electrical requirements and bus configuration are compatible. This includes using the same bit rate and ensuring their message identifiers, frame formats, and other configuration requirements do not conflict.
The CAN bus operates at 1 Mbps (1 megabit per second).
Sharing the physical bus does not mean the two actuator types communicate using the same protocol. The controller must still format commands and interpret responses according to the protocol supported by each actuator.
For example, communicating with an Avatar Robotics actuator may involve CANopen services, while communicating with a CubeMars actuator requires the message format defined by CubeMars.
It is important to distinguish between the physical CAN bus and the protocol used to communicate over it.
| Layer | Purpose | Robotic Arm Example |
|---|---|---|
| Physical CAN bus | Carries electrical signals between devices | CAN_H and CAN_L Wiring |
| CAN data link | Defines CAN frames, arbitration, and message identifiers | Transmitting and receiving CAN frames |
| Communication Protocol | Defines how messages represent commands, feedback, and device behaviour | CANopen or the CubeMars protocol |
| Application | Uses actuator commands and feedback to control the arm | Setting a joint's target position and monitoring its state |
CANopen and the CubeMars protocol operate above the underlying CAN communication mechanism. They define different ways to interface and use CAN messages.