Failed to find match for field 'intensity' with Ouster LIDAR

edit

Hi, I tried to convert Ouster lidar packets to pcl::PointCloud<pcl::PointXYZI> using the standard pcl::fromROSMsg. I have the error complaining about the conversion can't find the field intensity. However, carefully inspect the sensor_msgs::PointCloud2 message, I see that it has the intensity field

rostopic echo /os1_node/points 
  header: 
  seq: 2
  stamp: 
    secs: 1528426469
    nsecs: 194866238
  frame_id: "os1"
height: 1
width: 65536
fields: 
  - 
    name: "x"
    offset: 0
    datatype: 7
    count: 1
  - 
    name: "y"
    offset: 4
    datatype: 7
    count: 1
  - 
    name: "z"
    offset: 8
    datatype: 7
    count: 1
  - 
    name: "t"
    offset: 16
    datatype: 7
    count: 1
  - 
    name: "reflectivity"
    offset: 20
    datatype: 4
    count: 1
  - 
    name: "intensity"
    offset: 22
    datatype: 4
    count: 1
  - 
    name: "ring"
    offset: 24
    datatype: 2
    count: 1
is_bigendian: False
point_step: 32
row_step: 2097152

And I can print the intensity value of a point

pcl::fromROSMsg(*laserCloudMsg, *laserCloudIn);
 ROS_INFO("Point intensity %f ",laserCloudIn->points[3].intensity);
Failed to find match for field 'intensity'.
[ INFO] [1541667829.480241159, 1528426469.011953052]: Point intensity 0.994560 
Failed to find match for field 'intensity'.
[ INFO] [1541667838.574432769, 1528426469.102849368]: Point intensity 0.025828

Here I do not understand why I still get the error Failed to find match for field intensity.

I greatly appreciate your help!

EDIT1: @PeteBlackerThe3rd, thank for your help. According to the User manual,

Lidar data packets consist of 16 azimuth blocks and are always 12608 Bytes in length. The packet rate is dependent on the output mode. ​Words are 32 bits in length.

Each azimuth block contains:

● Timestamp ​[64 bits] - Unique time in nanoseconds.

● Measurement ID ​ [32 bits] - a sequentially incrementing azimuth measurement counting up from 0 to 511, or 0 to 1023, or 0 to 2047 depending on lidar_mode.

● Encoder Count ​ [32 bits] - an azimuth angle as a raw encoder count, starting from 0 with a max value of 90111 - incrementing 44 ticks every azimuth angle in x2048 mode, 88 ticks in x1024 mode, and 176 ticks in x512 mode.

● Data Block ​ [96 bits] - 3 data words for each of the 16 or 64 pixels. See ​Table below for full definition. ○ Range ​[20 bits] - Range in millimeters, discretized to the nearest 12 millimeters. ○ Reflectivity ​[16 bits] - Sensor signal_photon 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 future a future firmware release. ○ Signal Photons ​[16 bits] - Signal photons in the signal return measurement are reported ○ Noise Photons ​[16 bits] - Noise photons in the noise return measurement are reported.

● Packet Status ​ - indicates whether the azimuth block is good or bad. Good = 0xFFFFFFFF, Bad = 0x0. If a packet is bad ​Measurement ID ​, ​Encoder Count ​, and ​Data Bock:Range ​ and ​Data Block:Reflectivity ​ will also be set to 0x0.

The driver indeed does provide pointcloud messages directly. The conversion is for my segmentation algorithm. I can't understand why pcl::fromROSMsg complains that there is no intensity field to match while I can ... (more)