Solid-state LiDAR

Solid-state LiDAR – definition

Solid-state LiDAR is a light detection and ranging sensor that measures distance using emitted laser light and does not use a continuously rotating mechanical assembly to scan its field of view. In mobile robotics, it provides range measurements or three-dimensional point clouds for obstacle detection, mapping, localization, terrain analysis, and autonomous navigation.

The term is not fully uniform across manufacturers. It commonly includes flash LiDAR, MEMS-scanned LiDAR, and optical phased array (OPA) LiDAR. A MEMS LiDAR may contain a moving micro-mirror, but it has no macroscopic rotating head. FMCW is a ranging method that can be used with different beam-steering or scanning architectures; it is not, by itself, a solid-state scanning method. Engineers should therefore verify the scanning method, field of view, output format, range, update rate, and environmental rating rather than relying on the label alone.

On an unmanned ground vehicle (UGV), a solid-state LiDAR is normally installed with a fixed sensor pose. This can reduce cable twisting, mechanical wear, and enclosure complexity compared with a rotating multi-beam LiDAR. It does not make a Leo Rover or Raph Rover autonomous by itself. A complete autonomous system still requires calibrated transforms, odometry, a navigation stack, safety logic, and validation in the intended environment.

Measurement principles and sensor variants

Most solid-state LiDARs estimate range from the propagation of light. A pulsed time-of-flight sensor measures the delay between emission and return. The simplified distance equation is:

d = c × Δt / 2

In this equation, d is distance, c is the speed of light, and Δt is the measured round-trip time. FMCW LiDAR instead estimates range from the frequency difference between transmitted and received chirps. Depending on implementation, FMCW sensing can also estimate radial velocity from Doppler shift.

The following architectures and measurement methods are relevant when selecting a sensor for a UGV payload.

Architecture or method	Scanning method	Typical ROS output	Integration implication
Flash LiDAR	Illuminates an area at once	`sensor_msgs/msg/PointCloud2`	Dense depth frame, often limited field of view or range
MEMS LiDAR	Micro-mirror steers the beam	`PointCloud2` or `LaserScan`	Point density can vary across the scan pattern
OPA LiDAR	Electronic beam steering	Vendor-specific points or point cloud	Requires verification of field of view and angular sampling
FMCW LiDAR	Scanning depends on the optical architecture	Point cloud, sometimes velocity fields	Driver support, scanning behavior, and message mapping vary by vendor

Published values such as range, angular resolution, frame rate, wavelength, and ingress protection are model-specific. They must be taken from the selected manufacturer datasheet, because no single range or update-rate value defines solid-state LiDAR.

Solid-state LiDAR data in ROS 2

In ROS 2, a three-dimensional LiDAR driver commonly publishes sensor_msgs/msg/PointCloud2. The message stores a binary array of points with declared fields such as x, y, z, intensity, ring, or timestamp fields. The exact fields are driver-dependent. The official ROS 2 interface definition specifies the layout through fields, point_step, row_step, and endianness metadata.

A planar representation may be published as sensor_msgs/msg/LaserScan. This message represents ranges sampled at a constant angular increment, so it is not a lossless representation of a non-uniform 3D scan. Conversion to LaserScan can be useful for 2D costmaps, but it discards vertical geometry and should be configured with explicit height filtering.

ros2 topic list | grep -E 'points|scan'
ros2 topic echo /lidar/points --once
ros2 run tf2_ros tf2_echo base_link lidar_link

Coordinate conventions should follow ROS REP 103. Mobile robot body frames use x forward, y left, and z up. Frame relationships should follow REP 105, where base_link is rigidly attached to the robot body, odom provides locally continuous odometry, and map represents the global mapping frame. The LiDAR pose is normally published as a static transform from base_link to lidar_link.

pointcloud_to_laserscan:
  ros__parameters:
    target_frame: base_link
    min_height: 0.10
    max_height: 0.80
    range_min: 0.20
    range_max: 20.0
    use_inf: true

The values above are integration examples, not universal sensor limits. They must be changed to match the LiDAR specification, mounting height, robot geometry, and operational safety envelope.

Key parameters for UGV integration

Selection should be based on measurable parameters and on the required perception task. A LiDAR that performs well for indoor corridor mapping may be unsuitable for vegetation, reflective construction materials, rain, dust, or direct sunlight.

Field of view: Horizontal and vertical coverage determine whether the sensor can observe wheel-level obstacles, overhangs, and side hazards.
Point rate and scan pattern: These affect obstacle sampling at the robot’s maximum operating speed.
Minimum range: This determines whether near-field obstacles and the UGV body can be measured or must be masked.
Range accuracy and precision: These affect localization, map consistency, and obstacle inflation margins.
Timestamp behavior: Hardware timestamps and clock synchronization reduce motion distortion during driving.
Optical performance: Reflectivity, incidence angle, ambient light, rain, fog, and dust can change return quality.

Use on Leo Rover and Raph Rover

Leo Rover is a four-wheel differential-drive platform with an integrated Raspberry Pi compute unit and ROS 2 software support. Supported ROS 2 distributions depend on the installed system image and software version. A solid-state LiDAR can be integrated as an external sensor payload, provided that power consumption, interface bandwidth, mounting rigidity, and the ROS 2 driver are verified. For computationally demanding point-cloud filtering, visual-LiDAR fusion, or 3D SLAM, an additional onboard computer may be required.

For Leo Rover, a fixed forward-facing LiDAR can support local obstacle perception and mapping experiments. A 3D sensor mounted above the chassis reduces occlusion from the body but raises the effect of vibration and changes the sensor-to-ground geometry. Because Leo Rover has differential drive, wheel odometry and IMU data can be fused with LiDAR odometry using ROS 2 estimation tools before data is supplied to Nav2 or a SLAM system.

Raph Rover may be more suitable when a larger payload, more extensive sensor suite, or protected external compute enclosure is required. This does not eliminate the need for extrinsic calibration. The transform between LiDAR, IMU, GNSS antenna, and base_link must remain mechanically stable after installation.

Limitations and validation

Solid-state LiDAR does not guarantee uniform angular sampling, long range, or reliable operation in every outdoor condition. Point clouds can contain invalid returns, multipath artifacts, low-intensity surfaces, or gaps caused by glass, water, black materials, and adverse weather. Navigation costmaps should therefore combine LiDAR observations with robot footprint configuration, conservative inflation, timeout handling, and tested stopping behavior.

Before field deployment, record ROS 2 bags, inspect point timestamps and frame IDs, validate static transforms, and compare measured distances against known targets. Test the full pipeline while the UGV moves, because a static bench test does not reveal motion-induced distortion or synchronization errors.

Normative references and technical sources

The ROS interfaces and frame conventions used for LiDAR integration are defined by official ROS documentation and ROS Enhancement Proposals. Hardware values must be verified against the datasheet for the exact sensor model and firmware version.