自动驾驶汽车的故事：从DARPA挑战赛到纯视觉与激光雷达路线之争

1. 从“自动驾驶汽车的故事”说起这个项目到底在讲什么第一次看到“自动驾驶1-3 自动驾驶汽车的故事”这个标题我脑子里冒出来的第一个念头是这大概率不是一篇纯技术论文也不是一份产品说明书而更像是一个系列内容的第三讲用“讲故事”的方式把自动驾驶这件事从头到尾捋一遍。事实也确实如此——这类标题通常出现在系列课程、科普专栏或者内部技术分享的目录里编号“1-3”意味着它是某个模块下的第三个子话题前面大概率已经讲过了“自动驾驶是什么”和“自动驾驶的分级”到这里开始进入“故事线”的梳理。那这个“故事”到底能做什么说白了它解决的是一个非常实际的问题大多数人对于自动驾驶的认知是碎片化的。你可能刷到过某家公司路测的视频也听说过激光雷达和纯视觉路线之争甚至能说出L2、L3、L4这几个级别但要把这些点串成一条完整的线——从最早的幻想到实验室里的原型再到今天路上跑的量产车——大部分人脑子里是断片的。这个项目要做的就是用叙事的方式把这条线补上让听的人不仅知道“现在有什么”还能理解“为什么会走到今天这一步”。适合谁来参考我梳理了一下大概有三类人第一类是刚进入这个行业的新人不管是做算法、做系统还是做产品都需要一个全局视角来定位自己手头的工作第二类是做技术科普或者内容创作的人需要一条清晰的故事线来组织素材第三类是对自动驾驶感兴趣但非科班出身的产品经理、投资人或者纯粹的技术爱好者他们不需要推导公式但需要理解关键节点和背后的逻辑。我自己带过几个新人发现他们最缺的从来不是某个具体算法的细节而是“这件事是怎么一步步变成今天这样的”这种历史感。没有这种历史感做决策的时候就容易只看眼前容易跟风容易在路线选择上摇摆。所以这篇博文我会围绕“自动驾驶汽车的故事”这个核心把整个发展脉络拆开来讲同时补充大量实操层面的细节——比如不同阶段的技术方案是怎么选的、关键参数是怎么定的、踩过哪些坑、现在回头看哪些决策是对的哪些是走了弯路。我会尽量用从业者之间聊天的口吻把复杂的东西讲清楚让你读完能直接拿去用不管是做分享、写报告还是单纯跟人聊这个话题都能有货可讲。2. 自动驾驶的“史前时代”从幻想走到实验室2.1 最早的自动驾驶想象为什么都长一个样聊自动驾驶的故事如果直接从2004年的DARPA挑战赛开始其实漏掉了很重要的一段——也就是在技术真正落地之前人们是怎么想象这件事的。我翻过不少早期的资料发现一个很有意思的现象在20世纪中期之前几乎所有关于“无人驾驶”的想象都指向同一个画面——一条埋在地下的轨道或者电线车在上面跑不需要人操作。比如1939年纽约世博会上展出的“未来世界”模型里面就有通过无线电控制的车辆在专用道路上行驶的场景。再往后到1950年代通用汽车做过一个叫“Firebird II”的概念车也是基于埋线感应来导航的。为什么早期的想象都长这样因为当时的技术条件决定了要让车自己跑最可靠的方式不是让车“看”路而是让路“告诉”车怎么走。这就像你教一个盲人走路最稳妥的办法不是给他一根拐杖让他自己摸索而是给他铺一条盲道。埋线感应、轨道导航这些方案本质上就是把“感知”这个最难的环节从车上挪到了路上车只需要跟着信号走就行了。这个思路在当时是合理的但它有一个致命的局限基础设施的改造成本太高了。你不可能把全国所有的路都挖开埋线所以这种方案只能停留在示范阶段没法规模化。这个阶段的“故事”给我们的启示其实很直接任何技术方案的选择都不是单纯的技术问题而是技术可行性、成本、规模化潜力三者之间的权衡。早期方案选择了“路来感知”是因为当时车载计算能力和传感器水平根本做不到“车来感知”后来之所以转向“车来感知”是因为摄像头、雷达、激光雷达这些传感器成熟了车载计算平台也足够强了把感知能力放在车上变得可行了。这个转折点才是自动驾驶故事真正的起点。2.2 从实验室到公路那些没被记住的早期尝试在DARPA挑战赛之前其实已经有不少实验室在做自动驾驶的原型了。我印象比较深的是1980年代卡内基梅隆大学做的ALV项目那辆车用激光雷达和摄像头做感知能在校园道路上以很低的速度自主行驶。还有德国慕尼黑联邦国防军大学在1990年代做的VaMP项目那辆车在高速上跑到了130公里每小时完成了长距离的自主驾驶测试。这些项目今天很少有人提但它们解决了很多基础问题——比如怎么把激光雷达的点云和摄像头的图像对齐、怎么在颠簸的路面上保持定位精度、怎么处理传感器数据的时间同步。这些早期尝试有一个共同特点它们都是在“受控环境”里做验证。所谓受控环境就是道路标线清晰、交通参与者少、天气条件好、路线提前规划好。在这种环境下感知和决策的难度被大大降低了算法能跑通但一旦换到真实城市道路马上就会崩。我后来跟一个做过早期原型的老工程师聊过他说他们当年最怕的就是下雨天因为激光雷达的反射会受雨滴影响摄像头也会因为雨刷的遮挡出现盲区整个系统就变得非常不稳定。这些问题在今天依然存在只是被更好的传感器和更鲁棒的算法缓解了但并没有完全消失。这个阶段的故事告诉我们一个很朴素的道理实验室里跑通和路上能跑是两码事。很多在论文里看起来很美的方法一到真实场景就露馅。所以后来整个行业的重心从“能不能跑”转向了“能不能在各种条件下都跑得稳”这个转向直接催生了后面一系列技术路线的分化。3. 分水岭DARPA挑战赛如何重塑了整个行业3.1 2004年和2005年两次比赛两种命运如果要给自动驾驶的故事找一个“转折点”那一定是DARPA挑战赛。2004年第一届比赛在莫哈韦沙漠举行赛道全长240公里结果所有参赛车辆加起来只跑了不到20公里成绩最好的那辆车在跑了11.9公里之后卡在了路边。那一年没有人完赛奖金没人拿走。但仅仅一年之后2005年的第二届比赛有五辆车完成了全程斯坦福大学的“Stanley”拿了冠军用时6小时53分。从0到5从跑不完到跑完全程中间只隔了一年。这一年里发生了什么我后来仔细看过那几年的技术报告发现关键突破集中在三个地方第一是传感器融合把激光雷达、摄像头、GPS和惯性测量单元的数据真正整合到一起而不是各干各的第二是概率算法用粒子滤波和卡尔曼滤波来处理定位和跟踪问题让系统能在噪声很大的情况下依然保持稳定第三是行为决策把“看到障碍物就刹车”这种简单逻辑升级成了“根据障碍物类型和运动状态决定是绕行还是等待”的决策树。这三件事今天听起来很基础但在当时是从0到1的突破。我特别想提一下“Stanley”那辆车的配置因为它很能说明问题。那辆车顶上装了一个旋转的激光雷达车头装了摄像头后备箱里塞了一台当时算力很强的工控机整个系统的功耗和发热都很惊人。但就是这套看起来笨重的设备证明了“车自己看路、自己决策”这条路是走得通的。从那以后整个行业的注意力就从“埋线导航”彻底转向了“车载感知”。3.2 2007年城市挑战赛从“能跑”到“能应对复杂场景”2007年的第三届DARPA挑战赛换到了城市环境赛道设在一个废弃的空军基地里模拟了城市道路、十字路口、停车场等各种场景还加入了其他车辆和行人。这一届的难度比前两届高了一个数量级因为城市环境里的不确定性太多了——别的车不按规矩走、行人突然窜出来、施工路段标线不清这些在沙漠里都不会遇到。这一届的冠军是卡内基梅隆大学的“Boss”车队他们的方案我研究过一段时间核心思路是把感知、预测、规划、控制分成四个独立的模块每个模块有自己的算法和参数模块之间通过标准接口通信。这个架构后来成了行业主流直到今天大部分自动驾驶系统还是这个套路。为什么这个架构能赢因为它把复杂问题拆解了每个模块可以独立优化出了问题也容易定位。比如车没刹住你可以先看感知有没有检测到障碍物再看预测有没有判断对障碍物的运动方向再看规划有没有生成刹车轨迹最后看控制有没有执行到位。这种可调试性在工程上太重要了。这一届比赛还有一个容易被忽略的贡献它定义了“场景”这个概念。以前大家做测试就是“跑一圈看看”但城市挑战赛把场景拆成了十字路口左转、避让行人、跟车行驶、变道超车等具体类别每个类别单独评分。这个思路后来被整个行业继承下来成了今天自动驾驶测试的基础框架。你现在看到的任何一份自动驾驶测试报告里面一定会有“场景覆盖率”这个指标源头就在这里。4. 技术路线的分化与收敛激光雷达还是纯视觉4.1 两条路线的底层逻辑差异DARPA挑战赛之后行业里逐渐分化出了两条主要的技术路线一条是以激光雷达为核心的多传感器融合路线另一条是以摄像头为核心的纯视觉路线。这两条路线的争论持续了十几年到今天也没有完全平息。我先把它们的底层逻辑讲清楚然后再聊各自的优劣。激光雷达路线的核心思想是用主动测距来构建环境的三维模型。激光雷达发射激光束测量反射回来的时间就能算出每个点的距离大量点合在一起就是点云。点云的好处是精度高、不受光照影响白天黑夜都能用而且能直接得到物体的三维形状和位置。但它的缺点也很明显贵、寿命短、在雨雪雾天气下性能会下降而且点云的数据量很大对计算和存储的要求很高。纯视觉路线的核心思想是用图像来推断三维信息。摄像头拍到的是一张二维图像但通过多帧之间的视差、物体的运动、以及深度学习模型学到的先验知识可以反推出物体的距离和三维结构。这条路线的好处是成本低、硬件成熟、数据量相对小而且摄像头能识别颜色和纹理对交通标志和信号灯的识别有天然优势。但它的难点在于从二维到三维的推断本质上是一个病态问题需要非常强的模型和大量的数据才能做准。我个人的看法是这两条路线没有绝对的对错关键看你的应用场景和成本约束。如果你做的是Robotaxi对安全冗余要求极高那激光雷达几乎是必选项因为它在恶劣天气下的表现比纯视觉更可预测。如果你做的是量产乘用车成本敏感那纯视觉或者“视觉为主、雷达为辅”的方案更现实。这个选择不是技术信仰问题而是工程权衡问题。4.2 为什么最近几年纯视觉的声音越来越大最近几年纯视觉路线的声量明显变大了我觉得有三个原因。第一是数据规模上来了。深度学习模型的效果和训练数据的量级强相关当车队规模达到几万辆甚至几十万辆的时候每天回传的数据量是惊人的这些数据能训练出非常强的模型把纯视觉的短板补上不少。第二是算力上来了。以前车载芯片的算力根本跑不动大型视觉模型现在几百TOPS的芯片已经量产了跑一个BEV加Transformer的模型绰绰有余。第三是成本压力。激光雷达虽然价格降了很多但一套下来还是要几千块对于走量的车型来说这个成本很难接受。但我要提醒一句纯视觉的“省”是省在硬件上不是省在整体成本上。你省了激光雷达的钱但你要花更多的钱在数据采集、标注、训练和算力上。我算过一笔账一个中等规模的纯视觉团队每年在数据上的投入可能比买激光雷达的钱还多。所以“纯视觉更便宜”这个说法要看你怎么算账。如果你只看BOM成本那确实便宜如果你看全生命周期成本那不一定。还有一个容易被忽略的点纯视觉方案对corner case的处理更依赖数据覆盖。激光雷达因为直接测距遇到没见过的物体至少能知道“那里有个东西”但纯视觉如果训练数据里没有类似的样本模型可能会直接忽略掉。这就是为什么纯视觉方案特别强调“数据闭环”——车端发现问题数据回传标注训练OTA升级再回到车端。这个闭环的效率直接决定了纯视觉方案的上限。5. 从原型到量产那些工程化的坑5.1 传感器标定一个看似简单却极其磨人的环节聊完路线之争我们回到工程落地。不管选哪条路线有一个环节是绕不过去的那就是传感器标定。所谓标定就是确定各个传感器之间的相对位置和姿态以及它们各自的内部参数。比如摄像头和激光雷达装在不同的位置你要知道它们之间的旋转和平移关系才能把激光雷达的点云投影到图像上或者把图像里的物体映射到三维空间里。这件事听起来很简单不就是量一下距离和角度吗但实际操作中极其磨人。首先车辆在行驶过程中会有振动传感器支架会有微小的形变这些形变会导致标定参数漂移。其次温度变化也会影响传感器的内部参数比如摄像头的焦距会随温度变化。第三标定本身需要特定的场地和靶标不是随便找个地方就能做的。我见过一个团队因为标定没做好导致激光雷达和摄像头的数据对不齐车把路边的广告牌当成了障碍物频繁急刹。后来查了一周才发现是标定参数在高温下漂了。我的经验是标定一定要做在线校准。也就是说系统在运行过程中要能自动检测标定参数是否漂移并实时修正。具体做法可以是用路面标线、车道线、或者已知尺寸的物体作为参考通过优化算法反推标定参数。这个功能在量产车上几乎是必须的因为你不可能有用户每次开车前都去标定一次。5.2 数据闭环从车端到云端的完整链路数据闭环这个词最近几年被说烂了但真正做好的团队不多。我把它拆成四个环节来讲采集、回传、标注、训练。每个环节都有坑。采集环节最大的问题是采什么。你不能把所有数据都传回来那样带宽和存储都受不了。所以要有触发机制比如系统检测到置信度低的场景、驾驶员接管的场景、或者发生碰撞的场景才把那段数据标记出来。这个触发机制的设计很关键触发太松会传回大量无用数据触发太紧会漏掉关键场景。我见过一个团队用“方向盘转角突变”作为触发条件结果传回来的全是急转弯的数据真正需要关注的加塞、鬼探头反而没采到。回传环节的坑在于成本和时效。用蜂窝网络传数据流量费很贵而且在地下停车场或者偏远地区信号不好。所以很多团队采用“车端先筛选、再压缩、最后在WiFi环境下批量上传”的策略。但这样一来数据的时效性就差了可能今天发现的问题要一周后才能拿到数据。这个延迟对于快速迭代的团队来说是很致命的。标注环节的坑在于一致性和效率。同一个场景不同标注员标出来的结果可能不一样这会导致训练数据里有噪声。解决办法是制定详细的标注规范并且做交叉验证。效率方面现在很多团队在用预标注加人工修正的方式先用模型跑一遍人工只改错的地方这样能省不少时间。训练环节的坑在于过拟合和泛化。你在一批数据上训练得很好换一批数据就崩了这说明模型学到的是数据的表面特征而不是本质规律。解决办法是增加数据的多样性比如不同城市、不同天气、不同时间段的数据都要有。另外数据增强也很重要比如随机裁剪、旋转、加噪声这些都能提升模型的鲁棒性。6. 常见问题与排查技巧实录6.1 感知层面的典型问题在实际项目中感知层面最容易出的问题我整理了一个速查表问题现象可能原因排查思路解决方向车辆频繁对阴影急刹激光雷达把地面阴影误判为障碍物检查点云的地面分割算法优化地面拟合增加阴影过滤夜间对深色车辆检测率低摄像头曝光不足激光雷达反射率低对比白天和夜间的检测结果增加夜间数据训练调整曝光策略雨天误检增多雨滴在激光雷达点云中形成噪声检查点云密度和分布增加雨滴滤波降低激光雷达置信度权重隧道内定位漂移GPS信号丢失视觉特征重复检查定位模块的切换逻辑增加惯性测量单元的权重使用隧道内特征这些问题我几乎都遇到过最麻烦的是雨天误检。因为雨滴在激光雷达的点云里会形成很多小点这些点看起来像障碍物但实际上是噪声。早期的做法是简单滤波但滤波太强会把真正的障碍物也滤掉。后来我们改用基于密度的聚类方法把孤立的点去掉保留成簇的点效果好了很多。6.2 规划控制层面的典型问题规划控制层面的问题往往更隐蔽因为感知对了不代表规划就对规划对了不代表控制就能执行到位。我列几个常见的问题一车辆在路口犹豫不决。这通常是决策模块的阈值设得太保守了。比如它判断“对向车距离50米、速度60公里每小时”的时候算出来碰撞时间只有3秒低于设定的安全阈值所以不敢走。但实际上这个场景是安全的因为对向车也在减速。解决办法是引入预测模块不光看当前状态还要预测对方未来几秒的运动。问题二跟车距离忽远忽近。这是控制模块的PID参数没调好。比例项太大就会震荡积分项太大就会滞后。我一般会先用仿真工具调一组基础参数然后在实车上微调。实车调试的时候让车跟着一辆速度变化比较规律的车观察距离曲线的波动慢慢把参数收敛到平稳。问题三变道时方向盘抖动。这通常是轨迹规划的问题规划出来的轨迹曲率不连续导致控制模块频繁修正。解决办法是在规划阶段加入曲率平滑约束或者用样条曲线来生成轨迹保证曲率连续。6.3 我踩过的几个大坑说几个我亲身踩过的坑希望能帮你省点时间。第一个坑是过度依赖仿真。仿真环境里跑得好好的实车一跑就出问题。原因是仿真里的传感器模型太理想了没有噪声没有延迟没有标定误差。后来我们强制要求任何算法在仿真里跑通之后必须至少在实车上跑够500公里才能算通过。第二个坑是忽视时间同步。激光雷达、摄像头、毫米波雷达的数据到达时间不一样如果不做时间同步融合出来的结果就是错的。我们曾经因为时间同步没做好导致车把一辆已经开走的车当成还在那里差点追尾。后来我们用了硬件触发的方式让所有传感器在同一个时钟下采样问题才解决。第三个坑是低估了长尾场景的复杂度。你以为你覆盖了99%的场景但剩下的1%可能包含几千种不同的情况。比如“一辆载着超宽货物的卡车在夜间没有尾灯的情况下突然变道”这种场景你可能一辈子都遇不到一次但一旦遇到就是大事。所以做自动驾驶永远要对长尾保持敬畏。7. 这个系列后续可以怎么扩展如果这个“自动驾驶汽车的故事”系列要继续做下去我觉得有几个方向很值得展开。一个是按技术栈纵向拆比如专门讲感知的故事、规划的故事、控制的故事每个方向都能讲好几期。另一个是按应用场景横向拆比如高速场景的故事、城市道路的故事、泊车场景的故事每个场景的技术挑战和解决方案都不一样。还有一个是按时间线做深度回顾比如把2010年到2020年这十年的关键节点一个个拎出来讲清楚每个节点上行业在纠结什么、选择了什么、放弃了什么。我自己在实际做分享的时候发现听众最感兴趣的往往不是“现在最先进的技术是什么”而是“当年为什么选了这条路而不是那条路”。因为前者是结果后者是逻辑。理解了逻辑你才能在新的场景下做出自己的判断而不是盲目跟风。这也是我写这篇博文的初衷——把故事讲清楚把逻辑捋顺让后来的人少走点弯路。最后分享一个小技巧如果你要做类似的系列分享建议每一期都留一个“开放问题”给听众。比如讲完激光雷达和纯视觉的路线之争可以问一句“如果成本不是问题你会选哪条路线为什么”这种问题没有标准答案但能引发讨论让听众从被动接收变成主动思考。我试过几次效果比单纯讲技术好得多。