raster_lidar_proposal: adding relevant fields to support generic lidar…

[kolodkin]

…r with custom raster

osi_sensorviewconfiguration.proto:
LidarSensorViewConfiguration - adding timings, directions and number of pixels for generic configuration of lidar scan raster in each frame.

osi_featureddata.proto:
LidarDetection - adding reflectivity as detected by sensor

osi_sensorview.proto:
LidarSensorView::Reflection - adding normal to surface to be used for reflectivity calculation (future use), and object id for easier debugging

[ghost]

@LudwigFriedmannBMW this one might be important!

[ghost]

Looks good to me and doesn't break any existing implementations. Therefore I'll set is as a feature for OSI 3.1.0 and merge it to the master. Regards, Ludwig

[ghost]

Hi @kolodkin, after some discussion with @pmai , we would kindly ask you for some additional documentation (e.g. a conscise example). One of the topics we stumbled over was the dualism concerning rays and pixels. Is there any reason for that?

[kolodkin]

@LudwigFriedmannBMW I could supply an example based on innoviz scanning pattern, but only in private email, for a more generic example, it will take me some time.

With regards to your question, the dualism is redundant.
The new fields:
optional uint32 num_of_pixels = 10;
repeated Vector3d directions = 11;

imake the following fields redundant since providing a more generic appraoch to describe any raster (not just camera like):
optional double field_of_view_horizontal = 4;
optional double field_of_view_vertical = 5;
optional uint32 number_of_rays_horizontal = 6;
optional uint32 number_of_rays_vertical = 7;

From my point of view fields (4,5,6,7) can be removed, but I didn't want to make this change to the project since I don't know how relies on it.

Thanks
Mark

[ghost]

Hi @kolodkin, can you include an example in the comments of the code? The comments serve as a basis for the generation of our documentation.