Embedded Files
Standardized, Integrated Management of Motion Controller Status and Commands
Why bother with CANopen?
If you're using traditional DC motors and encoders, you are likely familiar with a point-to-point wiring scheme: a PWM signal and direction pin going to a motor driver, a power line, and a handful of signal wires coming back from the encoder. This works well for simple systems, but as your robot grows - adding more motors, limit switches, and sophisticated feedback systems - your wire count, circuit board space, and integration time increase exponentially.
The solution used throughout industrial automation and modern robotics is a Fieldbus communication system, with CAN (Controller Area Network) being the most common choice. A fieldbus replaces dozens of point-to-point wires with a single, two-wire network that carries all communication and feedback data.
Crucially, because CANopen motion control drives adhere to the CiA 402 Device Profile, all vendors use the same Object Dictionary indices for fundamental commands (e.g., Target Velocity is always 0x60FF). This standardization provides powerful flexibility: if you need to switch vendors due to price, availability, or feature requirements, your core ROS 2 control code and high-level logic remain largely unchanged. The new drive integrates with minimal rework, drastically reducing integration time and risk.
What is CAN? (Controller Area Network)
CAN is a robust, message-based protocol originally developed by Bosch for automotive applications. It is a Data Link Layer (Layer 2) protocol in the OSI model, meaning it focuses on how data is reliably transmitted between two nodes on a single bus.
Two Wires: Communication happens over two differential voltage wires, CAN-High and CAN-Low. This robust physical layer makes it extremely noise-resistant - perfect for high-power robotics environments.
Broadcast Principle: Every device (node) on the bus hears every message. It is up to each node to decide which messages it needs to process.
No Address, Just Content: Unlike protocols like RS-232 or Ethernet, CAN messages do not contain a "sender" or "receiver" address. Instead, they contain an Identifier (ID) that defines the content and priority of the message.
CANopen: The Application Layer
While CAN provides the robust hardware and the arbitration mechanism, it doesn't define what a motor controller is, how to command a speed, or where to store a gain parameter.
CANopen is the Application Layer (Layer 7) protocol that sits on top of the CAN hardware. It defines:
Device Profiles: Standardized behavior for specific devices (e.g., CiA 402 for motion control). This means a CANopen motor controller from Vendor A works fundamentally the same as one from Vendor B.
Data Structure: The central concept is the Object Dictionary (OD).
Communication Methods: Defines how to perform real-time control (PDOs) and configuration (SDOs).
The Heart of CANopen: The Object Dictionary (OD)
The Object Dictionary (OD) is the defining feature of a CANopen device. Think of it as a comprehensive, standardized, and searchable list of every single parameter, setting, or piece of status information available on the device.
Structure: The OD is indexed by a 16-bit Index (e.g. 0x6060 for Target Velocity)
Example: When you want to set the maximum acceleration, you don't send a PWM value; you write a new numerical value to a specific address in the OD
Real-Time Control: Process Data Objects (PDOs)
PDOs are the replacement for your dedicated motor control wires (PWM, Encoder feedback). They are designed for fast, cyclic, and deterministic real-time data exchange with minimal overhead.
Mapping: A PDO is a "snapshot" of 1 to 8 OD entries bundled into a single CAN message. You map the critical OD entries (like Target Velocity, Current Position, Status Word) into a single PDO.
Two Types:
RPDO (Receive PDO): Data sent to the motor (e.g., command a new velocity). This is your digital PWM replacement.
TPDO (Transmit PDO): Data sent from the motor (e.g., actual velocity feedback). This is your digital encoder replacement.
Speed: Because the PDO message ID directly defines the content, there is no overhead for addressing or configuration - they are the fastest form of communication.
Configuration and Diagnostics: Service Data Objects (SDOs)
SDOs are used for non-real-time, reliable, and confirmed parameter exchange. They are used primarily during the commissioning or setup phase of the robot.
Confirmation: SDOs are based on a client-server model (Master/Slave). The Master (Controller) sends a request to write or read an OD entry, and the Slave (Motor) sends back an explicit confirmation or error response.
Use Cases:
Setting the motor's current limit.
Reading the device’s firmware version.
Changing the acceleration or deceleration ramps.
Configuring the PDO mappings.
Network Management and Synchronization (NMT & SYNC)
Two additional message types are critical for network integrity:
NMT (Network Management): NMT is the "master control" of the network. The NMT Master (usually the main robot controller) can command all or specific nodes to transition between operational states (e.g., Pre-Operational, Operational, Stopped). You use this to boot and start the entire motion system.
SYNC (Synchronization): The SYNC message is an optional, high-priority message used for precise multi-axis coordination. The Master sends one SYNC message, and all motors will execute their pending control tasks simultaneously. This is essential for coordinated motion between multiple robot joints.
Next Steps and ROS 2 Integration
Bringing CANopen to life with ROS 2 involves configuring your Linux system's socketcan interface, selecting or developing a ros2_canopen package to handle NMT state transitions, SDO-based drive configuration (like PDO mappings and operating modes), and real-time control via PDOs.
You'll also integrate this with ros2_control using a custom hardware interface. If you're ready to dive deeper into these practical steps or need personalized guidance on your specific servo drive integration, I invite you to schedule a call with me to learn more!
Ready to revolutionize your ROS 2 projects with seamless cross-platform communication?
Report abuse