一、Apollo与Autoware概述：两大开源自动驾驶框架的起源、发展历程与社区生态对比
1.1 为什么我们要聊这两个框架？
做自动驾驶开发的朋友，一定绕不开两个名字——Apollo和Autoware。
我入行那会儿，市面上能用的开源自动驾驶框架屈指可数。那时候大家要么自己从零搭一套，要么就盯着这两个框架看。说实话，我最早接触的是Autoware，后来因为项目需要才转去研究Apollo。两个框架都用过之后，我发现它们的设计哲学差异还挺大的。
今天这一章，我们先从宏观上看看这两个框架的来龙去脉。说白了，就是搞清楚它们从哪里来，现在发展到什么程度了，以及各自的社区生态怎么样。
核心观点：Apollo和Autoware代表了两种不同的开源路线——Apollo偏向工业级、系统化；Autoware更偏向学术研究、模块化。没有绝对的好坏，关键看你的应用场景。
1.2 Apollo的起源与发展
Apollo是百度在2017年推出的。我记得那年百度AI开发者大会上，陆奇宣布Apollo开源的时候，整个自动驾驶圈都炸了。为什么？因为在此之前，很少有大型互联网公司愿意把整套自动驾驶技术拿出来开源。
Apollo的发展历程，我大致分了几个阶段：
- 1.0版本（2017年）：主要聚焦在封闭场景的循迹驾驶。说白了就是让车能沿着固定路线跑。那时候功能很基础，但架构已经搭起来了。
- 1.5版本（2017年）：加入了障碍物感知、决策规划。嗯，这时候开始有点自动驾驶的样子了。
- 2.0版本（2018年）：支持简单城市道路。我记得当时在测试场跑的时候，遇到红绿灯和行人已经能做出基本反应了。
- 3.0版本（2018年）：引入了硬件参考设计。这个很重要——它告诉你该用什么传感器、怎么装。
- 3.5版本（2019年）：支持复杂城市道路。无保护左转、环岛这些场景开始能处理了。
- 5.0版本（2019年）：加入了V2X（车路协同）。我个人觉得这是Apollo的一个特色，它不只是做单车智能。
- 6.0版本（2021年）：引入了"点到点"的城市自动驾驶。这时候的Apollo已经相当成熟了。
- 7.0版本（2022年）：进一步优化了算法和工具链，降低了二次开发的门槛。
我的经验：如果你刚开始接触Apollo，建议从3.5版本开始看。因为3.5之后的版本架构相对稳定，文档也比较全。我当年从1.5开始看，后来版本迭代太快，很多接口都变了，踩了不少坑。
1.3 Autoware的起源与发展
Autoware的故事要从2015年说起。它最初是由日本名古屋大学的加藤真平教授团队开发的。你想想看，一个学术团队做的框架，后来能发展成全球知名的自动驾驶开源项目，这本身就挺了不起的。
Autoware的发展脉络是这样的：
- Autoware 1.0（2015-2019年）：基于ROS1。那时候它更像是一个算法工具箱，把各种感知、规划、控制的算法集成在一起。我最早用的就是1.0版本，说实话，集成度不高，但胜在灵活。
- Autoware.AI（2019年）：这是1.0的延续版本，加入了更多AI相关的算法模块。
- Autoware.Auto（2020年）：基于ROS2重新开发。这是一个大版本升级，代码质量、安全性都有明显提升。我记得当时迁移的时候，很多接口都变了，但架构确实更清晰了。
- Autoware Core/Universe（2022年至今）：这是最新的架构。Core提供核心功能，Universe是社区贡献的扩展包。说白了，就是核心稳定、外围灵活。
注意：Autoware的版本命名有点乱。1.0、AI、Auto、Core/Universe，每个版本之间的代码结构差异很大。如果你在网上搜教程，一定要看清楚版本号。我曾经因为没注意版本，照着1.0的教程配Auto的环境，折腾了两天才发现是版本不匹配。
1.4 社区生态对比
聊完发展历程，我们来看看社区生态。这部分我直接做个表格，对比起来更清楚：
| 对比维度 | Apollo | Autoware |
|---|---|---|
| 主导方 | 百度（商业公司） | 名古屋大学 → Autoware基金会（非营利组织） |
| 开源协议 | Apache 2.0 | Apache 2.0 |
| 主要语言 | C++为主，Python为辅 | C++为主，Python为辅 |
| 中间件 | 自研Cyber RT | ROS1 → ROS2 |
| 社区活跃度 | 高，中文社区活跃 | 高，国际社区活跃 |
| 文档质量 | 中文文档完善，英文稍弱 | 英文文档完善，中文较少 |
| 商业化程度 | 高，有商业版本 | 低，以研究为主 |
| 硬件支持 | 有参考硬件设计 | 无官方硬件参考 |
从表格能看出来，两个框架的定位差异很明显。Apollo更像是一个"产品"，它告诉你该用什么硬件、怎么部署、怎么调试。Autoware更像是一个"研究平台"，它给你一堆算法模块，你自己去组合。
我个人觉得，如果你是在企业做产品，Apollo可能更适合你。如果你是做学术研究或者想深入理解每个算法模块，Autoware会更灵活。
1.5 核心架构对比图
下面我用一张SVG图来展示两个框架的核心架构对比。这张图我画了好几次才满意，希望能帮你快速建立整体认知：
从这张图你能看出来，Apollo是典型的分层架构，每一层职责清晰，层与层之间通过Cyber RT通信。Autoware则是模块化架构，每个模块相对独立，通过ROS2的Topic/Service通信。
我的建议：如果你团队里有系统工程师，Apollo的分层架构更容易做系统集成。如果你团队里都是算法专家，Autoware的模块化架构更适合各自独立开发。
1.6 选型建议
说了这么多，到底该怎么选？我根据自己的经验，给你几个参考维度：
- 看团队背景：如果团队有ROS开发经验，Autoware上手更快。如果团队有嵌入式系统开发经验，Apollo的Cyber RT可能更顺手。
- 看应用场景：做园区物流、低速场景，Autoware够用了。做高速、城市道路，Apollo的工业级设计更靠谱。
- 看商业化需求：如果最终要量产，Apollo的商业化支持更好。如果只是做原型验证，Autoware更灵活。
- 看社区支持：国内项目建议优先考虑Apollo，中文社区活跃，遇到问题好解决。国际项目或者学术研究，Autoware的社区资源更丰富。
避坑指南：我曾经在一个项目里，团队一半人用Apollo，一半人用Autoware，结果集成的时候出了大问题——两个框架的数据格式、通信协议完全不同。所以，选型一定要统一，不要混用。
好了，这一章我们聊了Apollo和Autoware的起源、发展历程和社区生态。下一章我们会深入技术细节，看看两个框架在感知模块上的具体实现差异。到时候我会结合代码，给大家讲讲我在实际项目中踩过的坑。