📚 课程目录第1章课程导论

1. 课程导论

各位同学，欢迎来到《Apollo与Autoware接口适配实战》课程。

我是你们这门课的主讲人。在自动驾驶行业摸爬滚打了七八年，从最早的机器人操作系统（ROS）玩起，到后来深度参与Apollo和Autoware的项目落地，说实话，踩过的坑比走过的路还多。今天咱们开篇，先聊聊这两个平台到底是怎么回事，为什么非要搞接口适配，以及这门课能带给你什么。

先说说Apollo。百度开源的Apollo，可以说是国内自动驾驶领域的“黄埔军校”。它架构清晰，模块化做得特别好。从高精地图、定位、感知、预测到规划控制，一条龙服务。我个人习惯把它比作一个“豪华精装房”——拎包入住，但装修风格是固定的，你想改个承重墙？嗯，得费点劲。

再说Autoware。这是源自名古屋大学的开源项目，后来由Autoware基金会维护。它更偏向于研究机构和创业公司。Autoware的强项在于算法灵活，尤其是基于ROS 2的架构，让开发者可以像搭积木一样替换自己的算法模块。说白了，它更像一个“毛坯房”——你想怎么装就怎么装，但水电煤气都得自己接。

核心区别一句话总结：

我在项目中遇到过不少团队，一开始选了Apollo，发现想换一个感知模型，得改一堆代码；后来换了Autoware，又发现想跑通一个完整的实车测试，光调参就花了两周。你看，没有完美的平台，只有合适的场景。

你可能会问：“既然两个平台都这么成熟，我选一个用不就行了？为什么非要搞适配？”

这个问题问得好。我举个例子你就明白了。

假设你是一家自动驾驶公司的技术负责人。你们用Apollo做感知和规划，但你们自己研发了一套非常牛的决策算法，是基于Autoware的框架写的。这时候问题来了——Apollo的感知输出是Protobuf格式，Autoware的决策输入是ROS 2的Topic。两个数据格式不兼容，接口对不上。

怎么办？

硬改Apollo的代码？风险太大，升级版本时全得重来。重写Autoware的接口？工作量巨大，而且容易引入bug。

这就是接口适配的价值所在。它就像一座“桥梁”，让两个平台的数据和消息能够互相理解、互相传递。没有这座桥，你只能二选一，或者自己造轮子。

避坑指南：

我曾经在一个项目中，为了省事，直接修改了Apollo的感知输出格式来匹配Autoware。结果Apollo升级了一个小版本，所有修改全部冲突，整整花了一周时间回滚和重做。从那以后，我再也不敢直接改源码了。老老实实做适配层，才是正道。

接口适配的核心价值，我总结为三点：

这门课的目标很明确：让你掌握在Apollo和Autoware之间搭建接口适配层的完整技能。

学完之后，你能做到：

学习路径我建议这样走：

阶段	内容	预计时间
基础篇	Apollo与Autoware架构详解、消息格式对比	2周
核心篇	适配器设计模式、Protobuf与ROS 2消息互转	3周
实战篇	激光雷达数据适配、规划控制指令适配、实车调试	4周
进阶篇	性能优化、多传感器融合适配、故障排查	2周

你想想看，如果你能把这套技能吃透，以后不管遇到什么自动驾驶平台，你都能快速上手。因为底层逻辑是一样的——数据流、消息格式、通信机制。说白了，一通百通。

注意事项：

这门课需要你有一定的ROS或ROS 2基础，至少知道什么是Topic、什么是Node。如果你完全零基础，建议先花一周时间补一下ROS基础。否则后面实战部分可能会有点吃力。

好了，开篇就聊这么多。下面这张图是我自己画的，展示了Apollo和Autoware在接口适配中的核心关系。你可以先有个整体印象。