Use smaller integral types for low-data rate profile

[Aposhian]

Is your feature request related to a problem? Please describe.
The low data rate profile (RNG15_RFL8_NIR8) is attractive because it uses less bandwidth. The new support for this profile is promising, but it doesn't take advantage of it as much as it could. So the current implementation doesn't go far enough to save bandwidth on the actual ROS messages.

ouster-ros/ouster-ros/include/ouster_ros/sensor_point_types.h

Lines 324 to 334 in 726b0d5

	// Default=RNG15_RFL8_NIR8 aka LOW_DATA profile
	POINT_CLOUD_REGISTER_POINT_STRUCT(ouster_ros::Point_RNG15_RFL8_NIR8,
	(float, x, x)
	(float, y, y)
	(float, z, z)
	(std::uint32_t, t, t)
	(std::uint16_t, ring, ring)
	(std::uint32_t, range, range)
	(std::uint16_t, reflectivity, reflectivity)
	(std::uint16_t, near_ir, near_ir)
	)

The current implementation uses a uint32_t for range, a uint16_t for reflectivity, and a uint16_t for NIR. However, it should be possible to use a uint16_t for range, a uint8_t for reflectivity, and a uint8_t for NIR. This would take the minimum required bytes for the point type from 26 bytes to 22 bytes.

Describe the solution you'd like
Use smaller types for those that can support it.

Describe alternatives you've considered
None.

Targeted Platform (please complete the following information only if applicable, otherwise dot N/A):

• Ouster Sensor? N/A
• Ouster Firmware Version? >=2.3
• ROS version/distro? N/A
• Operating System? N/A
• Machine Architecture? N/A

[Samahu]

@Aposhian thanks for opening this issue, and I do agree with you on this. Under the current setup ouster_client internally performs the necessary steps to decode the fields. A this stage I am relaying on it to get the data. But I could see in the future that we can bypass this step and stream out the data directly without decoding (all of the fields) and leave the task of unpacking of fields on the receiving end of the point cloud.

We probably still want to unpack the range field to compute xyz for the point cloud but we don't necessarily need to send the range data unpacked as you rightly noted.

[Samahu]

On this note, the Point Cloud Customization feature is still relatively new and admittedly lacking sufficient documentation. As an intermediate solution, if you explore the code a bit it isn't too difficult to craft and add new Point Types that include only the fields that you care about. For example checkout the definition of Velodyne PointType (PointXYZIR) which only utilizes intensity (signal) and omits the rest of fields. It shouldn't be too difficult to design something similar that includes different fields (depending on fields used and their names you may need to adjust or customize the template method point_transform defined here for your custom point type. If you follow the same pattern, your new point type should work seamlessly regardless of the active sensor udp profile.

P.S. this doesn't remove the need to send data unpacked as requested in the original problem.