Turtlebot3 Burger实机运行自定义gmapping包时RVIZ中机器人不移动如何解决

故障原因 #

该问题核心是实机与上位机运行环境的差异导致的时间、数据帧不匹配，仿真环境所有节点共用一套时间所以不会触发故障，官方标准包适配了实机运行规则所以运行正常，具体故障点如下：

1. 上位机和Turtlebot3实机的机载控制器未做时间同步，跨设备的时间差导致gmapping接收到的激光数据、里程计数据时间戳不匹配，无法解算位姿，也就不会发布map到odom的tf变换，RVIZ中机器人自然不会移动
2. 自定义ann3_publisher节点发布的/scan_new3话题header配置错误，要么frame_id不是tf树中激光对应的坐标系，要么时间戳未和实机时间同步
3. 自定义launch中引入的turtlebot3_remote.launch配置与实机运行场景冲突，没有正常获取实机发布的/odom里程计数据，gmapping缺少核心输入无法更新位姿

解决方案 #

• 先完成跨设备时间同步：在上位机和实机端都安装chrony同步工具 sudo apt install chrony，配置上位机为时间服务器，实机同步上位机时间，分别在两台设备执行date命令验证，时间误差控制在10ms以内
• 验证自定义激光话题配置：执行rostopic echo /scan_new3/header，确认frame_id为base_scan（和你tf树中激光传感器的坐标系一致），同时时间戳和本地执行date +%s.%N的结果误差不超过100ms
• 检查里程计数据接收状态：实机启动基础bringup节点后，在上位机执行rostopic hz /odom，确认话题发布频率稳定在30Hz左右无丢包；如果无数据，删除自定义launch中引入的turtlebot3_remote.launch代码段，避免和实机本地运行的bringup节点冲突
• 验证gmapping节点订阅状态：执行rosnode info /turtlebot3_slam_gmapping，确认节点同时订阅了/scan_new3和/odom两个话题，没有订阅异常

内容的提问来源于stack exchange，提问作者AmirulJ