ROS2核心概念：节点、话题、服务、动作、参数与图
ROS2 的通信架构建立在六个核心概念之上：节点（Node）、话题（Topic）、服务（Service）、动作（Action）、参数（Parameter）与图（Graph）。理解这些概念及其相互关系，是进行机器人开发部署的第一步。它们共同构成了 ROS2 分布式通信的骨架，决定了系统中数据如何流动、任务如何被调用、状态如何被共享。
核心原理：六要素的分工与协作
ROS2 采用去中心化的节点架构。每个节点是一个独立的可执行进程，负责完成某一项具体功能，例如读取激光雷达数据、执行路径规划或控制电机转动。节点之间不直接调用对方代码，而是通过 ROS2 提供的通信机制交换数据。这种设计带来了模块化、语言无关和故障隔离三大优势。
- 节点（Node）：系统的最小计算单元。一个机器人系统通常由多个节点组成，每个节点负责一个明确的子任务。
- 话题（Topic）：用于连续、单向的数据流传输。发布者（Publisher）将消息广播到话题上，订阅者（Subscriber）接收消息。适合传感器数据、状态信息等高频数据。
- 服务（Service）：用于请求-应答的同步通信模式。客户端（Client）发送请求，服务端（Server）处理并返回响应。适合一次性任务调用，如“打开相机”“查询地图”等。
- 动作（Action）：用于长时间执行的任务，支持实时反馈和取消操作。动作由目标（Goal）、反馈（Feedback）和结果（Result）三部分组成，适合导航、机械臂运动等耗时任务。
- 参数（Parameter）：节点的配置项，以键值对形式存储。可在节点启动时设置，也可在运行时动态修改，用于调整算法阈值、设备配置等。
- 图（Graph）：描述所有节点、话题、服务、动作等实体及其连接关系的全局网络视图。通过
rqt_graph可以直观看到系统的运行拓扑。
核心要点：话题是“广播”，服务是“问答”，动作是“可中断的长任务”。选择哪种通信方式，取决于数据流的性质——是持续推送、一次性请求，还是需要反馈的长期任务。
方法流程：从创建节点到建立通信
在实际开发中，遵循以下流程可以快速搭建一个基于 ROS2 的通信系统。以 Python 为例，创建一个发布激光雷达模拟数据的节点，并让导航节点订阅该数据。
- 初始化节点：使用
rclpy.init()初始化客户端库，然后创建节点实例。 - 创建发布者或订阅者：指定话题名称、消息类型和队列长度。
- 编写回调函数：订阅者收到消息后自动触发回调；发布者按固定频率发送消息。
- 启动节点：通过
rclpy.spin()让节点保持运行，持续处理通信事件。 - 使用命令行工具验证：通过
ros2 node list、ros2 topic list等命令检查节点和话题是否正常。
# 发布者节点示例（publisher.py）
import rclpy
from rclpy.node import Node
from sensor_msgs.msg import LaserScan
class ScanPublisher(Node):
def __init__(self):
super().__init__('scan_publisher')
self.publisher = self.create_publisher(LaserScan, '/scan', 10)
self.timer = self.create_timer(0.1, self.publish_scan)
def publish_scan(self):
msg = LaserScan()
msg.angle_min = 0.0
msg.angle_max = 6.28
msg.range_max = 10.0
msg.ranges = [5.0] * 360 # 模拟数据
self.publisher.publish(msg)
self.get_logger().info('Publishing scan data')
def main(args=None):
rclpy.init(args=args)
node = ScanPublisher()
rclpy.spin(node)
node.destroy_node()
rclpy.shutdown()案例场景：多节点协作的机器人导航系统
考虑一个典型的室内导航任务。系统由四个节点组成：激光雷达驱动节点、SLAM建图节点、路径规划节点和底盘控制节点。它们之间的通信关系如下表所示：
| 通信类型 | 话题/服务/动作名称 | 消息类型 | 发送方 → 接收方 | 触发频率 |
|---|---|---|---|---|
| 话题 | /scan |
sensor_msgs/LaserScan |
雷达驱动 → SLAM / 规划 | 10 Hz |
| 话题 | /odom |
nav_msgs/Odometry |
底盘控制 → SLAM / 规划 | 50 Hz |
| 服务 | /save_map |
std_srvs/Trigger |
用户 → SLAM | 手动触发 |
| 动作 | /navigate_to_pose |
nav2_msgs/NavigateToPose |
规划 → 底盘控制 | 按需执行 |
| 参数 | /navigation/max_vel |
double |
配置 → 规划节点 | 启动时加载 |
在这个系统中，话题负责高频传感器数据的持续流转，服务用于用户手动触发的地图保存操作，动作则承担了需要实时反馈的导航任务——当机器人执行导航时，规划节点不断向底盘控制节点发送速度指令，同时底盘控制节点通过动作反馈机制报告当前执行进度。参数服务器则保存了机器人的最大速度、加速度等配置，方便在不同场景下动态调整。
误区与复盘：常见概念混淆与设计陷阱
常见误区一：将话题当作远程过程调用（RPC）使用。话题是单向数据流，发布者不关心谁在接收，也不等待接收者的处理结果。如果需要在调用后立即获得返回值，应使用服务而非话题。
常见误区二：动作与服务混为一谈。服务适合秒级完成的短任务，一旦请求发出，客户端必须阻塞等待响应。而动作适合分钟级的长任务，客户端可以继续执行其他逻辑，并通过回调接收反馈。若用服务实现导航，客户端将无法取消任务或获取中间进度。
另一个常见设计问题是话题消息类型选择不当。例如，传输图像数据时使用 sensor_msgs/Image 而非压缩后的 sensor_msgs/CompressedImage，会导致带宽占用过高。在部署到物理机器人前，应通过 ros2 topic hz 和 ros2 topic bw 检查话题的发布频率和带宽消耗，确保通信负载在系统承受范围内。
最后，在调试多节点系统时，善用 rqt_graph 可视化工具可以快速发现节点间连接是否正常。如果某个话题没有订阅者，rqt_graph 中会显示该话题只有一个发布端，此时应检查订阅者节点是否成功启动、话题名称是否拼写一致。通过这种可视化复盘，可以显著减少因命名不一致或节点崩溃导致的通信故障排查时间。