Point cloud

Point cloud – definition

A point cloud is a set of 3D points that represent the geometry of a scene or object in Cartesian space. Each point usually contains at least x, y, and z coordinates, expressed in a defined reference frame. Depending on the sensor and software stack, a point may also include intensity, RGB color, return ring, timestamp, normal vector, or confidence. In mobile robotics, a point cloud is a common intermediate representation for perception, obstacle detection, terrain analysis, localization, and mapping.

On UGV platforms, point clouds are produced mainly by LiDAR sensors, stereo cameras, structured-light or time-of-flight depth cameras, and by map reconstruction pipelines. In ROS and ROS 2, the standard message for this data is sensor_msgs/PointCloud2. That message stores points in a binary layout with named fields and metadata such as width, height, point step, row step, and frame ID. For a rover, the practical meaning of a point cloud is simple: it is the spatial data structure that lets the robot estimate free space, detect obstacles, and build a local or global 3D model of its environment.

For Leo Rover and Raph Rover, point clouds are relevant when the platform is extended beyond basic teleoperation. Leo Rover, which can run ROS 2 on a Raspberry Pi-based compute unit, can use point clouds from compact sensors for education, prototyping, and moderate onboard perception workloads. Raph Rover, with higher payload capacity, is better suited to larger LiDARs, more stable sensor mounts, and higher compute budgets needed for denser 3D perception in outdoor or rough-terrain scenarios.

How point clouds are represented in ROS 2

In ROS 2, point cloud transport and processing are usually based on sensor_msgs/msg/PointCloud2. This message is designed for generic binary point sets and is the de facto standard across perception packages. The coordinate frame attached to the message must follow the TF tree used by the robot. In practice, correctness of the frame graph is as important as the cloud itself.

The most important implementation details are listed below.

header.frame_id defines the coordinate frame, for example lidar_link, camera_depth_optical_frame, or base_link.
fields describe per-point attributes such as x, y, z, intensity, or rgb.
height and width distinguish unorganized clouds from organized image-like clouds.
is_dense indicates whether invalid points are present.
TF2 is used to transform the cloud between frames, for example from a sensor frame to base_link or map.

For navigation on a mobile robot, point clouds are commonly projected or filtered before use. A 3D cloud may be converted into a 2D obstacle layer for Nav2 costmaps, or segmented into ground and non-ground components for traversability analysis.

# Inspect available point cloud topics
ros2 topic list | grep points

# Show message type
ros2 topic info /points

# Echo one message header only
ros2 topic echo /points --field header

# Visualize TF frames
ros2 run tf2_tools view_frames

How point clouds are generated on UGV platforms

Different sensors produce point clouds in different ways. This matters because point density, noise model, update rate, and field of view directly affect navigation and SLAM performance. A sparse but long-range LiDAR cloud behaves very differently from a dense short-range depth camera cloud.

The most common sources in mobile robotics are the following.

2D LiDAR with 3D reconstruction through platform motion or a tilt mechanism. This is computationally lighter but does not provide an instant volumetric snapshot.
3D LiDAR. This produces direct range measurements in multiple vertical channels and is the standard source for robust outdoor point clouds.
Depth cameras such as Intel RealSense. These generate dense local point clouds from depth images, useful indoors and at short range.
Stereo vision. This estimates disparity and triangulates 3D points. Performance depends strongly on texture, lighting, and calibration.

In ROS 2, depth cameras often publish both depth images and derived point clouds. LiDAR drivers may publish raw packets, laser scans, or directly a PointCloud2 topic. For outdoor UGV work, LiDAR remains the more stable choice for geometric perception because it is less sensitive to illumination than passive vision.

Key parameters and metrics

Point clouds are not only geometric data. They also have measurable properties that determine whether a specific cloud is suitable for mapping or obstacle avoidance on a rover. For engineering work, these parameters should be checked against the sensor specification and the available compute budget.

Parameter	Typical unit	Why it matters on a UGV
Update rate	Hz	Higher rates reduce latency in local obstacle detection
Range	m	Defines how far the rover can perceive obstacles or terrain
Angular resolution	deg	Affects point spacing and small obstacle detectability
Point density	points/s or points/frame	Controls geometric detail and processing load
Field of view	deg	Determines scene coverage around the robot
Timestamp accuracy	ms or µs	Critical for motion compensation and sensor fusion
Frame alignment error	mm or deg	Incorrect extrinsics distort maps and localization

For a moving rover, timing and calibration are often more important than raw density. A dense cloud with poor timestamps or wrong extrinsics can degrade SLAM and local planning more than a sparse but well-calibrated cloud.

Point cloud processing in autonomy stacks

Raw point clouds are rarely used directly. They are usually filtered and transformed into a representation suitable for a specific task. On ROS 2 systems this is often done with PCL-based nodes, custom perception pipelines, or GPU-accelerated modules.

Common operations include:

Voxel grid downsampling to reduce data size while preserving structure.
Pass-through filtering to remove points outside a working volume.
Ground segmentation to separate traversable surface from obstacles.
Outlier removal to suppress isolated noisy returns.
Registration such as ICP or NDT for localization and map alignment.
Projection into 2D costmaps for Nav2 obstacle layers.

A simple voxel filter reduces the number of points approximately by grouping points within cubes of edge length l. This lowers CPU and memory usage at the cost of geometric detail. On low-power onboard computers, this trade-off is often necessary.

pointcloud_filter:
  ros__parameters:
    input_topic: /camera/depth/color/points
    output_topic: /points/filtered
    voxel_leaf_size: 0.05
    min_range: 0.2
    max_range: 8.0
    target_frame: base_link

Use with Leo Rover and Raph Rover

On Leo Rover, point clouds are typically used in compact research or teaching setups. A depth camera or a small LiDAR can be mounted to provide local 3D perception. Because Leo Rover often uses a Raspberry Pi-class onboard computer, the full pipeline must be matched to available CPU, memory, and power. In practice this means moderate point rates, aggressive filtering, and selective use of 3D processing. For many tasks, converting the cloud into a 2D obstacle representation is the most efficient choice.

On Raph Rover, the engineering constraints are different. The platform can carry heavier sensors and stronger compute modules, which makes higher-resolution LiDAR mapping and multi-sensor fusion more realistic. This is useful in field robotics scenarios such as terrain inspection, construction-site mapping, or agricultural navigation, where the robot must perceive uneven ground, vegetation, and larger obstacle volumes.

In both platforms, the integration sequence is similar:

Mount the sensor rigidly and define extrinsics relative to base_link.
Publish a stable TF tree and verify time synchronization.
Filter the cloud to the operational range and remove self-points from the chassis.
Feed the processed cloud into SLAM, localization, or Nav2 costmaps.

Limitations and trade-offs

Point clouds are powerful, but they are expensive in bandwidth and compute. A dense cloud at high frame rate can saturate the network, storage, and CPU of a mobile platform. This is especially relevant on small UGVs.

The main trade-offs are straightforward.

Higher density improves geometric detail but increases latency.
Longer range usually reduces angular sampling density at near-field scale.
Depth cameras provide dense local data but degrade in sunlight and over reflective or transparent surfaces.
LiDAR is geometrically robust outdoors but may miss thin or low-reflectivity objects depending on beam pattern and material.

Normative references and standards

The ROS message definition for point clouds is maintained in the ROS interface packages and documented on docs.ros.org. Frame conventions and coordinate consistency should follow the ROS TF ecosystem and relevant REP documents, especially REP 103 for standard units and coordinate conventions. URDF-based sensor mounting should be aligned with the robot description used in ROS 2. For sensor-specific limits such as range, frame rate, and field of view, the authoritative source is the manufacturer specification, for example Intel RealSense documentation or LiDAR vendor datasheets.