SMR300
Autonomy stack for a 300 kg industrial AMR
A company's ROS 1 architecture replaced with a ROS 2 Humble stack written to be reused across a fleet, then validated over 300 logged trials on a live factory floor.
97%
Shelf docking success
Across 150 logged shelf-docking trials on a live factory floor.
2 cm
Mean docking error
Same 150-trial set.
3 cm
Point-to-point mismatch
Down from 5 cm, across 150 point-to-point runs.
Problem
The existing architecture was ROS 1 and had been written around one robot. A fleet needs a stack that can be configured rather than rewritten, and a factory floor needs one that degrades safely instead of stopping dead.
It also needed to be operable by engineers who do not write code, which rules out a system whose configuration surface is a set of YAML files and a terminal.
What I built
A layered stack — hardware, autonomy, operator — where each layer can be configured without editing the one below it.
- Reusable ROS 2 autonomy stack integrating LiDAR, PGV, Nav2, an AI camera, CANopen and CiA 402
- Reflective-marker shelf recognition for two- and four-legged shelves
- PGV floor-tag localization with wheel-odometry fallback
- Sector safety gating, safe aborts and alerts
- Operator platform: mapping, map editing, URDF and sensor configuration, Nav2 tuning, mission control, deployment validation
- Node-RED dashboard, evaluated by 5 operators and 2 engineers
Architecture
Three layers. The hardware layer speaks CANopen to Kinco servos through the full CiA 402 state machine. The autonomy layer runs Nav2 path planning, PGV localization with odometry fallback, shelf recognition and docking actions, sector safety gating and runtime diagnostics. The operator layer is the configuration and mission surface that sits on top of both.
CiA 402 that recovers instead of stopping
The ros2_control hardware plugin drives the servos through the full CiA 402 state machine with automatic fault reset, motor heartbeat monitoring, and command gating that refuses motion during initialization or error states. A separate lift-actuator driver enforces its limit switches independently, so a fault in one cannot move the other.
Localization that degrades rather than fails
PGV tag reads stream over RS-485 into a ROS 2 localization source backed by a tag map, with wheel-odometry fallback and explicit safety conditions when tag confidence drops. Getting there required URDF and sensor calibration, TF corrections, and confirmed SDO writes on the hardware interface.
Estimation tuned from measured noise
Allan variance analysis on the IMU produced real bias-instability and random-walk terms, which were injected as covariances into the IMU messages. The EKF then weights encoder against IMU corrections on measured uncertainty rather than assumed uniform reliability.
Failure diagnosis on a live floor
Intermittent docking failures were traced to direct sunlight entering through open factory doors and saturating the reflective-marker return. An environmental failure mode, not a software regression — which is the kind of answer that only comes from instrumenting the robot on the floor it actually runs on.
A docking attempt
The sequence that runs 97% of the time and, more importantly, what happens the other 3%. Nothing lifts until the pose has been validated.
Approach the shelf
Nav2 drives to the pre-dock pose.
Cluster the LiDAR return
Reflective-marker signatures isolated for two- and four-legged shelves.
Is the approach corridor clean?
No — sector safety gating blocks motionYes — continue to the center checkCenter check on the computed pose
Within tolerance — liftOut of tolerance — reposition and retryRetry exhausted — safe abort and alertLift the shelf
The lift actuator enforces its own limit switches, independently of the drives.
CiA 402, and how it recovers
The drive state machine the hardware interface drives over CANopen. The point of the diagram is the fault path: a fault resets automatically rather than stopping the robot for a person.
Switch on disabled
Ready to switch on
Heartbeat monitoring confirms the drives are actually present.
Operation enabled
Velocity commands translated to Kinco CANopen frames over SocketCAN; position integrated from velocity feedback.
Is the drive in fault?
Yes — automatic fault reset sequence, then re-enableNo — motion permittedCommand gating
Motion is refused during initialization or while any drive reports an error state.
The three layers
Each layer is configurable without editing the one below it. That is what makes the stack reusable across a fleet rather than tuned to one robot.
| Layer | What lives there |
|---|---|
| Operator | Mission control and monitoring, map editor and zone management, URDF and sensor configuration, Nav2 parameter tuning, Node-RED dashboard, deployment validation |
| Autonomy | Nav2 planning and following, PGV localization with odometry fallback, shelf recognition and docking actions, sector safety gating and safe abort, obstacle detection, runtime diagnostics |
| Hardware | ros2_control plugin, Kinco drives over CANopen, the CiA 402 state machine, lift actuator with independent limit switches, LiDAR and PGV interfaces |
Validation on a live floor
300 logged trials, split across the two behaviours that matter. These are the numbers already published by the deployment.
| Test | Trials | Result |
|---|---|---|
| Shelf docking | 150 | 97% success, 2 cm mean error |
| Point to point | 150 | 3 cm mean mismatch, down from 5 cm |
| Operator platform | 5 operators, 2 engineers | Node-RED dashboard evaluated in use |
Limitations and failure modes
- Reflective-marker docking is sensitive to direct sunlight on the approach corridor; mitigated by safe abort and retry rather than solved.
- Validated on one platform. Fleet reuse is designed for and not yet demonstrated across differing hardware.
Gallery
Not yet captured
- Node-RED operator dashboard
Repository map
The ROS 2 autonomy stack — navigation, docking, safety gating and bringup.
The ros2_control hardware interface: CANopen and the CiA 402 state machine.
State estimation, with covariances derived from Allan variance analysis.
Attribution
- My contribution within a team
- Built at Next Robotics Lab. I architected and wrote the ROS 2 autonomy stack, the hardware interface, the localization and estimation work, and the operator platform, and ran the validation trials. The robot platform and the business context are the company's.