A taxonomy of AMR failures: what we learned from 200,000 hours of fleet data.

Across our deployed AMR fleets — about 80 robots in production at the time of this writing — we have logged just over 200,000 hours of operation. We treat every "failure" event (anything that takes a robot out of normal operation, even briefly) as a learning opportunity. This note summarises the categories that have emerged.

The frequency-ranked taxonomy

1. Environmental obstacles (43%). Pallets out of place, cones left in aisles, cardboard fallen off a rack. Almost half of all "failures" are the robot doing exactly what it should — refusing to navigate around an obstacle that a human would step over but a robot, correctly, will not.

2. WMS data drift (22%). The robot is told to go to a location that has been re-allocated, or to pick up a pallet that has been moved manually since the task was issued. This is not a robot failure; it is a system-of-record problem. But operationally, it is the second-largest cause of intervention.

3. Localisation drift (14%). Visual SLAM has degraded because the environment has changed — racking moved, signage removed, lighting altered. Solvable with periodic re-mapping but requires discipline.

4. Battery / charging (8%). Less common than expected — modern AMRs manage their own charging well. The remaining failures are mostly contention at chargers during peak periods.

5. Mechanical (7%). Wheel wear, deck loose, sensor housing damaged. Predictable; addressed through maintenance schedules.

6. Software / fleet manager (6%). Edge cases in the navigation stack, fleet manager race conditions. Decreasing as the platform matures, but never zero.

What this changes about deployments

For any new customer, our pre-deployment audit now spends as much time on housekeeping discipline and WMS data quality as on physical infrastructure. The robots are not the bottleneck — the operating environment around them is.