第3章 TF消息与通信机制

聊到 TF，很多人第一反应是 lookupTransform 或者 broadcast。但说实话，真正让 TF 在分布式系统里跑起来的，是它背后那套消息与通信机制。这一章我就带你拆开看看——TF 消息到底长什么样？怎么发、怎么收？缓存又是怎么玩的？

3.1 TFMessage —— 藏在话题背后的消息结构

TF 的通信层其实特别简单。它没有搞什么自定义协议，直接复用 ROS 的标准话题机制。广播器往 /tf 话题上发消息，监听器从同一个话题收消息。消息类型就是 tf2_msgs/TFMessage。

我最初看这个结构时觉得有点绕——为什么叫 TFMessage 而不是直接叫 Transform？后来在项目里调试多机器人系统时才明白：一条 TFMessage 里可以塞多个 TransformStamped，批量发布效率更高。你想想看，如果每个坐标变换都单独发一条消息，网络开销得多大。

消息定义（精简版）：

# tf2_msgs/TFMessage.msg
geometry_msgs/TransformStamped[] transforms

而 TransformStamped 又包含：

header —— 时间戳、帧 ID（child_frame_id 在下一层）
child_frame_id —— 子坐标系名称
transform —— 平移 (Vector3) + 旋转 (Quaternion)

说白了，整个 TF 通信就是围绕着 TransformStamped 数组打转。广播器把当前时刻所有已知的变换打包，一股脑发出去。监听器收到后，再一条条塞进缓存。

3.2 发布与订阅 TF —— 谁在说话，谁在听？

在 ROS 里，发布 TF 和订阅 TF 的代码模式跟普通话题一模一样。我习惯用 tf2_ros::TransformBroadcaster 来发，用 tf2_ros::Buffer + TransformListener 来收。

发布端示例（C++）：

#include <tf2_ros/transform_broadcaster.h>

tf2_ros::TransformBroadcaster br;
geometry_msgs::TransformStamped t;

t.header.stamp = ros::Time::now();
t.header.frame_id = "odom";
t.child_frame_id = "base_link";
t.transform.translation.x = 1.0;
t.transform.translation.y = 0.0;
t.transform.translation.z = 0.0;
t.transform.rotation.w = 1.0;

br.sendTransform(t);

订阅端稍微绕一点。你不需要直接调用 subscribe，而是创建一个 tf2_ros::Buffer 对象，再给它配一个 TransformListener。监听器会在后台自动订阅 /tf 话题，并把数据喂给 Buffer。

订阅端示例（C++）：

#include <tf2_ros/buffer.h>
#include <tf2_ros/transform_listener.h>

tf2_ros::Buffer tfBuffer;
tf2_ros::TransformListener listener(tfBuffer);

// 之后就可以用 tfBuffer.lookupTransform() 查询了

这里有个细节我踩过坑：TransformListener 的构造函数会启动一个后台线程，持续接收消息。如果你在回调函数里阻塞太久，缓存更新就会延迟。嗯，所以别在 TF 回调里做重计算。

3.3 TF 缓存与查找 —— 时间旅行与坐标侦探

缓存是 TF 通信机制里最巧妙的部分。Buffer 默认保存最近 10 秒的所有变换数据。为什么是 10 秒？因为路径规划里经常需要查询历史位姿，比如做时间插值或者延迟补偿。

缓存参数	默认值	说明
缓存时长	10 秒	可通过 `setCacheLength()` 修改
最大存储条目	无硬限制	受内存约束，一般几千条没问题
查找超时	可配置	`lookupTransform` 可设置等待时间

查找变换时，最常用的就是 lookupTransform(target_frame, source_frame, time)。我个人习惯在路径规划的回调里这样写：

geometry_msgs::TransformStamped transformStamped;
try {
    transformStamped = tfBuffer.lookupTransform(
        "map", "base_link", ros::Time(0));
} catch (tf2::TransformException &ex) {
    ROS_WARN("TF 查找失败: %s", ex.what());
    return;
}

我曾经踩过的坑： 用 ros::Time(0) 表示获取最新可用变换，但如果你在仿真里回放 bag，时间戳可能乱掉。那时候 ros::Time(0) 会拿到 bag 里的最新数据，而不是系统当前时间。建议在回放场景显式指定时间戳。

还有一个容易被忽略的点：缓存查找是线程安全的。Buffer 内部用了锁，所以你可以在多个线程里同时查询。但别频繁调用——每次 lookupTransform 都会做一次树搜索，复杂度 O(n)，n 是缓存中的变换数量。我见过有人每 5 毫秒查一次，直接把 CPU 吃满。

3.4 通信机制背后的设计哲学

TF 的通信机制其实遵循了一个很朴素的原则：发布者不知道谁在听，监听者不知道谁在发。这种松耦合让多机器人系统、分布式传感器融合变得异常灵活。你想想看，一个激光雷达节点只管广播自己的位姿，导航节点只管从缓存里查，谁也不依赖谁。

但松耦合也带来一个麻烦：数据延迟。如果广播频率是 100 Hz，监听器那边可能收到 10 ms 前的数据。路径规划里差这 10 ms，在高速移动的机器人上可能就是几厘米的误差。所以后来 TF2 引入了 lookupTransform 的高级用法——你可以指定一个目标时间，Buffer 会自动做线性插值。

小技巧： 如果你需要最高实时性，可以把广播频率提到 200 Hz 以上，同时把缓存时长缩短到 2 秒。这样内存占用小，查找也快。我在 AGV 项目里就是这么干的。

好了，这一章我们把 TF 的通信骨架摸清楚了。先消化这些基础，后面才飞得起来。