第二章 ROS2基础入门：架构、节点、话题、服务、动作、参数、生命周期节点与DDS通信机制

ROS2（Robot Operating System 2）是Autoware.Auto自动驾驶软件栈的底层通信与运行框架。与ROS1相比，ROS2基于DDS（Data Distribution Service）中间件，实现了真正的分布式通信、实时性增强、进程隔离和跨平台支持。对于自动驾驶开发者而言，理解ROS2的架构与核心通信原语，是掌握Autoware.Auto系统集成、节点调试和功能扩展的前提。本章将系统梳理ROS2的架构分层、六大核心通信机制（节点、话题、服务、动作、参数、生命周期节点）以及DDS通信原理，并结合Autoware.Auto的实际应用场景进行案例拆解。

上图展示了ROS2的分层架构：最上层是Autoware.Auto应用功能包，中间是ROS2中间件层（提供节点、话题、服务、动作、参数、生命周期等API），下层是DDS通信中间件，最底层是操作系统与网络传输。DDS作为核心通信引擎，负责数据的可靠传输、发现和QoS策略执行。下面我们逐一深入解析每个核心机制。

2.1 节点（Node）与计算图

核心原理

节点是ROS2中可执行的计算单元，每个节点负责特定的功能（如激光雷达驱动、点云处理、路径规划）。节点之间通过话题、服务、动作等机制通信，形成一张分布式的计算图。在Autoware.Auto中，一个典型的感知节点可能订阅激光雷达点云话题，经过处理后再发布障碍物信息话题。节点使用rclcpp（C++）或rclpy（Python）编写，通过rclcpp::Node类实例化。

判断方法或操作流程

创建并运行一个节点的基本流程如下：

1. 初始化ROS2客户端库：rclcpp::init(argc, argv);
2. 创建节点对象：auto node = std::make_shared<rclcpp::Node>("node_name");
3. 在节点中定义发布者、订阅者、服务端等通信对象。
4. 调用rclcpp::spin(node);让节点进入事件循环，处理回调。
5. 使用ros2 run <package_name> <node_name>启动节点，或使用launch文件启动多个节点。

案例拆解：Autoware中的车辆状态节点

在Autoware.Auto中，vehicle_state节点负责收集车辆底盘反馈（速度、转向角、挡位），并发布到/vehicle/status话题。该节点订阅CAN总线数据，经过解析和坐标变换后，以autoware_auto_vehicle_msgs/msg/VehicleStateReport消息类型发布。控制节点再订阅该话题，用于反馈控制。这个节点体现了ROS2节点的典型职责：数据采集、处理、发布。

2.2 话题（Topic）——异步通信机制

核心原理

话题是ROS2中最常用的异步通信方式，采用发布-订阅模式。发布者（Publisher）向指定话题发送消息，订阅者（Subscriber）接收消息。话题通信是单向的、无反馈的，适合高频数据流（如传感器数据、状态信息）。在Autoware中，点云数据（/sensing/lidar/pointcloud）、规划轨迹（/planning/trajectory）均通过话题传输。

操作流程与QoS配置

创建话题通信需要以下步骤：

1. 定义消息类型（.msg文件），编译生成对应语言代码。
2. 创建发布者：create_publisher<MessageType>("topic_name", qos_profile);
3. 创建订阅者：create_subscription<MessageType>("topic_name", qos_profile, callback);
4. 在回调函数中处理接收到的消息。

QoS（Quality of Service）策略是ROS2话题通信的关键，它决定了消息的可靠性、历史深度和时效性。下表列出了常用QoS配置及其适用场景：

常见误区

2.3 服务（Service）——同步请求/响应通信

核心原理

服务是一种同步通信机制，客户端（Client）发送请求，服务端（Server）处理并返回响应。服务适合低频、需要确认的交互，如地图加载、参数查询、路径规划请求。在Autoware中，/api/planning/route服务用于请求全局路径规划。

操作流程

1. 定义服务接口（.srv文件），包含请求和响应结构。
2. 创建服务端：create_service<ServiceType>("service_name", handler);
3. 创建客户端：create_client<ServiceType>("service_name");
4. 客户端调用async_send_request()发送请求，并等待响应。

案例拆解：路径规划服务

在Autoware中，当用户通过Rviz设置目标点后，mission_planner节点调用/planning/mission_planning服务，请求从当前点到目标点的全局路径。服务端接收请求后，调用地图数据、车道网络，计算出一条平滑路径并返回。该过程是同步的，客户端会阻塞等待响应，因此适合耗时较短的规划请求。若规划耗时过长，应改用动作（Action）机制。

2.4 动作（Action）——长时任务通信

核心原理

动作机制专为长时任务设计，它结合了话题和服务的特点：客户端发送目标（Goal），服务端执行任务并持续反馈进度（Feedback），最终返回结果（Result）。动作支持取消和暂停，适合自动驾驶中的车辆控制、路径跟踪等任务。在Autoware中，control节点通过动作服务器接收轨迹跟踪目标，并实时反馈车辆状态。

操作流程

1. 定义动作接口（.action文件），包含Goal、Feedback、Result三部分。
2. 创建动作服务器：create_action_server<ActionType>("action_name", ...);
3. 创建动作客户端：create_action_client<ActionType>("action_name");
4. 客户端发送目标，服务器执行并发布反馈，最终返回结果。

对比与选型

2.5 参数（Parameter）与动态配置

核心原理

参数是节点的配置项，以键值对形式存储，支持整数、浮点、字符串、布尔、数组等类型。参数可以在节点启动时通过launch文件设置，也可以在运行时动态修改。在Autoware中，vehicle_characteristics参数（如轴距、最大转向角）用于控制算法，lidar_threshold参数用于感知过滤。

操作流程

1. 声明参数：declare_parameter("param_name", default_value);
2. 获取参数：get_parameter("param_name").as_double();
3. 设置参数（运行时）：ros2 param set /node_name param_name value
4. 在launch文件中传递参数：parameters=[{'param_name': value}]

2.6 生命周期节点（Lifecycle Node）——状态机管理

核心原理

生命周期节点为ROS2节点引入了状态机管理，节点在未配置（Unconfigured）、未激活（Inactive）、激活（Active）、已完成（Finalized）等状态间切换。这允许系统在启动时先加载配置、初始化资源，再激活节点开始工作，避免资源竞争和启动顺序问题。在Autoware中，感知、规划、控制节点均使用生命周期节点，由lifecycle_manager统一管理。

状态转换流程

1. Unconfigured：节点创建，未初始化。
2. Inactive：调用on_configure()，加载参数、分配资源，但节点不处理数据。
3. Active：调用on_activate()，节点开始正常发布/订阅。
4. Deactivated：调用on_deactivate()，暂停处理。
5. CleanedUp：调用on_cleanup()，释放资源。

案例拆解：Autoware的启动流程

Autoware.Auto使用autoware_launch启动时，lifecycle_manager会按照依赖顺序激活节点。例如，先激活vehicle_state节点，再激活perception节点，最后激活planning和control节点。如果某个节点配置失败，系统会将其置于ErrorProcessing状态，并停止后续激活，避免级联故障。

2.7 DDS通信机制与QoS深度解析

核心原理

DDS是ROS2的底层通信中间件，采用发布-订阅模型，支持点对点、多对多通信。DDS的关键特性包括：

• 全局数据空间：所有节点通过DDS域（Domain）连接，域ID相同的节点才能通信。
• 发现机制：DDS自动发现网络中的节点、话题、服务，无需手动配置IP。
• QoS策略：控制消息的可靠性、时效性、历史深度等，是ROS2通信的核心配置。
• 传输方式：默认使用UDP，也支持TCP、共享内存（Intra-process）和实时以太网。

判断方法：选择DDS实现

ROS2支持多种DDS实现（Fast DDS、Cyclone DDS、RTI Connext等）。选择时需考虑：

常见误区与排障

另一个常见问题是网络发现失败。当节点运行在不同网段或启用了防火墙时，DDS的发现协议（SPDP）可能被阻断。此时可设置ROS_DOMAIN_ID隔离不同系统，或配置DDS的发现服务器（Discovery Server）模式。

2.8 综合实战：构建一个简单的自动驾驶节点组合

为了巩固上述概念，我们设计一个简化场景：一个虚拟障碍物检测节点（使用话题）、一个路径规划服务节点（使用服务）、一个车辆控制动作节点（使用动作），并通过生命周期管理启动。

场景与目标

在仿真环境中，障碍物检测节点订阅激光雷达点云话题/sensing/lidar/pointcloud，检测到障碍物后发布/perception/obstacles话题。规划节点订阅障碍物信息，当收到路径规划请求（服务）时，计算避障路径。控制节点通过动作服务器接收路径，并模拟执行。

关键代码片段

// 障碍物检测节点（话题）
class ObstacleDetector : public rclcpp::Node {
public:
  ObstacleDetector() : Node("obstacle_detector") {
    sub_ = create_subscription<sensor_msgs::msg::PointCloud2>(
      "/sensing/lidar/pointcloud", rclcpp::SensorDataQoS(),
      [this](const sensor_msgs::msg::PointCloud2::SharedPtr msg) {
        // 处理点云，发布障碍物
        auto obstacles = std::make_shared<autoware_auto_perception_msgs::msg::PredictedObjects>();
        // ... 检测逻辑
        pub_->publish(*obstacles);
      });
    pub_ = create_publisher<autoware_auto_perception_msgs::msg::PredictedObjects>(
      "/perception/obstacles", rclcpp::QoS(10));
  }
private:
  rclcpp::Subscription<sensor_msgs::msg::PointCloud2>::SharedPtr sub_;
  rclcpp::Publisher<autoware_auto_perception_msgs::msg::PredictedObjects>::SharedPtr pub_;
};

结果与复盘

通过该组合，我们验证了话题的异步高频通信、服务的同步请求响应、动作的长时任务反馈。在调试中，我们发现若将点云话题的QoS设置为RELIABLE，在仿真负载高时会出现延迟累积；改为BEST_EFFORT后，延迟降低约30%。此外，使用生命周期节点后，系统启动顺序可控，避免了规划节点在感知数据未就绪时误规划的问题。