Glossary

Fictionlab > Glossary > Loop closure

Loop closure

Loop closure – definition

Loop closure is the process of detecting that a mobile robot has returned to a previously visited location and adding a constraint between the current robot pose and an earlier pose in its map or pose graph. In SLAM, this constraint reduces accumulated drift from wheel odometry, IMU integration, and scan matching.

For a UGV, loop closure is not simply a visual or LiDAR-based recognition event. It is a verified spatial relationship between two robot states. The SLAM back end uses this relationship to optimize the trajectory and correct the global map. A successful loop closure can align corridors, field rows, rooms, or repeated inspection routes that would otherwise appear duplicated or offset.

In graph-based SLAM, robot poses are represented as nodes and relative motion estimates as edges. A loop-closure edge connects non-consecutive nodes:

x_i ---- odometry / scan matching ---- x_j
 |                                      |
 +--------- loop-closure constraint ----+

The optimizer estimates the pose configuration that best satisfies all constraints. A common objective is:

x* = argmin_x Σ(i,j) e_ij(x_i, x_j, z_ij)^T Ω_ij e_ij(x_i, x_j, z_ij)

Here, z_ij is the measured relative transformation between poses x_i and x_j, e_ij is the residual error, and Ω_ij is the information matrix describing confidence in the measurement. This formulation is used by pose-graph SLAM systems such as slam_toolbox, Cartographer, and many research implementations.

Why loop closure is required in mobile robotics

Local odometry is useful for short-term motion estimation, but it drifts over distance and time. Differential-drive UGVs are affected by wheel slip, uneven terrain, encoder quantization, changes in wheel contact, and calibration error. LiDAR scan matching can also drift when the environment has few geometric features or contains repeated structures.

Loop closure provides a global correction. Its primary effects are:

  • reduction of accumulated position and heading error;
  • alignment of revisited areas in a 2D occupancy grid or 3D map;
  • removal of duplicated walls, paths, or obstacles caused by drift;
  • improved consistency of globally referenced navigation goals;
  • more reliable map reuse during later localization runs.

A false loop closure is more harmful than a missed one. If two similar but different locations are matched incorrectly, optimization can distort the complete map. For this reason, practical systems use candidate search, scan correlation, geometric verification, descriptor matching, and rejection thresholds before inserting a loop-closure constraint.

Loop closure in ROS 2 SLAM systems

ROS 2 does not define loop closure as a separate transport standard. It is implemented inside SLAM packages. The robot must publish time-consistent sensor data and transforms, while the SLAM package maintains the pose graph and publishes the corrected map.

For a 2D UGV configuration, the most relevant ROS 2 interfaces are listed below.

Interface Typical ROS 2 type Purpose in loop closure
/scan sensor_msgs/msg/LaserScan Provides 2D range data for scan matching and loop verification.
/points sensor_msgs/msg/PointCloud2 Provides 3D point-cloud data when using 3D LiDAR or depth sensing.
/odom nav_msgs/msg/Odometry Supplies locally continuous motion estimation.
/map nav_msgs/msg/OccupancyGrid Publishes the globally corrected 2D map.
map → odom TF2 transform Applies global SLAM correction without changing local odometry abruptly.

REP 105 defines the conventional relationship between map, odom, and base_link. The odom frame should be continuous but may drift. The map frame is globally referenced and may change discontinuously when a loop closure or global localization correction occurs. Navigation stacks normally consume the resulting TF tree rather than applying map corrections directly to wheel odometry.

Configuration example with slam_toolbox

slam_toolbox is a ROS 2 package for 2D synchronous and asynchronous SLAM. Its loop-closing parameters must be tuned against the environment, LiDAR quality, motion speed, and map scale. The following fragment illustrates relevant parameters, not a complete robot configuration.

slam_toolbox:
  ros__parameters:
    mode: mapping
    do_loop_closing: true
    loop_search_maximum_distance: 3.0
    loop_match_minimum_chain_size: 10
    loop_match_minimum_response_coarse: 0.35
    loop_match_minimum_response_fine: 0.45
    transform_publish_period: 0.05
    map_update_interval: 5.0

The numeric values above are example tuning values, not universal requirements. The package documentation defines the parameter semantics. A larger search distance may find more candidates but raises computation cost and the probability of ambiguous matches. Response thresholds should be validated against recorded sensor data from the target environment.

Loop closure on Leo Rover and Raph Rover

Leo Rover is a four-wheel skid-steer UGV with a Raspberry Pi-based compute unit. It can be configured to run ROS 2, subject to the installed system image and supported ROS 2 distribution. It can run a 2D mapping pipeline when equipped with a compatible LiDAR and correctly configured wheel odometry, TF frames, and time synchronization. Autonomous navigation is not enabled by default and requires integration of a navigation and perception stack.

For Leo Rover, loop closure is particularly relevant in indoor laboratory routes, warehouse-like corridors, greenhouse paths, and repeated educational experiments. A typical workflow includes:

  • publishing calibrated wheel odometry and base_link transforms;
  • mounting a 2D LiDAR with an accurately measured base_link → laser static transform;
  • recording ROS 2 bags during repeated routes;
  • evaluating whether revisited map features align after optimization;
  • saving the optimized map only after false closures have been excluded.

Raph Rover is intended for larger payloads and can accommodate sensor configurations that require more compute power, wider LiDAR coverage, or additional GNSS/RTK and IMU integration. In outdoor mapping, LiDAR loop closure can be combined with RTK position constraints, but GNSS should not be treated as a substitute for geometric verification. Vegetation, seasonal changes, wheel slip, and sparse terrain can reduce the reliability of appearance-based or scan-based place recognition.

Key limitations and validation criteria

Loop closure performance depends on environmental observability. Long straight walls, identical corridors, repetitive crop rows, and feature-poor terrain create perceptual aliasing. Dynamic objects can also produce unstable scan matches. A system should log candidate closures and inspect graph corrections during validation.

Useful validation criteria include the following:

  • difference between estimated poses before and after graph optimization;
  • map overlap quality in revisited areas;
  • scan-matching response or residual error for accepted candidates;
  • number of accepted and rejected loop candidates per route;
  • repeatability across multiple ROS 2 bag recordings.

Normative references and technical sources

The frame conventions used by ROS navigation and SLAM systems are defined in REP 105. Package-specific loop-closing behavior must be checked against the documentation of the selected SLAM implementation and its ROS 2 distribution.

See also