1. ROS2与Apollo概述

1.1 ROS2的前世今生

说起ROS，我入行那会儿还是ROS1的天下。2010年ROS1刚发布时，大家觉得这玩意儿就是个机器人研究工具，离量产还远着呢。但后来发现，ROS1在自动驾驶领域有个致命问题——它没有实时性保障。

为什么会这样？因为ROS1的通信机制基于TCP，节点挂了整个系统可能就崩了。我记得2017年做的一个园区物流项目，车跑着跑着突然没反应了，排查了半天发现是Master节点挂了。嗯，从那以后我就开始关注ROS2了。

ROS2从2015年开始设计，2017年发布第一个正式版。它最大的变化就是抛弃了Master中心化架构，改用DDS（数据分发服务）作为底层通信。说白了，就是每个节点都变成了对等体，谁也不用依赖谁。

我个人习惯把ROS2的发展分为三个阶段：

• 探索期（2015-2018）：架构设计、DDS选型、API定义。那时候API变动频繁，我写的一个感知模块每三个月就要改一次接口。
• 稳定期（2019-2021）：Foxy、Galactic等LTS版本发布，生态逐渐成熟。Apollo也开始在7.0版本中引入ROS2。
• 爆发期（2022至今）：Humble、Iron等版本，工业级应用越来越多。现在新项目我基本都推荐直接用ROS2。

1.2 Apollo自动驾驶平台简介

Apollo是百度2017年开源的自动驾驶平台。说实话，当年看到它开源时我挺震惊的——一个完整的自动驾驶系统，从感知到规划到控制，全给你了。

Apollo的架构设计很有层次感：

• 硬件层：支持多种传感器组合（激光雷达、摄像头、毫米波雷达、IMU/GPS）
• 系统层：基于Ubuntu，早期用ROS1，后来迁移到ROS2和自研的Cyber RT
• 软件层：感知、定位、预测、规划、控制、HMI等模块
• 云端层：仿真平台、数据标注、OTA升级

我在项目中遇到过一个问题：Apollo早期版本（3.0之前）用ROS1，但跑在实车上时，传感器数据量一大，ROS1的Master就成了瓶颈。你想想看，激光雷达每秒30万点云，摄像头每秒30帧1080p图像，这些数据都要经过Master调度，不卡才怪。

1.3 ROS2在Apollo中的角色与价值

ROS2在Apollo中到底扮演什么角色？我总结了三句话：

• 通信骨架：模块间数据交换的通道
• 工具链：可视化、日志、调试的支撑
• 生态接口：连接第三方算法和硬件的桥梁

具体来说，ROS2在Apollo中的价值体现在这几个方面：

1.3.1 去中心化通信

ROS2的DDS机制让每个模块独立运行。比如感知模块挂了，规划模块还能用上一帧数据继续工作。这在ROS1里是做不到的——Master一挂，全车瘫痪。

1.3.2 QoS保障

ROS2的QoS（服务质量）配置非常灵活。举个例子：

// 控制指令需要可靠传输
rclcpp::QoS qos_ctrl(10);
qos_ctrl.reliable();
qos_ctrl.transient_local();

// 传感器数据可以容忍丢包
rclcpp::QoS qos_sensor(10);
qos_sensor.best_effort();
qos_sensor.durability_volatile();

我在Apollo项目中，控制指令用Reliable QoS，传感器数据用Best Effort QoS。这样既保证了关键指令不丢失，又避免了传感器数据阻塞控制链路。

1.3.3 生命周期管理

ROS2的Managed Node机制让模块启动和关闭变得可控。比如车辆启动时，先启动定位模块，再启动感知模块，最后启动规划控制模块。这在Apollo的多模块协同中非常有用。

1.3.4 工具链集成

ROS2的rqt、rviz2、rosbag2等工具在Apollo中都能直接用。我个人最喜欢rosbag2，它支持按时间戳回放数据，调试时特别方便。

1.4 本章知识体系

下面这张图是我自己画的，把ROS2和Apollo的关系梳理清楚了：

这张图展示了Apollo的四层架构，ROS2作为中间件层，连接了上层的应用模块和下层的系统硬件。说白了，ROS2就是整个系统的"神经系统"——数据怎么传、模块怎么协调、故障怎么处理，都靠它。

1.5 我的实践心得

做了这么多年自动驾驶，我最大的体会是：选对通信框架，项目就成功了一半。ROS2在Apollo中的价值，不仅仅是技术层面的，更是工程层面的——它让团队可以并行开发不同模块，互不干扰。

举个例子，我们团队做感知的同事用C++写点云处理，做规划的同事用Python写路径规划，做控制的同事用C++写PID。ROS2的跨语言支持让这些模块能无缝对接。这在ROS1时代是很难做到的——Python和C++的节点通信经常出问题。