1. 课程导入

自动驾驶系统是典型的复杂分布式实时系统，其软件架构通常横跨感知、决策、规划、控制等多个模块，运行在异构多芯片平台上（如Orin、Xavier、高通SA8295等）。在这些模块之间，数据以数百Hz的频率流转，对延迟、可靠性、可扩展性提出了极高要求。中间件（Middleware）正是解决这一问题的核心基础设施——它屏蔽了底层操作系统与硬件差异，为上层应用提供通信、序列化、服务发现、生命周期管理、配置管理、时钟同步等通用能力。本课程聚焦两大主流中间件：面向科研与原型验证的ROS 2，以及面向量产车规级应用的Apollo Cyber RT。本章将首先厘清中间件的核心职责，随后对两者进行系统性对比，最后给出课程学习路径与实战环境搭建方案。

1.1 自动驾驶中间件的核心作用

在自动驾驶系统中，中间件并非单一组件，而是一整套位于操作系统（Linux/QNX）与应用算法之间的软件层。它的核心价值体现在四个维度：通信抽象、资源管理、开发范式与可靠性保障。

核心原理：通信抽象与数据分发

自动驾驶的感知模块（如摄像头、LiDAR、Radar）以不同频率产生数据——摄像头通常30fps，LiDAR 10-20Hz，Radar 20-50Hz。这些数据需要被多个下游模块（融合、预测、规划）同时消费。中间件提供发布-订阅（Pub/Sub）模型，解耦数据生产者与消费者。以ROS 2为例，其底层采用DDS（Data Distribution Service）标准，通过RTPS协议实现跨进程、跨主机的可靠/尽力传输。而Cyber RT则采用自研的共享内存机制，在单机多进程场景下，通过零拷贝技术将延迟降低至微秒级。

判断方法：如何评估一个中间件是否适合量产？

评估中间件需要从以下维度建立量化指标体系：

实战场景：感知数据分发链路

假设一个L4级Robotaxi场景：主LiDAR（128线）以10Hz产生约2.3MB/帧的点云数据。在ROS 2中，若采用默认的Fast DDS，点云Topic的发布频率可能因序列化开销而降至8Hz，且CPU占用率显著。而在Cyber RT中，通过共享内存通道（SharedMemory）和零拷贝机制，可以稳定维持10Hz，且CPU占用率降低约40%。这一差异在实车多传感器融合时尤为关键。

1.2 ROS 2与Cyber RT的深度对比

两者并非替代关系，而是面向不同阶段的产物。ROS 2由ROS 1演进而来，目标是标准化、模块化、支持多语言；Cyber RT则是百度Apollo为满足量产车规要求而自研的中间件，强调性能极致与资源可控。

核心原理：架构设计差异

ROS 2采用分层架构：应用层（rclcpp/rclpy）→ ROS客户端库（rcl）→ RMW（ROS Middleware Interface）→ DDS实现（Fast DDS、Cyclone DDS等）。这种抽象使得ROS 2可以切换不同的DDS供应商，但也引入了额外开销。其执行模型基于Executor，通过回调组（Callback Group）控制并发，但多线程执行器在复杂场景下可能产生锁竞争。

Cyber RT则采用更紧凑的架构：Component（算法模块）→ Scheduler（协程调度器）→ Transport（共享内存/Intra-process）。Cyber RT的核心创新在于协程（Coroutine）——将每个处理逻辑视为轻量级协程，由调度器统一管理，避免了线程切换开销，实现了确定性调度。其数据通路在单机场景下默认走共享内存，跨机则通过RTPS兼容。

操作流程：从代码结构看差异

以创建一个发布者为例，对比两者的代码范式：

// ROS 2 (C++)
#include <rclcpp/rclcpp.hpp>
int main(int argc, char** argv) {
    rclcpp::init(argc, argv);
    auto node = std::make_shared<rclcpp::Node>("talker");
    auto pub = node->create_publisher<std_msgs::msg::String>("chatter", 10);
    rclcpp::WallRate rate(1);
    while (rclcpp::ok()) {
        auto msg = std_msgs::msg::String();
        msg.data = "Hello";
        pub->publish(msg);
        rclcpp::spin_some(node);
        rate.sleep();
    }
    rclcpp::shutdown();
}

// Cyber RT (C++)
#include "cyber/cyber.h"
#include "cyber/demo_base_proto/student.pb.h"
int main(int argc, char** argv) {
    apollo::cyber::Init(argv[0]);
    auto node = apollo::cyber::CreateNode("talker");
    auto pub = node->CreateWriter<apollo::cyber::demo_base_proto::Student>("chatter");
    apollo::cyber::Rate rate(1);
    while (apollo::cyber::OK()) {
        auto msg = std::make_shared<apollo::cyber::demo_base_proto::Student>();
        msg->set_name("Hello");
        pub->Write(msg);
        rate.Sleep();
    }
    apollo::cyber::Clear();
    return 0;
}

从代码可见，ROS 2的API更贴近通用C++风格，而Cyber RT则强依赖其Proto消息定义和Node/Writer抽象。Cyber RT的编译需要依赖Apollo的bazel构建系统，而ROS 2使用标准的ament_cmake。

案例拆解：某L4公司中间件选型过程

某自动驾驶初创公司需在6个月内完成原型车到准量产车的软件迁移。初始团队基于ROS 1开发，面临以下痛点：

• 数据延迟抖动大：在拥堵路段多传感器并发时，规划模块的控制指令延迟从5ms波动至50ms。
• CPU占用过高：8核Xavier平台上，中间件及通信开销占用超过30% CPU。
• 无确定性调度：偶发死锁导致系统重启。

团队评估后决定：原型阶段保留ROS 2（利用其丰富的仿真工具如Gazebo、RViz2），量产阶段迁移至Cyber RT。具体操作：

1. 在ROS 2中完成算法验证，并定义标准Topic接口（基于.msg文件）。
2. 使用Cyber RT的cyber_recorder回放ROS 2录制的bag包，验证数据兼容性。
3. 将核心感知模块重写为Cyber RT Component，利用其协程调度优化CPU占用。
4. 通过Cyber RT的cyber_monitor工具实时监控各通道延迟，定位瓶颈。

结果：迁移后，控制指令P99延迟从45ms降至8ms，CPU占用从32%降至18%。但代价是开发效率下降——Cyber RT的调试工具远不如ROS 2丰富，且社区资料较少。

1.3 课程学习路径与实战环境搭建

本课程共30章，分为四个阶段：基础篇（1-5章）、ROS 2进阶（6-15章）、Cyber RT实战（16-25章）、综合项目与性能优化（26-30章）。建议学习者具备C++基础、Linux常用命令知识，并了解基本的多线程编程概念。

核心原理：学习路径设计逻辑

课程设计遵循“对比驱动”原则——每讲一个ROS 2概念，立即对照Cyber RT的对应实现。例如：

操作流程：环境搭建步骤

推荐使用Ubuntu 22.04 LTS + Docker方式，避免污染宿主机环境。以下是核心步骤：

# 1. 安装Docker
curl -fsSL https://get.docker.com | sh
sudo usermod -aG docker $USER

# 2. 拉取ROS 2 Humble镜像
docker pull ros:humble-ros-base-jammy

# 3. 拉取Apollo 8.0镜像（包含Cyber RT）
docker pull apolloauto/apollo:8.0.0-cpu

# 4. 创建共享工作目录
mkdir -p ~/autoware_ws/src ~/apollo_ws

# 5. 启动ROS 2容器（挂载工作目录）
docker run -it --name ros2_dev \
  -v ~/autoware_ws:/workspace \
  -v /tmp/.X11-unix:/tmp/.X11-unix \
  -e DISPLAY=$DISPLAY \
  ros:humble-ros-base-jammy

# 6. 启动Cyber RT容器（Apollo 8.0）
docker run -it --name cyber_dev \
  -v ~/apollo_ws:/apollo \
  apolloauto/apollo:8.0.0-cpu
  # 进入容器后执行: bash /apollo/scripts/apollo.sh enter

对于性能要求较高的场景，建议在宿主机直接安装Cyber RT源码编译，但需注意依赖项（如Protobuf 3.14、Eigen 3.3.7等）版本冲突。

实战场景：验证环境是否就绪

搭建完成后，运行一个简单的“Hello World”通信测试：

# 终端1 (ROS 2)
source /opt/ros/humble/setup.bash
ros2 run demo_nodes_cpp talker

# 终端2 (ROS 2)
source /opt/ros/humble/setup.bash
ros2 run demo_nodes_cpp listener
# 预期看到 "I heard: Hello World: N" 持续输出

# 终端1 (Cyber RT)
source /apollo/cyber/setup.bash
cyber_recorder play -f /apollo/data/bag/demo.record

# 终端2 (Cyber RT)
source /apollo/cyber/setup.bash
cyber_monitor
# 预期看到 /apollo/perception/obstacles 等通道实时刷新

若上述命令均正常，说明环境搭建成功。建议在后续学习中，为每个章节建立独立的Docker镜像快照，避免依赖污染。

常见误区与总结复盘

• 误区1：认为ROS 2可以直接用于量产。实际上，ROS 2的DDS实现（如Fast DDS）在极端负载下仍存在不确定性，且缺乏功能安全认证（ISO 26262）。量产需基于DDS的Safety版本或自研中间件。
• 误区2：忽视消息类型设计。无论是ROS 2的.msg还是Cyber RT的.proto，消息定义一旦发布，修改成本极高。建议在项目初期定义好接口规范，并采用版本号管理。
• 误区3：只学API不学原理。中间件的核心是调度与通信机制，如果只停留在调用API层面，遇到性能问题将无从下手。建议深入阅读源码（如Cyber RT的scheduler模块）。