move_base+自己的定位程序（攻略篇） --- 成功实现ESKF的lidar+imu以及move

本文主要是介绍move_base+自己的定位程序（攻略篇） --- 成功实现ESKF的lidar+imu以及move_base的路径规划，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

临近放假，老板要求回去之前找其汇报进展，无奈近几月忙于毕业论文的编写，实在是没有多少可以汇报的内容，想来自己弄得定位程序只能实现定位，要不自己再加一个路径规划，直接干！

本文的文字量较大，请各位耐心阅读

首先，我自己的定位程序是参考网课写的，其主要实现的是基于ESKF的LIDAR/GNSS/IMU的多传感器融合定位系统，那么我自己的程序的TF树如下图所示。
在这里插入图片描述

可以看到，我的定位程序给出的是map到激光雷达传感器坐标系PandarXT-16的坐标变换，我们再考虑move_base的TF结构，如下图所示：
在这里插入图片描述
上面这幅图是在网上找的网图（侵删），可以看到，move_base需要如上图所示，需要map->odom->base_link（也可以是base_footprint，看你自己喜好），如此下来，我们似乎只需要将我们的定位程序按照这样的TF树进行发布即可？

非也！

我们在将自己的定位程序移植与move_base结合时，需要考虑如下几点：
1.TF结构；
2.那些坐标系之间可以是静态的，哪些可以是动态的？（这很重要！！！）；
3.move_base在启动过程中，需要使用amcl获取到里程计信息，从而完成位姿初始化，进而完成costmap的初始化（没有costmap，就无法使用路径规划器！）；
4.move_base需要单线激光雷达数据，但考虑到有一部分情况下，我们使用的是三维激光的定位程序，比如我自己的这个，那么就需要对原始点云做一些处理，进而得到单线激光雷达数据类型（即laser_scan）；

以上四点，除了第四点外的每一个点都可能会出现不同种类的报错或者警告，第四点相对比较好处理，直接一个第三方工具包即可完成任务（链接放到最后）。

首先考虑TF之间的变换，哪些是可以静止的，哪些是必须动态的，直接给出答案：
map->odom：可以是静止的（我自己实测，手动发布map和odom之间的静态转换，后续的程序是可以启动的，我发布的是map与odom重合的TF静态变换）
odom->base_link/base_footprint：必须是动态的，必须是动态的，必须是动态的！！！！重要的事儿说三遍。这里解释一下，其实amcl通过订阅坐标系之间的变换来完成位姿的初始化以及实时定位，笔者在这里卡了很久（基础不牢，地动山摇啊），因为一直以为amcl是通过订阅某个定位话题去完成位姿的初始化，后来请教过大佬和查看官网后，才发现amcl其实订阅的是odom与base_link/base_footprint之间的TF变换来的。
这里就很关键，回到本文的第一张图，可以看到我自己的定位程序发布的其实是map->PandarXT-16这两个坐标系之间的TF变换，笔者最开始的时候以为amcl订阅的是map->odom之间的TF变换，将自己的定位程序修改为发布map->odom之后，发现一直提示如下图的warning：
在这里插入图片描述
可以看到一直提示global_pose的stamp一直为0.00，这就很奇怪了哦，因为我使用tf_echo map odom这个指令监听这两个坐标系之间的变换时，at time是有时间的，笔者最开始一直没想明白，后来也是在别人的提醒下，同时参考了网上一篇博文lio-sam+move_base后，自己研究了一下lio-sam的TF变换情况，在RVIZ中查看lio-sam运行过程中各个坐标系之间的变换后，才猛然发现有可能amcl拿到的不是map->odom，而是odom->base_link/base_footprint！！！！
随后笔者立即修改定位程序，手动发布map与odom之间的静态变换，最终，成功点亮move_base~
在这里插入图片描述
很漂亮的轨迹就出现了~~~~
最后的TF树：
这张图里面map->odom应该是static，而odom到base_link是/kitti_…才对，写博文的时候实在是找不到最后正确TF的截图了，但是跟这个图片的结构是一样的，只需要吧map到odom和odom到base_link的变换关系对调一下就行~（后续有正确的了我会更新补充的）

网上对于这块内容的博文较少（我会在本文最后贴出所有自己参考过的博文），且有些看着有点云里雾里的，所以我自己在前辈们的经验基础上，得出了自己在做这项工作时的一些总结，汇总形成此篇博文，很感谢他们！
最后，再给出一个自己的经验总结，在使用move_base时，一定要清楚自己所使用的定位程序的TF结构，确保与move_base基本一致后，再查看定位程序是否能够发出满足amcl需求的TF变换，通常要考虑好哪些坐标系之间可以静态变换，哪些必须动态变换！其实一般TF一致后，能够正常发布amcl所需要的TF变换后，基本move_base就能跑起来了，但我在网上也看到过一些其他的问题，诸如：
1.move_base起来了，但是global_pose的时间戳与系统时间差的有点多，这种情况我看网上多见于一些自己搭建的小车里，主要原因好像是因为没有做系统时钟同步，我自己是用工控机跑的，所以暂时没出现这样的问题；
2.局部代价地图和全局代价地图过小，这个就是调节一下move_bsae的地图相关的参数，还有map_server相关的参数就行，网上有相关教程
3.关于map->odom，其实这个问题我自己也有点犯迷糊，因为有一部分代码中，虽然odom坐标系与map坐标系基本保持一致，但其并不是如我这样是一个静态的坐标转换，而是通过某一个节点发布的动态坐标变换，我之所以使用静态，一方面是参考博文lio-sam+move_base一文中，博主说一般认为map与odom坐标系之间为静态变换，另外一方面我自己运行lio-sam时发现odom与map就是一个静态变换，所以我才这样做的。所以，还是要特别关注一下自己的定位程序的TF树结构，因为有可能您修改了TF树后，move_base的满足了，但是定位却出现了其他的错误，这样是事倍功半的。
我自己的定位其实本身只发布两个坐标系之间的变换关系，所以，我修改定位程序，将其两个坐标系改为odom与base_link之间的变换后，我发现启动定位后RVIZ中有时不会出现定位信息，究其原因是因为我最开始做定位时，基坐标选择的是map，但是修改了坐标转换后，与map之间失去了TF关系，故我手动发布map到odom之间的坐标系转换。