CAN bus

CAN bus – definition

Controller Area Network (CAN) is a serial communication bus designed for reliable real-time data exchange between electronic control units on a shared network. It is defined by the ISO 11898 family of standards. In mobile robotics, CAN bus is commonly used to connect motor controllers, battery management systems (BMS), wheel encoders, inertial measurement units (IMUs), GNSS receivers, safety devices, and auxiliary controllers.

A CAN network is multi-master. Any node may transmit when the bus is idle. Message priority is determined by the arbitration identifier, not by the physical address of a device. Lower numerical identifiers have higher priority because CAN uses dominant-bit arbitration. This behaviour is important on UGV platforms, where drive-control and safety messages must be delivered before lower-priority telemetry.

CAN is not a complete robotics middleware. It transports frames between embedded devices. ROS 2 nodes usually access CAN through a Linux SocketCAN interface and translate CAN frames into ROS 2 topics, services, diagnostics, or actions.

CAN bus in mobile robotics and UGV platforms

A mobile robot often contains controllers with different timing requirements. A motor controller may require commands at tens or hundreds of hertz, while a BMS may publish voltage, current, temperature, and fault-state data at a lower rate. CAN allows these controllers to exchange data over one differential two-wire bus.

For a differential-drive UGV, the relevant CAN data commonly includes:

wheel speed commands for the left and right drive sides;
encoder counts, wheel velocity, motor current, and controller temperature;
battery voltage, state of charge, charging state, and BMS fault flags;
emergency-stop state, watchdog status, and drive-enable signals;
IMU orientation or raw inertial measurements when the sensor exposes CAN output.

CAN uses a differential physical layer, usually labelled CAN_H and CAN_L. ISO 11898-2 specifies the high-speed CAN physical layer. A correctly terminated high-speed bus normally has a 120 Ω termination resistor at each physical end of the trunk. Two 120 Ω terminators measure approximately 60 Ω between CAN_H and CAN_L when the system is powered off and no other resistance paths affect the measurement.

Incorrect termination, long stubs, poor grounding, and excessive electromagnetic interference can cause error frames, retransmissions, bus-off events, or intermittent motor-controller communication. These faults are operationally significant on outdoor UGVs because drive feedback may be required by odometry and safety-monitoring nodes.

CAN frame types, arbitration and timing

Classical CAN supports two identifier formats. The standard frame format uses an 11-bit identifier, while the extended frame format uses a 29-bit identifier. The identifier is used for arbitration and message filtering. It is not equivalent to an IP address or a ROS 2 node name.

CAN variant	Maximum payload	Relevant standard	Typical robotics use
Classical CAN	8 bytes	ISO 11898-1:2024	Motor commands, encoder data, BMS telemetry
CAN FD	64 bytes	ISO 11898-1:2024	Higher-bandwidth sensor or diagnostic payloads

Classical high-speed CAN is commonly configured up to 1 Mbit/s, subject to cable length, transceiver characteristics, topology, and timing configuration. CAN FD separates the arbitration bit rate from the data-phase bit rate. Its practical configuration must be supported by every controller and transceiver on the network. A CAN FD-capable adapter does not make a classical CAN device CAN FD-capable.

Bus load should be calculated before adding high-frequency messages. A simplified estimate is:

bus_load ≈ Σ(frame_rate × average_frame_bits) / bus_bit_rate

The actual frame length depends on bit stuffing, identifier type, control fields, CRC, acknowledgements, and inter-frame spacing. Engineering calculations should therefore include margin and should be validated with a CAN analyser or SocketCAN statistics.

CAN bus integration with ROS 2

On Linux-based robot computers, CAN devices are normally exposed through SocketCAN. A USB-to-CAN adapter, PCIe interface, or embedded CAN controller may appear as can0. ROS 2 does not define one universal CAN message type for all devices because payload encoding, scaling, byte order, and identifiers are device-specific.

A ROS 2 integration layer should decode each frame according to the controller documentation or a DBC file. It can then publish semantically meaningful messages, such as sensor_msgs/msg/Imu, nav_msgs/msg/Odometry, sensor_msgs/msg/BatteryState, or diagnostic_msgs/msg/DiagnosticArray. Motor command nodes may convert geometry_msgs/msg/Twist into platform-specific wheel commands.

The following example configures a Classical CAN SocketCAN interface at 500 kbit/s. The selected bit rate must match every node on the physical bus.

sudo ip link set can0 down
sudo ip link set can0 type can bitrate 500000
sudo ip link set can0 up

candump can0
ip -details -statistics link show can0

For ROS 2 control architectures, the CAN driver is often placed below a hardware interface. The hardware interface reads encoder and status frames, updates joint state data, and writes wheel velocity commands. Timestamping requires care: a CAN frame timestamp is not automatically equivalent to the timestamp of a physical sensor measurement.

CAN bus on Leo Rover and Raph Rover

Leo Rover is a four-wheel differential-drive mobile platform with an onboard Raspberry Pi-based compute unit and documented ROS 2 software configurations. CAN should be treated as an optional integration interface unless a specific Leo Rover configuration, controller, or accessory explicitly documents CAN connectivity. Interface pinout, voltage level, connector type, and supported protocol must be verified against the relevant hardware documentation at docs.leorover.tech.

A practical Leo Rover use case is an external CAN-connected payload controller. Examples include a BMS monitor, a GNSS/INS receiver with CAN output, or a motor-controller test rig. The ROS 2 computer can bridge decoded data into navigation, logging, or diagnostic pipelines without assuming that all platform-internal control signals are available on CAN.

Raph Rover can use CAN for distributed payload electronics where multiple embedded controllers must share state with the onboard computer, provided that the relevant hardware configuration exposes a compatible CAN interface. Typical examples include actuator controllers, power-distribution monitoring, environmental sensor modules, and redundant safety-status reporting. The required bus topology depends on payload cable routing, controller count, electrical noise, and the update rate of each device.

Implementation limits and safety considerations

CAN provides priority-based, non-destructive arbitration, but it does not provide semantic interoperability by itself. Two devices can share the same physical bus while using incompatible frame identifiers, byte ordering, scaling, or command-state machines. Device documentation is required for every transmitted frame.

CAN also has no built-in authentication or encryption in Classical CAN and CAN FD. A node that can inject frames may influence other nodes if identifiers and payload formats are known. For field robots, access to CAN connectors and bridge computers should be controlled. Command frames should include application-level checks such as counters, timeouts, state validation, and watchdog behaviour where supported by the controller.

Standards and implementation references

The following documents define the core technology or provide implementation context for ROS-based Linux systems:

ISO 11898-1:2024, Road vehicles – Controller area network (CAN) – Part 1: Data link layer and physical signalling.
ISO 11898-2:2016, Road vehicles – Controller area network (CAN) – Part 2: High-speed medium access unit.
Bosch, CAN Specification Version 2.0, 1991. This document defines Classical CAN 2.0A and 2.0B frame formats.
Linux Kernel documentation, SocketCAN – Controller Area Network, for the Linux CAN networking interface.
ROS 2 documentation, ros2_control, for hardware-interface integration patterns in ROS 2 systems.