echo_pulse_width added in osi_featuredata.proto for message LidarDetection

[PhRosenberger]

echo_pulse_width added in osi_featuredata.proto for message LidarDetection.

Add a description

As intensity is in % and echo_pulse_width is in m, such a field is currently missing in OSI for LidarDetectionData.
It is necessary to transfer echo_pulse_width since sensors like Ibeo LUX or Valeo SCALA are having this as an output instead of intensity.
The PR comes out of the SET Level project, where it has already been approved by the project-internal OSI-CCB.

Take this checklist as orientation for yourself, if this PR is ready for the Change Control Board:

• My suggestion follows the style and contributors guidelines.
• I have taken care about the documentation.
• I have done the DCO signoff.
• My changes generate no errors when passing CI tests.
• I have successfully implemented and tested my fix/feature locally.
• Appropriate reviewer(s) are assigned.

If you can’t check all of them, please explain why.
If all boxes are checked or commented and you have achieved at least one positive review, you can assign the label ReadyForCCBReview!

[kmeids]

@PhRosenberger as discussed in the SM meeting, could you please provide more documentation/explanation on the echo_pulse_width ?

[PhRosenberger]

@PhRosenberger as discussed in the SM meeting, could you please provide more documentation/explanation on the echo_pulse_width ?

I have added an explanation with reference to some figures.
@kmeids what do you think about it?

[kmeids]

@PhRosenberger I think that is really good!
@max-rosin would it be more practical to have the images Philipp is referring to directly integrated into the documentation and a link to the publication for more info?

[max-rosin]

From the user perspective, directly integrating the images is better.
However, I do not know whether simply integrating these images produces copyright problems (for example, some sort of exclusivity clause with Springer in the publishing contract).

[PhRosenberger]

From the user perspective, directly integrating the images is better.
However, I do not know whether simply integrating these images produces copyright problems (for example, some sort of exclusivity clause with Springer in the publishing contract).

Is this a question to us or are you clarifying it right now?

[max-rosin]

From the user perspective, directly integrating the images is better.
However, I do not know whether simply integrating these images produces copyright problems (for example, some sort of exclusivity clause with Springer in the publishing contract).

Is this a question to us or are you clarifying it right now?

I simply wanted to raise awareness, that we are talking about images which are subject to copyright, publishing contracts, employment contracts etc.
Whoever adds the images to the documentation must also make sure that he or she is allowed to do so and is also capable of granting OSI the permission to re-distribute them under its license. That's basically what the DCO sign-offs on your commits mean. Usually this is not a big deal, but here we are talking about images that have already been published by a big publisher.

But since you asked, I took a second look at the article and saw that it is licensed under Creative Commons Attribution 4.0 International License. This license extends to the images in the article as well, unless otherwise noted. This makes everything a lot easier, because it allows to by-pass many of the more complicated questions.

However, even with creative commons there are still a couple of things to do, namely proper attribution and a link to the license text. I have no idea how to do that properly in the context of OSI.

If complying with the license is infeasible, we can of course always create new images. This has the added benefit that we can improve them and adapt them to OSI.

[stefancyliax]

However, even with creative commons there are still a couple of things to do, namely proper attribution and a link to the license text. I have no idea how to do that properly in the context of OSI.

Clarified this topic inside ASAM:
We can use this image with the footnote:
Figure: Creative Commons from Rosenberger, P., Holder, M.F., Cianciaruso, N. et al. Sequential lidar sensor system simulation: a modular approach for simulation-based safety validation of automated driving. Automot. Engine Technol. 5, 187–197 (2020). Lizenz: CC BY 4.0. Fig 7 / 8 from the original.

Please include @pasched

[kmeids]

Please update the white spaces.

[stefancyliax]

I think this is also the reason the pipeline fails. Patching now.

[kmeids]

Output CCB 15.09.2021:

1. @stefancyliax to take care of adding the pictures referenced by @PhRosenberger.
2. @pasched to do documentation review and set to "ReadyToMerge".
3. @pmai to merge after "1" and "2" are done.

[stefancyliax]

From the user perspective, directly integrating the images is better.
However, I do not know whether simply integrating these images produces copyright problems (for example, some sort of exclusivity clause with Springer in the publishing contract).

@PhRosenberger Can you provide the images from the linked paper?

[kmeids]

CCB Output 13.10.2021:

1. Update citation according to the following comment (echo_pulse_width added in osi_featuredata.proto for message LidarDetection #511 (comment)).
2. @pmai to fix the DCO and merge.

[stefancyliax]

Please use this citation style:

[1] Rosenberger, P., Holder, M.F., Cianciaruso, N. et al. Sequential lidar sensor system simulation: a modular approach for simulation-based safety validation of automated driving. Automot. Engine Technol. 5, 187–197 (2020). https://doi.org/10.1007/s41104-020-00066-x

[stefancyliax]

CCB Output 13.10.2021:

1. Update citation according to the following comment (echo_pulse_width added in osi_featuredata.proto for message LidarDetection #511 (comment)).
2. @pmai to fix the DCO and merge.

Point 1 done. Over to you @pmai