自动驾驶 Apollo 源码分析系列，感知篇(一)

我是自动驾驶从业者，百度的 Apollo 是行业优秀的开源框架，近几年发展的比较快，基于对技术的热爱，我计划用 3 个月的样子来学习 Apollo 的源码，以提升自己的自动驾驶认知和技术。

在 Apollo 官网它有显示自己开放平台的架构，我关注于算法及代码实现。

自动驾驶公认的分层架构是：

感知
决策
控制
执行

所以，系列文章我先从感知模块开始。

当前 Apollo 版本是 6.0，所以这一系列文章都是 Apollo 6.0。

百度 Apollo 是基于 Lidar 的，这个需要明白这一点。

即使在当前，一款机械式的激光雷达也要 10 多万出头，仪器比车贵，所以我认为 Apollo 的方案大规模和普通用户见面还需要硬件领域的发展和成本优化，这需要整个行业的努力。

当然，如果 L4 面向政府、大型企业，高昂的传感器成本是可以通过运营持续的收入承接的，用激光雷达也没有什么问题。

高端车用激光雷达也没有什么问题。

现实是普通大众还是很在乎成本的，据我了解到 Apollo 也在摸索纯视觉的方案，如果真的成熟了成本会急剧下降。

传感器

讲感知不能不提到机器视觉，但视觉不仅仅包括摄像头，还包括其它的传感器。

Apollo 有 360 度感知能力，因为它配备了下面的传感器：

前视摄像头 2 个(6mm 焦距 1 个，12mm 焦距 1 个)
毫米波雷达 2 个(前向、后向)
激光雷达 3个(128 线 1 个，16 线前后向各1个)

感知的目的

我们在学习源码的时候，最好的方式就是先了解这个东西是干吗用的。

Apollo 的感知目的就是 2 个：

障碍物检测(车、行人或者其它交通要素)
红绿灯检测

借助于激光雷达和深度学习，Apollo 的感知模块能够输出障碍物的 3D 信息。

感知融合

自动驾驶靠单一的传感器不满足安全冗余的要求，所以自动驾驶的解决方案都会进行多传感器的融合。

Apollo 的感知模块需要接收传感器信息及自车速度信息，经过内部算法处理最终输出障碍物的 3D 轨迹和交通灯探测结果。

其中，3D 障碍物轨迹其实就是融合的体现。

camera

打开源码中 camera 的目录

从代码目录中可以看到 camera 主要任务有 4 个：

障碍物感知
车道检测
交通灯检测
障碍物和车道检测基础上计算出来的 CIPV(closest in-path vehicle)

Radar

相比于 Camera，Radar 的任务单一，它只处理障碍物的检测。

Lidar

Lidar 的感知主要是处理点云数据，Apollo 6.0 会应用 PointPillar 模型得到障碍物的 3D 信息,也就是能得到障碍物的 3D 尺寸框加上速度和偏航角信息。

Lidar 输出的信息送到 Fusion 组件和 Camera 、Radar 的结果进行融合，形成最终的 3D 障碍物跟踪轨迹。

Fusion

感知模块的核心应该是融合.

不同的自动驾驶场景要求的传感器不一样，也许是纯视觉方案，也许是激光雷达为主，也许是视觉+毫米波雷达，但无论传感器怎么配置，多传感器的融合也必不可少。

融合的好坏决定了感知的好坏，甚至是一款自动驾驶产品的好坏。

所以，建议每一位关注自动驾驶感知的同学都要建立自己的传感器融合能力。

从代码目录上看，Apollo 要融合的东西大概这 5 样：

目标存在可能性的融合
目标运动状态的融合
目标形状的融合
目标轨迹融合
目标的类别融合

后续

我在浏览 Apollo 的代码是，确实感受到了工程的庞大，然后很多代码运用了很多设计模式的技巧，面向对象和多态封装的思想。

程序员应该加强代码的这种高度抽象和封装的能力，但同时我还是喜欢简单的代码，因为越简单越容易理解。

后续的文章，我将从 camera 讲起，之后 radar，然后 Lidar，然后 fusion，可能 fusion 我会花的时间更多点，因为我对它更感兴趣。