首先我们明确几个重要的坐标系
1.base_link
移动机器人的当前坐标系
2.odom
里程计坐标系，一般由里程计运动模型来计算，不过不同的地方可能会有不同的计算方法，比如有的可能是编码器计算。
这个坐标系的特点就是，会有累计误差，并不能做为一个长期的参考坐标系，但是优点则是连续，无跳变
3.map
地图坐标系，可以作为一个长期的参考坐标系，但是不连续。原因是，在定位模块中会根据传感器的观测值来重新计算机器人当前位置，在消除漂移的同时产生了跳变，所以不连续。
gmapping坐标系
需要的坐标变换
1.base_laser到base_link，这里如果整个机器人是一个刚体，也就是雷达和机器人的中心(base_link)之间的距离在运动过程中是不会变化的，那么这个变换可以看作是一个静态变换。
2.base_link到odom，这一块是由里程计运动模型提供的。
发布的坐标变换
1.map到odom
下面这张图片是我运行的一个仿真gmapping建图的节点，图中有五个坐标系。
1.注意，base_laser_link大概是在base_link的上前方，只是这个图可能看的不是很清楚，但是他们两者的关系是静态的。
2.其中还有个base_footprint的坐标系是和base_link重合的，footprint即为机器人的轮廓。但是这里值得注意的是，为什么我们需要这两个坐标系。因为base_footprint指的是在平面上的坐标系，也就是说，如果这个仿真是3D的，那么base_link显然会在空中，但是base_footprint是在某一个平面的投影。
3.图中的map和odom坐标系也是重合的，但是这两个是不一样的。。map的原点是指地图的原点，而odom 的原点是机器人的起始点。但是odom是会飘逸的，而且累积误差是一直累加的，所以之后的行走中可以看到map和odom并不是一直重合，所以这就需要gmapping这样算法通过发布map到odom的变换来校正
gmapping 的tf tree大概张这样
hector的坐标系
需要的坐标变换
base_laser到base_link这里不难理解，因为hector是不依赖odometry的，有laserscan的输入就可以建图
发布的坐标变换
map到odom其实在这里我的理解是这样的，这个坐标变换对于建图来说并不是必须的，但是为了统一建图算法的对外接口，所以提供了一个这样的变换(还记得吗，上面gmapping也是提供一个这样的变换)
源码里面为了发布map到odom，是先lookup了base到odom的变换，然后由hector算出的map到base，两个相乘得到map到odom之后再发布出来的。
hector的tf tree如下，其中nav是一个人为造出来的坐标系，实际用途中可以自己定义
amcl的坐标系
ros wiki上面这个图已经很经典了
在实现上面，它同样也是发布map到odom的变换
源码里面是由amcl得到map到base的变换，然后将其tf::TransformPose转成odom到map的变换
