在tf树中的父坐标系和子坐标系中间的odom

机器人在平直走廊中由于缺少参照物的变化，无法估计自己的位移；可以通过轮子转动的圈数和一

圈的位移来计算距离，这种通过电机转速计算机器人位移的方法就是常用的电机里程计；里程计不

是硬件而是一种软件算法，该算法会运行在机器人的驱动节点中，此位移信息也是以tf消息包的形

式发布到话题/tf中去。

激光雷达SLAM输出的是map到base_footprint的tf，里程计输出的是odom到base_footprint

                     

 通过里程计的位移信息就能推算机器人的当前位置，还不会受参照物特征的误导，那激光雷达 

SLAM中通过雷达点云和参照物配准所实现的定位功能的用处在于？

通过电机里程计推算的位移数据只是理论值，必然和实际情况存在一些偏差

如何进行修正呢？→障碍物点云配准的定位算法

机器人的实际位置处使用激光雷达扫描障碍物得到雷达点云如下所示

接下来将点云挪到里程计估算的位置上，点云和障碍物并没有重合

 误差如何弥补呢？将点云直接贴合到障碍物上的同时机器人的位置也会拉到原位置，在里程计估

算的位置上加上一小段位移即可得到点云和障碍物相吻合。

问题在于，里程计输出的是odom到base_footprint，没办法在base_footprint和机器人底盘之间插

入新的tf→SLAM节点迁就里程计，base_footprint已经被里程计占用，那么SLAM节点将这段tf挪到

根端的odom之前，也就是下图1到2的变化，

map→odom→base_footprint就实现了map到base_footprint的tf

以上的操作就是gmapping的核心

 hector的核心：直接将雷达点云贴合障碍物的轮廓所得出的机器人位移作为最终的定位结果，也就

是map到scanmatcher的过程，不是为了修正里程计误差，而是让base_footprint的位置始终和

scanmatcher_frame保持一致。

另外，要实现rviz显示地图和模型，就必须实现map到base_footprint的tf，这样才能将机器人本身 

的tf和map连接上，实现完整的tf树。

总结：gmapping中机器人的位移主要由里程计推算，激光雷达点云配准算法只是在修正里程计出

现的误差；而hector  mapping在单位过程中，完全不考虑里程计的数据，只使用雷达点云和障碍

物配准的方法来进行定位，为了在rviz中显示地图和模型勉强输出一段map到odom的tf去抵消不断

增长的里程计tf好让base_footprint的位置始终和scanmatcher_frame保持一致。