Elevation map

Elevation map – definition

An elevation map is a spatial representation of terrain height used by a mobile robot to reason about ground geometry. In mobile robotics, it usually stores an estimated elevation value z for each cell of a two-dimensional grid defined in a local coordinate frame. The grid is typically aligned with a horizontal plane, while each cell describes the height of observed terrain relative to that frame.

Unlike a two-dimensional occupancy grid, an elevation map represents variation in terrain height. This allows an unmanned ground vehicle (UGV) to detect slopes, curbs, trenches, obstacles, ramps, and uneven surfaces. The map can be derived from LiDAR point clouds, stereo cameras, RGB-D cameras, or fused sensor data. It is commonly used as an input to traversability analysis, local planning, collision checking, and terrain-aware navigation.

In ROS-based systems, an elevation map is not defined by a single mandatory ROS message type or REP. Implementations commonly use grid_map_msgs/msg/GridMap, sensor_msgs/msg/PointCloud2, or a custom grid representation. Coordinate-frame conventions should follow REP 103, while relationships between map, odom, and base_link should follow REP 105.

Elevation map structure and terrain layers

An elevation map is normally organized as a regular grid. Each grid cell represents an area of physical terrain and can contain more than one layer. A height layer alone is often insufficient because terrain observations have uncertainty, may be stale, or may be occluded.

A practical elevation map for a UGV can include the following layers:

Elevation: estimated ground height for a grid cell.
Variance: uncertainty of the elevation estimate.
Time: timestamp of the latest valid observation.
Surface normal: estimated orientation of local terrain.
Slope: local gradient derived from neighboring cells.
Traversability: a cost or binary result used by a planner.

For a grid with resolution r, every cell covers an area of r². Lower values of r preserve smaller obstacles but increase memory use, update time, and sensor-noise sensitivity. The map dimensions must also cover the robot footprint, stopping distance, sensor field of view, and expected local-planning horizon.

For a height function z(x, y), an approximate local slope can be calculated from the terrain gradient:

slope = atan(sqrt((dz/dx)^2 + (dz/dy)^2))

In practice, derivatives are estimated from adjacent grid cells. Cells with missing measurements should not automatically be interpreted as flat terrain. They may represent unknown terrain, sensor occlusion, reflective surfaces, or areas outside the sensor range.

How elevation mapping works in ROS 2

A ROS 2 elevation-mapping pipeline transforms terrain observations into a stable frame, filters non-ground data, and updates grid cells. The transform tree is essential because LiDAR, camera, IMU, and robot-base measurements must be expressed in a common frame before fusion.

A typical data flow contains these stages:

A LiDAR or depth camera publishes terrain observations as sensor_msgs/msg/PointCloud2.
The robot state estimator publishes orientation and pose through tf2 transforms.
A mapping node transforms points into odom or map.
Points are filtered for range, outliers, and robot-body returns.
The mapper updates elevation and uncertainty layers.
A traversability node converts terrain metrics into planning costs.

The ROS 2 QoS model matters for sensor integration. High-rate point clouds often use a best-effort sensor-data profile to reduce latency. Map consumers must use compatible QoS settings; reliable delivery requires both the publisher and subscriber to use compatible reliable policies.

The following command can be used to inspect an elevation-map topic when a package publishes the common Grid Map message type:

ros2 topic info /elevation_map -v
ros2 topic echo /elevation_map --once

The message layout and layer names are implementation-specific. The Grid Map library provides a widely used multi-layer grid representation for ROS and ROS 2, but it does not make a specific elevation-mapping algorithm mandatory.

Sensor integration for UGV terrain mapping

Elevation maps depend on both exteroceptive and proprioceptive sensors. A point cloud provides terrain samples, but a valid orientation estimate and transform chain are needed to compensate for vehicle pitch and roll. Without orientation compensation, a robot driving uphill can incorrectly interpret its own body motion as terrain elevation.

Common sensor roles are as follows:

3D LiDAR: provides direct range measurements and is suitable for outdoor terrain geometry.
Depth camera: provides dense near-field data but, depending on its technology, can degrade in strong sunlight, low-texture scenes, or with reflective surfaces.
IMU: provides attitude information for gravity alignment and motion compensation.
Wheel odometry: provides short-term motion estimates but may drift on loose or uneven ground.
GNSS/RTK: can anchor a global map frame in outdoor deployments, but does not replace local terrain sensing.

Sensor timestamps must be synchronized closely enough for the robot motion during acquisition not to distort the point cloud. The transform timestamp used by tf2 must correspond to the measurement time, not only to the time at which the map update is processed.

Elevation maps on Leo Rover and Raph Rover

Leo Rover is a differential-drive, four-wheel UGV that can be used with ROS 2. It can act as a base platform for local elevation mapping, but autonomous terrain navigation requires integration of sensors, state estimation, mapping, and a navigation stack. It is not provided as an autonomous off-road system by default.

On Leo Rover, an elevation map is useful for laboratory ramps, construction mock-ups, agricultural rows, and inspection areas where a planar costmap would hide relevant ground geometry. A depth camera or compact LiDAR can be mounted as a payload, while IMU and odometry data are fused into the robot pose estimate. Compute requirements must be assessed against the available Raspberry Pi-based onboard compute unit and the selected point-cloud rate.

Raph Rover is better suited to configurations requiring a larger payload, such as a higher-performance compute unit, a multi-beam LiDAR, an RTK receiver, or multiple cameras. Its larger form factor does not eliminate the need for terrain validation. Map resolution, sensor mounting height, robot footprint, wheel clearance, and braking behavior must still be reflected in the traversability model.

Limitations and planning considerations

An elevation map is not automatically a navigation map. Nav2 costmaps primarily represent two-dimensional obstacle costs, so a terrain-aware system usually requires a conversion step from elevation layers to a cost layer, keepout region, or custom planner input. The cost function must define how slope, step height, roughness, and unknown space affect motion decisions.

Important limitations include self-occlusion, vegetation, moving objects, sparse returns, wheel slip, and pose-estimation drift. A map frame can remain locally consistent while becoming globally inaccurate if odometry drifts. For this reason, local rolling elevation maps are often preferable for immediate obstacle avoidance, while SLAM or GNSS-based localization supports global consistency.

Normative references and technical sources

ROS coordinate conventions are specified by REP 103, published by Open Robotics. Mobile-platform frame semantics are specified by REP 105. ROS 2 message definitions for point clouds are maintained in the sensor_msgs documentation. The Grid Map message definition is maintained in grid_map_msgs. Leo Rover platform documentation is available at docs.fictionlab.pl.