move_base+自己的定位程序(攻略篇) --- 成功实现ESKF的lidar+imu以及move_base的路径规划

发布时间:2024年01月23日

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

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

首先,我自己的定位程序是参考网课写的,其主要实现的是基于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之间的坐标系转换。

参考文献

1.lio-sam+move_base
2.hdl_localization+move_base
3.lio-sam+move_base+3d点云转2d

希望阅读本文的各位工作学业顺利!

文章来源:https://blog.csdn.net/qq_44705939/article/details/135772220
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。