2. 发布者与订阅者模式：ROS话题通信核心机制
好，咱们今天聊聊ROS里最核心的东西——话题通信。说白了，就是节点之间怎么“说话”。你想想看，一个机器人身上有几十个传感器、执行器，它们要是各干各的，那不乱套了？ROS用了一套发布者与订阅者的模式，把这事儿安排得明明白白。
2.1 什么是发布者与订阅者模式？
我习惯把这种模式叫做“广播站模式”。想象一下：
- 发布者（Publisher）：就像广播电台的主持人。他只管对着麦克风说话，不管谁在听。
- 订阅者（Subscriber）：就像收音机前的听众。他只要调到正确的频道，就能收到内容。
- 话题（Topic）：就是那个频道频率。比如“/camera/image”就是图像话题，“/cmd_vel”就是速度指令话题。
我在项目中遇到过最典型的场景：激光雷达节点发布点云数据，导航节点订阅它来做路径规划。雷达只管发，导航只管收，两者完全解耦。这就是ROS设计的精髓——节点之间不直接依赖，只通过话题交换数据。
核心要点：发布者不知道谁在订阅，订阅者也不知道谁在发布。他们只关心话题本身。
2.2 Publisher与Subscriber的角色
咱们把这两个角色拆开细说。
2.2.1 发布者（Publisher）
发布者的职责很简单：把数据“扔”到话题上。但这里有几个关键点：
- 消息类型必须固定：比如你发布的是图像，就不能突然改成点云。ROS靠消息类型来匹配发布者和订阅者。
- 发布频率可以控制：你可以10Hz、50Hz甚至100Hz地发。但频率太高，CPU和网络带宽会扛不住。
- 可以多个发布者：同一个话题可以有多个节点同时发布。比如两个摄像头都发布图像话题，订阅者会收到两路数据。
我的经验：我曾经在一个项目里，把IMU数据的发布频率设成了200Hz。结果CPU直接飙到80%，机器人走路都一卡一卡的。后来降到50Hz，一切正常。所以，发布频率不是越高越好，够用就行。
2.2.2 订阅者（Subscriber）
订阅者就是“等着收数据”的那一方。它需要做两件事：
- 注册回调函数：告诉ROS，“一旦有数据来了，就调用这个函数处理”。
- 处理数据：在回调函数里做你想做的事——比如显示图像、计算路径、控制电机。
这里有个容易踩的坑：回调函数里不要做耗时操作。比如你订阅了激光雷达数据，然后在回调里做复杂的路径规划，那下一帧数据来了，上一帧还没处理完，就会丢数据。
避坑指南：我曾经在回调函数里直接写了一个while循环等待电机响应，结果整个节点卡死了。后来才明白，回调函数应该“快进快出”，耗时操作要放到单独的线程里去做。
2.3 同步与异步通信的区别
这个话题，很多初学者容易搞混。我直接给你画个表：
| 对比项 | 同步通信 | 异步通信 |
|---|---|---|
| 核心特点 | 发送方等待接收方确认 | 发送方发完就走，不等待 |
| ROS中的体现 | 服务（Service）通信 | 话题（Topic）通信 |
| 实时性 | 高，但会阻塞 | 低，但不阻塞 |
| 适用场景 | 请求-响应模式（如：获取地图数据） | 流式数据（如：传感器数据、图像） |
| 数据可靠性 | 保证送达 | 不保证送达（可能丢包） |
说白了，话题通信是异步的。发布者把数据扔到话题上，然后扭头就走，不管有没有人收。订阅者呢，有空就来取一下，没空就等下一帧。这种模式的好处是：
- 不阻塞：发布者不会被订阅者的处理速度拖累。
- 灵活：可以随时增加或减少订阅者，不影响系统运行。
- 适合高频数据：比如摄像头30帧/秒的图像流，用同步通信根本跑不动。
但缺点也很明显：数据可能丢失。如果订阅者处理不过来，ROS会丢弃旧数据，只保留最新的。嗯，这里要注意——如果你需要保证每一帧数据都被处理，那就得用服务（Service）或者动作（Action）了。
一句话总结：话题通信是“发完就跑”的异步模式，适合传感器数据这种“丢了就丢了，下一帧马上来”的场景。如果你需要“你问我答”的可靠通信，请用服务。
2.4 一个简单的代码示例
光说不练假把式。咱们写个最简单的发布者和订阅者，用C++实现。
发布者代码（talker.cpp）
#include <ros/ros.h>
#include <std_msgs/String.h>
int main(int argc, char **argv)
{
// 初始化节点
ros::init(argc, argv, "talker");
ros::NodeHandle nh;
// 创建发布者，话题名为"chatter"，消息类型为String
ros::Publisher pub = nh.advertise<std_msgs::String>("chatter", 10);
ros::Rate rate(10); // 10Hz
int count = 0;
while (ros::ok())
{
std_msgs::String msg;
msg.data = "Hello ROS! Count: " + std::to_string(count++);
// 发布消息
pub.publish(msg);
// 打印日志
ROS_INFO("Published: %s", msg.data.c_str());
rate.sleep();
}
return 0;
}
订阅者代码（listener.cpp）
#include <ros/ros.h>
#include <std_msgs/String.h>
// 回调函数：当收到消息时被调用
void chatterCallback(const std_msgs::String::ConstPtr& msg)
{
ROS_INFO("I heard: [%s]", msg->data.c_str());
}
int main(int argc, char **argv)
{
ros::init(argc, argv, "listener");
ros::NodeHandle nh;
// 创建订阅者，订阅"chatter"话题，回调函数为chatterCallback
ros::Subscriber sub = nh.subscribe("chatter", 10, chatterCallback);
// 进入循环，等待回调
ros::spin();
return 0;
}
个人习惯：我写订阅者时，喜欢在回调函数里加一个时间戳判断。如果两帧数据间隔太久，就打印警告。这样能及时发现传感器掉线或者网络延迟的问题。
2.5 关于队列大小
你注意到代码里有个数字“10”吗？那是队列大小。它决定了：
- 发布者：如果发布频率高于订阅者处理速度，消息会积压在队列里。队列满了，旧消息就被丢弃。
- 订阅者：如果处理不过来，ROS会缓存最多10条消息。超过10条，最旧的消息就被扔掉。
我建议：队列大小不要设太大。10到100之间比较合理。设太大只会浪费内存，而且处理的是旧数据，意义不大。
避坑指南：我曾经把队列大小设成1000，以为这样能保证不丢数据。结果内存占用飙升，节点直接OOM（内存溢出）了。后来才明白，队列不是用来存历史数据的，它只是临时缓冲。
好了，关于发布者与订阅者模式，咱们就聊到这儿。记住一句话：发布者只管发，订阅者只管收，话题是桥梁，异步是灵魂。下一节咱们会深入聊消息类型和自定义消息，到时候你会更清楚ROS的数据是怎么流动的。