第3章 · TF广播与监听机制

tf2_broadcaster 与 tf2_listener 的工作原理，发布频率对性能的影响。

说实话，TF 广播和监听是 ROS2 导航里最基础、也最容易出幺蛾子的环节。很多人觉得不就是发个坐标嘛，频率设高点总没错——结果系统直接卡成幻灯片。这一章我就把 tf2_broadcaster 和 tf2_listener 的底牌翻出来，结合我踩过的坑，聊聊发布频率到底怎么影响性能。

3.1 tf2_broadcaster 是怎么工作的？

说白了，广播器就是把一个坐标系相对于另一个坐标系的变换（位置+姿态）打包成 TransformStamped 消息，然后往 /tf 话题上怼。你想想看，每个广播器内部其实维护了一个发布器，调用 sendTransform() 时，消息会带上时间戳和父/子坐标系名称。

我个人习惯把静态变换（比如激光雷达到基座）用 StaticTransformBroadcaster，只发一次；动态变换（比如里程计到基座）才用普通广播器。为什么？因为静态变换如果也用高频广播，纯粹浪费带宽。我在项目里见过有人把机器人底盘到激光雷达的变换以 100Hz 往外发……其实那个变换根本不变。

核心代码片段（C++）：

// 广播器示例
tf2_ros::TransformBroadcaster br;
geometry_msgs::msg::TransformStamped t;
t.header.stamp = now;
t.header.frame_id = "odom";
t.child_frame_id = "base_link";
t.transform.translation.x = 0.1;
t.transform.rotation.w = 1.0;
br.sendTransform(t);

3.2 tf2_listener 的监听与缓存

监听器做的事情正好相反——它订阅 /tf 话题，把收到的所有变换塞进一个缓存（Buffer）。这个缓存默认能存 10 秒的数据。当你调用 lookupTransform() 时，它会在缓存里找对应时间戳的变换，然后插值或者直接返回。

嗯，这里要注意：监听器不会主动“拉”数据，它完全靠广播器往里推。如果广播频率太低，或者网络有延迟，缓存里可能查不到你要的时间点。我曾经调试一个 AGV 小车，发现路径规划总是跳变，最后查出来是监听器缓存里缺了最近 200ms 的变换——因为广播器被某个阻塞任务拖慢了。

💡 个人经验： 监听器的 Buffer 大小虽然可以调，但我建议不要超过 15 秒。缓存太大不仅占内存，而且查询旧数据的概率极低，反而拖慢 lookupTransform 的查找速度。

3.3 发布频率——甜蜜点与陷阱

发布频率直接决定了 CPU 开销、网络负载以及下游数据的时效性。我整理了一张表，方便你对照自己的场景：

频率范围	典型场景	CPU 开销	定位精度影响
10 ~ 20 Hz	静态变换、低频里程计	极低	可能出现明显延迟
50 ~ 100 Hz	轮式里程计、IMU 融合	中等	平滑，多数导航够用
200 ~ 500 Hz	高速机器人、高精度插补	高	边际收益递减，容易丢帧
> 500 Hz	几乎不用（除非仿真）	极高	缓存频繁覆盖，得不偿失

你想想看，如果广播频率是 1000Hz，相当于每毫秒发一条消息。ROS2 的 DDS 底层要做序列化、传输、反序列化，CPU 很快就跑满了。而且监听器的缓存会不断被新数据冲刷，旧数据还没来得及查就被覆盖了。

⚠️ 避坑指南： 我曾经把一个差速机器人的里程计 TF 广播设到了 400Hz，结果机器人原地打转时 CPU 占用率直接飙到 85%，导航节点频繁超时。后来降到 80Hz，一切恢复正常。记住：不是越高越好，够用就行。

3.4 频率调优的实用建议

区分动静变换： 静态外参用 StaticTransformBroadcaster，只发一次。动态变换（如 odom→base_link）根据运动速度调整，一般 50~100Hz 足够。
监听端设置合理的缓存时间： 导航场景建议 5~10 秒。如果经常查询历史变换，可以适当增大，但别超过 15 秒。
用 tf2_monitor 工具查看实际发布频率： 我习惯在调参时开一个终端跑 tf2_monitor，看看有没有异常抖动。
注意时间戳一致性： 广播时 header.stamp 最好用 now()，不要用过去的时钟。监听端如果发现时间戳跳跃，会触发插值异常。

其实调频率这件事，没有银弹。我一般会先跑一个默认值（比如 100Hz），然后用 ros2 topic hz /tf 看实际发布频率，再结合 CPU 占用和定位延迟做微调。记住，你的机器人运动速度、传感器更新率、控制周期都会影响这个“甜蜜点”。