Sensing/Perception Architecture Design

[mitsudome-r]

I would like to initiate the discussion for the new Localization module that we are going to implement for Core/Universe.

The overview of the AD stack is being discussed here, and this discussion thread would focus on the details of the localization module.

Tier IV has prepared the initial proposal in the following slides:
Auto.Perception.Investigation.Eng.pdf

[mitsudome-r]

Here's the meeting minutes from today's discussion:
https://docs.google.com/document/d/1ZobsK1qR4axNW8g9gVsQQ-YZ7BiJxZPbIX1GMtvQelg/edit?usp=sharing

Summary

Sensing

• We are moving forward with current design made by Fatih in here.
• we are still flexible with additional sensors (e.g. ultrasonic, 2D LiDAR, etc)
  

Perception

• We have decided add Untracked object as output of perception stack. However, the output format and how it is provided needs further discussion
• We have decided to move fusion out of tracking to make it more flexible to different sensor configuration.
  

I would like to use this thread to discuss further about untracked objects and traffic light recognition, so any comments or proposal are welcome.

[alexandrx]

One comment regarding sensing part is about LiDAR pointcloud filtering.
The text we analyzed during today's call, the pointcloud preprocessor (page 3) says "ring_outlier_filter". While I guess this was intended as an example, there are plenty of LiDARs which do not have "rings" (multiple beams + mechanical 360° rotation); some examples are: Livox Horizon, RoboSense RS-LiDAR-M, Baraja, etc. Say, one potential deployment could use a bunch of Livox around the car and not use a 360° LiDAR on top.

Therefore, the architecture should adopt a "wording" which does not necessary limit the technology of LiDARs to use.

[xmfcx]

From Velodyne VLS-128 datasheet:

A laser channel is a single 903 nm laser emitter and detector pair.
Each laser channel is fixed at a particular elevation angle relative to the horizontal plane of the sensor.
Each laser channel is given its own Laser ID number.
Since the elevation angle of a particular laser channel doesn't change, it doesn't appear in data packets. Its value is inferred by a data point's location in a data packet.

[xmfcx]

From Livox Horizon Point Cloud Characteristics Page

In Fig. 3 you can see the FOV coverage of other (non-Livox) LiDAR sensors that use common mechanical scanning
methods. For these sensors, the number of laser lines and vertical FOV are 64-lines-27°, 32-lines-41°, and 16-lines-30°.

[yukkysaito]

If it is closed to the sensing component, the ring information may or may not be required.
Since the PointCloud2 type can freely define fields, it is not necessary to define even the inner fields as an interface within the sensing component.

I think it is better to remove the ring information in the output of the sensing component.

Proposed pointcloud fields of output of the sensing component

• x
• y
• z
• intensity (optional)

[xmfcx]

@yukkysaito I think you've meant to post under #101 (comment)

I agree the rest of the stack doesn't need the ring information.

Here problem is, what should we rename field ring into?

[yukkysaito]

what should we rename field ring into?

@xmfcx
I see 👍
Sorry. I misunderstood something.

I don't have a strong preference, but I think laser id is the best.
Channel can also be interpreted as frequency band, so I think I would mistake it to mean wavelength.

I am not a native English and may have misunderstood the meaning of the word. 🙏