Glossary

Fictionlab > Glossary > Particle filter

Particle filter

Particle Filter – definition

A particle filter is a recursive Bayesian state-estimation method used to estimate a robot’s pose when measurements and motion are uncertain. In mobile robotics, the estimated state commonly includes planar position and heading: x = [x, y, θ]. Instead of representing uncertainty with one value, a particle filter represents the posterior probability distribution as a weighted set of samples, called particles.

Each particle is a possible robot pose. Its weight expresses how well that pose explains the latest sensor data. The method is particularly useful for UGV localisation because wheel odometry, LiDAR scans, IMU readings, and GNSS measurements contain noise and may be ambiguous. A particle filter can also represent multiple plausible poses before the robot has converged on a single location.

For a Leo Rover or Raph Rover, particle filtering is normally used for localisation in a known map. It is not, by itself, a complete autonomous-navigation system. It requires odometry, sensor drivers, a map source, and valid transform frames, and it can be connected to a navigation stack such as Nav2.

How a particle filter estimates UGV pose

A particle filter approximates the posterior distribution of robot state using N weighted particles. At time t, the approximation can be written as follows:

p(x_t | z_1:t, u_1:t) ≈ Σ(i=1..N) w_t[i] δ(x_t - x_t[i])

In this expression, x_t[i] is the state of particle i, w_t[i] is its normalized weight, u_1:t represents motion inputs, and z_1:t represents sensor measurements. The filter applies prediction when motion information is available and performs a measurement update, followed when needed by resampling, when sensor data arrive.

  1. Prediction: particles are moved according to the motion model. For a differential-drive UGV, the model usually uses wheel odometry and adds noise to account for wheel slip, uneven terrain, encoder error, and imperfect kinematics.
  2. Measurement update: particle weights are updated by comparing expected observations with real sensor data. In 2D localisation, this usually means comparing a LiDAR scan against an occupancy grid.
  3. Resampling: particles with high weights are retained more often, while particles with low weights are removed. This concentrates computation around likely robot poses.

A common resampling trigger uses the effective sample size:

N_eff = 1 / Σ(i=1..N) w[i]^2

When N_eff becomes low, the particle set is dominated by a small number of samples. Resampling can reduce this degeneracy, but excessive resampling may reduce particle diversity and cause premature convergence.

Particle filters in ROS 2 and Nav2

In ROS 2 mobile-robot systems, the most common particle-filter implementation for 2D map localisation is Adaptive Monte Carlo Localization (AMCL), provided by the Nav2 nav2_amcl package. It typically runs the amcl lifecycle node, which publishes an estimated pose and, when TF broadcasting is enabled, the transform between the map and odometry frames.

AMCL follows the ROS coordinate-frame convention defined in REP 105. A typical UGV transform chain is:

map → odom → base_link → laser

The map frame is globally referenced and typically fixed. The map → odom transform may change discontinuously after a localisation correction. The odom frame should be locally continuous and is normally produced from wheel encoders, visual odometry, or sensor fusion. The robot body frame is commonly named base_link. Sensor frames, such as laser or camera_link, must be connected through valid static or dynamic TF transforms.

A standard ROS 2 AMCL integration uses the following interfaces:

Interface Typical ROS 2 type Purpose
/scan sensor_msgs/msg/LaserScan 2D LiDAR observations used for map matching.
/map nav_msgs/msg/OccupancyGrid Static occupancy map used as the localisation reference.
/initialpose geometry_msgs/msg/PoseWithCovarianceStamped Initial pose hypothesis with uncertainty.
/amcl_pose geometry_msgs/msg/PoseWithCovarianceStamped Estimated pose and covariance.

ROS 1 used the amcl package in the ROS Navigation Stack. ROS 2 deployments should use the Nav2 AMCL documentation and parameters matching the installed distribution, such as Humble, Jazzy, or a newer supported release. Parameter names and lifecycle-node behavior can differ between releases.

Key parameters for a mobile robot

Particle-filter performance depends on sensor quality, map quality, motion uncertainty, and available compute capacity. A Raspberry Pi-based Leo Rover can run basic 2D localisation, but the particle count, scan processing load, and concurrent navigation nodes must be chosen according to the actual CPU load and LiDAR rate. A Raph Rover can support larger sensor payloads and more demanding compute configurations where required.

  • min_particles and max_particles: bound the number of pose hypotheses maintained by AMCL.
  • update_min_d and update_min_a: define minimum translation and rotation before a sensor update is processed.
  • laser_model_type: selects the scan likelihood model, such as likelihood-field or beam-based methods.
  • Odometry noise parameters: model uncertainty in rotational and translational motion.
  • Initial covariance: defines the search area after startup or manual pose initialization.

The following simplified ROS 2 YAML fragment illustrates parameters that should be tuned using recorded sensor data rather than copied unchanged between platforms:

amcl:
  ros__parameters:
    global_frame_id: map
    odom_frame_id: odom
    base_frame_id: base_link
    scan_topic: scan
    min_particles: 500
    max_particles: 2000
    update_min_d: 0.20
    update_min_a: 0.20
    laser_model_type: likelihood_field

Use on Leo Rover and Raph Rover

On a Leo Rover, a practical particle-filter setup uses differential-drive wheel odometry, a 2D LiDAR, a static occupancy map, and ROS 2 Humble or a newer supported distribution. The rover must publish a coherent odom → base_link transform and a calibrated base_link → laser transform. Incorrect sensor extrinsics can cause persistent pose offsets even when the particle filter is correctly configured.

Raph Rover can use the same 2D localisation architecture in larger indoor or outdoor test environments. For field use, GNSS or RTK-GNSS can provide a global position estimate, while LiDAR-based localisation can improve local consistency where a suitable map exists. Sensor fusion should account for different update rates, timestamp accuracy, antenna offsets, and GNSS multipath effects.

Limitations and validation

The AMCL particle-filter setup described here does not create a reliable map automatically and does not compensate for invalid transforms, poor wheel odometry, moving obstacles, or an outdated occupancy grid. LiDAR localisation may fail in repetitive corridors, open areas with few geometric features, or environments that have changed substantially since mapping.

Validation should include repeated trajectories, pose-error measurements against known landmarks or RTK reference data, TF inspection, and bag-file replay. The estimated covariance in /amcl_pose is useful for monitoring uncertainty, but it should not be treated as a guaranteed physical error bound without experimental validation.

Normative references and technical documentation

The following primary documentation defines the ROS interfaces and frame conventions relevant to particle-filter localisation on UGV platforms.

See also