4 · 动态TF发布器

用 TransformBroadcaster 在节点中发布动态坐标变换，比如里程计与底盘的关系。说白了，就是让 TF 树里那些会随时间变化的坐标系“活”起来。

4.1 为什么需要动态发布？

机器人跑起来的时候，底盘相对于里程计的位置一直在变。你想想看，如果还用静态 TF，那轮子转了半天，地图上的位置还是原地踏步——这导航肯定炸。

我早期做AGV项目时就踩过这个坑。当时偷懒把 odom→base_link 设成固定值，结果小车一转弯，路径规划直接崩溃。嗯，从那以后我养成了习惯：凡是跟运动相关的坐标系变换，一律用动态发布。

4.2 TransformBroadcaster 怎么用？

在 C++ 里，你只需要包含 tf2_ros/transform_broadcaster.h，然后创建一个广播器对象。Python 也类似，用 TransformBroadcaster 就行。我个人习惯把广播器声明成节点类的成员变量，这样生命周期清晰。

            核心套路： 每次回调（比如里程计更新）里构造 geometry_msgs::TransformStamped，填上时间戳、父坐标系、子坐标系，然后调用 broadcaster->sendTransform()。
        

4.3 代码骨架（C++ 示例）

#include <ros/ros.h>
#include <tf2_ros/transform_broadcaster.h>
#include <geometry_msgs/TransformStamped.h>
#include <nav_msgs/Odometry.h>

class OdomTfPublisher {
public:
    OdomTfPublisher() : nh_("~") {
        // 初始化广播器
        tf_broadcaster_ = std::make_shared<tf2_ros::TransformBroadcaster>();
        // 订阅里程计话题
        odom_sub_ = nh_.subscribe("/odom", 10, &OdomTfPublisher::odomCallback, this);
    }

private:
    void odomCallback(const nav_msgs::Odometry::ConstPtr& msg) {
        geometry_msgs::TransformStamped transform;
        transform.header.stamp = msg->header.stamp;
        transform.header.frame_id = "odom";
        transform.child_frame_id = "base_link";

        // 从里程计消息中提取位置和姿态
        transform.transform.translation.x = msg->pose.pose.position.x;
        transform.transform.translation.y = msg->pose.pose.position.y;
        transform.transform.translation.z = 0.0;
        transform.transform.rotation = msg->pose.pose.orientation;

        // 发布动态变换
        tf_broadcaster_->sendTransform(transform);
    }

    ros::NodeHandle nh_;
    std::shared_ptr<tf2_ros::TransformBroadcaster> tf_broadcaster_;
    ros::Subscriber odom_sub_;
};

你看，代码其实很简洁。但有几个细节我得多说两句——

4.4 避坑指南 & 个人经验

时间戳必须用对。 我曾经直接用 ros::Time::now() 代替里程计的时间戳，结果 TF 树里时间错乱，EKF 输出直接飞掉。记住：用数据本身的 stamp，别自己拍脑袋。
发布频率别太低。 动态变换最好跟里程计更新频率一致，通常 50~100 Hz。如果低于 10 Hz，导航栈的 tf::MessageFilter 会疯狂报“extrapolation into the future”。
子坐标系别写错。 大小写敏感！base_link 和 Base_Link 是两个东西。我见过有人因为首字母大写，查了一下午的 TF 断链。

⚠️ 曾经有个血泪教训： 我在多机器人项目里，不小心把两个机器人的 odom 父坐标系都设成了同一个名字，结果 TF 树直接乱成一锅粥。动态发布时，务必保证父坐标系在全局唯一。

4.5 动态 vs 静态：一张表说清楚

特性	静态 TF 发布器	动态 TF 发布器
发布频率	一次或极低 (如 1 Hz)	随运动更新 (10~100 Hz)
典型场景	激光雷达与底盘的固定外参	里程计与底盘的位姿变化
数据源	URDF / 参数服务器	里程计话题 / 轮式编码器
时间戳敏感度	低	高，必须与传感器时间对齐
资源消耗	几乎为 0	中等，注意不要阻塞主循环

💡 我的小技巧： 调试动态 TF 时，开两个终端：一个 rostopic echo /odom，另一个 rosrun tf tf_echo odom base_link。两边对比看平移和旋转是否一致。如果对不上，八成是时间戳或坐标系名字的锅。

4.6 动态发布器的典型流程

订阅里程计或编码器数据。
在回调里构造 TransformStamped，填充位置、姿态、时间戳。
调用 sendTransform() 发布。
TF 树自动更新，监听器就能拿到最新的变换。

说白了，动态 TF 就是让坐标变换跟着传感器数据一起“呼吸”。你只要保证数据新鲜、名字正确，剩下的 ROS 底层会帮你搞定。

嗯，我记得第一次自己手写动态发布器时，还担心性能问题。后来用 ros::Rate 控制了一下，发现 CPU 占用几乎可以忽略。放心大胆地用吧。