You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Thank you for this dataset and the related Lidar odometry methods.
I'm applying the original version of LeGO-LOAM on your dataset (by 'original' I mean the version available via https://github.com/RobustFieldAutonomyLab/LeGO-LOAM). And I would like to know if you modified something in the code before getting the trajectory's figures based on the topic /aft_mapped_to_init.
In my humble opinion, in the original version of LeGO-LOAM at least, I think that the topic containing the final trajectory estimation is rather /key_pose_origin than /aft_mapped_to_init.
In attachment, you find a figure of both the poses contained in /key_pose_origin and /aft_mapped_to_init. The trajectories are very similar, except after the detection of a loop closure. There, /aft_mapped_to_init seems to "jump" until the correct pose without updating the previous poses, while /key_pose_origin seems to update all poses.
I would be happy to know your opinion about this. Don't hesitate to tell me what you think.
Have a nice day.
The text was updated successfully, but these errors were encountered:
Many thanks for pointing this out! We actually very much welcome community contributions and really appreciate it. We have linked your contribution to README to better help the community.
Hi @yzrobot,
Thank you for this dataset and the related Lidar odometry methods.
I'm applying the original version of LeGO-LOAM on your dataset (by 'original' I mean the version available via https://github.com/RobustFieldAutonomyLab/LeGO-LOAM). And I would like to know if you modified something in the code before getting the trajectory's figures based on the topic /aft_mapped_to_init.
In my humble opinion, in the original version of LeGO-LOAM at least, I think that the topic containing the final trajectory estimation is rather /key_pose_origin than /aft_mapped_to_init.
In attachment, you find a figure of both the poses contained in /key_pose_origin and /aft_mapped_to_init. The trajectories are very similar, except after the detection of a loop closure. There, /aft_mapped_to_init seems to "jump" until the correct pose without updating the previous poses, while /key_pose_origin seems to update all poses.
I would be happy to know your opinion about this. Don't hesitate to tell me what you think.
Have a nice day.
The text was updated successfully, but these errors were encountered: