Traversability

Traversability – definition

Traversability is the estimated ability of a mobile robot to move safely and controllably through a specific area of terrain. In unmanned ground vehicle (UGV) robotics, it is not a fixed property of terrain alone. It depends on the terrain, the robot geometry, wheel or track configuration, payload, sensor uncertainty, motion controller, and mission constraints.

A traversability assessment assigns a cost, probability, or binary label to terrain cells, point-cloud regions, or candidate trajectories. The result is used by a planner to avoid terrain that could cause collision, immobilisation, rollover, excessive wheel slip, loss of localisation, or unacceptable energy consumption.

For a differential-drive UGV such as Leo Rover, traversability commonly considers obstacle height, local slope, surface roughness, clearance, and traction. For Raph Rover, the same factors apply, but the larger platform, higher payload capacity, wheel load, and physical dimensions can change the acceptable limits. A terrain feature that is traversable by one platform may be non-traversable by another.

Traversability versus obstacle detection

Obstacle detection identifies objects or terrain structures that may interfere with robot motion. Traversability is broader. It evaluates whether the robot can execute a planned motion over or around a surface while meeting safety and performance constraints.

For example, a low curb may be detected correctly by a LiDAR or depth camera. It can still be classified differently depending on the robot configuration:

A curb higher than the available ground clearance can create a collision risk.
A shallow ramp can be geometrically passable but exceed a configured slope limit.
Loose gravel can have low geometric risk but high slip risk.
Tall grass can be physically traversable but reduce LiDAR returns, increase slip risk, or reduce visual localisation reliability.

Obstacle detection is therefore an input to traversability estimation, not a complete replacement for it.

Key traversability parameters for UGVs

A practical traversability model converts terrain observations into measurable features. These features should be related to the actual mechanical limits and mission requirements of the vehicle. Values must be validated experimentally for the specific UGV, payload, tyre type, surface, and controller configuration.

Parameter	Typical representation	Why it matters
Local slope	Surface normal or elevation gradient, in degrees	Excessive pitch or roll can reduce traction and increase rollover risk.
Step height	Maximum elevation difference between neighbouring cells	Approximates curbs, rocks, roots, and trench edges.
Terrain roughness	Height variance, standard deviation, or plane-fit residual	Indicates vibration, wheel unloading, and unstable motion.
Clearance	Minimum distance between chassis model and terrain	Prevents underbody contact and high-centering.
Slip	Difference between wheel-derived motion and an independent body-motion estimate	Indicates reduced traction and degraded odometry.
Traversability cost	Normalised scalar, often 0.0 to 1.0 or 0 to 255	Allows planners to prefer safer paths rather than only reject obstacles.

A simplified terrain cost can be expressed as a weighted function:

C = ws * S + wr * R + wh * H + wc * (1 - Cmin) + wl * L

In this expression, S is slope, R is roughness, H is step height, Cmin is a normalised clearance margin, L is estimated slip risk, and the w values are platform-specific weights. The input features should be normalised to compatible ranges before applying this expression. A production system should also include confidence values, because unknown terrain should not automatically be treated as safe terrain.

Traversability data in ROS 2

ROS 2 does not define one universal traversability message type or a normative traversability algorithm. Instead, a system usually derives traversability from standard sensor messages, transforms data through tf2, and publishes the result as a map, grid, point cloud, or planner cost layer.

Common ROS 2 message types used in this pipeline include:

sensor_msgs/msg/LaserScan for 2D LiDAR range data.
sensor_msgs/msg/PointCloud2 for 3D LiDAR or depth-camera point clouds.
sensor_msgs/msg/Imu for orientation and acceleration measurements.
nav_msgs/msg/Odometry for estimated body motion.
nav_msgs/msg/OccupancyGrid for 2D cost or occupancy maps.
grid_map_msgs/msg/GridMap when using multi-layer elevation and traversability maps.

Frame conventions should follow REP 105, which defines coordinate frames for mobile platforms. A typical UGV frame tree contains map, odom, base_link, and sensor frames such as lidar_link or camera_link. REP 103 defines standard ROS coordinate conventions, including right-handed frames and SI units.

ros2 topic echo /points_raw --once
ros2 topic echo /imu/data --once
ros2 run tf2_ros tf2_echo base_link lidar_link
ros2 topic hz /elevation_map

The update rate of a traversability map should be measured at runtime with ros2 topic hz. It depends on sensor rate, point-cloud density, filtering, CPU or GPU capacity, and map size. There is no ROS 2 requirement for a fixed map frequency.

Traversability pipeline for Leo Rover and Raph Rover

Leo Rover provides a ROS 2 software stack for its Raspberry Pi-based compute hardware. The supported ROS 2 distribution depends on the installed Leo Rover software image and platform documentation. Its four-wheel differential-drive layout makes 2D costmaps useful on relatively flat surfaces, but obstacle height and slope cannot be inferred reliably from a 2D laser scan alone.

A typical Leo Rover outdoor configuration uses a 3D sensing source, such as a depth camera or 3D LiDAR, together with IMU data and wheel odometry. The sensor data can create an elevation map or voxel representation. A local planner can then reject cells with excessive slope, insufficient clearance, or obstacle height above a tested threshold. Leo Rover is rated IP55, but ingress protection does not define terrain capability, traction, or autonomous navigation performance.

Raph Rover can carry larger sensor suites and heavier compute payloads where the application requires denser 3D perception, additional GNSS/RTK equipment, or a higher-mounted LiDAR. Its larger size does not automatically make all terrain traversable. The footprint, centre of mass, payload distribution, and braking behaviour must be included in the robot model and validation procedure.

Integration with Nav2 costmaps

In ROS 2, Nav2 can use costmaps to represent obstacles and inflated safety regions. A traversability layer may integrate terrain-derived costs into a local or global costmap, or it may be implemented as a custom Nav2 costmap layer. Standard obstacle layers are suitable for occupied-space information, while a custom layer is appropriate when the map must encode slope, roughness, vegetation risk, or slip probability.

local_costmap:
  local_costmap:
    ros__parameters:
      plugins: ["obstacle_layer", "inflation_layer"]
      obstacle_layer:
        plugin: "nav2_costmap_2d::ObstacleLayer"
        observation_sources: pointcloud
        pointcloud:
          topic: /points_filtered
          data_type: PointCloud2
          marking: true
          clearing: true
      inflation_layer:
        plugin: "nav2_costmap_2d::InflationLayer"
        inflation_radius: 0.35

The inflation radius in this example is only a configuration example. It must be set from the robot footprint, localisation uncertainty, stopping distance, and required clearance. It is not a universal value for Leo Rover or Raph Rover.

Limitations and validation

Traversability estimation is uncertain because sensors only observe part of the terrain and cannot directly measure all physical properties. LiDAR and depth cameras can estimate geometry, but they do not reliably measure soil bearing strength, mud depth, ice, or subsurface voids. Camera-based classification can identify semantic terrain classes, but performance depends on training data, lighting, weather, and camera calibration.

A UGV traversability model should be validated with controlled tests before autonomous deployment. Validation should include representative slopes, uneven ground, loose material, wet surfaces, payload conditions, and emergency-stop behaviour. Logged data should include commanded velocity, wheel odometry, IMU data, localisation output, motor state where available, and the resulting terrain classification.

Normative references and technical sources

The following documents define relevant ROS conventions and interfaces. They do not prescribe a single traversability algorithm, but they provide the coordinate, message, and navigation foundations used by ROS 2 UGV systems.

ROS REP 103 – Standard Units of Measure and Coordinate Conventions, Open Robotics.
ROS REP 105 – Coordinate Frames for Mobile Platforms, Open Robotics.
ROS 2 sensor_msgs documentation, Open Robotics.
ROS 2 nav_msgs documentation, Open Robotics.
Nav2 documentation, Open Navigation LLC and contributors.
Leo Rover technical documentation, Fictionlab.