SLAM

SLAM – definition

SLAM stands for Simultaneous Localization and Mapping. In mobile robotics, it means estimating a robot’s pose while building a map of an unknown or partially known environment from sensor data. The pose is usually expressed in a global or locally consistent map frame, while the map may be represented as a 2D occupancy grid, a 3D point cloud, a pose graph, or a set of landmarks. In ROS and ROS 2 systems, SLAM is typically part of the perception and navigation stack for UGV platforms that operate without relying solely on external infrastructure.

For a differential-drive rover such as Leo Rover or a larger UGV such as Raph Rover, SLAM is not a single algorithm but a pipeline. It combines odometry, sensor fusion, scan or image matching, loop closure, and map optimization. The practical goal is to reduce drift that accumulates in wheel odometry and to provide a consistent map frame for navigation. In ROS terminology, this usually involves the transform chain map -> odom -> base_link, as defined by REP 105 for mobile platforms.

From a systems perspective, SLAM is required when GNSS is unavailable, degraded, or insufficiently precise for local navigation. This is common indoors, in urban canyons, under vegetation, near structures, and in research scenarios where the robot must build its own map. On Leo Rover, SLAM is often used in labs, classrooms, indoor test tracks, and small outdoor sites. On Raph Rover, the same concept extends to larger workspaces, rougher terrain, and heavier sensor payloads such as higher-grade LiDARs or RTK receivers.

How SLAM works in ROS 2

In ROS 2, SLAM nodes subscribe to sensor topics, estimate motion, and publish a map plus the required transforms. The exact interfaces depend on the package, but most integrations follow established ROS message types and TF conventions. This makes SLAM interoperable with Nav2, visualization tools, rosbag2, and simulation.

The standard data flow on a UGV usually includes the following topics and message types:

/scan – sensor_msgs/msg/LaserScan for 2D LiDAR
/points or /points_raw – sensor_msgs/msg/PointCloud2 for 3D LiDAR or depth processing
/imu/data – sensor_msgs/msg/Imu
/odom – nav_msgs/msg/Odometry
/tf and /tf_static – coordinate transforms per REP 105 and REP 103
/map – often nav_msgs/msg/OccupancyGrid in 2D SLAM systems

For ROS 2 Humble and newer, common SLAM options include:

slam_toolbox – 2D LiDAR SLAM for ROS 2, widely used with Nav2. It supports online asynchronous and synchronous mapping, map serialization, and pose-graph optimization.
RTAB-Map – visual and RGB-D SLAM, with optional LiDAR integration. It supports 3D graph-based mapping, loop closure, and multi-session workflows.
Cartographer – available in ROS ecosystems, though ROS 2 support and maintenance status should be verified per repository and distribution before deployment.

A minimal ROS 2 launch pattern for 2D SLAM with slam_toolbox looks like this:

ros2 launch slam_toolbox online_async_launch.py \
  use_sim_time:=false \
  slam_params_file:=/home/robot/config/slam_toolbox.yaml

A compact parameter example is shown below. Exact defaults vary by release and package version, so deployment should be aligned with the package documentation for the ROS 2 distribution in use.

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_travel_distance: 0.10
    minimum_travel_heading: 0.10
    transform_publish_period: 0.02
    map_update_interval: 2.0

Algorithms and sensor combinations

The choice of SLAM algorithm depends on the environment, compute budget, and sensor suite. On small UGVs, the main distinction is between LiDAR-based and vision-based SLAM. The former is usually more stable in texture-poor scenes. The latter can provide denser 3D information but is more sensitive to illumination and motion blur.

Typical combinations used on mobile robots include:

2D LiDAR + wheel odometry – common for indoor and structured environments. Efficient and practical for Raspberry Pi class systems if scan rate and map size are moderate.
2D LiDAR + IMU + wheel odometry – improves motion estimation and heading stability, especially on rougher terrain.
RGB-D camera + IMU – suited to indoor 3D mapping and research tasks where dense local geometry is useful.
3D LiDAR + IMU + GNSS/RTK – used in larger outdoor UGVs where elevation changes, sparse features, and loop closure over longer trajectories matter.

Core algorithmic steps usually include front-end registration and back-end optimization:

Front-end – scan matching, feature extraction, visual odometry, point cloud registration
Back-end – pose graph optimization, loop closure validation, bundle adjustment or factor graph optimization

In practical terms, slam_toolbox is often the first choice for 2D ROS 2 deployments on UGVs. RTAB-Map is more appropriate when stereo, RGB-D, or multi-modal 3D mapping is needed.

Key parameters and metrics

SLAM quality is evaluated by consistency, drift, map usability, and real-time performance. For field deployment, the limiting factors are often sensor rate, time synchronization, and compute headroom rather than the nominal algorithm design.

Parameter	Typical value	Why it matters
LiDAR scan rate	5-15 Hz	Higher rates improve motion tracking but increase CPU load
IMU update rate	50-200 Hz	Supports smoother state estimation and heading stabilization
Map resolution	0.02-0.10 m/cell	Lower cell size increases detail and memory usage
Odometry rate	20-100 Hz	Affects motion prior quality for scan or image registration
TF publication period	10-50 ms	Impacts downstream navigation and controller stability

For ROS-based systems, frame consistency is essential. REP 103 defines units and coordinate conventions, while REP 105 defines the relationship between frames such as base_link, odom, and map. If these are violated, SLAM may appear to work in visualization while failing in navigation or sensor fusion.

A simplified localization objective can be expressed as minimizing the discrepancy between predicted observations and measured observations:

x* = arg min_x Σ || z_i - h_i(x, m) ||_Ω

Here, x is the robot state or trajectory, m is the map representation, z_i are sensor observations, h_i is the observation model, and Ω is a weighting or information matrix.

Use on Leo Rover and Raph Rover

On Leo Rover, SLAM should be treated as an integration task, not as a built-in autonomous capability. The platform supports ROS natively on a Raspberry Pi-based compute unit, but autonomous navigation requires a configured sensor set, calibrated transforms, and a tuned navigation stack. A common setup is a 2D LiDAR with wheel odometry and optional IMU, publishing data into a ROS 2 Humble stack.

For Leo Rover, the practical constraints are compute and sensor placement. A lightweight 2D SLAM stack is generally the safest option. It is suitable for indoor mapping, corridor navigation, and compact research environments. The enclosure helps in light outdoor conditions, but wheel slip on loose terrain can degrade odometry and therefore SLAM quality.

Raph Rover allows larger payloads and therefore broader SLAM configurations. It can carry higher-performance LiDARs, more capable IMUs, depth cameras, or RTK-enabled positioning systems. This makes it more appropriate for larger outdoor sites, construction-like test areas, agricultural rows, or long-duration inspections where map scale and robustness matter more than minimal power draw.

In both cases, the integration checklist is similar:

Calibrate static transforms for LiDAR, IMU, camera, and base frames
Verify timestamp alignment and clock synchronization
Fuse wheel odometry and IMU where appropriate
Validate loop closures on rosbag2 recordings before field deployment
Confirm that Nav2 consumes the same map and TF tree produced by SLAM

Limitations and trade-offs

SLAM is sensitive to environment structure and sensor failure modes. Long featureless corridors, reflective surfaces, dust, rain, vibration, and repeated geometry can all reduce robustness. Outdoor operation adds problems such as wheel slip, vegetation motion, and changing illumination. These effects are relevant for both Leo Rover and Raph Rover in field tests.

The main trade-offs are straightforward:

2D LiDAR SLAM – efficient and stable, but limited in vertical structure representation
Visual SLAM – rich environment representation, but more sensitive to lighting and texture
3D LiDAR SLAM – robust in complex terrain, but expensive in power, bandwidth, and compute

If GNSS or RTK is available, it does not replace SLAM in close-range navigation. It complements it. In ROS 2 systems this is often handled through sensor fusion in packages such as robot_localization, where global measurements constrain long-term drift while SLAM provides local map consistency.

Normative references and standards

The ROS frame model and message interfaces used by SLAM systems are grounded in official ROS conventions and documentation. For technical implementation, the following references are the most relevant:

REP 103 – Standard Units of Measure and Coordinate Conventions
REP 105 – Coordinate Frames for Mobile Platforms
ROS 2 TF2 documentation on frame transforms and time-aware transform lookup
sensor_msgs, nav_msgs, and geometry_msgs interface definitions on docs.ros.org
Package documentation for slam_toolbox and RTAB-Map matching the deployed ROS 2 distribution

For hardware integration, sensor specifications should be taken from the relevant manufacturer documentation, such as LiDAR range and angular resolution, IMU noise density and update rate, depth camera operating modes, GNSS/RTK accuracy classes, and compute platform limits for boards such as Raspberry Pi or NVIDIA Jetson.