PointCloud2 fields not always sorted by offset

[cosama]

Some ROS sensor_msgs/PointCloud2 messages created with the functions defined in plc_conversion.h will not have the fields attribute sorted by offset. I don't think that is a documented requirement, so the messages are fine and readable with most tools. However, most of the time the fields are sorted in that way and it looks like some tools do assume that the field is sorted that way (for example eric-wieser/ros_numpy#40). I believe in general would be good practice to always make sure that the fields in point cloud messages are sorted in such a way, even though it is not specified.

The issue linked above has an example of a message that is not sorted. It was created with pcl::toROSMsg() from a pcl::PointXYZINormal type point cloud object. The curvature and intensity fields are both populated as used here. The fields look like this:

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: 32
datatype: 7
count: 1, name: "normal_x"
offset: 16
datatype: 7
count: 1, name: "normal_y"
offset: 20
datatype: 7
count: 1, name: "normal_z"
offset: 24
datatype: 7
count: 1, name: "curvature"
offset: 36
datatype: 7
count: 1

[SteveMacenski]

That makes sense - happy to review a PR

[cosama]

@SteveMacenski Thanks for the feedback.

I will see if I have the time to dig into this a bit more. I looked over the code quickly yesterday and I wasn't entirely sure what was going on.

[mvieth]

For your information: this also came up in PCL itself a few months ago: PointCloudLibrary/pcl#5598 (comment)
It was fixed by reordering the point type registration macros: PointCloudLibrary/pcl#5604 (the fix will be included in the next PCL release).
However, it could still make sense to also sort the fields in perception_pcl, for example like this: https://github.com/PointCloudLibrary/pcl/blob/0d123a41deb8721db1e5195ca92c6065754b83f2/io/src/pcd_io.cpp#L946