超级会员免费看
本文记录了一次在ROS中遇到底盘控制时，scan数据与车体运动不同步，以及tf变换问题的调试过程。首先排除了串口堵塞原因，然后发现map到base_footprint的tf变换存在延迟。通过对odom更新和轮速处理的分析，最终发现是静态tf中base_link到laser_link的transform角度错误，修正后问题得到解决，强调了正确配置tf的重要性。
现象描述
一个和底盘通讯的代码和ros包，总是发现当控制车体运行一段距离，rviz里面scan的数据更新会过一秒才能跟着运动走，同时发现tf的base_link也是过一秒才更新
调试过程
起初，以为是串口堵塞，没有及时的接受和处理底盘上行发布的轮速信息导致，之后写了一个串口缓存程序，但是发现并不是串口堵塞导致，而且odom更新是实时的。
之后发现map到base_footprint的tf的变换是卡顿的，起初跳动一下，之后才跳动成与odom差不多的数值。
此时认为是odom的更新不正确，在odom轮速的累加过程中，把轮速取相反数，发现可以解决这个问题，但是这是不正常的，轮速是正确的。
//计算odom
//vx_ 是未处理前的x方向速度
//v
订阅专栏 解锁全文
扫一扫
1278
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
