Adds explicit example for lidar

[maxspahn]

The lidar sensor is already accessible, but without the proper example, it was hardly noticed by users.

[lgtm-com[bot]]

This pull request introduces 1 alert when merging 3a3f69ba605f37d2ad11f4af1b46b400f70a28a4 into 00001beb199e8b1bc654b4380cd96356b52385cc - view on LGTM.com

new alerts:

• 1 for Unused import

[alxschwrz]

I do have a couple of questions regarding the general structure of the Lidar sensor though @maxspahn As far as I understand, it returns 8 values for 4 rays in this example. Those are the relative positions to the closest obstacle, right?

• Why is only the closest obstacle considered?
• What is the advantage of returning a relative position rather than the raw sensor outputs? I would expect the output to be the length of each ray.

[maxspahn]

Those are the relative positions to the closest obstacle, right?

Indeed.

Why is only the closest obstacle considered?

Because the lidar cannot look through an obstacle so it only returns the first obstacle.

What is the advantage of returning a relative position rather than the raw sensor outputs? I would expect the output to be the length of each ray.

That some processing is already done. Do you think it is better to directly return the raw value?

[lgtm-com[bot]]

This pull request introduces 1 alert when merging 2ad9ce20cb870bc9d45f224da9e77944ed9ab04e into 00001beb199e8b1bc654b4380cd96356b52385cc - view on LGTM.com

new alerts:

• 1 for Unused import

[alxschwrz]

Ah, thanks for clarifying. So it does take into account all obstacles, but only returns the distance to the first ones, if the other one is occluded, right? Thus, in the case of obstacles that do not occlude each other, both are taken into account.

I really like the option of directly returning the raw sensors :)