Glossary

Fictionlab > Glossary > Mobile mapping

Mobile mapping

Mobile Mapping – definition

Mobile mapping is the process of collecting georeferenced spatial data while a sensor platform moves through an environment. In mobile robotics, the result is usually a map that combines geometry, robot pose, timestamps, and optionally semantic information such as terrain classes, objects, or inspection targets.

For an unmanned ground vehicle (UGV), mobile mapping is not limited to producing a visual map. It is a localisation and data-acquisition pipeline. The robot must estimate its position in a local or global reference frame, transform sensor measurements into that frame, and store or publish the resulting data with known spatial uncertainty.

A typical mobile-mapping system on a UGV combines LiDAR, wheel odometry, an IMU, cameras, and optionally GNSS or RTK GNSS. LiDAR or depth cameras provide geometric observations. IMU data constrains orientation and short-term motion. Wheel encoders provide odometry. GNSS provides a global position reference where satellite reception is available.

In ROS 2, mobile mapping is commonly implemented through a combination of sensor drivers, tf2 transforms, state estimation, SLAM or localisation nodes, and map-export tools. ROS coordinate-frame conventions for mobile robots are specified by REP 105: Coordinate Frames for Mobile Platforms.

Coordinate frames and map consistency

A mobile map is useful only when its coordinate frames are explicit and internally consistent. REP 105 defines the commonly used map, odom, and base_link frames. The base_link frame is fixed to the physical robot body. The odom frame provides locally continuous odometry, while the map frame represents a world-fixed reference in which the robot pose estimate may be corrected, with discrete jumps, when loop closures or GNSS updates occur.

The standard transform chain for a differential-drive UGV is shown below. Static sensor transforms are normally published from base_link to each sensor frame.

map
 └── odom
      └── base_link
           ├── laser_frame
           ├── imu_link
           ├── camera_link
           └── gps_link

The transformation of a point measured by a sensor into the mapping frame can be expressed as:

p_map = T_map_odom · T_odom_base_link · T_base_link_sensor · p_sensor

Here, T is a homogeneous transformation containing rotation and translation. Incorrect sensor extrinsics, timestamp offsets, or a missing transform can produce distorted point clouds and misaligned occupancy grids even when individual sensors operate correctly.

Mobile mapping data in ROS 2

ROS 2 uses standard message definitions for the data streams required by a mapping pipeline. The specific topic names are configurable, but the message types should remain compatible with the mapping and localisation nodes used in the system.

Data type Typical ROS 2 message Purpose in mobile mapping Reference
2D laser scan sensor_msgs/msg/LaserScan Occupancy-grid mapping and 2D localisation ROS sensor_msgs
3D point cloud sensor_msgs/msg/PointCloud2 3D reconstruction, terrain mapping, inspection data ROS sensor_msgs
Robot pose and twist nav_msgs/msg/Odometry Wheel odometry and state-estimator output ROS nav_msgs
Occupancy map nav_msgs/msg/OccupancyGrid 2D navigation and obstacle representation ROS nav_msgs

Before running SLAM, an integrator should verify message timestamps, frame IDs, transform availability, and topic frequency. The following ROS 2 commands help identify missing or unstable inputs.

ros2 topic list
ros2 topic hz /scan
ros2 topic echo /odom --once
ros2 run tf2_ros tf2_echo base_link laser_frame

Mapping methods for UGV platforms

The mapping method depends on the environment, sensor payload, computational budget, and required output. A 2D occupancy grid is sufficient for indoor navigation and corridor inspection. A registered 3D point cloud is more appropriate for terrain analysis, construction documentation, or vegetation mapping.

Common approaches include the following:

  • 2D LiDAR SLAM – estimates a planar trajectory and produces an occupancy grid from LaserScan data. It is appropriate for mostly flat environments where vehicle pitch and roll are limited.
  • Visual-inertial mapping – combines monocular, stereo, or depth-camera observations with IMU measurements. It requires sufficient visual features and is affected by challenging illumination.
  • LiDAR-inertial odometry – combines point clouds and IMU data for six-degree-of-freedom pose estimation. It is suitable when the robot experiences pitch and roll on uneven terrain.
  • GNSS-referenced mapping – aligns local mapping data with geographic coordinates. RTK GNSS can improve global positioning where correction data and satellite visibility are available.

SLAM produces a map and trajectory without requiring a pre-existing map. Localisation uses an existing map to estimate the current pose. A complete autonomous navigation stack may use both: SLAM during survey acquisition and localisation during later repeatable missions.

Mobile mapping with Leo Rover and Raph Rover

Leo Rover can serve as a compact ROS 2 mapping platform when equipped with an external sensor payload such as a 2D LiDAR, depth camera, IMU, or GNSS receiver. It uses a differential-drive, four-wheel chassis and can run ROS 2 using its integrated Raspberry Pi computer. Its IP55 rating should not be interpreted as protection for externally mounted sensors unless those components have their own environmental rating. Platform-specific integration details are available in the Leo Rover documentation.

For Leo Rover, a practical mapping configuration usually separates low-level drive control from higher-level localisation and mapping. Wheel odometry can be fused with IMU data in a state estimator before being consumed by a SLAM or navigation component. Sensor mounts must be rigid because movement between a LiDAR, camera, or GNSS antenna and base_link invalidates the calibrated transform.

Raph Rover may be suitable when the mapping payload requires greater physical capacity, larger sensor assemblies, or additional onboard compute hardware. Typical examples include a 3D LiDAR, a GNSS/RTK receiver with antenna mast, an industrial computer, and protected power distribution. The mapping architecture remains the same: calibrated sensors, timestamped ROS 2 messages, REP 105 frame semantics, state estimation, and validated map output.

Validation and output quality

Map quality should be assessed using repeatability, registration error, trajectory drift, map completeness, and agreement with surveyed control points where available. A visually plausible point cloud is not sufficient evidence of positional accuracy.

For field deployments, store raw sensor recordings with rosbag2, the robot configuration, static transforms, and the coordinate reference system used for exported data. This makes the mapping result reproducible and allows later recalibration or reprocessing.

See also