雨幕下的纯视觉感知：能见度评估与决策降级实战

1. 雨幕之下纯视觉方案到底在赌什么纯视觉自动驾驶在晴天里的表现这两年已经被聊得差不多了。真正让做感知的人夜里睡不着的是雨幕、团雾、积水反光、夜间对向车灯炫光这几种场景叠加在一起的时候。特斯拉FSD坚持走纯视觉路线把摄像头当成唯一的主传感器这件事在业内一直有争议但争议归争议它确实把感知在恶劣天气下怎么保命这个问题推到了台前。我接触过几个做自动驾驶感知和数据集标注的团队大家有个共识纯视觉方案的核心赌注是赌算法能从图像里把被雨幕削弱的信息重新还原出来。激光雷达在雨雾里会因为水滴散射产生大量噪点毫米波雷达分辨率又不够细所以纯视觉反而在信息密度这件事上有理论优势——前提是你能把被雨滴、水雾、镜头污渍污染的那部分像素和真实世界里的物体区分开。这篇内容我想聊的不是纯视觉好不好这种站队问题而是把镜头对准一个更实际的问题当雨幕落下一套纯视觉感知系统从数据采集、模型设计、到决策执行每个环节到底该怎么打这场保卫战。适合做感知算法、数据集构建、自动驾驶测试以及研究恶劣天气下视觉鲁棒性的朋友参考。里面会涉及雾感知密度评估、SADA这类感知分析决策执行框架的思路也会聊到数据集构建和实车测试里那些文档不会写的坑。先说结论性的判断雨幕场景下纯视觉的胜负手不在看得多远而在知道自己什么时候看不清。一个能准确评估自身感知置信度、并据此降级决策的系统比一个硬撑着输出高置信度错误结果的系统要安全得多。这句话是后面所有内容的纲。2. 雨滴打在镜头上图像到底发生了什么变化2.1 从物理层面拆解雨幕对成像的三重干扰很多人一提到雨天感知第一反应是图像模糊了。这个描述太粗。雨幕对摄像头成像的干扰至少分三层每一层的处理思路完全不同。第一层是镜头表面的附着物。雨滴打在镜头保护玻璃上形成一层不规则的水膜这层水膜会折射和散射光线导致局部区域出现严重的形变和失焦。这种干扰的特点是位置相对固定因为雨滴附着位置在短时间内不变但形态随机。处理这类干扰硬件上靠疏水镀膜和气流吹扫算法上靠污渍检测和局部去模糊。第二层是雨滴在空中的运动模糊。高速快门能凝固雨滴但会牺牲进光量慢速快门进光量足但雨滴会拉成亮线。这些亮线在图像里表现为大量方向一致的短条纹会淹没掉远处的小目标比如行人、锥桶、非机动车。这一层的处理核心是雨线去除但难点在于不能把真实的细长物体比如电线、栏杆一起误删。第三层是整体大气散射造成的对比度下降。雨幕本质上是大量悬浮水滴它们对光线的散射会让整幅图像蒙上一层灰白色的雾远处物体的对比度和饱和度急剧下降。这一层和雾天成像的物理模型高度相似所以雾感知密度评估的方法在这里可以直接迁移。把这三层分开看你就会明白为什么单一的去雨算法效果总是不稳定——它可能只处理了第二层却对第一层的水膜和第三层的大气散射无能为力。2.2 为什么去雨不能只靠一个端到端模型现在很多团队喜欢用一个端到端的去雨网络输入带雨图像输出干净图像然后直接送进检测网络。这个思路在学术数据集上刷点很漂亮但实车落地经常翻车。原因有三个。一是去雨网络会引入幻觉。生成式去雨模型在抹掉雨线的同时可能凭空脑补出一些不存在的纹理这些纹理在检测网络眼里可能就是虚假目标。在雨幕这种信息本就稀缺的场景下幻觉的代价被放大了。二是去雨和检测的目标不一致。去雨追求的是人眼看着干净检测追求的是目标特征可分离。有时候保留一点雨线纹理反而有助于网络判断这是雨天应该降低置信度阈值全抹干净了反而丢掉了天气线索。三是算力预算。实车上的感知是实时系统去雨网络如果做得太重挤占的是检测和跟踪的算力。我见过一个方案去雨模块单独占了接近40%的推理时间最后只能砍掉。所以更务实的做法是把去雨当成一个可选的预处理分支而不是必经之路。系统先做天气和能见度评估只有在评估结果达到某个阈值时才激活去雨分支并且去雨的输出和原始图像一起送进检测网络做特征融合。这样既控制了算力又保留了原始信息。2.3 一个容易被忽略的细节摄像头参数对雨幕感知的影响热词里出现了不少摄像头型号从树莓派OV5647到海康、宇视的监控摄像头其实这些参数对雨幕感知的影响非常直接。做纯视觉感知摄像头的几个参数必须盯死参数对雨幕感知的影响建议方向快门类型卷帘快门在雨滴快速运动时产生果冻效应破坏几何一致性优先全局快门动态范围雨夜对向车灯炫光下低动态范围会直接过曝丢失目标高动态范围最好140dB以上镜头镀膜疏水镀膜能显著减少水膜附着硬件选型阶段就要确认最低照度雨夜环境照度极低直接影响信噪比大光圈加高感光但要注意噪点帧率高帧率有助于雨滴运动估计和去雨30fps起步能到60fps更好这里有个实操经验很多团队在实验室用工业相机调算法上车却换成车规相机结果发现雨幕下的表现完全对不上。原因是工业相机的快门、镀膜、ISP调校和车规相机差异巨大。算法验证阶段用的相机必须和量产相机在光学和ISP链路上尽量一致否则你调出来的去雨参数上车就废。3. 雾感知密度评估让系统知道自己看不清3.1 能见度评估为什么是纯视觉的保命机制前面反复强调一个观点纯视觉系统在雨幕下最重要的能力是知道自己什么时候看不清。这个知道的量化指标就是能见度或者雾感知密度。为什么它这么关键因为下游的检测、跟踪、规划模块都需要一个当前感知可信度的输入。如果系统误以为能见度很好就会用正常的置信度阈值去判断目标结果把雨幕里的噪声当成真实目标或者把远处模糊的行人漏检。反过来如果系统知道能见度已经降到50米它就可以主动降速、拉大跟车距离、把决策策略切换到保守模式。这就是SADA这类感知-分析-决策-执行闭环框架的价值所在。感知模块不仅要输出那里有个什么东西还要输出我对这个判断有多确信以及当前环境让我能信到什么程度。能见度评估就是后者的核心。3.2 基于图像本身的能见度估计方法不依赖额外传感器纯靠图像估计能见度主流有几条路子。第一条是基于大气散射物理模型。经典的暗通道先验就是从这里来的通过估计大气光和透射率反推出场景的雾浓度。这个方法在均匀雾天效果不错但雨幕的不均匀性会让它失准——雨幕往往是一阵一阵的图像不同区域的透射率差异很大。第二条是基于对比度衰减。在图像里选取包含已知或可估计距离参照物的区域测量其对比度随距离的衰减曲线拟合出消光系数。这个方法需要场景里有稳定的参照物比如车道线、路侧标志在高速和城市道路场景下比较可行。第三条是基于深度学习的直接回归。训练一个网络输入图像直接输出能见度数值。这个方法的问题是需要大量带能见度真值的标注数据而这类数据极难获取。常见的做法是用合成雾数据训练但合成到真实的域 gap 很大。我比较推荐的是物理模型和深度学习结合的思路用物理模型提供先验和中间监督信号用网络学习雨幕特有的散射模式。具体做法是让网络同时预测透射率图和大气光再用物理公式重建无雾图像重建误差作为辅助损失。这样网络学到的透射率图本身就携带了能见度信息。3.3 把能见度评估接入决策链路的实操细节评估出能见度数值只是第一步怎么用才是关键。这里分享几个实操中的设计。分级而不是连续值。把能见度分成几档比如大于200米、100到200米、50到100米、小于50米每档对应一套决策参数。连续值虽然精细但标定困难而且决策模块对微小变化的敏感反而会引入抖动。加入时间平滑。单帧的能见度估计会有噪声必须做时序滤波。但滤波窗口不能太长否则雨幕突然加厚时系统反应不过来。我的经验是用一个自适应窗口能见度变化剧烈时缩短窗口平稳时拉长窗口。设置置信度下限。当能见度评估本身的可信度很低时比如图像大面积过曝或欠曝系统应该直接进入最保守模式而不是相信一个不可靠的评估值。这个对评估的评估经常被忽略但在极端天气下恰恰是救命的。提示能见度评估模块一定要有独立的失效检测。如果它自己挂了却还在输出正常值比没有这个模块更危险。4. 恶劣天气数据集合成数据和真实数据怎么配比4.1 真实雨雾数据为什么这么难搞做恶劣天气感知数据集是绕不过去的坎。真实雨雾数据的采集难度没做过的人很难想象。首先是天气不可控。你没法预约一场恰到好处的雨更没法预约一场能见度刚好80米的团雾。团队带着采集车蹲守几天甚至几周可能只等到一场毛毛雨。而且雨幕的形态千变万化小雨、中雨、暴雨、阵雨、夜雨每种对成像的影响都不同。其次是标注成本高。雨幕里目标本身就模糊标注员很难判断远处那个模糊的斑块到底是行人还是广告牌。标注一致性差标注质量直接受影响。而且恶劣天气下的目标往往更密集比如雨天大家都挤在一起标注工作量更大。第三是真值难获取。能见度真值需要专业设备测量目标距离真值需要高精度定位这些在实车采集时都很难同步拿到。4.2 合成数据的价值边界在哪里既然真实数据难搞合成数据就成了主力。用渲染引擎或者图像转换方法把晴天数据转成雨天、雾天可以快速扩充数据量。但合成数据有几个必须清楚的边界。物理真实性有限。大多数合成方法对雨滴的建模是简化的雨滴的折射、水膜的形变、雨幕的多次散射这些复杂物理过程很难完全模拟。所以合成数据训练出来的模型在真实雨幕下往往有性能落差。域偏移问题。合成数据的统计分布和真实数据不一致模型容易学到合成数据的伪特征。比如某些合成方法会在图像上叠加固定的噪声模式模型可能就靠这个模式来判断这是雨天而不是真正理解雨幕的物理特性。标注是完美的但完美本身是问题。合成数据的标注是程序生成的绝对准确。但真实场景里标注是有噪声的模型如果只见过完美标注泛化到真实标注时会不适应。我的建议是合成数据用来做预训练和增广真实数据用来做微调和验证。合成和真实的比例在预训练阶段可以到9比1甚至更高但微调阶段真实数据必须占主导至少要到1比1。而且真实数据里要刻意保留一部分难例——那些能见度极低、目标极度模糊的样本这些才是真正考验模型的。4.3 数据增广里那些反直觉的经验在恶劣天气数据增广上我踩过几个坑分享出来。不要盲目加大雨量。很多人觉得雨越大越难就往死里加。但实际道路测试里暴雨时车速会大幅降低感知难度反而因为相对运动变慢而下降。真正难的是中雨加高速雨滴运动模糊严重目标又快速接近。增广时要模拟这种组合而不是单纯堆雨量。雾的均匀性要控制。真实团雾是不均匀的有的地方浓有的地方淡。如果增广时用均匀雾模型会学不到这种空间变化遇到真实团雾就懵。增广时应该用噪声调制雾的浓度分布。夜间雨天要单独处理。夜间雨天的成像特性和白天完全不同对向车灯在雨幕里会形成大面积炫光这种场景必须单独增广不能靠白天数据加暗就糊弄过去。保留一部分无增广数据。如果训练集全是增广数据模型会过度依赖增广引入的特征。保留一部分原始晴天数据有助于模型保持对基础特征的敏感度。5. 从感知到执行雨幕下的决策降级策略5.1 感知置信度如何传导到规划控制感知模块输出目标列表和能见度评估后这些信息怎么影响规划控制是纯视觉方案能不能真正安全落地的关键。核心机制是置信度传导。每个检测目标除了位置、速度还要带一个置信度分数。这个分数不仅来自检测网络本身还要乘以一个环境折扣因子——能见度越低折扣越大。规划模块拿到的是折扣后的置信度据此决定对这个目标投入多少注意力。具体到控制层有几个降级动作降速。能见度低于阈值时最高车速被限制。这个限制不是线性的而是分档的避免频繁调整。拉大跟车距离。跟车时距随能见度下降而增加给制动留出更多余量。保守变道。低能见度下变道决策更谨慎需要更高的安全间隙才执行。提前制动。对前方目标的制动触发点提前宁可误刹也不漏刹。这些策略听起来简单但难点在于阈值标定。阈值定得太保守系统在雨天几乎没法用定得太激进又失去了降级的意义。我的经验是阈值不能拍脑袋要用真实雨雾场景的数据反复回放标定找到安全和可用的平衡点。5.2 一个完整的雨幕感知处理链路示例把前面几节的内容串起来一个完整的雨幕纯视觉感知链路大概是这样图像采集全局快门、高动态范围相机输出原始图像。污渍检测判断镜头是否有水膜附着若有则触发告警并标记受影响区域。能见度评估物理模型加网络回归输出能见度分级和评估置信度。条件去雨能见度低于阈值时激活去雨分支输出与原始图像融合。目标检测在融合特征上做检测输出带置信度的目标列表。置信度折扣根据能见度和污渍情况对目标置信度做折扣。时序跟踪多帧关联利用时序信息弥补单帧信息不足。决策降级规划控制根据折扣后置信度和能见度分级调整策略。这个链路里第3步和第6步是雨幕场景特有的也是和晴天方案最大的区别。很多团队把精力全放在第5步的检测网络上却忽略了3和6结果就是检测指标好看实车表现拉胯。5.3 实车测试中那些让人措手不及的情况实验室和仿真里跑得再好实车测试总会给你惊喜。分享几个我在雨幕测试里遇到的情况。积水反光造成的虚假目标。路面积水会反射前车尾灯和路灯在图像里形成亮斑检测网络容易误判为车辆或灯光目标。这种虚假目标在夜间雨天尤其严重。处理办法是在检测后加一个反射抑制模块利用反射光斑的对称性和位置特征过滤。雨刷的周期性遮挡。雨刷扫过镜头的瞬间图像会被大面积遮挡。如果系统没意识到这是雨刷会以为前方突然出现巨大障碍物。必须有一个雨刷相位检测在雨刷遮挡期间冻结感知输出或降低置信度。隧道进出口的能见度突变。从隧道出来突然进入雨幕或者从雨幕进入隧道能见度在几秒内剧烈变化。能见度评估的时序滤波如果窗口太长就会反应迟钝。需要检测这种突变并快速重置滤波状态。对向车灯在雨幕里的炫光。雨幕会把对向车灯的光散射成一大片严重时整个画面都被照亮。高动态范围相机能缓解但算法上还需要做炫光抑制否则炫光区域内的目标全部丢失。这些情况没有一个是仿真能完全复现的。所以雨幕感知的测试实车里程必须够而且要刻意选择恶劣天气出车。我认识的一个团队专门做了一个追雨的测试计划哪里有雨就往哪里开虽然辛苦但积累的真实数据是任何仿真都换不来的。6. 纯视觉雨幕感知的几个长期判断聊了这么多技术细节最后说几个我个人的判断不一定对但都是从实际项目里磨出来的。第一纯视觉在雨幕下的上限取决于它对自身不确定性的建模能力。摄像头的信息密度优势能不能发挥出来关键看系统能不能准确知道自己什么时候看不清。这个能力比单纯提升检测精度更重要也更难做。第二恶劣天气数据集的建设会是未来几年纯视觉方案的核心竞争力之一。算法架构大家都能抄但真实雨雾数据的积累抄不走。谁手里有大规模、高质量、多形态的雨雾数据谁就有底气。第三感知和决策的耦合会越来越紧。以前感知只管输出目标决策只管用目标。雨幕场景下感知必须把不确定性传递给决策决策必须能接受模糊输入并做出保守但合理的动作。这种耦合需要感知和规划团队深度协作而不是各做各的。第四硬件和算法的协同设计不能省。疏水镀膜、全局快门、高动态范围这些硬件特性对雨幕感知的影响比很多算法trick都大。算法团队如果不懂硬件硬件团队如果不懂算法最后做出来的系统一定是瘸腿的。雨幕之下的这场感知保卫战说到底是一场关于诚实的战争——系统要对自身能力诚实对不确定性诚实对安全边界诚实。一个敢于说我看不清的系统比一个硬撑着说我都看得见的系统更值得信任。这大概就是纯视觉路线在恶劣天气下最该守住的东西。