hku-mars / HBA

[RAL 2023] A globally consistent LiDAR map optimization module
GNU General Public License v2.0
425 stars 58 forks source link

how to add loop closure? #13

Closed minho3 closed 1 year ago

minho3 commented 1 year ago

Hi, I highly appreciate your results. However, unlike your example, the point clouds from my custom dataset do not converge. I wonder if it is possible to add a loop closure to the pose graph. And I wonder if it can produce better results.

wwtinwhu commented 1 year ago

@minho3 Hello, I wonder how large is the deviation at the loop? HBA can handle some cases of loop. You can adjust the voxel size parameter in hba.hpp and global eigen ratio parameter in hba.cpp.

samsdolphin commented 1 year ago

Hi @minho3, our work intends to solve the issue that the point cloud divergence or gap is not fully closed after loop closure. With parameter tuning, we could optimize the point cloud when initial poses are without loop closure. I suggest that you do loop closure in your slam front end, then feed the poses to our work. Hope this helps.

minho3 commented 1 year ago

@samsdolphin Oh, that's useful information. Thanks. I was think your HBA only works odometry output. like LIO. I will try your suggest.

gongjun136 commented 10 months ago

Hi @minho3, our work intends to solve the issue that the point cloud divergence or gap is not fully closed after loop closure. With parameter tuning, we could optimize the point cloud when initial poses are without loop closure. I suggest that you do loop closure in your slam front end, then feed the poses to our work. Hope this helps.

@samsdolphin Hello author, I still want to ask about how to add closed-loop pairs after loop detection. The current code only inputs pose and time, and does not have the index of key frames, so how can we modify the code to add closed-loop pairs's relative pose.

samsdolphin commented 10 months ago

Hi @gongjun136, in this work we don't have such code. But you can refer to another work from our lab, STD, you should be able to find relative code there. Or alternatively, if you are not in a hurry, we will release our latest work HBA2 very soon, and such a loop closure function will be added.

gongjun136 commented 10 months ago

Hi @gongjun136, in this work we don't have such code. But you can refer to another work from our lab, STD, you should be able to find relative code there. Or alternatively, if you are not in a hurry, we will release our latest work HBA2 very soon, and such a loop closure function will be added.

@samsdolphin Thanks for the reply. Looking forward to your new work very much. When will it be published? I have tested the STD loop detection code and also seen the use of pgo for optimization in STD. I have completed the loop detection and pgo parts of my code. My original intention is to compare the final mapping effects of HBA and pgo. So I tested the map without loop detection and the HBA map. The following is the map without loop detection: image After multiple optimizations by HBA, the results are as follows: image-20231025181717078 Set result of HBA to white. The comparison picture is as follows. It is found that the floor is obviously tilted. image-20231025181834589 I would like to ask the author whether HBA is suitable for indoor multi-floor scenes.This is my test data: 链接:https://pan.baidu.com/s/136ChKUrWhe5QhEufhb7MYA 提取码:fifu --来自百度网盘超级会员V5的分享

gongjun136 commented 10 months ago

I forgot, I modified the following code to read the pose file because the source code would read an extra line image

samsdolphin commented 10 months ago

So @gongjun136, is your problem solved?

gongjun136 commented 10 months ago

So @gongjun136, is your problem solved?

@samsdolphin Not yet. What parameters do we need to adjust for indoor scenes? I have tested the outdoor scene and there have been significant improvements, but for my multi story scenario, it seems to be even worse. I saved and cut the map to determine the distance and parallelism of the floors to determine the quality.

samsdolphin commented 10 months ago

Hi @gongjun136, I tried your data. I think the LiDAR degenerated in the stairs scenario, and the current version of HBA cannot handle degeneration. I would suggest you tune the front end, e.g., FAST-LIO2 or whatever, such that the original odometry is not twisted. o0

gongjun136 commented 10 months ago

Hi @gongjun136, I tried your data. I think the LiDAR degenerated in the stairs scenario, and the current version of HBA cannot handle degeneration. I would suggest you tune the front end, e.g., FAST-LIO2 or whatever, such that the original odometry is not twisted. o0

@samsdolphin Thanks for the reply. It may not be a degeneration issue. This lidar inertial odometry was intentionally adjusted by me to see if the map has been optimized. I can give you a good data: https://cowtransfer.com/s/9b7c5d1229a849 点击链接查看 [ new_data.zip ] ,或访问奶牛快传 cowtransfer.com 输入传输口令 nkqnal 查看; My dataset starts and ends at the same location, and the final odometry output has a position difference of 0.003m, -0.0116m, and -0.0001m, with almost no error. Can you try it out for multi-floor scenes. image-20231027163716415 image-20231027163743178 I have also registered all detected loops and output cumulative error changes, indicating that there is basically no problem. Figure_hba

samsdolphin commented 10 months ago

Hi @gongjun136, I checked your data. It's better, but still, it is twisted, starting from the second floor (roughly the 100th frame). 2023-10-28_20-09 2023-10-28_20-10

Our code works for the multi-floor scenes, e.g., we have tested on the dataset from the HILTI SLAM Challenge. Below is the optimized map from sequence 09. Screenshot from 2023-10-28 20-19-06

gongjun136 commented 10 months ago

Hi @gongjun136, I checked your data. It's better, but still, it is twisted, starting from the second floor (roughly the 100th frame). 2023-10-28_20-09 2023-10-28_20-10

Our code works for the multi-floor scenes, e.g., we have tested on the dataset from the HILTI SLAM Challenge. Below is the optimized map from sequence 09. Screenshot from 2023-10-28 20-19-06

@samsdolphin Thank you for your reply. Yes, there is still twist in the stairwell, causing the point cloud of the entire floor to shift at a certain angle. Do you mean that HBA can only optimize floors, and cannot optimize degradation between floors, so these small angles can only be solved by the odometry itself? But I think this is a small error in odometry estimation that becomes apparent with distance. It's also difficult to solve this through the odometry itself, isn't it? Can you provide important adjustment parameters for the multi-floor scenes?

samsdolphin commented 10 months ago

Hi @gongjun136, I suggest scanning other common views from different floors. For example, one common building can be seen from both the 1st and 3rd floors, and when the odometry twists on the 2nd floor, the 1st and 3rd floors won't twist too much. Alternatively, you can choose different stairs (if possible). Like the figure above, you come upstairs from one side and go down from another side. So, the start and end points can share some overlap. Or you can have two or more LiDARs so the degeneration won't happen in the stairs scenario (with multi-sensor fusion). Or can you choose a high-performance IMU?

gongjun136 commented 10 months ago

@samsdolphin What you said does make sense. I'll give it a try right away, thank you.

duanxz0127 commented 9 months ago

Hi @gongjun136 and @samsdolphin , thanks for your great job and meaningful discussion. I'm also having trouble in testing my own outdoor scene data. Could you please provide the parameter setting idea for outdoor large scene data (over 20,000 frames)?

samsdolphin commented 9 months ago

Hi @gongjun136 and @samsdolphin , thanks for your great job and meaningful discussion. I'm also having trouble in testing my own outdoor scene data. Could you please provide the parameter setting idea for outdoor large scene data (over 20,000 frames)?

Hi @duanxz0127, generally speaking, you can try lalyer_num=4 and keep the voxel_size, eigen_ratio parameters the same as default. Let me know if it doesn't work.

gongjun136 commented 9 months ago

@duanxz0127 Sorry, I tried to adjust the parameters, but my device may not be suitable for this algorithm, so it was not successful.

duanxz0127 commented 9 months ago

Hi @gongjun136 and @samsdolphin , thanks for your great job and meaningful discussion. I'm also having trouble in testing my own outdoor scene data. Could you please provide the parameter setting idea for outdoor large scene data (over 20,000 frames)?

Hi @duanxz0127, generally speaking, you can try lalyer_num=4 and keep the voxel_size, eigen_ratio parameters the same as default. Let me know if it doesn't work. 非常感谢您的回复。 我的数据是由livox-mid360采集的,使用FAST-LIO2计算了里程计。虽然进行了闭环检测和图优化,但是仍然存在z轴方向上的分层(下图)。 1701842391028 1701842337931

我尝试了使用4个层而不改变其它参数,但是优化的结果没有解决z轴分层的问题(下图)。 1701842703849

我猜测是z轴分层区域没有被放进一个voxel里,所以尝试了使用4个层,同时增大voxel_size到30,得到的结果在一定程度上缓解了z轴分层的现象。但是整体点云变得模糊,出现了很多离散的杂点,而且在水平方向上出现了原本没有的分层(下图)。 1701842477839

目前还没有找到比较合适的参数。这是我的数据: 链接:https://pan.baidu.com/s/1N7lnJ9vrMZokOAxvSGWOiw?pwd=0fnl 提取码:0fnl

duanxz0127 commented 9 months ago

@duanxz0127 Sorry, I tried to adjust the parameters, but my device may not be suitable for this algorithm, so it was not successful.

GOT IT! Thank you all the same.

gongjun136 commented 9 months ago

@duanxz0127 确实,可能你的分层太大,需要增大体素大小,算法其实就是利用同一个体素内的平面做约束来优化地图。如果出现这种变坏的现象,我感觉可以先用gtsam把累计误差分摊下去,然后再用voxel_size为4试试。

duanxz0127 commented 9 months ago

@duanxz0127 确实,可能你的分层太大,需要增大体素大小,算法其实就是利用同一个体素内的平面做约束来优化地图。如果出现这种变坏的现象,我感觉可以先用gtsam把累计误差分摊下去,然后再用voxel_size为4试试。

感谢!我去试一试

lvpengxiang commented 2 months ago

voxel_siz

请教一下如何使用gtsam来分摊累计误差呢