However, the point_step of velodyne on ROS2 has been changed to 18. rqt_bag shows that it consists of x, y, z, intensity, and ring fields with no padding. This is causing trouble with the PCL function. Specifically, the function getVector4fMap() is used everywhere in PCL, but this function cannot be called in the velodyne point cloud definition in ROS2.
To Reproduce
I attached the rqt_bag display for ROS1(melodic) and ROS2(foxy).
Melodic
ROS2
Expected behavior
I would expect to go back to the ROS1 point cloud type. If that is not possible, I would appreciate any solution you can provide.
Please complete the following information:
Describe the bug This issue is a specification of velodyne in ROS2 and may not be a bug.
In ROS1, point_step is equal to 32 and is compatible with point cloud types such as [this](https://github.com/ros-drivers/velodyne/blob/master/velodyne_pcl/include/velodyne_pcl/point_types.h The custom PointT type document](https://pointclouds.org/documentation/tutorials/adding_custom_ptype.html). As stated in [The custom PointT type document](), it is recommended to use PCL_ADD_POINT4D MACRO with an additional padding field to define custom point types, and many PCL functions seem to support this kind of types.
However, the point_step of velodyne on ROS2 has been changed to 18. rqt_bag shows that it consists of x, y, z, intensity, and ring fields with no padding. This is causing trouble with the PCL function. Specifically, the function getVector4fMap() is used everywhere in PCL, but this function cannot be called in the velodyne point cloud definition in ROS2.
To Reproduce I attached the rqt_bag display for ROS1(melodic) and ROS2(foxy).
Melodic
ROS2
Expected behavior I would expect to go back to the ROS1 point cloud type. If that is not possible, I would appreciate any solution you can provide.