gicp speed

[yst1]

I run source code each scan's gicp process just cost 2-3 ms, when i run my own code use gicp library it cost 100-200ms. Both Input cloud's size almost same, which setting options may cause this phenomenon?

[yst1]

Both iterations num is almost same, both numthreads is same

[kennyjchen]

DLO contains a host of algorithmic innovations which improve the computational efficiency of LiDAR-based odometry/SLAM pipelines beyond just parameter tuning, such as data structure recycling. More information is in our paper linked in the Readme.

[yst1]

Can you give an example which data structure is recycled？I think that my usage is very similar with DLO. Thanks a lot!

[kennyjchen]

Structures such as kdtrees and point cloud covariances are reused between iterations and scan-to-scan/scan-to-map modules to avoid redundant computations. If you are referring specifically to scan-matching, then that is all handled by our GICP solver NanoGICP for fast nearest neighbor search. Details are in our paper.

[yst1]

In papaer's part G Algorithmic Implementation's Submap Multithreading, it writes it periodically checks if the main thread is running so it can pause itself and free up resources that may be needed by the highly-parallelized scan-matching algorithm, how to reflect in the code? In other words, parallelized scan-matching algorithm how to implement? I just see once receive the points, first do scan to scan, then transfer the result to scan to map as initial guess, it seems like serialized. The multi threads in code contain Metrics computation, ros publish, debug thread, does it have other threads in the code?

[kennyjchen]

That section is in a follow-up paper, not the one linked above. DLO only contains a serialized submap build.

[yst1]

Thanks for your careful reply. Another question, in NanoGICP code the nearest search function nearestKSearch just use PCL library, then how to speed up GICP solve process?

[kennyjchen]

NanoGICP uses nanoflann for nearest neighbor searching. The PCL inheritance and headers are just artifact from FastGICP (though we should really remove those).

[Gatsby23]

I run source code each scan's gicp process just cost 2-3 ms, when i run my own code use gicp library it cost 100-200ms. Both Input cloud's size almost same, which setting options may cause this phenomenon?

From my test, the amazing speed is mainly benefits from the nanoflann[The purposed KDTree]. It will benefits a lot from the OpenMP，when the core num is increased more than 4. When I use only one core, the gicp s2m costs more than 100ms. But when I use 10 core, it only costs 1ms about.