开源自动驾驶软件平台深度对比：Autoware 与 Apollo 谁更胜一筹？

公众号致力于点云处理，SLAM，三维视觉，具身智能，自动驾驶等领域相关内容的干货分享，欢迎各位加入，有兴趣的可联系dianyunpcl@163.com。文章未申请原创，未经过本人允许请勿转载，有意转载联系微信920177957。

文章：Open-Source Autonomous Driving Software Platforms:Comparison of Autoware and Apollo

作者：Hee-Yang Jung , Dong-Hee Paek and Seung-Hyun Kong

编辑：点云PCL

摘要

一个完整的全栈式自动驾驶系统，需要横跨感知、规划、控制等多个高精尖技术领域，并且每个环节都离不开深度的研发投入。不仅如此，要验证这些技术，还得配备庞大的支持体系——从仿真平台、各类传感器到高精度地图。这种高复杂度与高门槛，对个人开发者或小型研究团队来说，几乎是难以逾越的障碍。好在近年来涌现的开源自动驾驶软件平台正在打破这一僵局。它们不仅提供了现成的自动驾驶技术栈，还搭建了实用的基础设施，让功能实现与效果评估变得更加容易。在目前主流的开源平台中，Autoware 和 Apollo 在学术界和工业界应用最为广泛。虽然已有不少研究单独分析过这两者，但很少有研究对它们进行过全面、量化的直接对比。

本文系统梳理了 Autoware 与 Apollo 的核心模块构成，并对它们的中间件性能进行了详细评估，旨在揭示两者间的关键差异。希望通过这些分析，能为研究人员和工程师在选择最适合自身项目的平台时，提供一份清晰的参考。

开源自动驾驶平台

一个全栈自动驾驶系统的工作流程大致如下：首先，车辆利用各种传感器收集数据来感知周围环境；接着，根据感知结果规划下一步的行动轨迹；最后，将规划指令通过控制器传递给油门、刹车和转向系统。要独立研发这样一套系统，开发者不仅要精通传感器、路径规划算法和车辆控制技术，还得想方设法将它们无缝集成。更棘手的是，自动驾驶的落地测试严重依赖昂贵的基础设施，比如用于前期验证的仿真环境和用于实车测试的传感器套件。这些现实约束，让许多希望独立搭建自动驾驶系统的团队望而却步。

自2010年起，为了降低行业的准入门槛，各大厂商和研究机构纷纷推出了自家的自动驾驶软件平台。这其中包括业界的标杆产品，如 NVIDIA 的 DriveWorks、Elektrobit 的 EB robinos、Tier IV 的 Autoware 以及百度的 Apollo。此外，还有像 comma.ai 的 OpenPilot 这样专注于高级驾驶辅助系统（ADAS）的平台，以及 RoboCar、AutoRally 等来自学术界的贡献。

这些平台根据其开放程度、应用场景和自动驾驶等级，可以大致分为几类（如图1所示）。那些非开源的商业平台（如 DriveWorks、EB robinos）由于限制了代码修改和再分发，一定程度上减缓了技术的快速迭代。相反，像 Autoware、Apollo 这样的开源平台，凭借全球开发者社区的集体智慧，演化速度更快、灵活性更强，也更有可能成为未来的行业标准。

图1：自动驾驶软件平台的分类

在众多开源选项中，若要追求完全自动驾驶，平台的可扩展性和自动驾驶等级是两个硬指标。像 OpenPilot 这类侧重于 ADAS 功能的平台，难以支撑 L4 级以上的高阶自动驾驶。而 Autoware 和 Apollo 则都瞄准了 L4 级及以上的完全自动驾驶技术。因此，对于希望将自动驾驶技术推向商业化应用的开发者来说，兼顾工业级可扩展性与高阶自动驾驶能力的 Autoware 和 Apollo，无疑是两个绕不开的选项。

尽管此前已有不少研究分别介绍过 Autoware 的软件架构或 Apollo 的规划算法，但真正将两者放在同一维度下进行系统、量化对比的分析却少之又少。这也导致开发者在做选型决策时，往往缺乏客观的依据。本文正是为了填补这一空白。

自动驾驶软件平台的定义

要深入比较 Autoware 和 Apollo，需要先明确什么是自动驾驶软件平台。这得从“软件平台”的基本概念说起。通常，软件平台指的是一个“地基”——它为外部开发者提供核心功能与基础设施，让他们能在此基础上搭建各种应用。一个典型的软件平台架构通常包含三个层面（如图3所示）：

图3：软件平台的架构

• 核心功能：指那些开发应用必不可少的基础能力，比如数据传输、交互响应、资源调配等。
• 基础设施：指支撑核心功能运行的硬件资源，如显示器、CPU、内存等。
• 接口：负责连通核心功能、基础设施与上层应用，确保数据流畅通无阻。

把这一概念延伸到自动驾驶领域，自动驾驶软件平台则需要应对更加严苛的实时环境与计算负载。它的架构（如图2所示）可以细化为：

• 核心功能：一是负责模块间数据通信的中间件；二是串联起整个自动驾驶流程的核心模块（定位、感知、规划、控制）。
• 基础设施：包括传感器、高精地图、仿真模拟器等一系列测试与部署的必备资源。
• 接口：确保各算法模块与硬件资源间数据传输的稳定与高效。

图2：自动驾驶软件平台的架构。核心功能包括用于模块间数据通信的中间件。核心模块执行全栈自动驾驶所需的基本功能，例如定位、感知、规划和控制。基础设施则由运行这些模块所必需的传感器、地图和模拟器组成。

Autoware 与 Apollo 核心架构对比

A

中间件：数据流转的“高速公路”

中间件负责在各个算法模块之间传递海量数据，是系统的神经中枢（如图4所示）。

图4：Autoware 和 Apollo 所使用的中间件的数据流。原始数据从核心感知模块传输。在 Autoware 中，数据在发布端套接字和订阅端套接字之间通过序列化进行分片传输。相比之下，Apollo 将原始数据直接传输到共享内存，无需序列化，从而使核心规划模块能够直接从共享内存中访问原始数据。

1. Autoware 基于 ROS2，采用 DDS（数据分发服务） 作为中间件。DDS 的工作模式是在发布者和订阅者之间建立 Socket 连接，并在发送数据前进行序列化处理（可以理解为把大件货物拆成小包裹，收到后再重新组装）。这种方法在处理大规模数据时，拆包和打包的过程容易成为性能瓶颈。
2. Apollo 则使用自研的 CyberRT 中间件。它的设计思路截然不同：通过开辟一块共享内存区域，发布者直接把数据写进去，订阅者直接从中读取。这种机制省去了繁琐的序列化与反序列化过程，数据传输速度极快。不过，这也带来了新的挑战——如果多个进程同时读写同一块内存而没有做好同步管理，可能会导致数据错乱。

B

定位模块：我在哪里？

定位是自动驾驶的第一步，需要综合 IMU、GNSS、LiDAR、摄像头等多种传感器的数据来估算车辆自身的位置和姿态（如图5所示）。

图5：Autoware 和 Apollo 所使用的核心定位模块的内部结构。该模块利用 IMU、GNSS 和 LiDAR 进行位置估计。在 LiDAR 定位中，利用预构建的点云地图来确定车辆位置。从各传感器获得的位置估计值通过卡尔曼滤波技术进行融合，以提高精度。

• GNSS 策略差异：两者都依赖 IMU 和 GNSS。但在处理 GNSS 信号时，Autoware 主要依赖卫星原始信号；而 Apollo 引入了 RTK（实时动态差分）等参考站校正数据，定位精度更高。
• LiDAR 算法差异：在利用 LiDAR 点云匹配定位时，Autoware 采用 NDT（正态分布变换）算法结合扩展卡尔曼滤波（EKF）；Apollo 则将点云投射到鸟瞰图（BEV），利用 Lucas-Kanade 光流法配合直方图滤波，以此来降低计算量。
• 传感器融合：两者最终都通过卡尔曼滤波技术来融合多传感器数据。不同之处在于，Autoware 使用 EKF，而 Apollo 使用误差状态卡尔曼滤波（ESKF），后者在处理非线性误差时收敛性更稳定。

C

感知模块：周围有什么？

感知模块通过处理雷达、LiDAR 和摄像头数据，识别出周围物体的位置、尺寸、朝向等信息（如图6所示）。

图6：Autoware 和 Apollo 所使用的核心感知模块的内部结构。数据从视觉传感器（如雷达、LiDAR 和摄像头）获取。这些数据通过针对各传感器设计的检测算法进行处理，然后传输至预测模块和感知模块。

• 方法融合：Autoware 在传统基于模型的方法（如 L-Shape Fitting）基础上，融合了 PointPillars、YOLOX 等数据驱动的深度学习模型。Apollo 同样支持 PointPillars、CenterPoint 等多种前沿模型，并且特意强化了前后摄像头的协同感知能力，以降低视野盲区带来的碰撞风险。
• 功能覆盖：两者均具备交通信号灯识别能力，能够将红绿灯状态实时传递给规划模块。

D

规划模块：我要怎么走？

规划模块根据自车位置和周围环境信息，生成一条安全、可行的行驶轨迹（如图7所示）。

图7：Autoware 和 Apollo 所使用的核心规划模块的内部结构。仅激活一部分场景和交通规则。被激活的场景生成一条轨迹，随后该轨迹被传输至控制模块。

• 场景处理机制：Autoware 会并行计算多种场景（如车道保持、停车），然后由一个选择器根据当前情况激活最优方案。这意味着系统一直在后台同时运算多种可能性。
• Apollo 的高效策略：Apollo 则会先结合交规和环境因素进行预判，直接选定一个单一场景，然后按顺序执行该场景下的各个阶段任务。这种设计避免了为无关场景浪费算力，计算开销更小。

E

控制模块：怎么精准执行？

控制模块负责将规划好的轨迹转化为车辆的实际动作，分为横向（转向）和纵向（油门/刹车）控制（如图8所示）。

图8：Autoware 和 Apollo 所使用的核心控制模块的内部结构。Autoware 提供独立的横向和纵向控制器，而 Apollo 还提供了一种集成了两者的混合控制器。

• Autoware：横向控制提供纯追踪和模型预测控制（MPC）两种方案；纵向控制采用传统的 PID 控制器。
• Apollo：横向控制采用线性二次调节器（LQR），纵向也使用 PID。此外，Apollo 还额外提供了一种混合 MPC 控制器，能够将横向与纵向控制一体化考虑，在车辆激烈驾驶或复杂路况下，这种耦合控制往往能带来更好的表现。

量化实验

为了客观评价这两个平台，我们从功能丰富度和中间件性能两个维度进行了量化对比。

A

核心模块子功能统计

通过深入分析两平台的源码与官方文档，我们统计了各核心模块下的具体算法/功能点数量（详见表1）。

• 定位：Autoware 选项更多，提供了 5 种方案（含基于摄像头的方法），而 Apollo 为 3 种。
• 感知：Apollo 在摄像头感知方面投入巨大，支持多达 27 种相关组件，显著高于 Autoware 的 13 种。
• 规划：Apollo 在交通规则和具体任务拆解上更为细致（21 个任务节点），而 Autoware 提供的驾驶场景更丰富（14 种场景）。

B

中间件性能极限测试

中间件的核心使命是快且准地传输数据。我们测试了在不同数据量、不同频率下，FastDDS（Autoware 所用）与 CyberRT（Apollo 所用）的延迟、CPU 占用、内存消耗和丢包率（如图9和表2所示）。

图9：基于数据大小、频率和订阅者数量的中间件通信性能结果。第一行表示数据大小，第二行表示频率，第三行表示订阅者数量。第一列表示延迟，第二列表示CPU使用率，第三列表示内存使用量，第四列表示消息丢失率。

测试结果非常直观：

• 延迟对比：在处理超大容量数据（如高端传感器数据流）时，FastDDS 的延迟达到了毫秒级（约 380ms），而 CyberRT 依然维持在微秒级（约 1.72μs）。这得益于 CyberRT 的共享内存机制，完全规避了数据序列化带来的巨大开销。
• 资源消耗：CyberRT 的低延迟并非没有代价。由于需要使用共享内存，其内存占用量普遍比 FastDDS 高出几十到上百兆字节。在 CPU 占用率上，两者差异不大。

结论与选型建议

通过这次深入对比，可以得出以下结论：

• 功能广度各有侧重：Autoware 在定位模块的多样性上略有优势；而 Apollo 在感知（尤其是视觉）和规划（任务拆解）方面提供了更庞大的组件库。
• 架构设计理念不同：Apollo 的 CyberRT 中间件在性能上展现出绝对优势，特别是在高负载、大数据的传输场景下，其基于共享内存的设计带来了极低的延迟，是追求极致实时性的首选。但其代价是更高的内存开销。

如何选择：

• 如果项目对实时性要求极高（如高速场景下的紧急避障），且硬件内存充裕，Apollo 的性能优势会非常明显。
• 如果团队熟悉 ROS2 生态，或者项目前期希望快速搭建原型、灵活测试不同算法，Autoware 的开放性和模块化程度可能更适合。

希望这份详尽的对比，能为正在探索自动驾驶开源世界的你，提供一份有价值的参考。

以上内容如有错误请留言评论，欢迎指正交流。如有侵权，请联系删除