Is there any problem working with FAST-LIO2?
XW-HKU opened this issue · 19 comments
Dear kim,
I wonder if there is any problem when integrating FAST-LIO2 with scan context? I can help.
@XW-HKU hi Cris,
first I should say thank you for for having interest in this work and releasing such a great project FAST-LIO.
I have not enough time yet so I just have not tried the FAST LIO2 yet.
I guess there will be no problem, but one thing I wanna add is:
could you share a sample livox data sequence having enough loops (revisits) ?
Before (in the youtube video) I used lili-om author’s rosbag, but I think it would be better if a more diverse dataset is available. (Cause I have no livox lidar … )
@XW-HKU hi Cris,
first I should say thank you for for having interest in this work and releasing such a great project FAST-LIO.I have not enough time yet so I just have not tried the FAST LIO2 yet.
I guess there will be no problem, but one thing I wanna add is:
could you share a sample livox data sequence having enough loops (revisits) ?
Before (in the youtube video) I used lili-om author’s rosbag, but I think it would be better if a more diverse dataset is available. (Cause I have no livox lidar … )
Dear Kim, deeply thanks for your works. I think the lili-om's KA_Urban_East bag is a very good data for the loop closure verification. I will release some data sequences in a few days but my bag is almost all high frequency (100Hz) and not as long as KA_Urban_East, such that is not very good for loop closure test.
Moreover, I just try to implement scan context in FAST-LIO2. After I follows all the steps in your video, the results seems not right. The gpo_map look a little strange, as shown in below screenshot. The white is the odo-only-map from fastlio and the colored points is the pgo-map. The wall in pgo-map look separated (I am sure I already send the body frame point cloud, not the global frame, to sc-a-loam node). May I ask what is the reason, in your opinions?
Oh sorry, I found the problem, the timestamp of odometry and point in body frame (from FAST-LIO) is not totally same. If I gives the LiDAR scan-end time as the time stamp of odometry and point cloud, the map looks good.
Great Job!!!!
The result in KA_Scholess2.bag also from liliom.
I still has one more question, since the odometry from fast-lio is the lidar pose at the end time of a LiDAR frame (a scan), also the point cloud (body-frame undistort scan) is also projected to the scan-end before output. so is it right I set the scan-end time as the time stamp of both odometry and body-frame undistort point cloud? Or I should use the timestamp at the scan-begin like ros header timestamp of lidar topic?
@XW-HKU first thank you for the above great result sharing
for the last question,
I actually have not considered much about that timestamp issue
In my case, just using the motion-distorted cloud is okay for the map accuracy
because a small difference from the timestamp preference (i.e., using begin or end time) have empirically LESS affected the performance - I think the reason might be the PGO keyframe pose drop frequency is very low (e.g., 1-2Hz) than the odometry, also the keyframe poses will be optimized later when loop factors added.
@XW-HKU first thank you for the above great result sharing
for the last question,
I actually have not considered much about that timestamp issue
In my case, just using the motion-distorted cloud is okay for the map accuracy
because a small difference from the timestamp preference (i.e., using begin or end time) have empirically LESS affected the performance - I think the reason might be the PGO keyframe pose drop frequency is very low (e.g., 1-2Hz) than the odometry, also the keyframe poses will be optimized later when loop factors added.
Understood, thanks!
@XW-HKU hi Cris, sorry for the awake here again,
I'm under testing the integration of fastlio2 and SC-PGO.
and I found the PGO map slightly not aligned compare to the cleaner original fast lio map
below is the example (left: fastlio2, right: map from pgo)
so I think the timing issue might be more important than I previously naively thought.
I'm still under construction and will let you know again if some improvements found.
Thank you!
I think I found the reason, and now the two maps have similar accuracy
The reason was I had been publishing points in the lidar coord, but the pose in the imu coord. and my mistake. Sorry to bother you.
If the integration guide video is ready, I'll inform you again. thank you.
I think I found the reason, and now the two maps have similar accuracy
The reason was I had been publishing points in the lidar coord, but the pose in the imu coord. and my mistake. Sorry to bother you.
If the integration guide video is ready, I'll inform you again. thank you.
Thank you very much, I was just wondering why and so great to see the problem is found. I will set a switch parameter for the body-frame point cloud publishing. And I will set the IMU-body-frame point cloud as a default setting. Would you mind wait a while to make the video? Because I think, after the fix of FAST-LIO, your video will be easy to make.
I just update the FAST-LIO, seems works fine with SC-A-LOAM. Could you help to verify it?
@XW-HKU
I forked the last night's version of the FASTLIO2 and made a short video!
https://www.youtube.com/watch?v=nu8j4yaBMnw&feature=youtu.be
a very small portion of the code is added
https://github.com/gisbi-kim/FAST_LIO_SLAM/blob/ebe0c247aaad3a71be4426b3eed7f8f88abcca07/FAST-LIO/src/laserMapping.cpp#L517
to publish a scan within a lidar coord because scan context works well under "egocentric" setting (i.e., the lidar emission point is zero)
Excellent! Thanks for your efforts!
Hi @gisbi-kim , can you open the issue function of https://github.com/gisbi-kim/FAST_LIO_SLAM? It's in Settings->Options->Features->Issues.
I try to run roslaunch aloam_velodyne fastlio_ouster64.launch but the program crashes at the begining.
*** Error in `/home/zcc/RosWS/fast_lio_slam/devel/lib/aloam_velodyne/alaserPGO': double free or corruption (out): 0x0000000001939be0 ***
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x777f5)[0x7f2cbafbd7f5]
/lib/x86_64-linux-gnu/libc.so.6(+0x8038a)[0x7f2cbafc638a]
/lib/x86_64-linux-gnu/libc.so.6(cfree+0x4c)[0x7f2cbafca58c]
/home/zcc/Software/Professional/gtsam/InstallDir/lib/libgtsam.so.4(_ZN5gtsam10noiseModel8Diagonal6SigmasERKN5Eigen6MatrixIdLin1ELi1ELi0ELin1ELi1EEEb+0x18b)[0x7f2cbd702b3b]
/home/zcc/Software/Professional/gtsam/InstallDir/lib/libgtsam.so.4(+0x1198bb)[0x7f2cbd5be8bb]
/lib64/ld-linux-x86-64.so.2(+0x106fa)[0x7f2cc033c6fa]
/lib64/ld-linux-x86-64.so.2(+0x1080b)[0x7f2cc033c80b]
/lib64/ld-linux-x86-64.so.2(+0xc6a)[0x7f2cc032cc6a]
I do not know whether it ascribs to the environment, my system is Ubuntu16.04 and the pcl is 1.9, gtsam is 4.0.2
By the way, https://github.com/gisbi-kim/SC-A-LOAM runs well on my computer.
@CanCanZeng I opened the issue at FAST_LIO_SLAM thanks to let me know.
I'm also using GTSAM 4.0.2, but on Ubuntu 18.04
The PGO module is exactly equal to the one in FAST_LIO_SLAM.
Thus, if you successfully ran the SC-A-LOAM, I expect it will run correctly within FAST_LIO_SLAM ...
Thus now I could not grasp the reason, in my opinion, I would like to reinstall the GTSAM.
ps. I found some similar issues using keyword "gtsam double free"
ex. https://www.icode9.com/content-3-813104.html
Thank you for your help @gisbi-kim , I will try it later.