文纯属转载,并认真学习一遍,感谢大佬分享!
注释:文中蓝色文本是自己加上去的
本文章配套源代码地址:https://github.com/Little-Potato-1990/localization_in_auto_driving
测试数据:https://pan.baidu.com/s/1TyXbifoTHubu3zt4jZ90Wg提取码: n9ys
本篇文章对应的代码Tag为 12.0
代码在后续可能会有调整,如和文章有出入,以实际代码为准
============================================================================================
一、概述
我们在这个程序框架设计之初,就把扩展性作为一个重要特性来指导我们的设计。
所谓扩展性,就是每一个功能模块都可以随意更换。
这个更换不仅是模块内部可以增加选项,比如后端优化中,在g2o的基础上增加gtsam选项,前端匹配中,在ndt的基础上增加icp选项,等等。而且还包括可以整个替换掉一个模块。
之前提到的四大模块(前端、后端、闭环、显示)里,可替换选项最多的就是前端了,因为我们随处可见各种各样的激光里计。
其实我们的程序架构已经具备了这样的扩展性。这次就以A-LOAM作为例子,把它加入我们的建图系统中来。
二、实现方法
1. 配置A-LOAM
A-LOAM是港科大在LOAM基础上修改的一个版本,能够适应16线、32线和64线velodyne雷达。
A-LOAM在github上的链接地址为:https://github.com/HKUST-Aerial-Robotics/A-LOAM
这个开源系统的配置环境可以直接参考github上给出的步骤。
我们把这套代码也加入了我们的工程中来,配置完之后可以直接编译。
2. 运行
我们在工程中添加了一个新的launch文件,专门为了测试这个扩展的版本。在完成编译以后,执行如下指令,便可以运行程序
roslaunch lidar_localization mapping_with_aloam.launch
需要注意的是,aloam在运行64线雷达数据的时候,运算量比较大,这时候在我们的框架下,如果按正常速度播放bag,会偶尔丢失一部分数据,这是我的问题,后续再改。现在可以使用一个相对简便的方法避开这个问题,就是降低bag播放速度,以给每次运算留足够的时间。输入如下指令便可实现这一目的。
rosbag play kitti_2011_10_03_drive_0027_synced.bag -r 0.3
其中"-r 0.3"就是指以0.3倍的速度播放。
运行完之后别忘了输入指令,执行最后一次全局优化
rosservice call /optimize_map
三、 结果及分析
由于有GNSS和闭环做约束用来优化,所以前端里程计在更改前后的性能差异并不会在地图上有大的体现,我们只能评价一下前端里程计,看一下这二者之间的差异。
打开终端,在slam_data/trajectory目录下,输入如下指令,可评价里程计精度
evo_ape kitti ground_truth.txt laser_odom.txt -r full --plot --plot_mode xyz
结果如下
最大值:137.887078 m
平均值: 40.891957 m
RMSE: 56.073576 m
这个结果其实是比原来的前端要差一些的,但是我并不认为这是A-LOAM原本的性能,从它kitti odometry数据集上的效果看,精度要比这好得多。我认为这个应该是我们之前在畸变补偿那一节提到的原因,那就是我们的bag数据是在原始数据上二次处理的,它打乱了点云中激光点的原始顺序,而A-LOAM的原理是严重依赖这种顺序的,所以这个会导致它的性能上有大的下降。
四、总结
其实没啥可总结的,就是想说,用A-LOAM代替前端只是举个例子,各位可以把任何自己想用的前端按照同样的方法加入到这个系统中来。
需要注意的是,我们所有的数据都是按时间戳对齐的,所以如果您使用了别的里程计,那么应该保证输出的odom里的时间戳要和接收的点云里的时间戳保持一致。
五、问题和解答
1、感谢博主所做的这些工作。我想请教博主关于时间漂移的问题。当不同传感器融合的时候会存在触发延时、传输延时、时钟不同步等等一系列因素导致时间无法同步。即使有脉冲发生器解决触发,并选择相同时间戳,(前文里所讲部分)。按照前文所讲处理后,是不是依旧还是会存在少许时间漂移误差?
答:有,可以使用同一时钟源