SW-5466: Support Velodyne and other point types in ouster-ros driver

[Samahu]

Related Issues & PRs

• resolves Change the format into velodyne format #15
• resolves Parameter for Controlling PCL PointType #29
• resolves Add low data rate point type #210
• related [ROS2] configurable pointcloud type #97
• related ROS ouster Point struct meaning, and Autoware implmentation for enhancing data field of Point  #217
• related Ability to add other channels (RGB etc.) when generating the PointCloud2 msgs #223

Summary of Changes

• added the ability to customize the published point clouds(s) to velodyne point cloud format and
  other common pcl point types.
• made ouster_image_component operate separately from ouster_cloud_component

Validation

• Run the driver with default parameters and verify no observable behavioral changes.
• Change point_type parameter to native and verify that it reflects the same point cloud format that we get from the sensor.
• Change point_type parameter to xyz and verify that the published point cloud format only has xyz fields, regardless of the underlying sensor format.
• Change point_type parameter to xyzi and verify that the published point cloud format only has xyz fields plus intensity, regardless of the underlying sensor format (you should get a warning when the low data mode is selected for this mode).
• Change point_type parameter to xyzir and verify that the published point cloud format only has xyz fields plus intensity plus ring, regardless of the underlying sensor format (you should get a warning when the low data mode is selected for this mode).

[mtswisher]

Just made some typo changes :) How do you decide whether to designate a function as inline? I haven't seen the factory pattern in quite awhile so it was cool to see that solve this problem. Will probably need to dig into some more to really understand what is going on but LGTM :)

[Samahu]

Just made some typo changes :)

Addressed!

How do you decide whether to designate a function as inline?

Typically for short one liner methods this could minimally increase the code size but avoid having to invoke the method which is always faster .. With modern compilers the inline keyword only serves as a suggestion, compilers could inline methods automatically .. and could also ignore the suggestion if the method body is too long (in this case one needs to use __forceinline).

I haven't seen the factory pattern in quite awhile so it was cool to see that solve this problem. Will probably need to dig into some more to really understand what is going on but LGTM :)

Yeah, the factory pattern is definitely needed here. I will add more comments to the PR to explain what's going on and how could developers use existing code to implement other point types that are not included in this PR.