koide3
commented
1 month ago I think LIO-SAM should work better in general while hdl_graph_slam can be better in situations where GNSS and ground plane constraints are effective. In my opinion, the performance difference stems from the choice of the scan matching target (scan-to-scan vs scan-to-model matching) rather than the matching cost design (some works like DLIO showed a good accuracy with a combination of GICP and scan-to-model matching).
Anyways, both hdl_graph_slam and LIO-SAM are a bit outdated now, and I think it would be good to use a more recent ones like FAST-LIO and DLIO.
Note that we are planning to release a new mapping package that works quite well in many situations.
VRichardJP
Hi!
Do you have any opinion about LIO-SAM (https://github.com/TixiaoShan/LIO-SAM) and its derivatives?
For example this paper: https://www.researchgate.net/publication/362466555_Evaluation_and_comparison_of_eight_popular_Lidar_and_Visual_SLAM_algorithms reports LIO-SAM accuracy is comparable to hdl_graph_slam (or even better). However without much details about the parameters it is difficult to tell whether the comparison is fair.
Did you ever check and compare accuracy and performance with LIO-SAM (or similar) yourself?
One interesting difference I find between hdl_graph_slam and LIO-SAM is the latter implements a feature based ICP-like matching (using edge and surface features). The original LOAM paper claims features matching gives faster and better results, in a similar fashion than it does in traditional image processing. In both projects, the feature extraction is based on heuristics on LIDAR ring points scanning, but with modern high density LIDAR sensors (e.g. 64/128 lanes), I guess traditional 3D feature extraction methods could work.
Did you ever explore this kind of feature matching in hdl_graph_slam? (I know ICP/NDT kind of make their own features, but a normal/distribution is not quite the same as something like a corner or an edge)
Sorry for the too many questions :) Thanks!