ROS2 机器人开发：从能跑到能上机

一、先纠正一个误区：ROS2 不是“装好就能用”

新手最容易踩的坑，是把 ROS2 当成一个应用软件。实际上它更像一套“分布式系统的约定”，你要自己补齐很多东西：

• 话题能发出去，但对方 QoS 不匹配，一条都收不到；
• 仿真里 tf 树是完整的，上机后发现某个坐标系根本没人发布；
• 节点崩溃不会自动重启，launch 里没配 respawn 就整条链路挂掉；
• 用系统时间跑仿真，回放 bag 时时间跳变，控制直接发散；
• 单机通信正常，跨机部署后 DDS 发现不到对方；
• 没有记录 bag，出了问题无法复现。

所以正确姿势不是“写完节点就上机”，而是按闭环推进：

1. 最小闭环：一个发布、一个订阅、能通；
2. 通信选型：话题、服务、动作各用其位；
3. QoS 对齐：可靠性、历史深度、持久性要匹配；
4. 坐标与时间：tf2 树完整，时间源统一；
5. 编排与生命周期：launch 管启动，节点管状态；
6. 仿真到实机：先仿真，再旁路，再接管；
7. 可观测：bag 回放、日志、监控；
8. 安全与实时：看门狗、限幅、紧急停止。

二、第一步：先跑通一个最小闭环

不要一上来就写完整的感知—规划—控制。先证明“两个节点能通过 ROS2 通信”。

# talker.py
import rclpy
from rclpy.node import Node
from std_msgs.msg import String

class Talker(Node):
    def __init__(self):
        super().__init__("talker")
        self.pub = self.create_publisher(String, "chatter", 10)
        self.create_timer(1.0, self.tick)

    def tick(self):
        msg = String()
        msg.data = f"hello {self.get_clock().now().nanoseconds}"
        self.pub.publish(msg)

def main():
    rclpy.init()
    rclpy.spin(Talker())
    rclpy.shutdown()

这段代码的意义不在功能，而在建立可验证的基线：ros2 topic echo /chatter 能收到，说明环境、DDS、命名空间都没问题。后面所有问题都可以对照这个基线排查。

三、第二步：通信选型，别全用话题

ROS2 有三种主要通信方式，用错会让系统又乱又难调：

• 话题（Topic）：单向、高频、可丢。适合传感器数据、状态广播。
• 服务（Service）：请求—响应、同步语义。适合“查一次、改一次”的短操作。
• 动作（Action）：长任务、可反馈、可取消。适合导航到点、机械臂抓取。

判断标准很简单：需要中途反馈或取消的，用动作；需要明确成功失败的短操作，用服务；其余持续流，用话题。 把长任务硬塞进服务，会导致超时和阻塞；把高频数据做成服务，会把系统拖垮。

四、第三步：QoS 不匹配，是最隐蔽的“收不到数据”

这是 ROS2 新手最常见的困惑：ros2 topic list 能看到话题，echo 也有数据，但自己的订阅节点就是收不到。八成是 QoS 不匹配。

默认的可靠性是 RELIABLE，而很多传感器驱动用的是 BEST_EFFORT。两者不兼容，就收

from rclpy.qos import QoSProfile, ReliabilityPolicy, HistoryPolicy

sensor_qos = QoSProfile(
    reliability=ReliabilityPolicy.BEST_EFFORT,   # 与传感器驱动保持一致
    history=HistoryPolicy.KEEP_LAST,
    depth=10,
)

self.sub = self.create_subscription(Image, "/camera/image", self.on_img, sensor_qos)

规则很实用：订阅传感器数据，先看发布方的 QoS，再照着配。 用 ros2 topic info /camera/image --verbose 可以直接看到对方的 QoS 设置。图像、点云这类高频数据用 BEST_EFFORT，控制指令和状态用 RELIABLE。

五、第四步：tf2 和时间，是机器人特有的坑

机器人里大量问题最终都归结为两件事：坐标系不对、时间不对。

tf2 的要点：

• 每个坐标系必须有且只有一个父节点，树不能有环；
• 静态变换用 static_transform_publisher，动态变换由传感器或里程计发布；
• 上机前用 ros2 run tf2_tools view_frames 导出整棵树，确认没有断链；
• 查具体变换用 ros2 run tf2_ros tf2_echo base_link laser。

时间的要点：

• 仿真必须用 /clock，节点里用 self.get_clock().now()，不要用 time.time()；
• 回放 bag 时时间会跳变，控制器要能处理；
• 多机部署要统一时间源，否则消息时间戳无法对齐。

这两件事不解决，后面的算法调得再好也白搭。 而且它们出错时往往不报错，只是“效果不对”，最难排查。

六、第五步：launch 编排与生命周期节点

手动开十个终端启动节点，是不可维护的。用 launch 统一编排：

from launch import LaunchDescription
from launch_ros.actions import Node

def generate_launch_description():
    return LaunchDescription([
        Node(package="demo", executable="talker", name="talker",
             respawn=True, respawn_delay=2.0),
        Node(package="demo", executable="listener", name="listener",
             parameters=[{"topic": "chatter"}], output="screen"),
    ])

两个细节很关键：respawn=True 让节点崩溃后自动拉起；参数通过 launch 注入，而不是硬编码在代码里。

对于需要“配置—激活—运行”流程的节点（比如硬件驱动），优先用生命周期节点。它把“加载配置”和“开始工作”分开，避免启动顺序问题，也让系统状态可控。

七、第六步：从仿真到实机，必须分三步走

直接上机是事故之源。建议的顺序是：

1. 纯仿真：验证逻辑和坐标系，确认没有崩溃和死循环；
2. 旁路运行：实机上跑感知和决策，但不接管执行，只记录它的输出，和人工操作对比；
3. 灰度接管：只对低风险、可回滚的动作放开自动执行，其余仍人工确认。

每一步都要有明确的“通过标准”，比如旁路阶段要求“决策输出与人工操作一致率超过某阈值”。没有标准，就没有资格进入下一步。

八、第七步：可观测性，决定你能不能修

ROS2 自带的能力要充分利用：

• ros2 bag：录制关键话题，出问题能回放复现。建议长期保留“最近一次异常前后”的片段；
• ros2 topic hz / delay：检查频率是否达标、延迟是否正常；
• 日志分级：DEBUG/INFO/WARN/ERROR 分明，关键状态变化必须打日志；
• 看门狗：关键节点心跳超时就降级或停机，而不是带病运行。

bag 回放是最有价值的调试手段：同一个问题，能在仿真里回放一百次，比在实机上猜十次强得多。

九、第八步：安全与实时，别等到出事才想

机器人是物理系统，软件错误会变成物理伤害。最低限度要做到：

• 指令限幅：速度、加速度、关节角必须有上下限；
• 紧急停止：独立于主控链路，任何异常都能立即切断执行；
• 超时保护：控制指令超时未更新，必须自动归零或制动；
• 权限隔离：调试接口和运行接口分开，防止误操作；
• 通信加密：跨机部署时，DDS 安全和网络隔离要评估。

如果涉及硬实时需求，再考虑实时内核、DDS 调优和专用执行器。但绝大多数问题出在逻辑和安全设计，而不是实时性不够。

十、AI 在 ROS2 开发里的正确角色

AI 很适合帮你做这些：

• 生成节点骨架、launch 文件、参数配置；
• 审查 QoS 是否匹配、tf 树是否有断链；
• 根据 bag 和日志整理排障清单；
• 写单元测试和仿真测试用例。

一个实用的审查提示词：

请审查下面 ROS2 节点代码，只输出问题表格：
问题类型 | 位置 | 风险说明 | 修改建议
重点检查：QoS 是否与发布方匹配、是否使用了系统时间而非 ROS 时钟、
是否有参数硬编码、是否有异常处理和看门狗、话题命名是否规范。
不要重写代码，不要评价算法效果。

但坐标系约定、安全边界、仿真到实机的接管标准，必须人来做。AI 没有你的硬件和场景。

十一、常见坑

1. QoS 不匹配：话题能 echo 到，自己节点收不到。
2. 用系统时间跑仿真：回放时时间跳变，控制发散。
3. tf 树断链：某个坐标系没人发布，下游全部失效。
4. 手动开终端：启动顺序靠记忆，换台机器就跑不起来。
5. 没有 respawn：一个节点崩溃，整条链路挂掉。
6. 直接上机：仿真没验证，也没有旁路对比。
7. 不录 bag：出问题无法复现，只能靠猜。
8. 没有限幅和急停：软件 bug 直接变成物理事故。

结论

ROS2 机器人开发的正确姿势，不是“写完节点就上机”，而是先跑通最小闭环，再对齐 QoS 和 tf，用 launch 和生命周期节点管编排，按仿真—旁路—灰度三步走向实机，用 bag 和监控保证可复现，用限幅和急停守住安全底线。

代码可以很少，但 QoS 不能配错，坐标系不能断，时间源不能混，安全不能省。记住一句话：ROS2 帮你把模块连起来，但能不能稳定地跑在真实世界，取决于你对通信、时间和安全的每一个判断。