1. 课程导论与平台概览

大家好，我是你们这门课的老朋友。今天咱们正式开篇。

说实话，这几年我接触了不少自动驾驶项目，从早期的Demo演示到现在的量产落地，有两个名字你肯定绕不开——Autoware 和 Apollo。很多刚入行的朋友会问我：“这两个到底选哪个？” 我的回答通常是：“小孩子才做选择，成年人全都要。” 当然，这是玩笑话。但真正懂行的人都知道，协同开发才是降本增效的王道。

1.1 它们到底在解决什么问题？

先聊聊定位。

Autoware 是什么？它更像一个“乐高积木箱”。它基于ROS/ROS2，把感知、规划、控制这些模块拆得特别细。你想想看，如果你是个算法研究员，想快速验证一个新想法，Autoware的灵活性会让你爱不释手。我个人习惯用它来做算法原型验证，因为改一个节点、换一个模型，几乎不用动框架。

Apollo 呢？它更像一辆“成品车”。百度把硬件、软件、云端服务都给你打包好了。它的强项在于工程化和高精地图。我记得有一次做园区物流项目，甲方要求一周内跑通闭环。我直接用了Apollo的Dreamview，配合它的云端标定服务，三天就搞定了。说白了，Apollo适合快速落地，尤其是当你不想从零搭环境的时候。

1.2 核心功能对比：别被表面现象迷惑

很多人喜欢列个表，把功能一条条对比。我也列一个，但我会告诉你哪些是“真功夫”，哪些是“花架子”。

对比维度	Autoware	Apollo
定位	开源算法框架	全栈自动驾驶平台
核心语言	C++ / Python (ROS2)	C++ / Python (CyberRT)
高精地图	支持，但工具链较弱	强，自带HD Map引擎
感知模块	灵活，可替换性强	集成度高，但耦合性强
规划控制	多种算法可选	基于规则的优化方案
仿真环境	依赖第三方	自带Dreamview + SimControl
社区活跃度	全球开发者，偏学术	国内为主，偏工业

嗯，这里要注意。很多人看到Apollo的感知模块集成度高，就觉得它好。其实不然。我在项目中遇到过一个问题：Apollo的感知输出格式是固定的，你想换一个自己训练的YOLOv8模型，得改一堆接口代码。而Autoware这边，你只要把话题名对上，模型随便换。这就是灵活性和集成度的取舍。

1.3 协同开发的价值：1+1 > 2

为什么我们要把这两个平台放在一起讲？因为现实项目里，你根本不可能只用一套方案。

举个例子。我之前做一个港口无人驾驶项目，环境特别复杂，有集装箱、有龙门吊、还有各种不规则障碍物。Apollo的默认感知模型在那种场景下误检率很高。怎么办？我把Autoware的Lidar感知模块（基于PointPillars）移植到了Apollo的CyberRT框架下。前端用Autoware的算法，后端用Apollo的规划控制，效果出奇的好。

这就是协同开发的价值：

• 取长补短：用Autoware的灵活性弥补Apollo的僵化，用Apollo的工程化弥补Autoware的松散。
• 降低风险：如果某个模块在A平台上跑不通，马上切到B平台试试。我称之为“双保险”。
• 加速迭代：算法团队用Autoware快速验证，工程团队用Apollo做集成测试，互不干扰。

1.4 挑战：别以为协同就是复制粘贴

当然，协同开发不是请客吃饭。我踩过的坑，今天先给你提个醒。

• 框架差异：Autoware用ROS2，Apollo用CyberRT。消息格式、通信机制完全不同。我曾经花了一周时间写一个桥接节点，就为了把Autoware的PointCloud2转成Apollo的SensorMessage。嗯，那周我头发掉了不少。
• 版本兼容性：Autoware的版本迭代很快，从Auto到Universe，API变了好几次。Apollo的版本也很多，3.5、5.0、6.0、7.0，每个版本的模块结构都不一样。你如果拿Autoware.Universe的代码去对接Apollo 5.0，大概率会报错。
• 社区割裂：两个社区的开发习惯不同。Autoware社区喜欢用GitHub Issue讨论，Apollo社区更依赖百度自己的论坛。遇到问题，你得两边找答案。

1.5 知识体系总览：一张图看懂本章

说了这么多，咱们来张图总结一下。这张图是我自己画的，把Autoware和Apollo的定位、核心差异、协同价值以及挑战都串起来了。你保存下来，以后复习的时候看一眼就明白。

这张图你看懂了吗？说白了，Autoware和Apollo不是竞争对手，而是互补的。你掌握了协同开发的思路，就等于同时拥有了两把利器。

好了，这一章的内容就到这里。记住，不要纠结于“选哪个”，而是要思考“怎么一起用”。下一章我们会深入搭建开发环境，到时候我会手把手教你如何把这两个平台装在同一台机器上，并且让它们“和平共处”。