Production SLAM: Map Drift and Robot Fleet Localisation

Q: Why do warehouse robots get lost after the layout changes?

Because they localise by matching sensor scans against a stored map, and the map still describes the old layout. Moved racking or new fixtures reduce the match quality, so robots slow down, stop, ask for help or report a confident but wrong pose near the change. The fix is a map lifecycle, not more filter tuning.

Q: Should robots keep updating the map while they work?

Not the shared production map. Unsupervised continuous mapping across a fleet lets one robot write its own error into the reference every other robot uses. Run mapping as a supervised job, review the result, publish it as a new version and stage it through canary robots before the whole fleet adopts it.

Q: How do you measure localisation health on a robot?

Combine signals the localisation filter already exposes: pose covariance, particle spread for AMCL, the scan-match score against the map, and disagreement between the localised pose and wheel or inertial odometry. Turn them into a health state and publish it to the planner and fleet manager in real time, not only to logs.

Q: What is the difference between AMCL and slam_toolbox localisation mode?

AMCL is a particle filter that localises against a 2D occupancy grid and is mature and cheap. slam_toolbox's localisation mode matches scans against the saved pose graph without permanently changing it and can replace AMCL, but its own documentation notes it needs more tuning for each robot and site.

Q: What should a robot do when it is lost?

Slow down and widen safety margins as soon as health degrades, attempt relocalisation within a fixed time and motion budget, confirm any new pose with independent evidence such as a fiducial, and otherwise stop and request remote assistance. The fleet manager must be told so it can reroute traffic around the stopped robot.

Q: How does the ROS 2 Humble end of life affect robot localisation?

The ROS 2 release table lists Humble's end of life as May 2027 and Kilted's as December 2026, with Lyrical Luth supported to May 2031. Migrating distribution changes navigation packages and defaults, so re-run a recorded localisation evaluation set on the new stack before it reaches the fleet.

Q: When should a site use fiducials or reflectors instead of scan matching?

Where scan matching is physically weak or errors are expensive: long featureless corridors, glass and reflective surfaces, identical symmetric aisles, chargers and conveyor hand-offs. Markers give deterministic fixes at known points. Most production fleets combine a scan-based localiser with markers at the places that matter most.

Q: Can a good localisation score justify relaxing robot safety settings?

No. Safety functions that protect people should not depend on the robot's pose being correct; they belong in the certified safety layer with its own sensors and logic. Localisation health is an operational signal for speed, routing and recovery, not evidence that a protective field can be reduced.

Satyam Kumar

Back to Blog

architecture

The Map Is a Dependency That Rots: Production Localisation for Robot Fleets in 2026

By Satyam KumarNovember 11, 202611 min read

slam robot localisation amr fleet nav2 amcl slam toolbox map drift relocalisation ros 2 ros 2 humble migration vda 5050 fleet management warehouse robotics lidar localisation robot observability physical ai

The Map Is a Dependency That Rots: Production Localisation for Robot Fleets in 2026

Frequently Asked Questions

Share this article

Twitter LinkedIn WhatsApp

Satyam Kumar

Founder & AI Architect, AppScale LLP

AI & Cloud Architect. Helping teams build systems that scale to millions.

LinkedIn GitHub

The Map Is a Dependency That Rots: Production Localisation for Robot Fleets in 2026

Frequently Asked Questions

Share this article

Comments

Leave a comment