3D LiDAR

3D LiDAR – definition

3D LiDAR is a ranging sensor that measures distances to surfaces and produces a spatial point cloud. Each point represents a sampled position in three-dimensional space, usually expressed as Cartesian coordinates x, y, and z in the coordinate frame specified by the message. Depending on the device, a point may also contain intensity, return number, timestamp, ring index, reflectivity, or confidence information.

In mobile robotics, 3D LiDAR provides geometric observations of the environment around an unmanned ground vehicle (UGV). It is used for obstacle detection, terrain representation, localisation, 3D mapping, loop closure, and perception. Unlike a planar 2D LiDAR, which measures points in one scanning plane, a 3D LiDAR captures vertical structure such as shelves, walls, tree branches, ramps, building facades, kerbs, and uneven terrain.

On ROS 2-based UGVs such as Leo Rover and Raph Rover, a 3D LiDAR is normally integrated as an external payload. It requires mechanical mounting, a stable power supply, a supported driver, timestamp handling, and a valid transform tree. Leo Rover can run ROS 2 on its onboard Raspberry Pi computer, while heavier sensors or perception pipelines may require an additional onboard computer. Leo Rover has four wheels and differential-drive kinematics. Source: Leo Rover technical documentation.

How 3D LiDAR measures the environment

Most mobile robotics LiDARs use time-of-flight measurement. The sensor emits laser light and estimates the distance from the time required for a reflected signal to return. The basic relation is shown below, where c is the speed of light and Δt is the measured round-trip travel time.

distance = c × Δt / 2

A rotating multi-beam LiDAR commonly generates a point cloud by combining measurements from several vertically aligned laser channels with the sensor rotation. Solid-state and MEMS-based devices can generate 3D measurements without a continuously rotating assembly. The resulting cloud is not an instantaneous image of the environment. It is acquired over a scan interval, so robot motion can distort the cloud if motion compensation is not applied.

The following properties determine whether a sensor is suitable for a specific UGV task:

Range – the usable distance to targets with defined reflectivity.
Horizontal and vertical field of view – the area observed around and above the vehicle.
Angular resolution – the separation between adjacent rays.
Point rate – the number of valid measurements published per unit of time.
Scan frequency – the rate at which the sensor completes a full scan pattern.
Range accuracy and precision – the difference from reference distance and the repeatability of measurements.
Minimum range – important for detecting objects close to the chassis.
Environmental rating – relevant for ingress protection, vibration, and outdoor temperature changes.

Published values must be interpreted using the manufacturer’s test conditions. Maximum range can depend substantially on target reflectivity, ambient illumination, weather, and the selected return mode.

3D LiDAR data in ROS 2

In ROS 2, a 3D point cloud is commonly published using sensor_msgs/msg/PointCloud2. This message stores point data in a binary buffer and describes each field through metadata. It can represent different layouts, including clouds with x, y, z, intensity, and ring fields. Source: ROS 2 sensor_msgs documentation.

The message header contains a timestamp and frame_id. Both are essential. Navigation and mapping software must know when a point cloud was acquired and where the LiDAR is mounted relative to base_link.

ROS 2 element	Typical role	Reference
`/points`	Raw or filtered `PointCloud2` data	sensor_msgs
`base_link`	Robot body coordinate frame	REP 105
`odom`	Continuous local odometry frame	REP 105
`map`	Global frame used by localisation or SLAM	REP 105

ROS coordinate conventions are defined by REP 103. For body-fixed frames, the standard convention is x forward, y left, and z up. LiDAR drivers and static transforms should conform to this convention to avoid mirrored maps, inverted point clouds, or incorrect obstacle positions. Source: REP 103 – Standard Units of Measure and Coordinate Conventions.

Integration on Leo Rover and Raph Rover

A LiDAR mounted on Leo Rover should be placed high enough to reduce self-occlusion from the chassis while remaining mechanically rigid. A roof or mast mount may improve visibility, but it also increases vibration sensitivity and can affect stability. The sensor frame must be represented in the robot URDF or provided through a static transform publisher.

ros2 run tf2_ros static_transform_publisher \
  0.18 0.0 0.32 0.0 0.0 0.0 \
  base_link lidar_link

The translation and rotation above are examples only. They must be replaced with measured mounting values. REP 105 recommends using transforms to relate sensor frames to the robot body and navigation frames. Source: REP 105 – Coordinate Frames for Mobile Platforms.

Raph Rover can be more appropriate when the sensor payload, onboard compute hardware, battery capacity, or field enclosure is larger than a typical laboratory configuration. It remains necessary to account for sensor vibration, cable strain relief, power conversion, and the physical offset between the LiDAR and the vehicle centre of rotation.

3D LiDAR for SLAM and navigation

3D LiDAR supports LiDAR odometry and 3D SLAM, and it can be combined with IMU data and wheel odometry for lidar-inertial odometry. Common processing stages include deskewing, voxel-grid downsampling, ground segmentation, scan matching, pose estimation, and map generation. Algorithms may use point-to-point, point-to-plane, normal-distributions transform, or feature-based registration methods.

For a differential-drive UGV, wheel odometry estimates local motion but can drift on loose ground or during wheel slip. An IMU helps estimate rotational motion, while LiDAR scan matching can constrain pose against stable environmental geometry. GNSS, including GNSS with RTK corrections, may add a global reference outdoors, but it does not replace local obstacle sensing.

A 3D cloud may be projected into a 2D obstacle representation for Nav2, or it may be used by a voxel-based obstacle layer. The correct approach depends on the terrain, obstacle height, sensor mounting position, and computational budget. Nav2 uses ROS 2 and provides navigation components for mobile robots. Source: Nav2 documentation.

Limitations and validation

3D LiDAR does not directly classify objects. It measures geometry. Object recognition requires additional perception logic, such as clustering, tracking, camera fusion, or machine-learning inference. Dark, transparent, highly reflective, narrow, or rain-covered surfaces can produce weak, missing, or erroneous returns depending on the sensor technology and operating conditions.

Before field deployment, validate the integration with recorded ROS 2 bags. Check timestamp consistency, point-cloud density, transform availability, CPU load, dropped packets, and map alignment during turns. A cloud that appears correct in RViz can still be unsuitable for SLAM if its timestamps or extrinsic calibration are incorrect.