next_HI
CANopen hardware interface and the CiA 402 state machine
A ros2_control plugin that speaks Kinco CANopen and manages the CiA 402 state machine, including the parts of it that are ugly and load-bearing.
Problem
ROS 2 speaks in velocities; the drives speak CiA 402 over CANopen and have opinions about what state they are in. Between those two is a translation layer that has to be exactly right, because the failure mode is a heavy machine moving when it should not.
The state machine is also not optional. A drive that faults and is never reset is a robot that stops for a person, every time.
What I built
A ros2_control hardware interface, and the safety behaviour around it.
- Velocity commands to Kinco CANopen frames over SocketCAN, position integrated from velocity feedback
- Automatic CiA 402 state management and fault-reset sequences
- Heartbeat monitoring, so 'ready' means the drive said so
- Command gating that blocks motion during initialization or fault
- A separate lift-actuator driver enforcing limit switches independently
- SLAM Toolbox mapping and Nav2 bringup on top, with DWB local and Navfn global planners
What refuses motion
Each of these is a case where the correct behaviour is to not move, and where the default behaviour of a naive interface is to try.
| Condition | Behaviour |
|---|---|
| Drive still initializing | Commands gated; no motion |
| Any drive reporting a fault | Gated, then automatic reset sequence |
| Heartbeat missing | Drive is not treated as ready |
| Lift actuator at a limit switch | Enforced by its own driver, independently of the wheel drives |
Limitations and failure modes
- Written against Kinco drives. The CiA 402 handling generalises; the frame-level specifics do not.
Attribution
- Built by me
- The hardware interface, state machine handling, gating and the lift driver.
- My contribution within a team
- Built at Next Robotics Lab as part of the SMR300 deployment.