最近在整理一份关于深度学习的材料主题是自动驾驶感知前前后后做了43页PPT。整理的过程比想象中费功夫因为光把感知链路里的算法名罗列一遍不难难的是把这些东西串成一条线为什么感知成了自动驾驶的胜负手、深度学习在里面到底扮演什么角色、数据集为什么比模型更让人头疼、恶劣天气下系统为什么会“降智”……这些内容如果只放在PPT里很多思考和踩坑细节其实装不下。所以干脆把43页PPT的核心内容完整拆成一篇文字稿比PPT啰嗦但更贴近实际项目里会遇到的问题。如果你正准备入门自动驾驶感知或者已经在做检测、分割、跟踪相关的算法但觉得理论学了不少、一上手就懵那这篇文章应该能帮你把零散的知识点重新串一遍。我会从算法演化讲到任务拆解再聊数据、恶劣天气、部署落地和实际项目里的坑尽量说人话尽量给结论背后的理由。1. 感知算法为什么会从“规则派”转向“深度学习派”1.1 传统视觉方法在真实道路上的无力感很多人现在看自动驾驶感知觉得用深度学习是天经地义的事。但其实在2015年之前学术界和工业界的主流思路完全不是这样。那时候做感知主流玩法是手工特征加分类器用Canny边缘检测提取轮廓用HOG描述子刻画目标外观再用SVM或者Adaboost做分类最后用滑动窗口在整个图像上扫一遍找出可能是车或者行人的区域。这套思路在特定场景下能跑通比如结构化园区里的低速小车、固定路线的摆渡车光线稳定、背景简单、目标种类少传统方法还能应付。但一旦上了开放道路问题就暴露了光照变化导致边缘断裂阴影让HOG特征彻底失效车辆遮挡时滑动窗口的得分剧烈抖动更不用说雨天、逆光、夜间这些场景。传统方法本质是在做“人工特征浅层分类”它把感知问题简化成了特征工程问题而真实世界的视觉变化远远超出了手工特征能表达的范畴。我早年用传统方法做过一个行人检测的Demo在数据集上AP能到85%一上车跑实测直接掉到40%。后来分析原因不是分类器不行而是特征表达的天花板就在那里。HOG特征擅长描述刚性物体但行人会摆臂、会弯腰、穿不同的衣服光照一变梯度方向分布就全乱了。这类问题不是调参数能解决的是方法论层面的死胡同。1.2 感知在自动驾驶技术栈里的“胜负手”位置回看整个自动驾驶系统链路基本是感知、决策规划、控制执行三大块。很多人以为最难的是决策规划因为涉及博弈和复杂场景理解但现实中感知才是那个真正决定系统上限的模块。原因很简单下游所有模块的输入都来自感知。如果感知漏检了一个横穿马路的行人规划模块再有智能也来不及反应如果感知把路肩错认成可行驶区域控制模块再精准也会把车开上马路牙子。业内有句话叫“感知决定天花板决策决定体验”我深以为然。决策规划做得再优雅本质上是在感知给出的“世界模型”里做搜索和优化感知给的地图错了后面的操作全是错的。这也是为什么资本和学界当年在L4级自动驾驶上烧了那么多钱最后发现卡点往往不是规划算法而是感知在长尾场景下不够鲁棒。深度学习之所以接管感知核心原因是它把“特征工程”变成了“特征学习”。卷积神经网络能够从原始像素里自动学习多层级特征低层学边缘纹理高层学语义部件这种分层表达比手工特征鲁棒得多。更重要的是深度模型的能力上限随着数据量和算力提升一路走高而传统方法在数据量增加后性能提升非常有限两者在2015年的ImageNet竞赛之后差距被彻底拉开自动驾驶感知也顺势全面转向深度学习。2. 自动驾驶感知到底“感知”些什么四大任务逐一拆解2.1 目标检测从2D框到3D框再到BEV视角目标检测是感知最基础、也是大家最熟悉的任务。早期自动驾驶里的检测基本沿用通用视觉的2D检测也就是在图像平面上画矩形框输出类别和置信度。YOLO系列、Faster R-CNN这类模型在2D检测上已经做得非常成熟YOLOv8配合TensorRT部署在车载Orin平台上跑个30-60 FPS很轻松。但2D框对自动驾驶来说有一个根本问题它只有图像坐标没有深度信息。规划模块拿到一个2D框不知道目标距离多远、尺寸多大、朝哪个方向运动很难直接用来做避障。所以业界很快转向3D目标检测直接在三维空间里输出目标的中心点、长宽高、朝向角比如PointPillars把点云划分成 pillars用2D卷积处理3D特征CenterPoint则是基于中心点的高效3D检测器这些模型在KITTI和nuScenes数据集上表现都非常好。再往后发展大家发现一个更本质的问题自动驾驶需要的是以自车为中心的鸟瞰图视角也就是BEV。BEV视角下目标和道路结构都在同一坐标系里规划的路径规划、控制模块可以直接复用这个表达。Lift-Splat-ShootLSS用深度分布估计把2D图像特征“抬升”到3D空间再拍扁到BEVBEVFormer则用Transformer的注意力机制把多摄像头特征融合到统一BEV坐标系。我个人的看法是BEV已经是量产自动驾驶感知的默认范式后续新项目没必要再走回2D检测加后处理的路线。2.2 语义分割与可行驶区域识别检测解决的是“哪里有车有人”分割解决的是“每个像素是什么”。语义分割会把图像中的道路、车辆、行人、建筑、天空、植被全部逐像素打上标签密度信息比检测框高得多。自动驾驶里分割有两个直接用处一是可行驶区域识别车辆需要知道哪些路面能压、哪些是路肩和障碍物边界这直接给到规划模块做轨迹约束二是感知兜底检测器漏检的情况下分割结果可以提示前方区域存在异常物体。工程上做分割常用的是DeepLabV3和BiSeNet系列。DeepLabV3用空洞卷积扩大感受野精度高但计算量大适合离线处理。BiSeNet设计了一个双路结构一条路跑空间细节一条路跑语义上下文在算力有限的嵌入式平台上也能跑到实时。实际项目里我会把分割设计成一个精度尚可但延迟极低的轻量网络因为分割结果更多用于“兜底判断”和“道路约束”不需要像检测那样追求极致的类别细分。2.3 多目标跟踪与轨迹预测感知的“时间维度”单帧检测只是快照自动驾驶必须知道目标从哪来、往哪去、ID是否稳定。多目标跟踪就是给每个检测目标分配ID并跨帧关联。经典方案SORTSimple Online and Realtime Tracking只靠卡尔曼滤波加匈牙利匹配就能跑得飞快DeepSORT在SORT基础上引入Re-ID特征解决遮挡后的ID切换问题ByteTrack则是通过关联低分检测框来减少漏检这几年在工程落地中非常流行因为它在公平比较下仍然能保持很高的MOTA同时延迟极低。有了稳定轨迹之后轨迹预测才有意义。预测模块基于历史轨迹和场景上下文输出目标未来3到5秒的多条可能轨迹因为自动驾驶面对的是开放世界必须假设目标有多种意图比如前车可能直行也可能变道行人也可能突然折返。现在主流预测模型基本都转向了Transformer架构把场景中的车道线、信号灯、其他车辆编码成向量再用自注意力建模交互关系输出多模态的轨迹分布。3. 数据集是感知系统的真正瓶颈主流数据集与数据工程3.1 主流公开数据集横向对比很多初学者把注意力全放在模型结构上忽略了数据集的重要性。实际上在自动驾驶感知里数据往往比模型的边际收益大得多。公开数据集是评估模型的第一站我常用的几个各有侧重。KITTI是元老级数据集2012年发布主要覆盖卡尔斯鲁厄的城市道路传感器有双目相机和64线LiDAR早期很多3D检测论文都在它上面评测。但KITTI的场景规模和类别多样性已经不够看了只能当作算法调参的起点。nuScenes是Motional原nuTonomy发布的数据集包含1000个场景波士顿和新加坡两个城市传感器配置非常完整6个相机、5个雷达、1个LiDAR还有GPS/IMU。nuScenes的标注做了23类目标和8种属性3D跟踪检测都覆盖。它的特点是传感器齐、场景丰富适合做多模态感知算法的开发。Waymo Open Dataset是目前规模最大的公开数据集之一2000万帧的LiDAR数据和2000万帧的相机数据覆盖了多种天气和路况标注质量很高适合做大规模预训练和评测。Argoverse的优势在于稠密的高精地图和高精度轨迹标注研究轨迹预测基本绕不开。BDD100K则是10万张图像的驾驶视频数据集天气和时段覆盖广适合验证感知模型在多样化条件下的泛化性能。我个人的选择逻辑是研究检测用KITTI快速验证做多模态感知和跟踪用nuScenes做轨迹预测用Argoverse做泛化测试用BDD100K。如果目标是发论文在这些数据集上的涨点都有说服力如果目标是落地更推荐自建数据加困难场景定向采集。3.2 标注质量决定模型上限模型性能的上限很大程度上由标注质量决定。这不是鸡汤而是我踩过坑后的教训。3D框标注比2D框难得多标注员要在点云和图像之间反复切换把长方体的长宽高、朝向角对齐到物体表面遮挡和截断目标的边界往往要凭经验判断。一个典型的标注错误是LiDAR点云距离越远越稀疏远距离车辆可能只有几个点落在表面上标注员很容易把框标大或标歪。这类噪声会让模型在远距离检测时输出一个位置偏移的框而且置信度还不低非常危险。所以处理点云标注时我一般会要求标注平台提供多轮质检流程对遮挡、截断物体单独审核同时用自动标注算法先打底稿、人工再精修这样可以显著降低标注成本。难例挖掘也非常重要。自动驾驶感知的绝大部分困难场景在普通路采数据里非常稀疏比如corner case、异形车、行人带着自行车、雨天夜景如果只按随机比例训练模型可能永远学不到这些模式。主动学习的思路在这里很管用先用一个已经跑通的模型在无标注数据上预测把置信度低、不确定性高的样本挑出来优先标注这样可以让有限的标注预算花在最值得的地方。3.3 仿真数据与真实路采数据的配比真实路采数据的成本很高一辆采集车要配齐传感器、标定设备和高精度定位跑一天下来还要处理数据回传、筛选、脱敏能用得上的帧可能只有1%。所以仿真数据成了补充长尾场景的重要工具。CARLA是最常用的开源自动驾驶仿真器可以灵活设置天气、光照、交通流和传感器参数AirSim在无人机和城市环境的模拟上也很成熟另外还有Waabi、Waymo Simulator等工业级仿真平台。但仿真数据有一个绕不开的问题sim-to-real gap也就是域差。仿真场景的光照、材质、传感器噪声和真实世界并不完全一致模型如果在仿真数据上占比过大反而会在真实道路上掉点。我在实际项目里的经验是真实路采数据为主仿真数据用来补齐极端场景比如模拟暴雨、模拟夜间对向远光、模拟罕见车型。配比上仿真数据一般不超过总量的20%到30%而且要配合域适应技术来缩短差距。数据闭环是行业内公认的发展方向实车路采的真实数据回流到数据平台经过自动标注和挖掘把困难样本清洗出来再加入训练集训练出的新模型再部署到车上验证形成一个持续迭代的闭环。这条路没有捷径但走得越扎实感知系统的长尾能力就越强。4. 恶劣天气与复杂场景感知系统的“压力测试”4.1 雨雾、夜间、逆光下的传感器退化感知模型在公开数据集上刷分只是一个初级指标真正让工程师头大的是恶劣天气。下雨天挡风玻璃上的水珠和雨帘会直接遮挡相机视野图像对比度断崖式下降浓雾天可见距离从几百米降到几十米远距离目标几乎消失在背景里夜间光线不足传感器信噪比下降暗处的行人很难被检测到逆光情况下车头迎着太阳时图像高光区域过曝、阴影区域死黑动态范围完全超出普通CMOS的处理能力。LiDAR在恶劣天气里也会出问题。雨点和雪花会反射激光在点云里形成大量噪声点靠近传感器的雾霾粒子甚至会产生一片致密的假点云严重干扰障碍物的聚类和检测。毫米波雷达倒是受天气影响较小但它的分辨率低点迹稀疏对静止物体的感知能力也有限。这就是为什么真实部署的感知系统几乎都采用多传感器融合架构单靠任何一种传感器都无法覆盖所有天气场景。恶劣天气感知现在已经成了一个专门的研究方向。一类做法是在模型层面做鲁棒化通过恶劣天气数据增强来提升模型泛化能力比如在训练时随机叠加雨雪噪声、降低图像亮度、模拟镜头上的水滴效果另一类做法是设计天气自适应模块比如利用雾密度评估器来判断当前的雾气程度动态调整去雾处理和检测置信度阈值。4.2 多传感器融合的核心思路与工程细节多传感器融合的本质是信息互补相机提供丰富的纹理和颜色信息LiDAR提供高精度的深度和几何信息毫米波雷达提供全天候的速度测量。融合的难点不在于“捏在一起”而在于“怎么捏、什么时候捏”。后融合是最简单的方式各个传感器分别做感知输出目标列表再在tracking层通过匈牙利匹配做目标关联和融合。这种方案实现简单、模块解耦好但缺点是信息已经高度压缩融合的提升空间有限。前融合则是在数据层面直接把图像和点云对齐拼接让模型自己学习跨模态特征BEVFormer这类基于Transformer的BEV感知模型会把多摄像头特征映射到统一的BEV网格上天然支持多模态融合是目前效果最理想、也是工程量最大的方案。融合背后的工程细节比算法更磨人。硬件层要解决时间同步和空间对齐LiDAR和相机帧率不同需要做帧间插值对齐否则融合时目标位置会有偏差空间对齐依赖外参标定车辆行驶震动可能导致外参漂移所以量产系统都要求做在线标定校验。这些细节不解决算法融合做得再漂亮实车测试也会出现“同一个目标被两个传感器感知成两个位置”的尴尬情况。4.3 域适应与感知泛化同一个模型在A城跑得好好的到了B城换个道路风格、换个光照条件性能可能直接掉一截这就是域差问题。域适应技术就是用来缓解这类问题的常见思路有三种。第一种是数据层面的风格迁移把晴天数据迁移成雨天、雪天、夜景风格用生成模型扩大训练数据分布第二种是对抗训练在特征层面让域判别器无法区分特征来自哪个域迫使模型学到域无关的特征第三种是自训练利用在源域上训练的模型去预测目标域的无标注数据选取高置信度样本加入训练集。实际工程中我比较推荐以自训练为主、风格迁移为辅因为对抗训练系统收敛不稳定项目周期紧张时容易翻车。5. 从PyTorch训练到实车部署工程落地的关键细节5.1 训练环境的搭建与框架选型感知模型训练绕不开环境搭建这也是很多初学者卡壳的地方。我的建议无脑用Ubuntu 20.04加PyTorch这是目前生态最完善的组合。环境配置的关键是版本匹配先装显卡驱动再装CUDA工具包然后装cuDNN最后用conda创建一个独立的虚拟环境来安装PyTorch避免把系统Python环境搞乱。PyTorch的安装命令直接到官网生成对应的pip命令即可它会自动帮你装好匹配的CUDA版本。显存焦虑是这个阶段最普遍的问题。训练一个YOLOv8模型用主流的RTX 3090或4080批量大小设成16到32是够用的。如果显存不够第一反应不应该是换卡而是减小batch size、开启混合精度训练AMP或者用梯度累积来模拟更大的batch。3D检测和BEV模型的显存压力更大PointPillars还好BEVFormer这种基于Transformer的模型在训练时需要非常大的显存这时候多卡并行或者使用更好的优化器比如AdamW配合cosine annealing就很有必要了。5.2 模型压缩与TensorRT部署训练出来的PyTorch模型不能直接上车。车载计算平台算力有限而且对延迟极其敏感部署阶段的目标是在不显著掉点的前提下把模型跑得更快。通用流程是先把PyTorch模型导出成ONNX格式再用TensorRT做引擎优化最后量化成INT8。TensorRT会把网络做层融合、精度校准、内核自动调优推理速度通常能比PyTorch原版快2到4倍。INT8量化是提升性能的关键一步但也是掉点风险最大的地方。校准数据集的选择很讲究需要覆盖晴天、夜晚、雨天等多种场景只拿几百张标准图做校准很可能导致量化后检测框偏移或者小目标漏检。我的经验是量化后一定要做一次完整的实车回归测试重点关注远距离小目标和截断目标的召回率变化如果掉点明显可以考虑对敏感层保留FP16精度做混合量化。5.3 实车测试里的常见问题从模型到稳跑实车测试和离线评测完全是两个世界。第一个常见的问题是传感器延迟错位相机帧率是30 FPS而下游规划模块需要的信号必须带时间戳校准如果感知输出滞后几十毫秒高速场景下目标位置就会偏差明显。解决办法是给感知结果打上精确的时间戳在融合层做延迟补偿。第二个问题是感知输出的抖动。离线看每个点都很平滑但实车上检测框的坐标、朝向、置信度都会帧间跳动直接给到下游规划会让车速和轨迹产生抖动。工程上常用滞后逻辑加滤波比如检测到目标后需要连续N帧确认才输出、连续M帧丢失才删除框的坐标做平滑滤波。第三个问题是标定漂移摄像头和LiDAR的外参会随车辆颠簸缓慢偏移需要定期做在线标定校验否则融合模块会慢慢失效。6. 实际项目中的踩坑记录与经验教训6.1 我踩过的三个典型坑第一个坑来自数据集划分不当。做目标检测训练时我随手按7:2:1划分训练集、验证集、测试集但忘了同一段连续视频的相邻帧高度相似导致划分时大量相似帧同时出现在训练集和测试集里离线评估的mAP虚高非常多。后来改成按时间片划分数据保证测试集和训练集不是同一路段的连续帧评估数据才真实可靠。第二个坑是过度迷信公开榜单的SOTA。复现一篇顶会论文的最佳模型时我怎么调都达不到论文报告的精度。后来发现是训练细节的问题有的论文用了多尺度训练、测试时增强、模型集成有些还用了外部数据预训练。如果只看“模型结构评测结果”直接复现差异自然很大。做工程时我更看重单模型的稳定收益而不是靠一堆trick堆出来的榜单分数。第三个坑是忽略后处理和异常帧。有一次实车测试车辆通过隧道时感知系统出现大量误检排查到最后发现是车辆进入隧道的瞬间相机自动曝光调整导致连续几十帧图像过亮检测模型把隧道壁灯光误判成了车辆尾灯。这类问题在模型层面很难根除最终用前向摄像头曝光状态和全局光照强度做阈值过滤在感知推理链路里加了一个“坏帧抑制”逻辑才解决。6.2 给入门者的路径建议这几年经常有人问我自动驾驶感知怎么入门。我给的建议通常是不急着追SOTA模型先把流程跑通第一步在公开数据集上训练一个YOLO检测模型把数据的标注格式、训练流程、评测指标彻底吃透第二步把模型导出成ONNX再用TensorRT部署到本机体验一下推理加速的差距第三步尝试一个点云3D检测模型比如PointPillars理解点云数据处理和BEV特征表达第四步把相机和LiDAR的感知结果做简单的融合用BEV视角展示出来。这套路线走下来对整个感知链路的基本盘就有概念了。环境配置、数据准备、模型训练、部署推理、实车验证每一步都有非常多琐碎的坑。但正是这些坑构成了从“跑通Demo”到“做出一套可用的感知系统”之间真正的距离。做感知项目最大的体会是模型结构只是冰山一角数据质量、工程实现和系统集成才是真正决定成败的部分。自动驾驶感知的难度不在单点算法而在把所有环节组合在一起时还能稳定运行这份稳定只能靠一次次踩坑和修坑堆出来。