3、TF坐标变换：TF树原理、静态TF发布、robot_state_publisher配置、常见TF错误排查
说到机器人导航，TF（Transform）坐标变换是绕不开的核心。说白了，TF就是告诉机器人各个部件之间的位置关系——激光雷达装在哪儿、轮子在哪、底盘中心在哪。没有TF，机器人就是个“路痴”。
我刚开始做机器人时，觉得TF很简单，不就是几个坐标嘛。结果第一次跑导航，机器人原地转圈，死活不走直线。查了半天，发现是激光雷达的TF写错了10厘米。嗯，从那以后我再也不敢小看TF了。
3.1 TF树原理：机器人的“骨架”
TF树本质上是一个树状数据结构。每个节点代表一个坐标系（frame），边代表坐标系之间的变换关系（平移+旋转）。
举个例子，一个差速底盘机器人，典型的TF树长这样：
map → odom → base_footprint → base_link
├── laser_link
└── imu_link- map：世界坐标系，固定不变
- odom：里程计坐标系，由轮子编码器推算
- base_footprint：机器人在地面的投影点
- base_link：机器人本体中心
- laser_link：激光雷达安装位置
- imu_link：IMU安装位置
TF树必须是一棵树，不能有环。每个坐标系有且只有一个父坐标系。这是硬规则，违反了ROS会直接报错。
核心原则：TF树是单向的，从父坐标系到子坐标系。查询时只能从子找父，不能反向。
我个人习惯，在设计机器人URDF时，先把TF树画在纸上。这样能避免很多后期调试的麻烦。
3.2 静态TF发布：固定不变的变换
静态TF，顾名思义，就是坐标系之间的变换关系是固定的。比如激光雷达装在机器人前方10厘米、高度20厘米，这个值不会变。
ROS里发布静态TF有两种方式：
方式一：命令行发布（适合调试）
rosrun tf2_ros static_transform_publisher x y z yaw pitch roll frame_id child_frame_id举个例子：
rosrun tf2_ros static_transform_publisher 0.1 0 0.2 0 0 0 base_link laser_link这表示laser_link相对于base_link，在X方向偏移0.1米，Z方向偏移0.2米，无旋转。
我的习惯：调试阶段先用命令行发布，确认数值正确后再写进launch文件。这样改参数不用重新编译。
方式二：launch文件发布（适合正式部署）
<node pkg="tf2_ros" type="static_transform_publisher" name="laser_broadcaster" args="0.1 0 0.2 0 0 0 base_link laser_link" />注意，args的顺序是：x y z yaw pitch roll。yaw、pitch、roll的单位是弧度，不是角度。
常见坑：我曾经把角度单位搞错了，写了90度而不是1.57弧度。结果激光雷达的数据全歪了，导航路径直接飞到了墙上。查了半小时才发现。
3.3 robot_state_publisher配置：自动发布TF
如果你的机器人有URDF模型，那就不用手动发布每个关节的TF了。robot_state_publisher会自动读取URDF中的关节信息，发布对应的TF。
配置方式很简单：
<node pkg="robot_state_publisher" type="robot_state_publisher" name="robot_state_publisher">
<param name="robot_description" command="$(find xacro)/xacro $(find my_robot)/urdf/my_robot.urdf.xacro" />
</node>它会自动发布：
- 每个link对应的坐标系
- 每个joint对应的变换关系
- 固定关节（fixed joint）发布静态TF
- 运动关节（revolute/prismatic joint）发布动态TF
这里有个关键点：URDF中的joint必须定义正确。比如：
<joint name="laser_joint" type="fixed">
<parent link="base_link"/>
<child link="laser_link"/>
<origin xyz="0.1 0 0.2" rpy="0 0 0"/>
</joint>这样robot_state_publisher就会自动发布base_link到laser_link的静态TF。
建议：能用URDF+robot_state_publisher就别手动发TF。自动化的东西不容易出错。我见过太多手动发布TF导致参数不一致的案例了。
3.4 常见TF错误排查
TF出问题，导航基本就废了。下面是我这些年遇到最多的几种错误：
| 错误现象 | 可能原因 | 排查方法 |
|---|---|---|
| “No transform from [a] to [b]” | TF树不完整，缺少某个坐标系 | 用tf2_monitor查看TF树 |
| “Lookup would require extrapolation” | 时间戳不同步，TF过期 | 检查各节点的时间戳，确保使用ros::Time(0) |
| “Frame id [xxx] does not exist” | 坐标系名称拼写错误 | 用tf2_echo检查实际发布的frame_id |
| 机器人原地转圈 | base_link到laser_link的TF偏移错误 | 测量实际安装位置，核对URDF或静态TF参数 |
| 导航路径偏移 | map到odom的TF发布异常 | 检查AMCL或robot_localization的输出 |
排查工具推荐
- tf2_monitor：查看TF树结构，显示发布频率和延迟
- tf2_echo：查看两个坐标系之间的实时变换
- rviz：可视化TF树，直观看到坐标系位置
- view_frames：生成TF树的PDF图，适合离线分析
我的排查流程：先用tf2_monitor看整体结构，再用tf2_echo查具体变换，最后用rviz看实际效果。三步走，基本能定位90%的问题。
一个真实案例
有一次，客户说机器人导航时总是偏右30厘米。我远程连上去，先用tf2_echo查base_link到laser_link的变换，发现X方向偏移是0.3米。但客户说激光雷达装在机器人正前方，距离中心应该是0.1米。
问题找到了：URDF里写的是0.3，实际是0.1。改回0.1后，导航恢复正常。
教训：URDF参数必须和实际机械尺寸一致。差1厘米都不行，导航精度会直接受影响。
嗯，TF这部分内容比较多，但理解了原理，配置起来其实很快。记住一句话：TF树是机器人的骨架，骨架歪了，走的路肯定歪。