10.1 机器人操作系统（ROS/ROS2）
10.1.1 引言：机器人软件开发的挑战与中间件的必要性
随着机器人系统从封闭的、功能单一的工业设备，演变为开放的、需集成感知、决策、规划与控制于一体的复杂智能体，其软件开发面临着一系列前所未有的工程挑战。这些挑战主要包括：异构性（硬件与编程语言多样）、模块化（功能解耦与团队协作）、分布式计算（计算负载跨平台分布）、通信实时性以及代码复用。传统上，机器人软件往往是为特定硬件和任务定制的“烟囱式”结构，导致开发周期长、调试困难且难以移植。
为解决这些问题，机器人操作系统应运而生。ROS并非传统意义上的操作系统（如Windows、Linux），而是一个运行在宿主操作系统之上的中间件框架和一套工具、库与约定的集合。它提供了硬件抽象、底层设备控制、进程间消息传递、包管理和常用功能实现，其核心目标是简化复杂机器人软件的创建过程，促进代码的复用与共享。ROS的出现，标志着机器人软件开发从“手工作坊”模式向基于标准化平台的“现代软件工程”模式的关键转变。
10.1.2 ROS（机器人操作系统）核心架构与概念
ROS1的架构设计围绕“松耦合、高内聚”的理念，其核心是一个基于发布/订阅模型的分布式通信系统。
10.1.2.1 核心概念
- 节点：ROS中的基本执行单元，是一个完成特定功能（如驱动一个激光雷达、执行路径规划、运行PID控制器）的进程。一个机器人系统由众多节点组成，每个节点负责单一、明确的职责。
- 节点管理器：ROS1架构的中心，负责节点的注册、注销，并为节点间的通信建立连接。它是节点发现和通信的桥梁，但也因此成为了ROS1架构中的单点故障源。
- 话题：一种异步的、单向的数据流通信机制。节点可以向一个话题发布消息，也可以订阅感兴趣的话题以接收消息。这是一种典型的一对多、多对多的数据分发模式，适用于传感器数据流、状态信息等连续、流式的数据交换。
- 服务：一种同步的、请求-响应式的双向通信机制。客户端节点发送请求消息，并等待服务器节点处理并返回响应。适用于需要确认执行结果的离散指令，如请求一个坐标变换、调用一个算法。
- 消息：节点间通信的数据结构，由
.msg文件定义。它是ROS中数据交换的标准化载体。 - 动作：建立在话题和服务之上，用于处理长时间运行、可抢占、带有反馈的任务。它包含目标话题、反馈话题和结果话题，非常适合机器人轨迹跟踪、导航等任务。
10.1.2.2 通信模型示例
例如，在一个移动机器人导航系统中：
- 激光雷达驱动节点作为一个发布者，将扫描数据发布到
/scan话题。 - 同时，SLAM节点和避障节点作为订阅者，分别订阅
/scan话题以获取数据。 - 导航规划节点在需要时，通过一个服务调用
/request_map来获取当前地图。 - 当上层系统下达导航目标时，通过动作
/move_base向底盘控制节点发送目标，并在移动过程中持续接收包含当前位置和状态的反馈。
10.1.2.3 核心工具链
- RViz：3D可视化工具，用于显示机器人模型、传感器点云、路径、地图等，是调试机器人感知与状态的“仪表盘”。
- Gazebo：高保真物理仿真环境。它不仅可以模拟机器人动力学，还能模拟复杂的传感器（如激光雷达、摄像头在噪声和光照下的输出）和环境交互，是算法开发、测试和验证不可或缺的平台。
- Catkin/CMake：ROS的构建系统，用于编译和管理ROS工作空间中的众多功能包。
- rosbag：数据记录与回放工具，可以录制话题数据，便于离线分析和算法调试。
表10.1-1：ROS1核心通信机制对比
| 机制 | 通信模式 | 实时性 | 适用场景 | 数据流向 |
|---|---|---|---|---|
| 话题 | 异步，发布/订阅 | 软实时，存在不确定延迟 | 传感器数据流、连续状态更新、广播信息 | 单向，一对多/多对多 |
| 服务 | 同步，请求/响应 | 取决于服务器响应时间 | 离散命令、远程过程调用、查询状态 | 双向，一对一 |
| 动作 | 异步，含反馈 | 支持长时任务，可反馈进度 | 导航、机械臂轨迹执行、需中途取消的任务 | 双向（目标、反馈、结果），一对一 |
10.1.3 ROS2：架构演进与关键增强
尽管ROS1取得了巨大成功，但其在设计之初的局限性也逐渐暴露，尤其是在实时性、可靠性和跨平台部署方面。ROS2是针对这些局限性进行彻底重新设计的产物。
10.1.3.1 核心架构变革
- 去除中心节点：ROS2最大的变革是彻底移除了ROS1中的单点故障源——节点管理器。节点发现和通信采用数据分发服务标准，实现了真正的去中心化对等网络。
- 引入DDS作为通信中间件：DDS是一个工业级的、支持实时发布/订阅的数据通信标准。它提供了丰富的服务质量配置选项，是ROS2实现确定性通信的基石。
- 支持跨平台与实时操作系统：ROS2从设计之初就支持在Linux、Windows、macOS以及多种RTOS上运行，使得它可以被部署到从高性能计算单元到微控制器的各类硬件。
10.1.3.2 QoS策略
QoS是ROS2最强大的特性之一，它允许开发者根据数据的性质，精细地控制通信行为。关键的QoS策略包括：
- 可靠性：
RELIABLE（确保消息送达，可能重传） vsBEST_EFFORT（尽力而为，低延迟但不保证）。 - 持久性：
VOLATILE（不保留历史消息） vsTRANSIENT_LOCAL（为新订阅者保留最近的历史消息）。 - 历史深度：设置发布者/订阅者队列中保留的消息数量。
- 截止时间：指定消息必须被发布的周期或必须在多长时间内被接收，超时可用于检测故障。
通过QoS，开发者可以为关键的控制指令（如关节目标位置）配置可靠、确定性的通信链路，而为高频的、可容忍丢失的传感器数据（如视频流）配置尽力而为的链路，从而在整体上优化系统性能与资源。
10.1.3.3 生命周期管理
ROS2为节点引入了明确的生命周期状态机（如未配置、非活跃、活跃、最终化），使得节点的启动、激活、去激活和关闭过程可控且可预测。这对于需要按顺序安全启动复杂系统（如先启动驱动，再启动算法）至关重要。
表10.1-2：ROS1与ROS2关键特性对比
| 特性 | ROS1 | ROS2 |
|---|---|---|
| 通信架构 | 中心化（依赖于节点管理器）。 | 去中心化（基于DDS对等网络）。 |
| 通信中间件 | 自定义TCPROS/UDPROS协议。 | 基于DDS标准，可插拔中间件实现。 |
| 实时性 | 有限，难以保证硬实时。 | 支持实时，通过DDS QoS策略可实现确定性通信。 |
| 系统可靠性 | 存在单点故障（节点管理器）。 | 高可靠性，无单点故障，支持多种冗余策略。 |
| 网络支持 | 主要面向单机器人、局域网。 | 原生支持多机器人系统及复杂的网络拓扑。 |
| 节点生命周期 | 简单，缺乏统一管理。 | 具备结构化的生命周期管理，状态可控。 |
| 平台支持 | 以Linux为主。 | 跨平台（Linux, Windows, macOS, RTOS）。 |
| 适用场景 | 研究原型、教育、对实时性要求不高的机器人应用。 | 产品级机器人、自动驾驶、工业自动化、对实时性和可靠性有要求的 |
