LiDAR SLAM

LiDAR SLAM – definition

LiDAR SLAM is a class of methods for simultaneous localization and mapping in which the primary exteroceptive sensor is a LiDAR. In mobile robotics, the robot estimates its own pose while building a map of the environment from laser range measurements acquired over time. The term is used both for 2D scan-based systems and for 3D point-cloud-based systems.

In a UGV context, LiDAR SLAM is usually implemented as a pipeline that combines laser scans or point clouds with odometry and the TF transform tree used in ROS. The output is typically a robot pose in a global or local map frame, plus a map representation such as an occupancy grid, submaps, or a registered 3D point cloud. In ROS and ROS 2 systems, this usually means consistent use of frames such as map, odom, and base_link, as described in REP-105.

For platforms such as Leo Rover and Raph Rover, LiDAR SLAM is relevant when wheel odometry alone is not sufficient. This is common on loose soil, grass, gravel, ramps, or uneven indoor floors where wheel slip degrades dead reckoning. LiDAR observations reduce drift by matching current scans to a map or to previous scans. The result is more stable localization for navigation, inspection, research, and field robotics.

How LiDAR SLAM works in ROS 2

In ROS 2, LiDAR SLAM is not a single standard package but an integration pattern. A LiDAR driver publishes range data, robot state publishers expose the kinematic frames, and a SLAM node estimates pose and map updates. Navigation stacks such as Nav2 then consume the resulting map and localization output.

A minimal ROS 2 data flow on a differential-drive UGV usually looks like this:

LiDAR driver publishes sensor_msgs/msg/LaserScan for 2D sensors or sensor_msgs/msg/PointCloud2 for 3D sensors
Wheel odometry publishes nav_msgs/msg/Odometry
TF publishes transforms such as odom -> base_link and static sensor extrinsics such as base_link -> laser
SLAM node estimates map -> odom or directly outputs pose in map
Map server or SLAM node provides occupancy grid or submaps for Nav2

For 2D LiDAR SLAM in ROS 2, common options include slam_toolbox. For 3D LiDAR-based localization and mapping, common research and integration choices include LOAM-derived methods, LIO-SAM, and related packages, often with IMU fusion. Their interfaces, ROS 2 support, and maturity vary by package and distribution.

REP-105 is important because it defines the semantic separation between the continuously drifting local frame odom and the globally corrected frame map. A LiDAR SLAM node usually computes the correction between them.

ros2 topic list
ros2 topic echo /scan
ros2 topic echo /odom
ros2 run tf2_tools view_frames
ros2 topic hz /scan

Core algorithmic steps

The exact implementation depends on the package, but most LiDAR SLAM systems on UGVs share the same structure. The LiDAR provides geometric constraints, and motion priors come from wheel odometry, IMU, or both.

Acquire a scan or point cloud at a known timestamp
Compensate motion distortion if the sensor scans over a finite time and robot motion is significant
Extract geometric features or use raw points
Register the current observation against a local map, previous scan, or submap
Optimize the robot pose
Update the map representation
Perform loop closure if a previously visited place is recognized

Scan matching can rely on ICP, NDT, correlative scan matching, or graph-based optimization. In 2D indoor robotics, occupancy-grid-based scan matching is common. In 3D outdoor robotics, feature-based or surfel-based registration is more typical, often combined with IMU preintegration.

A simplified pose estimation objective can be written as:

x* = argmin_x Σ_i || p_i^map - T(x) p_i^scan ||^2

Here, T(x) is the transform parameterized by pose x, and the optimizer minimizes the alignment error between measured points and the map.

Key parameters and metrics

LiDAR SLAM performance depends strongly on sensor quality, mounting, timing, and motion model quality. On small UGVs, practical integration details often matter more than nominal algorithm accuracy.

Parameter	Typical value	Why it matters
LiDAR update rate	5 – 20 Hz for many 2D units, 10 Hz or more for many 3D units	Higher rates reduce motion between scans and improve registration stability
Angular resolution	Sensor-specific, often around 0.2° – 1.0° in 2D LiDARs	Controls map detail and feature observability
Range	From a few meters to over 100 m depending on hardware	Determines usable environment scale and outdoor viability
Odometry rate	20 – 100 Hz	Provides motion prior between scans
Map update latency	Application-dependent	Affects closed-loop navigation responsiveness
Extrinsic calibration error	Should be minimized and measured	Incorrect sensor pose causes systematic drift and map distortion

In ROS 2, practical checks include topic frequency, timestamp consistency, dropped messages, and TF availability. If the LiDAR runs at 10 Hz but the CPU on a Raspberry Pi saturates, the effective SLAM rate may drop below real time.

Supported hardware and integration on Leo Rover and Raph Rover

Leo Rover is a compact differential-drive UGV with ROS 2 support, typically based on an embedded Raspberry Pi compute unit. This makes 2D LiDAR SLAM feasible, but compute budget must be treated as a hard constraint. A lightweight 2D pipeline is usually more realistic than dense 3D mapping unless compute is offloaded to an external machine or a more capable companion computer.

A typical Leo Rover setup includes:

a 2D LiDAR publishing /scan
wheel odometry publishing /odom
static TF for the LiDAR mount
slam_toolbox in asynchronous or synchronous mode
Nav2 consuming the occupancy grid and pose estimate

Raph Rover supports larger payloads and is better suited to heavier sensors and more demanding compute stacks. In practice, this makes 3D LiDAR, higher-grade IMUs, GNSS/RTK receivers, and NVIDIA Jetson-class computers more realistic integration choices. For field robotics, LiDAR SLAM on Raph Rover is often paired with IMU and GNSS to handle long trajectories and low-feature outdoor areas.

On both platforms, the sensor mount must be rigid. A flexible mast or bracket changes extrinsics under vibration and directly degrades scan registration.

slam_toolbox:
  ros__parameters:
    odom_frame: odom
    map_frame: map
    base_frame: base_link
    scan_topic: /scan
    mode: mapping
    resolution: 0.05
    max_laser_range: 12.0
    minimum_time_interval: 0.2

Limitations and trade-offs

LiDAR SLAM is robust, but it is not universal. It fails or degrades when the environment does not provide enough stable geometry or when sensor data quality is poor.

Typical failure modes on UGVs include:

feature-poor corridors, open fields, or long fences with repetitive geometry
dust, rain, fog, or direct contamination of the LiDAR window
wheel slip that corrupts the motion prior
rolling or pitching motion that violates 2D planar assumptions
timestamp errors between LiDAR, odometry, and IMU
CPU overload, causing delayed TF and stale map updates

For Leo Rover, the main trade-off is compute versus map quality. For Raph Rover, the trade-off is usually system complexity versus robustness. A larger platform can host better sensors, but calibration, synchronization, and power management also become more demanding.

Normative references and standards

The most relevant ROS reference is REP-105, which defines coordinate frames for mobile platforms. Message-level interoperability depends on standard ROS interfaces such as sensor_msgs/msg/LaserScan, sensor_msgs/msg/PointCloud2, nav_msgs/msg/Odometry, and TF2 transforms. In practice, package behavior differs between ROS 1 and ROS 2, and also by distribution. Leo Rover should be considered in a ROS 2 Humble-or-newer context.

When selecting hardware, verify the vendor specification for:

scan rate and angular resolution from the LiDAR datasheet
IMU bias stability and output rate from the IMU vendor
timestamping and PPS support for GNSS/RTK receivers when used in fused systems
available CPU and GPU resources on Raspberry Pi or Jetson-class computers

These parameters are not interchangeable across vendors and must be checked against the actual target package and ROS 2 integration.