Inquiry Regarding the Use of the "ring" Field in Point Cloud Segmentation

[HowieHepburn]

I would like to express my sincere gratitude for your outstanding contributions to the open-source community. Your project, groundgrid, has been immensely helpful and inspiring, and I truly appreciate the effort and dedication that has gone into its development.

As I was using the project, I came across the use of the "ring" field in point cloud segmentation. Specifically, I noticed that the following code snippet includes certain predefined "ring" values (src/GroundSegmentation.cpp line 189):

const bool ground_point = point.ring == 40 || point.ring == 44 || point.ring == 48 || point.ring == 49 || point.ring == 60 || point.ring == 72;
This raises a few questions that I was hoping you could help clarify:

1. What is the basis for determining these specific "ring" values?
2. Does this fixed set of "ring" values imply that the segmentation method is tailored to a specific LiDAR model?
3. If I were to use a different LiDAR device (from a different manufacturer, with a different number of beams/lines), how should I go about determining the appropriate "ring" values for segmentation?
4. What potential issues might arise if these "ring" values are inaccurate or not properly adjusted for a different LiDAR model?

Your guidance on these questions would be incredibly helpful for me to better understand and adapt the segmentation method for my specific use case.
Thank you again for your exceptional work and for your time in addressing my queries. I greatly appreciate your support and look forward to hearing from you.

[Nussknacker]

Hi @HowieHepburn,

Thank you for your interest in our work.
The line you are asking about is simply a remnant of some now-deleted evaluation code, which is also why the variable is set but never read. I will remove it from the code.

The ring field is used in only one instance of the segmentation code (line 240). Its purpose is to filter out laser beams facing an upward direction and thus never hitting the ground. We have found it beneficial for LiDAR models such as the Velodyne VLS-128 or the Ouster OS1-64. If your LiDAR does not supply this field, you can remove this reference as well without sacrificing too much performance.
Additionally, you may find the following comment helpful: #5 (comment) which contains general information about parameter adjustments for other LiDAR sensors.

If you have further questions, please don't hesitate to ask here.

[HowieHepburn]

Thank you so much for your prompt and insightful response, I do have another question regarding the performance of the algorithm. While evaluating the processing time, I noticed that the processing time for a single frame of point cloud data is in the range of hundreds of milliseconds (KITTI-00 sequence / Intel 12490F), which seems a bit different from the 171Hz performance mentioned in the paper. Could you help me understand what factors might be influencing this discrepancy?

output << time_taken_1 << "," << time_taken_2 << "," << time_taken_3 << "," << time_taken_1 + time_taken_2 + time_taken_3 << "," << milliseconds << "," << avg_time << "," << c_millis << "," << avg_cpu_time;

0.024117 | 0.280355 | 0.046216 | 0.350688 | 280.362 | 292.04 | 614.651 | 703.557

Looking forward to hearing from you and once again, thank you for your amazing work and support!

[Nussknacker]

You are correct, it should run a lot faster than that.
Did you make sure to compile it in "Release"-Mode or anything equivalent that skips assertions? This is necessary because the Grid Map Framework relies on Eigen which has assertions guarding every access leading to a huge performance impact.
Otherwise, you could set the ROS log level to debug, to receive more timing information to figure out what part of the code is causing the delay.

[HowieHepburn]

Thank you very much, now the order of magnitude of the time seems to be more normal, about 10-20ms

output << time_taken_1 << "," << time_taken_2 << "," << time_taken_3 << "," << time_taken_1 + time_taken_2 + time_taken_3 << "," << milliseconds << "," << avg_time << "," << c_millis << "," << avg_cpu_time;

0.004579 | 0.014009 | 0.009332 | 0.02792 | 15.2766 | 15.6474 | 52.807 | 50.7416

Have you tried to use GroundSegmentationBenchnmark to evaluate the algorithm? When I want to compare with other algorithms, I find that the evaluation method seems to be a little different, so it seems diffcult to compare the results directly. For example, your evaluation seems to be different from the benchmark regarding the treatment of the "VEGETATION" label (this label accounts for 27% of the total point cloud in the SemanticKITTI dataset). I wonder if this affects the evaluation of the results.

And the following are the runtime results of other algorithms I obtained using the benchmark (ms):

         CascadedSeg      69.75077372 
         GPF                     12.23549196 
         Gaussian             14.23426255 
         LineFit                 16.97570813
         Patchwork           16.68008052
         RGPF                  16.42739315
         Ransac                63.45367161

[Nussknacker]

Seeing that the Intel 12490F has only 6 physical cores you might gain some milliseconds by lowering the max_threads configuration variable from 8 to 6.

We did not attempt to use the GroundSegmentationBenchmark because, due to its iterative nature, GroundGrid needs the robot pose in addition to the point cloud. Also, GroundGrid relies on the ROS tf-Library for coordinate system transformations. For this to work these transformations need to be published by some ROS-node. As far as I can tell the GroundSegmentationBenchmark would need to be modified quite a bit to support GroundGrid.

Additionally, we were unsure about the label processing of the GroundSegmentationBenchmark: It appears that it considers points labeled "unlabeled", and "outlier" as non-ground. We do not think that is always correct. Also the label "vegetation" seems to be reclassified with a constant z-height-threshold (see line 122 in common.hpp). This makes the result a bit more difficult to compare. However, if you want to include "vegetation" in the overall scores, you can add this label to the non-ground label list in line 76 of our eval_groundpoint_classifier.py evaluation script.

Regarding the "vegetation" label: As stated in our paper, we, like other authors (e. g. Patchwork++) decided to exclude this label from the evaluation for several reasons. According to the citiscapes definition, the "vegetation" label is reserved for vertical vegetation, while "terrain" should be used for horizontal vegetation, like grass. Unfortunately, the SemanticKITTI dataset contains many instances where the "vegetation" label is applied to areas belonging to the terrain class. Also, the distinction between horizontal and vertical vegetation is often very difficult to make especially when both classes appear closely together leading to the "vegetation" label being applied uniformly to the whole area in question.
The high prevalence of vegetation in the data makes the results less meaningful since then, important but less prevalent classes, like "person" or "moving-car" do not contribute to the overall accuracy in a meaningful way.

Here are some examples of the problems with the "vegetation" label:
Sequence 03, bright green is "terrain", and dark green is "vegetation". The grass by the road is labeled as "vegetation", even though it appears flatter than the field in the back, which is labeled as "terrain".

Sequence 01, the grass between the highway lanes is sometimes labeled as "vegetation" (dark green) and sometimes as "terrain" (bright green):