NEW KEY FEATURE: Point Cloud Customization

[Samahu]

Starting with v0.11.2 for ROS2 and v0.11.0 for ROS1 we have implemented a new feature that let's ouster-ros users customize the PointCloud generated by the driver. This comes at a very little to no overhead on the driver operation. Here are some keys aspects to utilizing this feature:

• ouster-ros driver users will now see a significant drop of the bandwidth (about 33%) when enabling the low data mode (RNG15_RFL8_NIR8) from the sensor and utilizing the native format -described below - instead of the previous implementation where the required bandwidth in the ROS driver will stay the same even if the sensor lidar udp profile has changed.
• Also, we are providing the users with the ability to work with the Velodyne format using Ouster sensors, or even use the bare minimum xyz fields.
• The feature will also work seamlessly for the DUAL mode which results in two point clouds produced. However, currently users can only apply the same PointCloud format to both point clouds (you can not choose one type for the first point cloud and a different one for the other topic).

User can start using this feature through the new launch file parameter point_type which is described below:

point_type: This parameter allows to customize the point cloud that the driver produces through its /ouster/points and /ouster/points topics. Choose one of the following values:

• original: This uses the original point representation ouster_ros::Point of the ouster-ros driver.
• native: directly maps all fields as published by the sensor to an equivalent point cloud representation with the additon of ring and timestamp fields.
• xyz: the simplest point type, only has {x, y, z}
• xyzi: same as xyz point type but adds intensity (signal) field.
• xyzir: same as xyzi type but adds ring (channel) field. This type is same as Velodyne point cloud type.

Note: Not that the PointCloud types that require the intensity field such as xyzi or xyzir are not compatible with Ouster's low data mode since it lacks signal (intensity) from its representation. If the user choose these point type along with the low data mode the driver will still operate but the intensity field will always bet set to zero.

Note: starting with v0.11.0 for ROS1 the driver requires C++17 to compile.

All related issues and PRs:

• ROS2 SW-5466: Support Velodyne and other point types in ouster-ros driver #216, SW-5466: Support Velodyne point type in the ROS driver amendments #254, SW-5466: Support velodyne point type in the ros driver (foxy) #255
• ROS1 SW-5657: Back port SW-5466 to ROS-1 #253
• resolves Change the format into velodyne format #15
• resolves Parameter for Controlling PCL PointType #29
• resolves Add low data rate point type #210
• resolves [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
• related Ouster support for Apollo? #287

[James-R-Han]

Hi @Samahu!

Thanks for this great PR! One question I had was about the 't' (time) field of non-original type points. Is it possible to get something like txyz or txyzi? The time field is useful for point clouds to undistort them when the sensor is in motion, but I'd still like to get some bandwidth reduction.

Thank you in advance!

[Samahu]

I prototyped something similar to what you are asking for but I haven't merged it. You can check it out here: https://github.com/ouster-lidar/ouster-ros/pull/290/files. I would like to merge the PR at some point but in case you wanted to pick and choose which fields to include or exclude or add a derivative custom fields, then this PR shows you how to do that.

[GreatAlexander]

Hi @Samahu , thanks for all your great work on this repo. We are users of this Ouster driver and we are interested in the xyzit format as well (Not interested in Apollo/CyberRT support).
Are you aiming to merge that PR anytime soon, or should we just go ahead and create a fork with these changes?

[Samahu]

The issue is I wasn't sure how much widely this format is in use (I don't have a lot of users asking for it and at same time we have plenty of requests) .. I can try to merge it after I am doing with #363. I don't see a harm in doing so.