第1章 MoveIt与TF坐标系统概述
理解机器人学中的坐标变换，TF树的概念，以及MoveIt如何依赖TF进行运动规划。
说实话，我刚接触机器人运动规划那会儿，最头疼的就是坐标系。明明每个零件都画好了，一到仿真里机械臂就飞到天上去。后来才明白——TF坐标变换才是整个系统的骨架。没有它，MoveIt根本不知道你的机器人长什么样、手在哪儿、目标在哪儿。
1.1 为什么机器人需要坐标变换？
你想想看，一个六轴机械臂，每个关节都有自己的旋转中心。激光雷达装在基座上，相机挂在手腕上。每个传感器、每个连杆都在不同的坐标系里说话。如果不把它们的位姿统一起来，规划出来的轨迹就是一堆废纸。
我个人习惯把TF理解成“翻译官”。它把base_link下的一个点，翻译成camera_link或者tool0下的坐标。这样，规划器才能算出“从A到B”的路径。
核心概念： 坐标变换就是描述两个坐标系之间的平移和旋转关系。在ROS2里，我们用
geometry_msgs/TransformStamped消息来传递这个关系。
1.2 TF树——机器人的“家谱”
TF树本质上是一个有向无环图。每个节点代表一个坐标系，边代表父子变换关系。比如：
world→odom→base_link→shoulder_link→ … →tool0- 每个变换都带时间戳，所以你能知道“0.1秒前相机看到的东西，对应现在机械臂的什么位置”。
我记得有一次调试AGV+机械臂，TF树里出现了两个base_link，结果规划器直接崩溃。排查了半天才发现是命名冲突。所以，TF树的根节点必须唯一，这是铁律。
▲ 典型的TF树结构：world为根，odom和map为中间节点，base_link下挂载传感器
1.3 MoveIt如何依赖TF？
MoveIt本质上是一个运动规划框架，但它自己并不维护坐标变换。它通过tf2库实时查询机器人当前的状态。比如：
- 加载URDF/SRDF时：MoveIt从参数服务器读取机器人模型，但每个link的位姿必须由TF提供。
- 运动规划时：规划器需要知道
start_state和goal_state。这些状态里的关节角度、末端位姿，全部依赖TF树来转换到公共参考系。 - 碰撞检测：场景中的障碍物（比如桌子、箱子）通常用
world坐标系描述。机械臂的每个连杆必须通过TF变换到world下，才能判断是否碰撞。
💡 我的经验： 如果你发现MoveIt规划出来的轨迹莫名其妙抖动，八成是TF时间戳不同步。我曾经在仿真里忘了发布
odom到base_link的变换，结果规划器一直用0.5秒前的位姿，机械臂像喝醉了酒。
1.4 关键组件一览
| 组件 | 作用 | 与TF的关系 |
|---|---|---|
| robot_state_publisher | 发布URDF中每个link的TF | 直接广播关节变换 |
| joint_state_publisher | 发布关节角度 | 驱动TF树更新 |
| move_group | MoveIt核心节点 | 订阅TF树，查询当前状态 |
| planning_scene | 规划场景（含障碍物） | 障碍物位姿依赖TF |
⚠️ 避坑指南： 千万不要在TF树里出现循环依赖！比如
base_link是shoulder_link的父级，同时shoulder_link又发布一个变换指向base_link。这会导致tf2缓存溢出，整个系统卡死。我曾经在调试双臂机器人时踩过这个坑，查了两天才找到原因。
1.5 一个小例子：查看TF树
在终端里运行：
ros2 run tf2_tools view_frames.py这个命令会生成一个frames.pdf，里面就是当前所有活跃的TF关系。我个人习惯在启动MoveIt之前先跑一下这个命令，确认树的结构对不对。尤其是当你用了static_transform_publisher时，很容易漏掉某个传感器。
说白了，TF就是MoveIt的“眼睛”和“尺子”。没有准确的TF，再好的规划算法也是白搭。