search

norlab-ulaval / libpointmatcher

An Iterative Closest Point (ICP) library for 2D and 3D mapping in Robotics
BSD 3-Clause "New" or "Revised" License
1.58k stars 542 forks source link

Plans to implement new registration methods #369

Open YoshuaNava opened 4 years ago

YoshuaNava commented 4 years ago

Hi, I'm a frequent user of libpointmatcher, its filter chains and specially the point-to-plane error minimizer for ICP.

In recent times, new registration methods have been developed, which show really strong performance in benchmarks (e.g. KITTI). Most of them are variants of ICP depending on different descriptors, point representations, and introduce extra steps to ensure higher robustness. Some examples are:

I was wondering if there are any plans to integrate any of the above methods into libpointmatcher in the near future, and if the main authors of the library have experience with them. I think libpointmatcher must be the most flexible and feature rich implementation of ICP and point cloud filters, and could benefit from some of the above methods.

Thank you in advance.

pomerlef commented 4 years ago

Yes, we are tracking those solutions (and others). The short terms goals are:

Auto-tuned ICP was relying on libpointmatcher for there publication, but I'm not aware that they send us a PR to integrate it.

LOAM (and alike) are tightly coupled with IMU (or vision). The short term step is to focus on the point-to-edge they were using.

YoshuaNava commented 4 years ago

@pomerlef Thank you for your immediate reply.

I'm interested in the developments you mention. I'll stay in sync to and would be glad to help review/test.

Regarding LOAM, I gather they use a different type of descriptor instead of surface normals, which is inspired on surface smoothness. Based on that they extract corner and edge points, and use them for matching. The data association is performed with k-NN, and they employ bi-square weights to account for outliers. What is your opinion on these changes?

About LOAM's use of IMU data, it's interesting that they do it to accumulate point cloud data, run light registration to get a good initial guess and release some burden from the frame-to-map localization module, but they don't employ the gravity vector to prevent the map from curving away. However, there are other methods (e,g, LIO-mapping) which take advantage of available pre-integrated IMU graph factors to build a gravity-aligned localization estimate.