cartographer_assets_writer and rosbag_validate: Failed to find match for field 'intensity'.

[kajep09]

I have a problem with the assets_writer and rosbag_validate reporting the warning Failed to find match for field 'intensity'. while running it with my bagged data. I don't have the possibility to upload the bagfiles at the moment, but I have included the output of the header of my PointCloud2 topic and for comparison also included one from one of the official 3d_backpack rosbags (b3-2016-04-05-15-51-36.bag)

As you can see there is indeed an intensity field in the fields part of the message and I can visualize the pointcloud with intensity colouring in rviz.

However, in the b3-2016-04-05-15-51-36.bag I can see that the intensity has datatype: 7 (uint8 FLOAT32 = 7) and my intensity data has datatype: 4 (uint8 UINT16 = 4). See http://docs.ros.org/kinetic/api/sensor_msgs/html/msg/PointField.html

Do you know if the data type of the intensity data has anything to do with the assets_writer and rosbag_validate complaining?

Link is a gist of running rosbag_validate (excluding thousands of lines of the warning): rosrun cartographer_ros cartographer_rosbag_validate -bag_filename=ouster_ros.bag https://gist.github.com/kajep09/91869019925676b69e4ea5e6025277b1

header: 
  seq: 1269
  stamp: 
    secs: 1536832001
    nsecs: 178107976
  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

header: 
  seq: 0
  stamp: 
    secs: 1459871511
    nsecs: 702640300
  frame_id: "horizontal_vlp16_link"
height: 1
width: 384
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: "intensity"
    offset: 12
    datatype: 7
    count: 1
is_bigendian: False
point_step: 16
row_step: 6144

[gaschler]

cartographer_ros has only one code location where PointCloud2 messages are decoded, see msg_conversion.h ToPointCloudWithIntensities. So yes, if rosbag_validate complaints, the main algorithm won't work either in this case. You could of course work around by writing a conversion node/tool that converts the intensities. Or just drop them, because the current algorithm does not use intensity values.

[kajep09]

Thank you for the quick response. By dropping the intensity values you mean rerecording / manipulating my bagged data to not have the intensity field? I guess there is no option to ask rosbag_validate / asset writer to not even check for intensity values if they are not used in the first place?

[gaschler]

manipulating my bagged data to not have the intensity field?

That or patching msg_conversion.cc in your local workspace.

I guess there is no option to ask rosbag_validate / asset writer to not even check for intensity values if they are not used in the first place?

There is no such option. I won't drop reading the values for PointCloud2 messages where it works. A nice patch would be to log an error if the intensity field has an unsupported format (your case) and only then skip that field.

[kajep09]

Thank you for the answers, closing this issue now. P.S. In case anyone gets the same idea as me and wants to try cartographer on the publicly available datasets from Ouster lidar (https://github.com/ouster-lidar/ouster_example) you will likely have the same problem with the intensity data.

[gaschler]

@kajep09 In case you have the time to provide a patch, I'd be glad to review. I wasn't aware that this bug applies to a collection of public data.

[kajep09]

Thank you for the offer, but I don't think I will have the time in the near future. Besides, there are more issues I've run into with the Ouster lidar data that I am trying to fix (non sequential data in timestamps etc.). The Ouster lidar data is uploaded as raw imu / lidar packets and they provide a ROS node to translate into sensor_msgs/Imu and PointCloud2 - I simply modified this node to translate the intensities to floats instead of uint16.

[dsb6063]

Have you made any progress on with the Ouster sensor? I have applied the intensity correction you suggested. That allowed the bag to pass validation. However, cartographer seems to write the pbstream file with no trajectory info. No errors ,but the file size is 428 bytes.