5.1 ROS：节点、话题与系统拼装

5.1 ROS：节点、话题与系统拼装

本节摘要：ROS 不是操作系统，是一套"机器人软件的接口公约"：模块即节点，数据流即话题，请求即服务与动作。本节讲清四件套的分工与选型标准，给出一个最小发布-订阅节点，并交代 ROS1 到 ROS2 变了什么、没变什么。

行话开路：「节点」与「话题」

「节点」（Node）是 ROS 对"一个进程"的称呼，话题（Topic）是节点间单向数据流的名字。这个设计的聪明处在于解耦命名与依赖：定位模块只管往话题叫 map_odom 的管道里发位姿，它不需要知道谁在听——今天听的是路径规划器，明天换成日志记录器，后天换成远程监控，定位模块一行代码不改。整个系统像一张"命名了的数据流网络"，调试时每条流都能单独旁听、录制、回放，这是机器人软件工程几十年来最重要的公共资产。

四件套的分工与选型标准：

判断标准其实就一条：看时间语义。连续产生、过期作废的用话题（旧的位姿没必要补发）；要明确回执的用服务；持续几秒以上、需要中途反馈与取消的用动作。用错机制的报应很具体：把导航目标发成话题，发丢了没有回执，机器人站着不动而系统以为已下达。

图：导航系统的节点-话题拓扑

一个最小节点：发布与订阅

ROS2 的 Python 接口写一个速度平滑器（订阅 cmd_vel 原始指令，限幅后转发），十行量级：

import rclpy
from rclpy.node import Node
from geometry_msgs.msg import Twist

class VelocityLimiter(Node):
    def __init__(self):
        super().__init__('velocity_limiter')
        self.declare_parameter('v_max', 0.5)          # 参数可外部覆写
        self.sub = self.create_subscription(
            Twist, 'cmd_vel_raw', self.on_cmd, 10)     # 订阅原始指令
        self.pub = self.create_publisher(Twist, 'cmd_vel', 10)
        self.timer = self.create_timer(0.02, self.tick) # 50 Hz 发送
        self.latest = None

    def on_cmd(self, msg):            # 回调：只存最新值，不阻塞
        self.latest = msg

    def tick(self):
        if self.latest is None:
            return
        v_max = self.get_parameter('v_max').value
        out = self.latest
        out.linear.x = max(-v_max, min(v_max, out.linear.x))
        self.pub.publish(out)          # 发布限幅后的指令

def main(args=None):
    rclpy.init(args=args)
    rclpy.spin(VelocityLimiter())
    rclpy.shutdown()
​

值得读的是回调的结构：订阅回调只存数据不做重活，计算放在定时器里——回调里阻塞是节点卡死的第一大原因。参数在启动时可被覆写（同一节点无需改代码就能适配不同底盘），这是"配置与代码分离"的接口化。

ROS1 到 ROS2：变了什么

ROS1 的中心化 Master 与自研传输协议，在多机、实时、安全上碰了壁。ROS2 换成 DDS 数据分发中间件：无中心（节点互相发现）、支持服务质量策略（可靠传输或尽速传输按话题选择）、实时执行器模型。没变的是思想：节点、话题、解耦、参数化——学的是公约而不是版本。工程上还有一个不变的红线：话题频率与时间戳是集成的命脉，第 5.5 节的复盘里一半故障与它们有关。

⚠️ 常见坑：点云、图像这类大消息默认按"尽速传输"发送，丢帧无告警。定位与安全相关的话题要显式配可靠传输 + 合理队列深度，否则偶发丢帧会被当成"感知抖动"冤案排查半天。

本节要点

• ROS 是接口公约不是操作系统：节点解耦、话题命名、四件套按时间语义选型。
• 目标类长任务用动作（有回执有进度），一次性查询用服务，流数据用话题——发错机制等于没有回执。
• 回调只存不做、重活进定时器；参数外部可覆写，配置与代码分离。
• ROS2 换了传输内核（DDS）没换思想；话题频率与时间戳是集成命脉。

服务质量策略：可靠与实时的天平

ROS2 把传输策略暴露为 QoS 配置，常用三项要背下来。可靠性：可靠模式保证送达（重传补丢包），适合任务指令、地图、配置；尽速模式不重传（旧包不如新包），适合传感器流。历史深度：队列里攒几条消息——消费慢于生产时，深队列意味着旧数据堆积（定位迟到半秒的位姿还有意义吗），浅队列意味着主动丢旧保新；传感器流典型深度取 1 到 5。寿命：消息超龄即判无效——给位姿类消息设 0.5 秒寿命，迟到的数据自动作废，下游"宁缺毋滥"。这套配置的哲学与第 3 章一脉相承：过时的正确不如当下的近似。

录制与回放：调试的时间机器

话题网络的旁听能力要靠录制工具兑现。开发规范建议：联调期全程录制所有话题（按大小分级，点云图像可用低频或按需），出现任何异常先回放。回放的三个用法按常用度排序：一是复盘——把"那一刻"的完整输入重演给每个模块，定位是谁先错的（第 5.5 节十个故障的定位全靠它）；二是回归——修复后用同一包数据验证不再复发；三是开发——没有真机也能用真实数据开发下游算法。配套纪律：包文件按"日期加场景"命名入库存档，重要事故的包永久保留——它们是最贵也最有价值的数据资产。

问题：系统该拆多少个节点

拆分粒度没有标准答案，但有失效边界原则。粒度过粗（万能节点）的问题在第 5.2 节讲过；粒度过细（一个功能十个节点）的问题是调度与序列化开销、以及调试时话题爆炸。实用的切法按"失效域与时钟域"：同一失效域（一起挂掉没有意义）且同一时钟域（频率相近）的功能合为一个节点；跨失效域必须拆（感知挂了控制还要活）；跨时钟域建议拆（100 赫兹控制回路别和 0.1 赫兹大计算同进程）。按这个原则，典型导航系统落在八到二十个节点的区间——比这多太多或少太多，都值得回头审视边界。