Autonomous Mobile Robots: SLAM, Navigation & Localization
Autonomous mobile robots (AMRs) navigate unstructured environments without fixed guidance infrastructure. Unlike automated guided vehicles (AGVs) that follow magnetic tape or painted lines, AMRs build maps, localize within them, plan collision-free paths, and make decisions in real time. The global AMR market is projected to reach $8.5 billion by 2027, driven by adoption in warehousing, healthcare, manufacturing, and logistics (Interact Analysis, “Mobile Robot Market Report,” 2024). This article covers the core technologies — SLAM, localization, navigation stacks, and behavior trees — that enable AMRs to operate reliably in dynamic environments.
Understanding Autonomous Mobile Robots
An AMR must solve three simultaneous problems: Where am I? Where am I going? How do I get there without colliding with anything? These correspond to localization, goal specification, and motion planning. The ROS Navigation Stack packages solutions to these problems into a modular framework that supports multiple robot platforms.
The AMR hardware platform typically includes a differential drive or omnidirectional base, wheel encoders for odometry, an inertial measurement unit (IMU), and one or more exteroceptive sensors such as LiDAR, depth cameras, or ultrasonic rangefinders. Computing is usually handled by an onboard single-board computer running ROS, with a separate microcontroller handling low-level motor control at higher update rates. For industrial deployments, many platforms integrate safety-rated controllers that independently monitor velocity and stop functions.
The software architecture follows a sense-plan-act loop. Sensors feed data into perception pipelines that produce an environmental model. The planning module computes a trajectory to the goal. The control module translates the trajectory into motor commands. This loop must run at 10–50 Hz for safe navigation in dynamic environments. Thrun et al. provide the foundational text on probabilistic robotics that underpins these architectures (Thrun, Burgard, and Fox, Probabilistic Robotics, MIT Press, 2005).
SLAM Fundamentals
Simultaneous localization and mapping (SLAM) answers the chicken-and-egg problem: a robot needs a map to localize, but it needs to know its location to build the map. SLAM algorithms solve both problems concurrently using probabilistic state estimation.
GMapping, based on Rao-Blackwellized particle filters, was the canonical SLAM approach for many years. Each particle represents a possible robot trajectory and map. As the robot moves and observes new features, particles are weighted by how well they explain the sensor data. Resampling discards unlikely trajectories, concentrating particles on the most probable path. Grisetti et al. provide a comprehensive treatment of the Rao-Blackwellized particle filter approach (Grisetti, Stachniss, and Burgard, “Improved Techniques for Grid Mapping with Rao-Blackwellized Particle Filters,” IEEE Transactions on Robotics, vol. 23, no. 1, pp. 34–46, 2007).
Modern LiDAR-based SLAM has largely moved to graph-based methods. Cartographer, developed by Google, constructs a pose graph where nodes represent robot poses at keyframes and edges represent spatial constraints from odometry, loop closures, and scan matching. When the robot revisits a previously mapped area, a loop closure edge corrects accumulated drift. Graph optimization distributes the error across the entire trajectory, producing globally consistent maps. Cartographer’s real-time performance on low-power hardware made it the standard for many commercial AMR deployments.
Visual SLAM uses camera images instead of LiDAR. ORB-SLAM3, developed by Mur-Artal and Tardós, supports monocular, stereo, and RGB-D cameras with inertial fusion (Campos, Elvira, Gómez, Montiel, and Tardós, “ORB-SLAM3: An Accurate Open-Source Library for Visual, Visual-Inertial, and Multi-Map SLAM,” IEEE Transactions on Robotics, vol. 37, no. 6, pp. 1874–1890, 2021). It operates in real time on consumer hardware and maintains a sparse feature map suitable for localization. The key advantage of visual SLAM is cost — cameras are orders of magnitude cheaper than LiDAR — but visual methods struggle in low-light or texture-poor environments.
Long-term SLAM adds the dimension of time. Environments change — furniture moves, seasonal decorations appear, construction alters layouts. Lifelong SLAM systems detect changed regions in the map, update them incrementally, and maintain multiple map versions for different environmental states. ROS 2’s Nav2 includes support for dynamic map updates through the costmap layer architecture.
Localization with AMCL and Extended Kalman Filters
Given an existing map, Monte Carlo localization (MCL) estimates the robot’s pose using a particle filter. The ROS implementation, AMCL (adaptive Monte Carlo localization), dynamically adjusts the number of particles based on the ambiguity of the pose estimate. When the robot is highly uncertain — after being kidnapped or teleported — AMCL increases particles for wider coverage. When the pose is well determined, it reduces particles to save computation.
Each particle represents a hypothesis (x, y, θ) with a weight proportional to the likelihood of the current sensor observations given that pose. The particle set converges on the correct location within seconds of robot motion, provided the initial uncertainty is bounded. The adaptive variant also detects convergence failures and re-disperses particles when localization is lost.
For higher accuracy, many AMRs fuse multiple pose estimates using an extended Kalman filter (EKF). The robot_localization package in ROS 2 fuses wheel odometry, IMU data, visual odometry, and GPS (when available) into a single smooth pose estimate. The EKF predicts motion from inertial and odometry inputs, then corrects using absolute measurements from GPS or map-based localization. Moore and Stouch provide the canonical reference for multi-sensor fusion in ROS (Moore and Stouch, “A Generalized Extended Kalman Filter Implementation for the Robot Operating System,” IEEE ICRA, 2014).
Global localization — determining pose without an initial estimate — remains a hard problem. In large facilities where GPS is unavailable, this often requires a “kidnapped robot” recovery procedure: the robot attempts to match its current sensor scan against the map at multiple candidate positions, rotating in place to disambiguate symmetric environments.
Navigation Stack Architecture
The ROS 2 Navigation Stack (Nav2) processes a goal pose and produces velocity commands using a layered planning approach. Nav2 represents a complete redesign from the ROS 1 navigation stack, replacing the hand-coded state machine with behavior-tree-driven execution.
The global costmap operates at the resolution of the pre-built map and incorporates static obstacles from the SLAM map plus known dynamic obstacles received over topics. The global planner, commonly implementing Dijkstra’s algorithm or A*, finds the shortest path from the current pose to the goal while keeping the robot inside the global costmap’s free space. Smac Planner, the default global planner in Nav2, provides hybrid-A* and lattice-based planning options that respect the robot’s kinematic constraints during path search.
The local costmap is a rolling window centered on the robot at higher resolution. The local planner tracks the global plan while reacting to obstacles not in the map — moving people, newly placed objects, opened doors. The Timed Elastic Band (TEB) planner optimizes trajectory timing while respecting kinematic constraints, acceleration limits, and obstacle clearance (Rösmann et al., “Efficient Trajectory Optimization Using a Sparse Model,” IEEE ICRA, 2013). The Regulated Pure Pursuit planner provides a simpler, more robust alternative for lower-speed applications.
These layered planners run asynchronously. The global planner replans at a lower frequency (1–5 Hz), while the local planner updates at controller rate (10–50 Hz). This separation ensures reactivity without sacrificing global optimality.
Behavior Trees for AMR Decision Making
Behavior trees (BTs) structure robot decision-making as a tree of composable nodes, offering significant advantages over finite state machines for complex navigation behaviors. Behavior trees were formalized for robotics by Colledanchise and Ögren in their comprehensive text (Colledanchise and Ögren, Behavior Trees in Robotics and AI: An Introduction, CRC Press, 2018).
A navigation BT might include a “Navigate to Goal” sequence node with children: “Localize”, “Plan Global Path”, “Execute Local Plan”. Fallback nodes implement recovery behaviors — if “Execute Local Plan” fails, a fallback triggers “Rotate in Place” to clear the local costmap, then retries planning. Decorator nodes add conditions like “Has GPS Fix” or “Battery Sufficient”.
Nav2 uses behavior trees as its core behavioral architecture. Nav2 BTs can be edited using the Groot graphical editor, enabling non-expert users to reconfigure robot behavior without C++ programming. Commercial AMR platforms from MiR, Omron, and Fetch Robotics use similar behavioral architectures, often wrapping the planning core with application-layer behaviors for docking, charging, elevator operation, and interaction with industrial equipment.
Semantic Navigation and Open-Set Perception
Modern AMRs increasingly incorporate semantic understanding into navigation. Rather than treating all obstacles equally, semantic navigation distinguishes between static walls, movable objects, and dynamic entities like people or other robots. This distinction enables more intelligent behavior — the robot can ask a person to move rather than re-planning around them, or it can know that a chair is navigable while a shelving unit is not.
Open-set object detection models (YOLO-World, Grounding DINO) enable robots to recognize objects beyond a fixed training set. Coupled with large language models, AMRs can now respond to natural language commands like “Go to the red toolbox next to the workbench” — parsing the description, localizing the referenced objects, and planning a path to the described location.
Fleet Management and Multi-Robot Coordination
Scaling from a single AMR to a fleet introduces coordination challenges. Fleet management systems (FMS) assign tasks, monitor robot health, and resolve traffic conflicts across the robot fleet. Task allocation optimizes which robot handles which mission using the Hungarian algorithm or auction-based methods for fleets of 10–100 robots.
Traffic coordination prevents deadlock at intersections, elevators, and narrow corridors. Zone-based systems divide the facility into cells with mutual exclusion — only one robot may occupy a cell at a time. Path reservation systems assign time-slot occupancy for each robot’s planned trajectory, detecting and resolving conflicts before they occur.
Battery management is a fleet-level concern. Robots autonomously return to charging stations when battery drops below a threshold. The FMS must ensure that charging demand does not exceed charger availability, delaying urgent missions. Prediction of battery drain based on assigned mission distance and payload weight enables proactive charging scheduling.
FAQ
What is the difference between AMR and AGV?
AGVs follow fixed paths using guide tape, wires, or markers. AMRs navigate freely using onboard sensors and maps, enabling greater flexibility and adaptability to changing environments. AMRs can dynamically re-route around obstacles while AGVs stop when their path is blocked.
How accurate is AMCL localization?
Under good conditions with a high-quality map, AMCL achieves centimeter-level accuracy. Accuracy degrades in symmetrically ambiguous environments (long corridors) or when sensor quality is poor. Fusing AMCL with an EKF that includes odometry and IMU data improves both accuracy and robustness.
Does an AMR need GPS?
Indoor AMRs typically do not use GPS due to signal blockage. Outdoor AMRs use GPS as one input in a multi-sensor fusion pipeline, combined with IMU, odometry, and visual localization. For GPS-denied indoor environments, LiDAR or visual SLAM provides accurate localization.
How often does an AMR need to remap?
Maps remain valid as long as the environment is static. Significant layout changes — moved shelving, new walls, seasonal decor — require map updates. Many AMR fleets perform daily or weekly autonomous map updates to capture slow environmental drift. Lifelong SLAM systems handle incremental updates automatically.
Can AMRs operate in outdoor environments?
Yes. Outdoor AMRs add GPS, higher-power drive systems, weatherproof enclosures, and more robust obstacle detection. Applications include last-mile delivery, lawn maintenance, security patrol, and agriculture. Outdoor navigation faces additional challenges including variable lighting, uneven terrain, and weather effects on sensors.
Related: Explore path planning algorithms for details on the A* and Dijkstra implementations used in global planning. See the sensors and actuators guide for information on LiDAR and camera selection for AMRs. Learn about robot simulation for testing navigation stacks before deployment.