LiDAR

LiDAR – definition

LiDAR stands for Light Detection and Ranging. It is an active ranging sensor that estimates distance by emitting light, usually near-infrared laser pulses, and measuring the return time or phase shift of reflected energy. In mobile robotics, LiDAR is used to build geometric representations of the environment, detect obstacles, support localization, and provide input for mapping and navigation pipelines.

In the context of unmanned ground vehicles (UGV), LiDAR is valued because it measures structure directly and does not depend on ambient illumination in the same way as RGB cameras. A 2D LiDAR typically scans a plane and publishes range samples over angle. A 3D LiDAR produces a point cloud with x, y, z coordinates and often intensity. On ROS and ROS 2 systems, these outputs are commonly represented as sensor_msgs/LaserScan for planar scanners and sensor_msgs/PointCloud2 for 3D devices.

For platforms such as Leo Rover and Raph Rover, LiDAR is not a complete autonomy solution by itself. It is one sensor within a larger stack that usually includes odometry, TF transforms, robot description, and a navigation framework such as Nav2 on ROS 2. In practice, LiDAR is often the primary exteroceptive sensor for indoor SLAM, obstacle avoidance, local costmaps, and terrain-aware perception when fused with IMU, wheel odometry, depth cameras, or GNSS/RTK.

How LiDAR works in mobile robotics

The physical principle is simple. The sensor emits light and measures the return from surfaces in the scene. The estimated distance depends on the measurement method and the speed of light. For a time-of-flight device, range is approximated by the standard relation below.

distance = (c * Δt) / 2

Here, c is the speed of light and Δt is the round-trip travel time. The division by two accounts for the outbound and return path. Some LiDARs use direct time-of-flight, while others use phase-based methods or FMCW variants. For UGV integration, the important engineering result is not only raw range accuracy, but also update rate, field of view, minimum range, reflectivity sensitivity, and behavior under dust, rain, glass, and strong sunlight.

A 2D rotating scanner is common on compact robots. It samples a horizontal slice of the environment and is efficient for wall detection, corridor navigation, and occupancy grid mapping. A 3D LiDAR is more suitable when the robot must perceive ramps, vegetation, construction elements, or uneven outdoor terrain. On a differential-drive platform, sensor height and mounting angle matter. A low-mounted scanner can miss higher obstacles. A high-mounted scanner can miss curbs and low objects close to the bumper.

LiDAR in ROS 2

ROS 2 provides standard message types and transform conventions for LiDAR integration. The sensor driver usually publishes a scan or point cloud topic, and the system uses TF2 to express the sensor pose relative to base_link. This is required by SLAM, Nav2 costmaps, and point cloud processing nodes. REP 103 defines standard units and coordinate conventions in ROS. REP 105 defines the relationship between coordinate frames such as map, odom, and base_link.

For a planar scanner on ROS 2 Humble, a typical topic layout looks like this:

/scan – sensor_msgs/msg/LaserScan
/tf and /tf_static – frame transforms
/odom – wheel or fused odometry
/map – occupancy grid from a SLAM node or map server

The most common fields in LaserScan are operationally important for debugging and configuration:

angle_min, angle_max, angle_increment – angular coverage and resolution
range_min, range_max – valid measurement interval
scan_time, time_increment – temporal properties of one scan
ranges[] and intensities[] – measurement arrays

A minimal ROS 2 example for inspecting a LiDAR topic is shown below.

ros2 topic list
ros2 topic info /scan
ros2 topic echo /scan --once
ros2 run tf2_ros tf2_echo base_link laser

Key parameters and metrics

When selecting or integrating a LiDAR for a UGV, the published range figure alone is insufficient. The useful performance envelope is defined by several coupled parameters.

Parameter	Why it matters on a UGV	Typical ROS impact
Range	Limits early obstacle detection and map extent	Costmap obstacle layer horizon
Angular resolution	Determines ability to resolve narrow objects	Map quality and scan matching stability
Scan rate	Affects responsiveness during motion	Topic frequency, CPU load, Nav2 update behavior
Field of view	Defines coverage around the robot	Blind spots and local planner robustness
Minimum range	Important for near-field safety and bumper region sensing	Obstacle detection close to chassis
Ingress protection	Outdoor use requires resistance to dust and moisture	Reliability in field deployments

For ROS 2 navigation, practical integration questions include whether the scan is stable at 5-15 Hz or higher, whether timestamps are accurate enough for motion compensation, and whether the transform tree is valid at all times. Even a good sensor will perform poorly if laser -> base_link is mis-specified by a few centimeters or if scan timestamps drift under CPU load.

Supported hardware and integration on Leo Rover and Raph Rover

Leo Rover can use compact 2D LiDAR units connected over USB or UART and processed on its built-in Raspberry Pi-based compute unit. This is sufficient for indoor mapping, obstacle detection, and education-focused SLAM experiments on ROS 2 Humble or newer. However, compute headroom is limited compared with larger edge computers, so algorithm choice matters. Lightweight 2D SLAM and local navigation pipelines are usually a better fit than dense 3D perception.

Raph Rover can carry larger sensors and more compute. That makes it more suitable for multi-sensor setups with 3D LiDAR, IMU, GNSS/RTK, and additional perception nodes. The platform is better aligned with outdoor inspection, agricultural prototyping, and heavier payload integration. The trade-off is system complexity, power budget, and calibration effort.

In both cases, correct URDF and TF setup is mandatory. A static transform for the LiDAR frame is commonly used if the sensor is rigidly mounted.

ros2 run tf2_ros static_transform_publisher \
0.12 0.0 0.18 0 0 0 base_link laser

LiDAR for SLAM and navigation

LiDAR is one of the most common primary sensors for 2D SLAM on UGV platforms. On ROS 2, packages such as slam_toolbox are widely used for online and offline mapping with planar scans. Nav2 then consumes localization and live scan data for obstacle avoidance and path execution. In these pipelines, LiDAR contributes to both mapping and the local costmap.

For outdoor or unstructured scenes, LiDAR-only navigation has limits. Sparse vertical structure, vegetation motion, dust, and repetitive geometry can degrade scan matching. Fusion with IMU and wheel odometry improves short-term motion estimation. If global consistency is required over large areas, GNSS or RTK can be added. For rough terrain, 3D LiDAR or depth sensing is often needed because a single horizontal scan does not capture traversability well.

Limitations and trade-offs

LiDAR is precise, but not universal. Reflective, transparent, absorptive, or very dark surfaces can reduce measurement quality. Weather and airborne particles can generate noise or false returns. Mechanical spinning sensors may have wear and vibration sensitivity, while solid-state devices often trade field of view for robustness.

On small UGVs, another trade-off is compute and power. Higher scan density and 3D point clouds increase CPU, memory, storage, and bandwidth requirements. This is relevant on Leo Rover, where a Raspberry Pi-class computer can run ROS 2 navigation, but heavy perception stacks may require optimization, offloading, or a different compute architecture. Raph Rover offers more flexibility for such payloads, but the integration burden also increases.

Normative references and standards

The ROS-specific interpretation of LiDAR data should follow official message and frame conventions. The most relevant references are:

ROS REP 103 – Standard Units of Measure and Coordinate Conventions
ROS REP 105 – Coordinate Frames for Mobile Platforms
ROS 2 message definitions for sensor_msgs/msg/LaserScan and sensor_msgs/msg/PointCloud2
Vendor specifications for range, scan frequency, accuracy, wavelength, and environmental limits

In technical documentation, numerical claims such as maximum range, scan rate, angular resolution, IP rating, or interface type should always be verified against the manufacturer datasheet. For system behavior on Leo Rover or Raph Rover, the relevant source is the platform documentation at docs.leorover.tech.