第三章 话题通信深入：自定义消息接口、QoS配置与多话题同步
各位同学，今天我们聊点真正干活儿的东西。话题通信是ROS2的命脉，但很多人用了很久还停留在“发个Int32、收个String”的阶段。说实话，那只是皮毛。真正上了自动驾驶的车，你会发现——消息怎么定义、怎么保证不丢、怎么对齐时间戳，这些才是决定系统能不能跑起来的关键。
3.1 自定义消息接口（.msg）——别再用标准消息凑合了
我见过太多人，明明要传一个带时间戳的障碍物列表，硬是用std_msgs::Float32MultiArray拼凑。结果呢？代码可读性极差，调试时根本不知道第几个元素代表什么。我的建议是：只要数据超过3个字段，就定义自己的.msg文件。
3.1.1 定义.msg文件
在功能包下创建msg/目录，新建Obstacle.msg：
# 障碍物消息定义
uint32 obstacle_id
string classification # 分类：car, pedestrian, cyclist
float32 x # 横向距离 (m)
float32 y # 纵向距离 (m)
float32 velocity # 速度 (m/s)
float32 yaw_angle # 朝向角 (rad)
builtin_interfaces/Time timestamp # 感知时间戳
uint8 confidence # 置信度 0-100
嗯，这里要注意：builtin_interfaces/Time是ROS2内置的时间类型，比你自己传秒和纳秒两个字段要规范得多。
3.1.2 编译配置
在CMakeLists.txt中添加：
rosidl_generate_interfaces(${PROJECT_NAME}
"msg/Obstacle.msg"
DEPENDENCIES builtin_interfaces
)
在package.xml中添加：
<build_depend>rosidl_default_generators</build_depend>
<exec_depend>rosidl_default_runtime</exec_depend>
<member_of_group>rosidl_interface_packages</member_of_group>
uint8 version字段。为什么？因为消息结构可能会升级，有了版本号，接收方可以兼容处理旧版本数据。这个习惯帮我避免过一次线上事故。
3.2 话题QoS配置——别让你的数据在路上丢了
QoS（Quality of Service）说白了就是ROS2的“快递服务等级”。你想想看，控制指令丢了车会撞，但激光雷达丢几帧点云问题不大。所以不同话题要用不同的QoS策略。
3.2.1 核心QoS参数
| 参数 | 选项 | 适用场景 |
|---|---|---|
| History | KEEP_LAST / KEEP_ALL | KEEP_LAST适合大多数场景，KEEP_ALL慎用（内存爆炸） |
| Depth | 整数（如10, 100） | 控制话题建议depth=1，感知话题depth=10~50 |
| Reliability | RELIABLE / BEST_EFFORT | 控制指令用RELIABLE，传感器数据用BEST_EFFORT |
| Durability | TRANSIENT_LOCAL / VOLATILE | 地图、参数用TRANSIENT_LOCAL，晚加入的节点也能收到 |
3.2.2 代码示例：发布端配置
rclcpp::QoS qos(rclcpp::KeepLast(10));
qos.reliability(RMW_QOS_POLICY_RELIABILITY_RELIABLE);
qos.durability(RMW_QOS_POLICY_DURABILITY_VOLATILE);
auto publisher = this->create_publisher<Obstacle>("obstacle_topic", qos);
3.2.3 代码示例：订阅端配置
rclcpp::QoS qos_sub(rclcpp::KeepLast(10));
qos_sub.reliability(RMW_QOS_POLICY_RELIABILITY_BEST_EFFORT);
// 注意：发布端和订阅端的QoS必须兼容，否则会报错
auto subscription = this->create_subscription<Obstacle>(
"obstacle_topic", qos_sub,
[this](const Obstacle::SharedPtr msg) {
// 处理消息
});
3.3 多话题同步与时间戳管理——让数据“对齐”是门艺术
自动驾驶里，摄像头30Hz、激光雷达10Hz、毫米波雷达20Hz。这些数据到达的时间不一样，你怎么融合？答案就是——时间戳对齐。
3.3.1 使用TimeSynchronizer同步多话题
#include <message_filters/subscriber.h>
#include <message_filters/time_synchronizer.h>
#include <message_filters/sync_policies/approximate_time.h>
message_filters::Subscriber<sensor_msgs::msg::Image> img_sub(this, "/camera/image");
message_filters::Subscriber<sensor_msgs::msg::PointCloud2> pc_sub(this, "/lidar/points");
typedef message_filters::sync_policies::ApproximateTime<
sensor_msgs::msg::Image, sensor_msgs::msg::PointCloud2> MySyncPolicy;
message_filters::Synchronizer<MySyncPolicy> sync(MySyncPolicy(10), img_sub, pc_sub);
sync.registerCallback(std::bind(&MyClass::callback, this, _1, _2));
这里有两个策略：ExactTime要求时间戳完全一致（几乎不可能），ApproximateTime允许一定的时间偏差（默认0.1秒）。我个人推荐用ApproximateTime，因为实际系统中时间戳很难完全对齐。
3.3.2 时间戳管理最佳实践
- 统一时基：所有传感器的时间戳必须使用同一个时钟源（比如GPS的PPS信号）
- 记录原始时间：不要对时间戳做任何滤波或平滑处理，保留传感器原始时间
- 使用
rclcpp::Time：ROS2的Time类支持加减运算，方便计算时间差
// 计算两个消息的时间差
rclcpp::Time t1(msg1->timestamp);
rclcpp::Time t2(msg2->timestamp);
rclcpp::Duration diff = t2 - t1;
RCLCPP_INFO(this->get_logger(), "时间差: %.2f ms", diff.seconds() * 1000);
3.4 话题监控与调试工具——别等出问题了再查
我见过太多团队，系统跑崩了才想起来看话题。其实ROS2提供了非常强大的调试工具，关键是你得会用。
3.4.1 命令行工具
| 命令 | 作用 | 我的使用频率 |
|---|---|---|
ros2 topic list |
列出所有话题 | 每天用无数次 |
ros2 topic echo /topic_name |
实时打印话题数据 | 调试时必用 |
ros2 topic hz /topic_name |
查看话题发布频率 | 检查传感器是否掉帧 |
ros2 topic bw /topic_name |
查看话题带宽 | 排查网络瓶颈 |
ros2 topic delay /topic_name |
查看端到端延迟 | 评估系统实时性 |
3.4.2 rqt_graph可视化
运行rqt_graph，你能看到所有节点和话题的连接关系。我习惯在系统启动后先看一眼这个图，确认所有连接都正确。有一次我发现某个节点没有连上，就是因为话题名称拼写错误——这种低级错误，用rqt_graph一眼就能看出来。
3.4.3 使用ros2 bag记录与回放
# 记录所有话题
ros2 bag record -a -o my_bag
# 记录指定话题
ros2 bag record /camera/image /lidar/points /control/cmd
# 回放数据
ros2 bag play my_bag
1. 先用
ros2 topic list确认话题存在2. 用
ros2 topic hz检查频率是否正常3. 用
rqt_graph检查连接拓扑这三步能解决80%的通信问题。
3.5 本章知识体系
下面这张图总结了本章的核心内容，我建议你保存下来，写代码时对照着看：
好了，这一章的内容就到这里。自定义消息让你不再凑合，QoS配置让你的数据安全到达，多话题同步让传感器数据对齐，调试工具让你快速定位问题。这四个能力，是每个自动驾驶系统工程师的必修课。
可可精品资料库