3、话题通信基础：ROS2话题机制、发布者与订阅者、使用命令行工具查看话题
聊到机器人仿真，绕不开的一个核心概念就是「话题通信」。说白了，ROS2里各个节点之间怎么聊天？就是靠话题。我刚开始接触ROS时，总觉得这玩意儿有点抽象，后来在Gazebo里调一个激光雷达数据，折腾了半天才发现是话题没对上。嗯，从那以后，我对话题机制就格外上心了。
3.1 话题机制：发布-订阅模式
ROS2的话题通信，本质上是一种发布-订阅模式。你可以把它想象成一个电台广播：
- 发布者（Publisher）：就是电台主持人，只管往外发消息，不管谁在听。
- 订阅者（Subscriber）：就是听众，只接收自己感兴趣频道的消息。
- 话题（Topic）：就是频道名称，比如“/cmd_vel”、“/odom”。
这种设计的好处很明显——解耦。发布者和订阅者互不知道对方的存在，它们只关心话题本身。我在项目中遇到过好几次这样的情况：想换掉某个传感器节点，只要它发布的话题名和消息类型不变，其他节点完全不用改代码。这就是话题通信的魅力。
核心要点：ROS2的话题通信是异步的、多对多的。一个话题可以有多个发布者，也可以有多个订阅者。消息一旦发布，所有订阅者都会收到。
为什么会这样设计？你想想看，机器人系统里传感器数据、控制指令、状态信息，这些数据流都是持续不断的。如果用请求-响应模式（比如服务），那CPU得忙死。话题通信这种「发完就不管」的方式，天然适合高频数据流。
3.2 发布者与订阅者：代码实战
光说不练假把式。咱们直接上手写一个最简单的发布者和订阅者。我用的是Python，因为调试起来方便，在Gazebo仿真里也够用。
3.2.1 编写发布者节点
先创建一个发布者，每隔1秒发一次“Hello, Gazebo!”字符串。我个人习惯把节点名和话题名都定义成常量，方便后期维护。
# talker.py
import rclpy
from rclpy.node import Node
from std_msgs.msg import String
class Talker(Node):
def __init__(self):
super().__init__('talker_node')
self.publisher_ = self.create_publisher(String, 'chatter', 10)
self.timer = self.create_timer(1.0, self.timer_callback)
self.get_logger().info('发布者节点已启动！')
def timer_callback(self):
msg = String()
msg.data = 'Hello, Gazebo!'
self.publisher_.publish(msg)
self.get_logger().info(f'发布: {msg.data}')
def main(args=None):
rclpy.init(args=args)
node = Talker()
rclpy.spin(node)
node.destroy_node()
rclpy.shutdown()
if __name__ == '__main__':
main()
小提示：create_publisher的第一个参数是消息类型，第二个是话题名，第三个是队列长度。队列长度设10就够了，太大反而浪费内存。我在Gazebo里调激光雷达数据时，队列长度设了100，结果内存直接爆了——别学我。
3.2.2 编写订阅者节点
订阅者就更简单了，只需要注册一个回调函数，收到消息就打印出来。
# listener.py
import rclpy
from rclpy.node import Node
from std_msgs.msg import String
class Listener(Node):
def __init__(self):
super().__init__('listener_node')
self.subscription = self.create_subscription(
String, 'chatter', self.listener_callback, 10)
self.get_logger().info('订阅者节点已启动！')
def listener_callback(self, msg):
self.get_logger().info(f'收到: {msg.data}')
def main(args=None):
rclpy.init(args=args)
node = Listener()
rclpy.spin(node)
node.destroy_node()
rclpy.shutdown()
if __name__ == '__main__':
main()
运行的时候，先开一个终端启动发布者，再开另一个终端启动订阅者。你会看到订阅者终端里不断打印“收到: Hello, Gazebo!”。嗯，就是这么简单。
注意：ROS2的消息类型必须严格匹配。发布者用String，订阅者也必须用String。我曾经在项目里把消息类型写成了Int32，结果订阅者那边死活收不到数据，排查了半天才发现是类型不匹配。这种低级错误，犯一次就够了。
3.3 使用命令行工具查看话题
写代码只是第一步，真正调试的时候，命令行工具才是你的好帮手。ROS2提供了一整套CLI工具，我平时用得最多的就是下面这几个。
3.3.1 查看话题列表
想知道当前系统里有哪些话题在活跃？用这个命令：
ros2 topic list它会列出所有活跃的话题名。如果你还想看话题的消息类型，加个-t参数：
ros2 topic list -t输出大概长这样：
/chatter [std_msgs/msg/String]
/parameter_events [rcl_interfaces/msg/ParameterEvent]
/rosout [rcl_interfaces/msg/Log]
3.3.2 查看话题消息
想知道某个话题里到底在发什么数据？直接监听它：
ros2 topic echo /chatter这个命令会实时打印话题里的消息内容。我在Gazebo里调试机器人位置时，经常用ros2 topic echo /odom来查看里程计数据，非常直观。
3.3.3 查看话题信息
想了解某个话题的详细信息，比如消息类型、发布者数量、订阅者数量：
ros2 topic info /chatter输出示例：
Type: std_msgs/msg/String
Publisher count: 1
Subscription count: 1
3.3.4 查看消息频率
有时候你需要知道话题的发布频率，比如激光雷达是不是在正常转：
ros2 topic hz /chatter它会统计每秒收到的消息数量。如果频率突然掉下来，那八成是节点卡住了或者网络有问题。
3.3.5 手动发布消息
调试的时候，手动发一条消息到话题上，看看订阅者有没有反应，这招特别管用：
ros2 topic pub /chatter std_msgs/msg/String "{data: 'test'}"加个--once参数就只发一次，不加的话会持续发。我个人习惯先用--once试一下，确认没问题再持续发。
避坑指南：我曾经在调试一个导航堆栈时，发现机器人怎么都不动。用ros2 topic echo /cmd_vel一看，发现话题里根本没有数据。后来用ros2 topic pub手动发了一条速度指令，机器人动了。这才确定是上游节点没发数据，而不是执行器的问题。所以，先确认话题有没有数据，再往下查，这是调试的基本功。
3.4 话题通信的QoS设置
ROS2里有个东西叫QoS（服务质量），它决定了消息的可靠性、持久性等。简单说，就是发布者和订阅者之间得「商量好」怎么传数据。
| QoS策略 | 说明 | 适用场景 |
|---|---|---|
| Reliability | 可靠性：RELIABLE（保证送达）或 BEST_EFFORT（尽力而为） | 控制指令用RELIABLE，传感器数据用BEST_EFFORT |
| Durability | 持久性：TRANSIENT_LOCAL（保留最后一条）或 VOLATILE（不保留） | 地图数据用TRANSIENT_LOCAL，实时数据用VOLATILE |
| Depth | 队列深度：缓存多少条消息 | 一般设10，高频数据可以设大一点 |
你想想看，如果发布者用RELIABLE，订阅者用BEST_EFFORT，那它们就匹配不上，话题通信会失败。所以，写代码时一定要确保两边的QoS设置一致。我在Gazebo里遇到过好几次这种问题，最后都是用ros2 topic info查出来的。
个人经验：在Gazebo仿真里，传感器数据（比如激光雷达、IMU）我一般用BEST_EFFORT，因为丢几帧数据不影响大局。但控制指令（比如/cmd_vel）必须用RELIABLE，丢一条指令机器人可能就撞墙了。这个取舍，你得根据实际场景来定。
好了，话题通信的基础就这些。发布者、订阅者、命令行工具，这三样东西你玩熟了，ROS2的调试就入门了。下一节咱们会深入Gazebo仿真环境，看看怎么把话题通信和仿真模型结合起来。嗯，到时候再聊。
可可精品资料库