AMCL (Adaptive Monte Carlo Localization)

AMCL – definition

Adaptive Monte Carlo Localization (AMCL) is a probabilistic localization method used to estimate a mobile robot’s pose on a known, static map. In ROS and ROS 2 navigation systems, AMCL typically estimates the robot pose as x, y, and yaw in the map coordinate frame. It is intended for robots that already have an occupancy-grid map and need to determine where they are within that map.

AMCL is based on Monte Carlo Localization, also called particle-filter localization. The algorithm maintains a population of pose hypotheses called particles. Each particle represents one possible robot position and orientation. Sensor observations, usually 2D LiDAR scans, are compared with the known map. Particles that better explain the scan receive a higher probability weight. The particle set is then resampled to concentrate computation around more probable poses.

The adaptive part of AMCL adjusts the number of particles during operation. It uses Kullback-Leibler divergence (KLD) sampling to increase or decrease the particle population according to the number of occupied pose-space bins needed to meet specified approximation-error and confidence bounds. This can make AMCL more computationally efficient than a particle filter with a permanently fixed particle count. The method is described in the original KLD-sampling work by Fox (2001) and is implemented in ROS navigation software.

For UGV platforms such as Leo Rover and Raph Rover, AMCL is commonly used after a map has been created with a SLAM system. It is not a mapping algorithm. AMCL localizes the rover against an existing map, while SLAM simultaneously estimates pose and builds or updates a map.

How AMCL works in ROS 2

In ROS 2, AMCL is provided by the nav2_amcl package in the Navigation2 stack. It runs as a lifecycle-managed node and is normally activated by the Nav2 lifecycle manager. The node consumes a static occupancy grid, odometry, laser scans, and coordinate transforms published through tf2.

The standard transform chain for a differential-drive UGV is:

map -> odom -> base_link -> sensor_frame

AMCL publishes the map -> odom transform. The robot driver, wheel odometry node, or state estimator publishes odom -> base_link. This separation follows ROS REP 105, which defines conventional coordinate frames for mobile robots. The odom frame should be locally continuous but can drift over time. The map frame is globally consistent with the static map but may be corrected discontinuously when AMCL updates its estimate.

The main ROS 2 interfaces used by nav2_amcl are listed below. Topic names can be remapped in a launch configuration.

Interface	ROS message type	Purpose
`/map`	`nav_msgs/msg/OccupancyGrid`	Static occupancy-grid map used as the localization reference.
`/scan`	`sensor_msgs/msg/LaserScan`	Planar range measurements used by the laser likelihood model.
`/initialpose`	`geometry_msgs/msg/PoseWithCovarianceStamped`	Initial pose hypothesis, usually set in RViz.
`/amcl_pose`	`geometry_msgs/msg/PoseWithCovarianceStamped`	Estimated robot pose and covariance in the map frame.
`/particle_cloud`	`geometry_msgs/msg/PoseArray`	Particle distribution for diagnostics and visualization.

Particle filter model and adaptive sampling

Each localization cycle combines a motion model and a sensor model. The motion model predicts how particles move using odometry. The sensor model evaluates how likely the observed LiDAR scan is for each particle pose in the map. A simplified particle weight is:

wᵢ ∝ p(zₜ | xᵢ, m)

In this expression, wᵢ is the weight of particle i, zₜ is the sensor observation, xᵢ is the particle pose, and m is the map. After normalization, AMCL resamples the distribution. Particles with low probability are removed, while high-probability regions receive more samples.

KLD sampling limits the particle count according to the desired approximation error and confidence. In Nav2 AMCL, this behavior is configured through parameters including min_particles, max_particles, pf_err, and pf_z. Their values depend on map size, environmental symmetry, LiDAR quality, processor capacity, and required recovery behavior.

Key AMCL parameters for a mobile UGV

Correct parameterization is more important than selecting a large particle count. A rover operating in narrow corridors, repetitive warehouse-like spaces, or outdoor areas with few stable features can otherwise converge to an incorrect pose hypothesis.

robot_model_type selects the motion model. Differential-drive platforms normally use nav2_amcl::DifferentialMotionModel.
laser_model_type selects the range-sensor likelihood model. Nav2 supports beam-based and likelihood-field approaches.
update_min_d and update_min_a define translational and rotational motion thresholds before a filter update is performed.
resample_interval controls how often resampling occurs after filter updates.
transform_tolerance defines the validity period assigned to the published localization transform.
set_initial_pose and always_reset_initial_pose affect startup and recovery behavior when a prior pose is available.

A minimal ROS 2 parameter fragment can define the expected frames and scan source. Values should be validated against the rover’s real transform tree and sensor mounting geometry.

amcl:
  ros__parameters:
    robot_model_type: "nav2_amcl::DifferentialMotionModel"
    base_frame_id: "base_link"
    odom_frame_id: "odom"
    global_frame_id: "map"
    scan_topic: "scan"
    laser_model_type: "likelihood_field"

AMCL on Leo Rover and Raph Rover

Leo Rover has a four-wheel drive configuration that can be modeled with differential-drive kinematics. For indoor autonomous navigation, a typical AMCL setup includes wheel odometry, a 2D LiDAR publishing sensor_msgs/msg/LaserScan, a static map, and a correctly defined URDF and tf2 tree. The onboard Raspberry Pi can run basic ROS 2 nodes, but computational load must be assessed when AMCL runs together with Nav2 planning, perception pipelines, camera processing, or SLAM.

Raph Rover can use the same ROS 2 localization architecture when a larger payload or additional sensing is required. A larger UGV may carry a higher-mounted LiDAR, GNSS receiver, IMU, or an external compute unit. AMCL remains map-based and primarily LiDAR-based. GNSS, RTK, and IMU data are usually fused separately, for example by an Extended Kalman Filter, before or alongside AMCL. They do not replace the map-to-scan matching process performed by AMCL.

Limitations and operational requirements

AMCL assumes that the map is sufficiently accurate and that the environment contains stable geometric features detectable by the selected range sensor. It performs poorly when scans are dominated by moving people, vegetation, temporary construction objects, glass, rain, dust, or large unmapped changes.

Before deploying AMCL on a UGV, verify the following conditions:

The LiDAR frame is correctly connected to base_link through static or robot-state-publisher transforms.
Wheel odometry uses the correct wheel geometry and direction conventions.
The occupancy-grid map uses the same physical scale and orientation as the operating environment.
The LiDAR scan timestamp, odometry timestamp, and TF buffer are synchronized sufficiently for the rover speed and sensor latency.
The initial pose is supplied when global localization is not configured or when the robot starts in an ambiguous area.

Normative references and technical sources

The ROS frame conventions relevant to AMCL are defined in REP 105. The ROS 2 implementation is documented in the Navigation2 AMCL package documentation. The underlying adaptive particle-filter method is described in Dieter Fox, “KLD-Sampling: Adaptive Particle Filters,” NeurIPS, 2001.