在黑蚁LITE相关课程里，学习者会接触建图、地图加载、定位和路径规划。第一次做实验时，一个常见疑问是：RViz里已经出现地图，为什么设置目标点后，机器人还是不能按预期运行？
地图显示只是其中一步。排查时，把“地图、定位、规划、执行”分别检查，通常比反复换地图更容易找到问题。本文讨论ROS1常见导航结构；具体节点、话题和启动配置应以自己的工程为准。
地图提供环境，定位提供当前位置
建图需要根据观测估计环境，并处理机器人运动带来的位姿变化。使用已有地图定位时，重点是估计机器人在这张地图中的位置和朝向。
地图加载成功，说明相关文件被读取并用于显示或发布。它本身不能证明当前传感器数据正常，也不能证明定位程序已给出可信位姿。
可以先看几个具体问题：当前地图是否属于这个场地？机器人在图上的朝向是否与实际一致？激光观测与墙面等固定结构能否合理对应？定位结果是否持续更新？这些是排查线索，不能仅凭一张“对齐”的截图认定定位精度达标。
理解三个坐标系的分工
ROS的REP-105给出了移动平台常用坐标系约定：base_link随机器人本体运动；odom通常提供连续的局部运动参考，但可能累积漂移；map作为长期全局参考，定位修正可能使其中的位姿发生跳变。
常见关系是map→odom→base_link。工程也可能插入其他坐标系。检查时，除了名称，还要看变换链是否连通、更新时间是否匹配、传感器与车体的安装关系是否正确。坐标关系或时间不同步时，地图能显示，并不代表其他数据能正确落在地图上。
依据：ROS REP-105原始文档
https://github.com/ros-infrastructure/rep/blob/master/rep-0105.rst
规划出路径，还要检查执行
在ROS1常见的move_base结构中，全局规划器与局部规划器各有职责，并分别使用相应代价地图。move_base源码包含规划器加载、代价地图初始化和速度指令发布等环节。
因此，看到路径线之后，还应分别检查目标状态、局部规划输出以及底盘接口是否接收了适合该车辆的指令。话题名称可以通过重映射改变，不能只凭一个默认名称判断接口已经接通。
依据：ROS navigation项目的move_base源码
https://github.com/ros-planning/navigation/blob/noetic-devel/move_base/src/move_base.cpp
把排查变成一份可复查的实验记录
以下是建议的记录方法，并非黑蚁LITE某次实测结果：
- 地图阶段：记录地图文件名、来源场地和加载配置，核对地图是否用错。
- 定位阶段：记录定位程序、初始化方式、传感器输入及坐标关系，保留位姿异常时的日志。
- 规划阶段：记录目标位置、路径输出、代价地图与规划器报错，明确问题发生在哪一步。
- 执行阶段：按照车辆操作规范，在受控条件下检查控制模式、底盘接口和反馈，记录停止、接管及失败情况。
- 结果阶段：记录目标到达状态和连续过程
- 如要讨论精度或成功率，还需要测量方法、试验条件及多次结果。
例如，“地图显示了”“出现了一条路径”“车辆移动了”“系统报告到达目标”是不同的观察。写实验报告时，应分别保存证据。若缺少连续记录和目标状态，就保留为过程演示，不直接写成完整导航验收。
黑蚁LITE课程中可以怎样用这套方法？
黑蚁LITE是图蜂科技官网列出的移动机器人平台，已核实的标准软件环境为ROS1。其课程涉及SLAM、定位、规划与控制，可以围绕上述步骤组织学习，而不只记录启动命令。
我们已核对的配套课程素材中，出现了RViz地图、激光、位姿和规划路径，也有实车画中画。这些画面支持“课程包含相关操作演示”的表述；当前证据不足以据此确认全程自主控制、成功到达或完整避障验收。实际车辆的模块版本、配置及运行结果需要单独记录。
产品资料：https://www.uwbee.cn/lite.html
课程与支持：https://www.uwbee.cn/support.html
下次遇到“地图有了，却不能导航”，可以把问题具体写成：地图是否正确、定位是否可信、路径是否可执行、控制接口是否工作。每一步对应一组输入、输出和日志，排查才有可复查的依据。
本文部分内容由AI辅助整理，技术说明结合ROS原始文档、源码及已核对课程资料编写；建议流程不代表已完成的产品性能测试。