规划与执行是两条需要衔接的链路
在 RViz 中看到一条漂亮轨迹，并不意味着真实机械臂已经具备执行条件。规划端主要回答是否存在满足模型与约束的路径，执行端还需要控制器接收带时间的关节轨迹，并获得正确的硬件状态反馈。把“规划失败”和“规划成功但不执行”分开，能够明显缩小排查范围。
建议先把链路写成：机器人模型与当前状态—规划场景—目标与约束—轨迹—控制器接口—硬件反馈。日志中的报错应落到具体一段，而不是统称为 MoveIt 没配好。第一次接入时，应先在对应的演示或仿真配置中确认流程，再逐步替换硬件接口。
规划场景里应包含实际要避开的东西
PlanningScene 是 MoveIt 进行碰撞与约束检查的重要接口；官方教程推荐用 PlanningSceneMonitor 维护来自机器人状态和传感器的信息。自碰撞、环境碰撞与约束检查并非同一个问题。桌面、料盒或夹持物没有进入场景，规划器就无法依据这些物体判断路径。来源：Planning Scene 教程。
以抓起零件后移动为例，夹持物的状态要与任务阶段一致：接近时它是环境中的物体，抓住后通常需要作为附着物随末端移动。仅在可视化里看到模型，不能证明它已经进入规划器使用的碰撞场景。应核对对象名称、坐标系及场景更新是否被接收。
当前状态不正确，后面的判断也会失真
| 检查项 | 需要确认的内容 | 典型后果 |
|---|---|---|
| 关节名称与顺序 | 模型、状态消息与控制器一致 | 轨迹发给错误关节或被拒绝 |
| 状态时间戳 | 反馈持续更新，时钟基准一致 | 当前状态被判定过旧 |
| 机器人基座与工具 | 目标位姿使用正确参考系 | 目标不可达或末端方向错误 |
| 关节边界 | 位置、速度与硬件限制相符 | 规划、校验或执行阶段失败 |
不要用放宽全部容差来掩盖状态错误。若当前关节值与真实姿态明显不符，应先修复反馈或单位转换，再重新规划。否则规划路径可能只对一个不存在的起始状态成立。
确认轨迹实际发给哪个控制器
MoveIt 控制器配置要描述受控关节、控制器名称与接口类型；常见执行链路使用 FollowJointTrajectory action。MoveIt 侧知道控制器存在，与控制器已经由 ros2_control 或其他系统正确启动，是不同条件。接口的 namespace、关节集合及 action 名称都要对齐。来源：Low Level Controllers。
先检查控制器是否运行并提供预期 action，再查看执行请求是否到达、是否被接受、最终返回什么状态。如果根本没有收到请求，应排查 MoveIt 的映射；如果收到后拒绝，则继续查看关节不匹配、起始偏差、时间参数或硬件状态。不要只根据机器人“没动”就认定是规划器的问题。
用逐层验证代替一次改很多配置
- 核对模型与反馈状态，在可视化中确认姿态和实际一致。
- 在仿真或演示系统中执行简单轨迹，验证规划到控制器的接口。
- 接入目标设备的状态与控制接口，逐项确认名称、单位和时间。
- 加入桌面、料盒和附着物，再验证完整任务的规划场景。
每一步保存配置和日志，尤其保留控制器的请求与结果。若使用不同 ROS 发行版或 MoveIt 发布版，先对照对应文档，避免混用 Rolling 示例与旧版插件名称。本文给出的是排错顺序，不是一段可以直接驱动任意机械臂的通用命令。
验收不仅看有没有运动
一次有效验收应能说明：轨迹从哪个状态开始、哪些碰撞物参与检查、指令由哪个控制器执行、反馈是否持续更新、任务为什么结束。对于搬运类任务，还应回看抓取后物体状态是否同步到规划场景。把这些证据留下，下一次换工具或工位时，才能判断原有假设哪些仍然成立。
资料来源与延伸阅读
整理更新：2026-10-26。本文基于以上公开资料，经 AI 辅助整理与扩写；实践方案为编辑建议，未作为本站实测结果发布。工具接口请结合所用版本核对。