Use compatible structs for velodyne_pointcloud::PointXYZ* and autoware_point_types::PointXYZ* types

[VRichardJP]

velodyne_pointcloud and autoware_point_types don't define the same point types:

awf_velodyne/awf_velodyne_pointcloud/include/velodyne_pointcloud/point_types.h

Lines 24 to 42 in 4a20d06

	struct PointXYZIR
	{
	PCL_ADD_POINT4D;
	float intensity;
	uint16_t ring;
	EIGEN_MAKE_ALIGNED_OPERATOR_NEW
	} EIGEN_ALIGN16;
	struct PointXYZIRADT
	{
	PCL_ADD_POINT4D;
	float intensity;
	uint16_t ring;
	float azimuth;
	float distance;
	uint8_t return_type;
	double time_stamp;
	EIGEN_MAKE_ALIGNED_OPERATOR_NEW
	} EIGEN_ALIGN16;

https://github.com/autowarefoundation/autoware.universe/blob/main/common/autoware_point_types/include/autoware_point_types/types.hpp

This has caused some issues in the past, but also it makes reading/writing PointCloud2 message data painful and slow.

I don't think there is any advantage to keep incompatible types. It would be better if velodyne_pointcloud was using the types defined by autoware_point_types.

If we are not willing to have velodyne_pointcloud depending on autoware_point_types package, at least the velodyne_pointcloud::PointXYZIR and velodyne_pointcloud::PointXYZIRADT types could be re-written to have "compatible layouts". For example:

struct PointXYZIR
{
  float x;
  float y;
  float z;
  float intensity;
  uint16_t ring;
  EIGEN_MAKE_ALIGNED_OPERATOR_NEW
} EIGEN_ALIGN16;

struct PointXYZIRADT
{
  float x;
  float y;
  float z;
  float intensity;
  uint16_t ring;
  float azimuth;
  float distance;
  uint8_t return_type;
  double time_stamp;
  EIGEN_MAKE_ALIGNED_OPERATOR_NEW
} EIGEN_ALIGN16;

Or the other way around: to have autoware_point_types types modified so that they would have the same layout than velodyne_pointcloud. Actually, it makes maybe more sense that way, because PCL operations rely a lot on the padding after xyz fields.