Point cloud pre-processing design#
Point cloud pre-processing is a collection of modules that apply some primitive pre-processing to the raw sensor data.
This pipeline covers the flow of data from drivers to the perception stack.
Recommended processing pipeline#
graph TD Driver["Lidar Driver"] -->|"Cloud XYZIRCADT"| FilterPR["Polygon Remover Filter / CropBox Filter"] subgraph "sensing" FilterPR -->|"Cloud XYZIRCADT"| FilterDC["Motion Distortion Corrector Filter"] FilterDC -->|"Cloud XYZIRCAD"| FilterOF["Outlier Remover Filter"] FilterOF -->|"Cloud XYZIRC"| FilterDS["Downsampler Filter"] FilterDS -->|"Cloud XYZIRC"| FilterTrans["Cloud Transformer"] FilterTrans -->|"Cloud XYZIRC"| FilterC FilterX["..."] -->|"Cloud XYZIRC (i)"| FilterC["Cloud Concatenator"] end FilterC -->|"Cloud XYZIRC"| SegGr["Ground Segmentation"]
List of modules#
The modules used here are from pointcloud_preprocessor package.
For details about the modules, see the following table.
It is recommended that these modules are used in a single container as components. For details see ROS 2 Composition
Point cloud fields#
In the ideal case, the driver is expected to output a point cloud with the
PointXYZIRCADT point type.
||Measured reflectivity, intensity of the point|
||Laser return type for dual return lidars|
||Vertical channel id of the laser that measured the point|
||Nanoseconds passed since the time of the header when this point was measured|
A (azimuth) and
D (distance) fields are derived fields.
They are provided by the driver to reduce the computational load on some parts of the perception stack.
Motion Distortion Corrector Filter won't be used, the
T (time) field can be omitted,
PointXYZIRCAD point type can be used.
Autoware will support conversion from
PointXYZIRCAD (with channel and return is set to 0) for prototyping purposes.
However, this conversion is not recommended for production use since it's not efficient.
We will use following ranges for intensity, compatible with the VLP16 User Manual:
Quoting from the VLP-16 User Manual:
For each laser measurement, a reflectivity byte is returned in addition to distance. Reflectivity byte values are segmented into two ranges, allowing software to distinguish diffuse reflectors (e.g. tree trunks, clothing) in the low range from retroreflectors (e.g. road signs, license plates) in the high range. A retroreflector reflects light back to its source with a minimum of scattering. The VLP-16 provides its own light, with negligible separation between transmitting laser and receiving detector, so retroreflecting surfaces pop with reflected IR light compared to diffuse reflectors that tend to scatter reflected energy.
- Diffuse reflectors report values from 0 to 100 for reflectivities from 0% to 100%.
- Retroreflectors report values from 101 to 255, where 255 represents an ideal reflection.
In a typical point cloud without retroreflectors, all intensity points will be between 0 and 100.
Retroreflective Gradient road sign, Image Source
But in a point cloud with retroreflectors, the intensity points will be between 0 and 255.
Intensity mapping for other lidar brands#
This lidar has 2 modes for reporting reflectivity:
- Linear mapping
- Non-linear mapping
If you are using linear mapping mode, you should map from [0, 255] to [0, 100] when constructing the point cloud.
If you are using non-linear mapping mode, you should map (hesai to autoware)
- [0, 251] to [0, 100] and
- [252, 254] to [101, 255]
when constructing the point cloud.
This lidar has 2 modes for reporting reflectivity similar to Velodyne VLP-16, only the ranges are slightly different.
You should map (livox to autoware)
- [0, 150] to [0, 100] and
- [151, 255] to [101, 255]
when constructing the point cloud.
RoboSense RS-LiDAR-16 User Manual
No mapping required, same as Velodyne VLP-16.
Software User Manual v2.0.0 for all Ouster sensors
In the manual it is stated:
Reflectivity [16 bit unsigned int] - sensor Signal Photons measurements are scaled based on measured range and sensor sensitivity at that range, providing an indication of target reflectivity. Calibration of this measurement has not currently been rigorously implemented, but this will be updated in a future firmware release.
So it is advised to map the 16 bit reflectivity to [0, 100] range.
I couldn't get the english user manual, link of website
In a user manual I was able to find it says:
Byte 7 represents echo strength, and the value range is 0-255. (Echo strength can reflect the energy reflection characteristics of the measured object in the actual measurement environment. Therefore, the echo strength can be used to distinguish objects with different reflection characteristics.)
So it is advised to map the [0, 255] to [0, 100] range.
Various lidars support multiple return modes. Velodyne lidars support Strongest and Last return modes.
R field represents return mode with an
|R (return type)||Description|
||Unknown / Not Marked|
The channel field is used to identify the vertical channel of the laser that measured the point. In various lidar manuals or literature, it can also be called laser id, ring, laser line.
For Velodyne VLP-16, there are 16 channels. Default order of channels in drivers are generally in firing order.
C field represents the vertical channel id with an
Solid state and petal pattern lidars#
This section is subject to change. Following are suggestions and open for discussion.
For solid state lidars that have lines, assign row number as the channel id.
For petal pattern lidars, you can keep channel 0.
In lidar point clouds, each point measurement can have its individual time stamp. This information can be used to eliminate the motion blur that is caused by the movement of the lidar during the scan.
Point cloud header time#
The header contains a Time field. The time field has 2 components:
||Unix time (seconds elapsed since January 1, 1970)|
||Nanoseconds elapsed since the
The header of the point cloud message is expected to have the time of the earliest point it has.
sec field is
int32 in ROS 2 humble. The largest value it can represent is 2^31 seconds, it is subject to
year 2038 problems. We will wait for actions on ROS 2 community side.
More info at: https://github.com/ros2/rcl_interfaces/issues/85
Individual point time#
PointXYZIRCT point type has the
T field for representing the nanoseconds passed since the first-shot point of the point cloud.
To calculate exact time each point was shot, the
T nanoseconds are added to the header time.
T field is
uint32 type. The largest value it can represent is 2^32 nanoseconds, which equates to roughly
4.29 seconds. Usual point clouds don't last more than 100ms for full cycle. So this field should be enough.