公众号致力于点云处理，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 这样的开源平台，凭借全球开发者社区的集体智慧，演化速度更快、灵活性更强，也更有可能成为未来的行业标准。
在众多开源选项中，若要追求完全自动驾驶，平台的可扩展性和自动驾驶等级是两个硬指标。像 OpenPilot 这类侧重于 ADAS 功能的平台，难以支撑 L4 级以上的高阶自动驾驶。而 Autoware 和 Apollo 则都瞄准了 L4 级及以上的完全自动驾驶技术。因此，对于希望将自动驾驶技术推向商业化应用的开发者来说，兼顾工业级可扩展性与高阶自动驾驶能力的 Autoware 和 Apollo，无疑是两个绕不开的选项。
尽管此前已有不少研究分别介绍过 Autoware 的软件架构或 Apollo 的规划算法，但真正将两者放在同一维度下进行系统、量化对比的分析却少之又少。这也导致开发者在做选型决策时，往往缺乏客观的依据。本文正是为了填补这一空白。
要深入比较 Autoware 和 Apollo，需要先明确什么是自动驾驶软件平台。这得从“软件平台”的基本概念说起。通常，软件平台指的是一个“地基”——它为外部开发者提供核心功能与基础设施，让他们能在此基础上搭建各种应用。一个典型的软件平台架构通常包含三个层面（如图3所示）：
核心功能：指那些开发应用必不可少的基础能力，比如数据传输、交互响应、资源调配等。
基础设施：指支撑核心功能运行的硬件资源，如显示器、CPU、内存等。
接口：负责连通核心功能、基础设施与上层应用，确保数据流畅通无阻。
把这一概念延伸到自动驾驶领域，自动驾驶软件平台则需要应对更加严苛的实时环境与计算负载。它的架构（如图2所示）可以细化为：
核心功能：一是负责模块间数据通信的中间件；二是串联起整个自动驾驶流程的核心模块（定位、感知、规划、控制）。
基础设施：包括传感器、高精地图、仿真模拟器等一系列测试与部署的必备资源。
接口：确保各算法模块与硬件资源间数据传输的稳定与高效。
图2：自动驾驶软件平台的架构。核心功能包括用于模块间数据通信的中间件。核心模块执行全栈自动驾驶所需的基本功能，例如定位、感知、规划和控制。基础设施则由运行这些模块所必需的传感器、地图和模拟器组成。
中间件负责在各个算法模块之间传递海量数据，是系统的神经中枢（如图4所示）。
图4：Autoware 和 Apollo 所使用的中间件的数据流。原始数据从核心感知模块传输。在 Autoware 中，数据在发布端套接字和订阅端套接字之间通过序列化进行分片传输。相比之下，Apollo 将原始数据直接传输到共享内存，无需序列化，从而使核心规划模块能够直接从共享内存中访问原始数据。
Autoware 基于 ROS2，采用 DDS（数据分发服务） 作为中间件。DDS 的工作模式是在发布者和订阅者之间建立 Socket 连接，并在发送数据前进行序列化处理（可以理解为把大件货物拆成小包裹，收到后再重新组装）。这种方法在处理大规模数据时，拆包和打包的过程容易成为性能瓶颈。
Apollo 则使用自研的 CyberRT 中间件。它的设计思路截然不同：通过开辟一块共享内存区域，发布者直接把数据写进去，订阅者直接从中读取。这种机制省去了繁琐的序列化与反序列化过程，数据传输速度极快。不过，这也带来了新的挑战——如果多个进程同时读写同一块内存而没有做好同步管理，可能会导致数据错乱。
定位是自动驾驶的第一步，需要综合 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），后者在处理非线性误差时收敛性更稳定。
感知模块通过处理雷达、LiDAR 和摄像头数据，识别出周围物体的位置、尺寸、朝向等信息（如图6所示）。
图6：Autoware 和 Apollo 所使用的核心感知模块的内部结构。数据从视觉传感器（如雷达、LiDAR 和摄像头）获取。这些数据通过针对各传感器设计的检测算法进行处理，然后传输至预测模块和感知模块。
方法融合：Autoware 在传统基于模型的方法（如 L-Shape Fitting）基础上，融合了 PointPillars、YOLOX 等数据驱动的深度学习模型。Apollo 同样支持 PointPillars、CenterPoint 等多种前沿模型，并且特意强化了前后摄像头的协同感知能力，以降低视野盲区带来的碰撞风险。
功能覆盖：两者均具备交通信号灯识别能力，能够将红绿灯状态实时传递给规划模块。
规划模块根据自车位置和周围环境信息，生成一条安全、可行的行驶轨迹（如图7所示）。
图7：Autoware 和 Apollo 所使用的核心规划模块的内部结构。仅激活一部分场景和交通规则。被激活的场景生成一条轨迹，随后该轨迹被传输至控制模块。
控制模块负责将规划好的轨迹转化为车辆的实际动作，分为横向（转向）和纵向（油门/刹车）控制（如图8所示）。
图8：Autoware 和 Apollo 所使用的核心控制模块的内部结构。Autoware 提供独立的横向和纵向控制器，而 Apollo 还提供了一种集成了两者的混合控制器。
为了客观评价这两个平台，我们从功能丰富度和中间件性能两个维度进行了量化对比。
通过深入分析两平台的源码与官方文档，我们统计了各核心模块下的具体算法/功能点数量（详见表1）。
定位：Autoware 选项更多，提供了 5 种方案（含基于摄像头的方法），而 Apollo 为 3 种。
感知：Apollo 在摄像头感知方面投入巨大，支持多达 27 种相关组件，显著高于 Autoware 的 13 种。
规划：Apollo 在交通规则和具体任务拆解上更为细致（21 个任务节点），而 Autoware 提供的驾驶场景更丰富（14 种场景）。
中间件的核心使命是快且准地传输数据。我们测试了在不同数据量、不同频率下，FastDDS（Autoware 所用）与 CyberRT（Apollo 所用）的延迟、CPU 占用、内存消耗和丢包率（如图9和表2所示）。
图9：基于数据大小、频率和订阅者数量的中间件通信性能结果。第一行表示数据大小，第二行表示频率，第三行表示订阅者数量。第一列表示延迟，第二列表示CPU使用率，第三列表示内存使用量，第四列表示消息丢失率。
测试结果非常直观：
延迟对比：在处理超大容量数据（如高端传感器数据流）时，FastDDS 的延迟达到了毫秒级（约 380ms），而 CyberRT 依然维持在微秒级（约 1.72μs）。这得益于 CyberRT 的共享内存机制，完全规避了数据序列化带来的巨大开销。
资源消耗：CyberRT 的低延迟并非没有代价。由于需要使用共享内存，其内存占用量普遍比 FastDDS 高出几十到上百兆字节。在 CPU 占用率上，两者差异不大。
通过这次深入对比，可以得出以下结论：
如何选择：
希望这份详尽的对比，能为正在探索自动驾驶开源世界的你，提供一份有价值的参考。
以上内容如有错误请留言评论，欢迎指正交流。如有侵权，请联系删除
扫描二维码
关注我们
让我们一起分享一起学习吧！期待有想法，乐于分享的小伙伴加入知识星球注入爱分享的新鲜活力。分享的主题包含但不限于三维视觉，点云，具身智能，自动驾驶，以及机器人等相关的领域。
分享与合作：微信“920177957”（备注：姓名+学校/公司+研究方向） 联系邮箱：dianyunpcl@163.com。
10个月宝宝每天需要喝多少奶粉？
