Skip to content

[WIP] Build and use a vertex map for keypoints extraction

Nicolas Cadart requested to merge VertexMap into master

Currently, the keypoints extraction is based on the analysis of the laser neighborhood of each point. The scan lines are filled with points shot by the same laser, without any consideration of azimuth or the absence of firing return. This lead to erroneous neighborhoods analysis.

With this MR, a vertex map (~ 2D range image) is built to store the points indices in a coherent manner between different scan lines or along azimuth value. This allows to define new rules or mechanisms to invalidate or select keypoints:

  • The points which have no neighbor (left or right) are considered to lay on a depth gap boundary. This could be really helpful in very poor features environments with only a few laser returns, by detecting the edges of the scanned objects.
  • The points which miss some neighbors are excluded from keypoints extraction.

NOTE: The vertex map filling and the automatic computation of angular resolution do not rely anymore on the prior that all points from the input pointcloud come in sorted order (increasing azimuth) in each scan line.

There are still some points to dicuss/improve:

  • if spinning velocity is not perfectly constant or if the measurements are imprecise, we won't have a perfect 1 vertex = 1 point match, because two points will lie in the same voxel, and the next one will be empty. This is even more true when dealing with dual return.
  • too many depth gaps are now detected, especially far isolated points. Maybe we could limit this by checking if a depth gap exists in the previous/next scanline at this azimuth value, or disable this criterion for too far points. I'm not sure how to properly deal with this, but this MR cannot be merged as it is now.
  • should we keep the (maybe too costly) PCA computation and replace it by average line only : apparently, this extracts much more keypoints than necessary. Therefore, even if kp extraction is faster, matching and optimization are much slower.

Done in !398 (merged)

Edited by Julia Sanchez

Merge request reports