Glossary

Fictionlab > Glossary > Cartographer

Cartographer

Cartographer – definition

Cartographer is an open-source simultaneous localization and mapping (SLAM) system originally developed by Google. It estimates a mobile robot’s trajectory while building a map from range sensor data. The core system supports 2D and 3D SLAM and uses scan matching, submaps, loop closure detection, and sparse pose-graph optimization.

In mobile robotics, Cartographer is commonly used to generate a consistent map frame for a UGV operating indoors or in structured outdoor areas. A typical deployment combines LiDAR data with IMU measurements and, optionally, wheel odometry, GNSS, landmark observations, or externally measured poses. Cartographer is not a navigation stack. It provides localization and mapping outputs that can be consumed by a planner such as Nav2.

For Leo Rover and Raph Rover, Cartographer can be part of a mapping workflow based on a 2D LiDAR, the rover’s wheel odometry, and an IMU. The robot still requires a separate navigation, obstacle detection, and motion-control configuration for autonomous operation.

How Cartographer performs SLAM

Cartographer separates the real-time estimation problem from global map consistency. Local SLAM processes incoming sensor data with low latency. Global SLAM periodically optimizes the trajectory when new constraints or loop closures are available.

The main processing stages are as follows:

  • Sensor synchronization and time ordering – range, IMU, odometry, and optional pose data are transformed into the robot tracking frame.
  • Pose extrapolation – the system predicts the current pose between range measurements using IMU and odometry data.
  • Local scan matching – an incoming laser scan or point cloud is aligned with the active submap.
  • Submap construction – consecutive scans are inserted into local probability grids. In 2D, these are occupancy-style grid representations.
  • Loop closure – Cartographer searches for constraints between trajectory nodes and previously created submaps.
  • Pose-graph optimization – a sparse optimization problem adjusts node and submap poses to reduce residual error across all accepted constraints.

A simplified pose-graph objective can be expressed as:

minimize over poses x:

Σ(i,j) || r_ij(x_i, x_j) ||²_Ωij

where:
x_i, x_j - trajectory node or submap poses
r_ij       - relative-pose residual for a constraint
Ωij        - information matrix / constraint weight

The optimized global pose may change after loop closure. This is expected behavior. A robot using Cartographer for navigation should therefore distinguish between the globally corrected map frame and the locally continuous odom frame, as described by ROS REP-105.

Cartographer inputs and ROS interfaces

Cartographer ROS uses standard ROS sensor messages and the ROS transform tree. Exact topic names are configured by the integrator, but message semantics must remain consistent with the selected trajectory builder and TF frame configuration.

Input or output Typical ROS message or frame Role in a UGV deployment
2D LiDAR sensor_msgs/LaserScan Primary range input for 2D mapping and localization.
3D LiDAR or depth cloud sensor_msgs/PointCloud2 Range input for 3D trajectories or multi-layer environments.
IMU sensor_msgs/Imu Angular-rate and linear-acceleration input. Required by Cartographer’s 3D trajectory builder.
Wheel odometry nav_msgs/Odometry Optional motion constraint for a differential-drive platform.
Global map map TF frame and optional nav_msgs/OccupancyGrid output Globally corrected reference used by localization and navigation components. Occupancy-grid output is commonly generated by Cartographer’s occupancy-grid node.

The standard TF relationship for a ground robot is typically map -> odom -> base_link. Sensor frames such as laser, imu_link, or camera_link must have known static transforms relative to base_link. Incorrect sensor extrinsics can produce warped maps, unstable scan matching, or false loop closures.

Cartographer in ROS 2 deployments

Cartographer core is written in C++, but the upstream Cartographer ROS integration targets ROS 1. ROS 2 deployments require a ROS 2-compatible port, a maintained vendor integration, or a custom wrapper around the core library. A maintained ROS 2 port (ros2/cartographer_ros) is released as binary packages for distributions such as Humble, but its launch files and parameters differ from the ROS 1 documentation.

Leo Rover documentation provides ROS 2 Humble support, but this does not make Cartographer a default mapping component. Compatibility with newer ROS 2 distributions should be verified. Before integrating a port, verify its supported ROS 2 distribution, TF2 implementation, lifecycle behavior, message namespaces, and compatibility with the installed compiler and Ceres Solver version.

The following commands are useful for validating sensor availability before starting a Cartographer-based stack:

ros2 topic list
ros2 topic echo /scan --once
ros2 topic echo /imu/data --once
ros2 topic hz /scan
ros2 run tf2_ros tf2_echo base_link laser

A 2D trajectory configuration commonly enables IMU and odometry when both sources are calibrated and timestamped correctly. The values below are examples only and must be tuned to the LiDAR range limits, mounting position, expected robot speed, and environment.

TRAJECTORY_BUILDER_2D.min_range = 0.12
TRAJECTORY_BUILDER_2D.max_range = 12.0
TRAJECTORY_BUILDER_2D.use_imu_data = true
TRAJECTORY_BUILDER_2D.num_accumulated_range_data = 1

POSE_GRAPH.optimize_every_n_nodes = 90

Use with Leo Rover and Raph Rover

On Leo Rover, a practical Cartographer configuration starts with a 2D LiDAR mounted rigidly above the chassis, wheel odometry from the differential-drive base, and an IMU with a documented transform to the robot frame. Leo Rover has an integrated Raspberry Pi compute unit, so point-cloud density, scan rate, submap size, and optimization frequency should be selected according to available CPU and memory resources. A 2D LiDAR workflow is generally less computationally demanding than a full 3D trajectory.

Raph Rover is suitable when the sensor payload, onboard compute unit, or environmental requirements exceed the scope of a compact platform. Its larger payload capacity can accommodate a higher-performance computer, a survey-grade GNSS/RTK receiver, or multiple perception sensors. GNSS data should not be treated as a replacement for local scan matching. It is an additional global constraint whose accuracy depends on antenna placement, correction availability, and local multipath conditions.

Limitations and integration risks

Cartographer assumes that sensor timestamps, coordinate frames, and calibration parameters are reliable. It cannot correct every hardware or integration fault at the mapping layer. A map may look plausible while still containing systematic scale, heading, or frame-alignment errors.

The following issues should be checked during commissioning:

  • LiDAR and IMU clocks are synchronized or have a known and compensated offset.
  • Static transforms use ROS coordinate conventions defined in REP-103 and REP-105.
  • Wheel odometry covariance reflects slip and wheel-radius uncertainty.
  • LiDAR scans contain sufficient static geometry for scan matching.
  • Dynamic objects, dust, vegetation, glass, and repetitive corridors are considered during validation.
  • Global pose corrections do not directly destabilize the rover’s local control loop.

Normative references and primary documentation

The following primary sources define the ROS coordinate conventions and Cartographer configuration concepts used in this entry.

See also