凌晨一点我蹲在工程车边上看实时日志。前方三十米处的护栏毫米波雷达给出的回波强度稳定激光雷达点云也扫出了护栏立柱的轮廓可视觉分支偏偏把路面反光当成一片白色障碍。融合模块按“少数服从多数”的逻辑把视觉结果压了下去车子却还是在护栏前刹停了一次——因为融合置信度算得保守门限没过。那一刻我突然意识到多传感器融合感知的问题从来不是“传感器不够多”而是三个传感器各说各话谁也不理解谁。这也是我写这篇的动机。近两年基于Transformer的多模态融合感知几乎成了端到端感知的默认形态把摄像头、激光雷达、毫米波雷达送进同一个网络输出统一的三维空间特征。它能解决的不只是单一传感器失效时系统不崩的那点冗余而是让不同模态在特征层面互相补位、互相校验真正“听懂”彼此。这篇文章会从传感器物理特性讲起一直拆到网络设计、训练细节和部署时的坑适合正在做多传感器融合方案的开发者也适合刚接触端到端感知、想搞清楚“融合到底融合在哪层”的入门读者。1. 三种传感器各自的脾气为什么单传感器方案总是差一口气做融合之前得先把每个传感器的“性格缺陷”摸清楚。很多人一上来就搭Transformer结果数据还没对齐就被带偏问题恰恰出在对传感器本身的理解不够。1.1 摄像头信息密度最大但天生没有尺子摄像头是三个模态里语义信息最丰富的。红绿灯、车道线、路牌文字、刹车灯这些东西只有图像里能读到激光雷达和毫米波雷达完全无能为力。但代价也很明确单目图像没有尺度。一个像素只能告诉你“这里是白色”给不出“这个白色物体离我8.2米”。单目深度估计这些年进步很大可误差依旧是厘米梁级别的遇到纹理弱的墙面、黑夜里的行人深度基本靠猜。更麻烦的是光照敏感逆光、隧道出入口、夜间无路灯环境下图像信噪比掉得飞快。所以在融合架构里视觉的定位通常是“语义提供者”。它负责回答“这是什么”深度问题主要交给主动传感器去校正。1.2 激光雷达自带高精度深度却只能“画一挂点”激光雷达的好处是主动测距不同物体的回波时间差直接把深度量出来精度能到厘米级而且不依赖环境光照。夜里摄像头瞎了激光雷达照样画点。坏处是稀疏。一个32线激光雷达转一圈真正落在一个行人身上的点可能只有十几个远距离目标更稀疏。点云密度随距离衰减特别快60米外的障碍物可能就两三个点根本撑不起一个框。另一个问题是它读不了语义点云里没有“红色”“人”这种概念物体分类基本靠几何形状。我个人的习惯是调点云可视化时永远开着和图像的对齐显示。如果点云里的“人形轮廓”和图像里的人群对不上先别急着调网络大概率是标定矩阵有问题。1.3 毫米波雷达二十四小时待命但细节全靠猜毫米波雷达最大的优势是全天候。雨、雾、沙尘对它影响小还能直接用多普勒效应测径向速度这是摄像头和激光雷达都不具备的能力。某次雨天测试摄像头和激光雷达都出现不同程度的退化只有毫米波雷达还稳定地报出前车的距离和速度。代价是角度分辨率低、点很稀疏一个路灯杆回波可能只是模糊的一团行人和金属护栏在反射特征上区分度不高。现在工程上主推4D毫米波雷达多了俯仰角信息点云质量比老式3D雷达好不少但和激光雷达比还是有差距。1.4 为什么“早期往一块拼接”不行早期融合方案大多是把三个传感器的输出做后验拼接图像检测框和点云检测框各自跑一遍然后按照类别和IOU合并。这种方案在干净天气下能跑一旦某个传感器退化融合结果会被拖累。真正的深度多模态融合要把数据放进同一个特征空间让网络自己学习“什么时候信谁”。Transformer在这个场景下的优势就显现出来了它天然支持把不同模态编码成token用注意力机制跨模态查询不再需要人手工写一堆规则。2. 坐标系、畸变和体素把物理世界翻译成同一张桌布多模态融合首先要解决空间对齐。三个传感器看同一个物理世界各看各的坐标系如果不先把数据转换到统一的“桌布”上后面一切融合都是空中楼阁。2.1 外参标定一切融合的前提也是最容易埋坑的位置外参描述的是传感器之间的相对位姿通常是一个旋转矩阵R加一个平移向量t把激光雷达坐标系下的点变换到相机坐标系再经相机内参投影到图像像素。这一步看似基础实际最容易出错。A同学在某次项目里调了整整三天网络性能最后发现是标定文件里旋转矩阵的符号写反了三个点云全投影到了图像的镜像位置。实操上我建议用标定板法把反光板或者棋盘格放在车辆前方多个位置分别采集点云和图像提取角点后做PNP求解。流程大致是先在图像里标出角点的像素坐标再在点云里找到对应角点的3D坐标最后用最小化重投影误差的方式估计外参。常见的做法是优化重投影误差让点云落在图像正确位置。外参标定不是一劳永逸的。装配公差、热胀冷缩、碰撞都会让外参漂移。如果部署后长期不校正点云边缘会开始“模糊”重投影误差变大。工程上要定期做在线重标定或者用视觉特征和点云特征的匹配做监控。2.2 透视视图到俯视视图BEV为什么成了多模态的“共同语言”摄像头看到的是透视视图近大远小。激光雷达看到的是三维点云而毫米波雷达输出的是稀疏点的距离和速度。要把它们统一起来BEVBird\u2019s Eye View鸟瞰视角是目前的主流选择。BEV相当于把自车周围的地面网格化例如以自车为中心、向前向左右各50米按0.1米或0.2米的网格分辨率划分。来自不同传感器的特征最终都落到这张网格上。路径规划、控制模块可以直接在这张“地图”上工作非常直观。做BEV融合有一个容易被忽略的细节BEV网格的中心和朝向定义必须与车辆坐标系一致。通常前向为Y轴右侧为X轴网格索引方向要严格对应否则会出现所有框整体偏移半格的情况平时很难看出来一旦撞上墙才暴露。2.3 分辨率不匹配像素质点、点云柱子和雷达点怎么落到同一格三种模态的空间分辨率差异巨大。图像像素几百上千万个毫米波雷达点每帧只有几百个。直接把它们拼一起注意力机制会失衡。工程上通常分模态编码模态表征方式空间分辨率特征编码图像2D网格像素高卷积或patch embedding激光雷达3D点云-pillar体素中每柱内点特征聚合毫米波雷达稀疏点云低点级别或pillar编码激光雷达最常用的是pillar方式把点云按BEV网格切分成一个个垂直柱体每个柱体内聚合高度、强度、坐标等特征再用小网络编码为一个固定维度向量。毫米波雷达点也可以沿用同样方式只是柱体内点数更少需要更强的噪声抑制。把三种模态都变成“网格上一格一位”的特征后Transformer的token序列就很好构造了每个网格位置就是一个token模态特征作为该token的初始编码再配合位置编码输入后续的注意力模块。3. 时间同步摄像头拍下的那一刻雷达看到的是哪一秒空间对齐解决“同一个地方”时间对齐解决“同一时刻”。这在动态场景里尤其关键——一个行人以1米/秒的速度横穿马路100毫秒的时间差就带来10厘米的空间错位。3.1 快门不是瞬间扫描也不是同时相机曝光有全局快门和卷帘快门之分卷帘快门逐行曝光一帧图像里不同行对应的时间本来就不同。激光雷达旋转一圈需要数十毫秒到一百多毫秒角度不同采集时刻也不同。毫米波雷达通常按固定帧周期输出帧率和前两者都可能不一致。融合训练时如果不处理时间戳就会拿“上午9点整的图像”和“9点0.1秒的点云”强行融合。车速60km/h时等效移动约1.7米这对小目标检测是致命误差。3.2 软同步让特征“对齐到同一时刻”我的做法是先记录每个传感器数据到达时的系统时间戳选一个参考时间通常选激光雷达帧时间或某张图像曝光中间时刻把其他模态的数据插值或外推到该时刻。最简单的方案是恒速运动假设已知上一帧和下一帧点的位置按时间比例线性插值到参考时刻。这个方法在低速场景下足够高速或急刹时会有误差。稍微进阶一点的做法是用IMU的角速度和加速度做运动补偿把旋转和平移量都算进点坐标变换里。伪代码思路def align_point_cloud_to_timestamp(pc, ts_prev, ts_cur, ts_ref, imu_dataNone): # 1. 计算参考时刻在 (ts_prev, ts_cur) 区间内的比例因子 alpha (ts_ref - ts_prev) / (ts_cur - ts_prev) # 2. 若 imu_data 可用用旋转向量与平移向量构造变换矩阵 delta_T interpolate_by_imu(imu_data, alpha) # 3. 点云右乘delta_T完成运动补偿 return pc delta_T[:3, :3].T delta_T[:3, 3]软同步不要求硬件改动适合先把算法链路跑通。要注意的一点是插值只对短时间内误差有效太大延迟根本无法靠插值修复这时就得考虑硬同步。3.3 硬同步与触发器工程上更彻底但更费事硬同步方案通常用脉冲信号给传感器打同步时间戳或者用精确时间协议让所有传感器共享同一个时钟。打上硬件时间戳后传感器数据到达时可以直接用硬件时钟对齐而不是靠软件接收时间猜。但硬同步在工程上实施成本不低。我之前在某个项目里推动过硬件时钟同步最后因为传感器的触发接口不一致花了几周才把所有数据的时间戳对齐到同一毫秒级。实际项目里如果算力板卡资源有限先把软同步做好更容易见效。我个人的经验是先软同步把pipeline跑通等测出的误差确实影响精度了再考虑硬同步。4. 拆开Transformer哪几层在做融合哪几层在做感知Transformer把多模态融合从“手工规则”变成了“数据驱动”。但很多读者拿到网络结构图会懵那么多注意力模块到底哪一步是在做融合哪一步是在做感知4.1 为什么是Transformer把不同模态当成“同一桌不同语言的人”卷积网络做融合时通常是把两个模态的特征图在通道维度上拼接然后继续卷积。这种方式的局限在于卷积核感受野有限跨模态的长距离依赖得靠堆层数才能覆盖而且拼接前两个模态的语义没有对齐。Transformer的注意力机制天然适合跨模态建立联系每个位置都能直接“看到”另一个模态的任意位置不需要中间层层传递。而且注意力权重是动态计算的网络自己学会在恶劣天气下少信任图像、在缺纹理区域少依赖激光雷达。这样一来“理解彼此”就不再是手工设定的规则而是从数据里学出来的分布。4.2 Token化图像patch、点云pillar、雷达点云成为同一种单位在进入Transformer之前所有模态都要变成token序列。图像的常见做法是把特征图切成patch映射为token序列点云通常用pillar或体素特征作为token毫米波雷达点云小而稀疏可以每个点或每根柱体作为一个token。关键点是每个token都必须附带位置信息——BEV网格有坐标图像patch有2D坐标点云token有3D坐标这样才能让后续的注意力知道“这里”和“那里”的关系。位置编码通常加在token特征上工程上可以用正弦位置编码也可以直接用可学习的嵌入表。复杂点云场景下我会同时加模态类型编码让网络一开始就知道这个token是视觉来的还是雷达来的。4.3 自注意力先清场交叉注意力再搭桥通用做法分两步第一步各模态先自己内部做一遍自注意力把模态内的歧义去掉。比如被树挡了一半的人图像分支经过自注意力后可能根据两侧背景补全出完整的轮廓。第二步做交叉注意力融合让一个模态的token去查询其他模态的token。我把这个逻辑总结成一句话先内部开会统一口径再跨部门开会整合资源。如果一开始做跨模态注意力两个模态都各说各话融合效果很差。先各自把噪声消掉再融合信息利用率会高很多。交叉注意力的典型形式是Q来自主模态比如BEV queryK和V来自不同模态的特征。自车周围整个空间被划分成网格每个网格一个query去查询图像特征和点云特征聚合回来的信息就是该网格位置的综合特征。4.4 可变形注意力不是把眼睛撒满整张图而是让注意力学会找重点原始Transformer的注意力是全局的每个query都要跟所有token做计算对BEV大范围场景计算量爆炸。工程上更常用的是可变形注意力思想每个query只采样少量关键位置用一个小型预测头预测采样点的偏移量和权重。举个例子某个BEV网格想判断“这里是不是有车”它不需要遍历整幅图像的所有像素只需要预测几个采样点集中在目标物体边缘附近再去查询这些位置的特征就够了。这样计算量显著降低收敛也快很多。对激光雷达点云这种稀疏模态可变形注意力还有个额外好处采样点可以只落在有点云覆盖的区域避免大量注意力被空网格吸引。5. 训练一版能跑的模型数据、Loss与模态缺失网络结构再好训练数据不够合理也白搭。多模态融合特别容易依赖“最强势的那个传感器”一旦它失效模型就崩。5.1 真值从哪里来激光雷达画框、相机做语义、雷达做剪枝3D目标检测的真值框通常以激光雷达点云为主因为点云尺度准确、不受光照干扰。标注时在点云视图里画3D框再把框投影回图像里做校核能发现点云稀疏导致的漏标或错标。毫米波雷达点一般不适合单独建真值因为点太稀、没有语义。它在训练中更多扮演“辅助模态”提供速度先验和夜间时的补充信息。5.2 模态随机遮挡逼着网络学会“相互补位”有个很容易踩的坑模型在训练集里看惯了“图像点云毫米波”三者同时出现一旦部署时某一路传感器故障融合性能直接崩到比单模态还差。解决办法是训练时做模态随机遮挡。我的习惯是单模态以20%~30%的概率随机mask掉双模态同时mask的概率控制在5%以内三模态全mask不加。这样做的好处是网络被迫学会从剩余模态里寻找线索部署时即使某传感器掉线输出也不会完全烂掉。还要在验证集里单独建一个“模态缺失测试子集”专门监控每个模态单独丢失时的性能下降幅度。5.3 白天黑夜与天气数据不均衡比网络结构更伤人传感器性能受时间和天气影响极大。常见做法是统计训练集的时段分布如果白天数据占绝大多数网络会隐性拟合“白天模式”到了夜间反光干扰大的场景直接失灵。补充几个高效的增强图像的亮度和对比度随机扰动、夜间噪声注入激光雷达点云随机降密度、加雨点噪声毫米波雷达点做位置抖动和多路径回波模拟。训练集里至少保留20%-30%的夜间或恶劣天气样本否则验证集指标再高也说明不了问题。5.4 实验设计先各自为战再看融合收益评估融合模型的效果至少要跑三类对比单模态基线、简单特征拼接基线、完整的多模态Transformer模型。只看一张融合结果表远远不够要拆场景看。我习惯做一张分场景结果表场景图像mAP点云mAP融合模型mAP融合相对提升白天城区0.520.580.626.9%夜间0.300.540.575.6%雨天0.350.460.5110.9%隧道出入口0.280.410.447.3%还有一种情况必须警惕某场景融合后反而比单模态低。这通常是模态特征没有对齐好或者两个模态在该场景下存在语义冲突。出现这种情况不用急着加模块先回看时间同步和空间标定。6. 部署时不那么优雅的部分内存、延时与corner case训练跑的模型终归要上车。到了部署环节Transformer这种“富贵模型”会遇到很多在训练环境里完全不会考虑的问题。6.1 注意力机制在边缘设备上是“富贵病”算力预算怎么定Transformer的计算开销主要在注意力矩阵乘法和全连接的FFN层。边缘计算平台上同样参数量的Transformer通常比CNN慢不少。如果目标帧率需要20Hz以上就得从一开始把计算预算算清楚。一个粗略的规划思路是输入图像分辨率控制在800x450内BEV网格分辨率采用0.3米以90米x60米覆盖范围计算大约9万到12万网格点云pillar数量裁剪到每秒不超过5万根。比起追求极致精度部署场景更看重“稳定在帧率以上”这个硬指标。把Transformer层数控制在6层以内注意力头数取4到8通常能在性能和算力之间找到平衡。6.2 从fp32到int8注意力矩阵也能量化部署优化中比较成熟的手段是fp16和int8量化。fp16一般不需要特殊处理直接转换就有不错效果。int8量化要小心注意力分数的动态范围变化不同帧、不同位置的注意力分数差异可能很大动态范围不固定量化误差会让长距离依赖失效。实操上量化后一定要重点看夜间场景和目标较小场景的精度下降情况。如果注意力层误差大可以对这部分用更高位宽或者混合精度也可以改用动态量化只对注意力权重做逐token的缩放校准。6.3 标定漂移融合开始错位时系统不会给你报错外参漂移是最难察觉的部署问题。漂移初期模型还能正常输出但框的位置会整体偏移几厘米到十几厘米。你不去对比原始点云和图像投影根本看不出问题。建议在部署时加一个监控模块每隔一段时间用实时数据计算激光雷达点云重投影到图像后的边缘对齐误差设置阈值超过则触发报警。实测下来这个监控比定期人工检查靠谱得多尤其是行驶路况颠簸、天气温差大的场景。6.4 工程上比网络结构更值得盯的corner case清单训练数据里没有的新情况往往比参数调优更能决定系统可靠性。我整理了一份需要考虑的corner case清单横穿马路的行人被静止的围栏遮住一半视觉分支看不到雷达点也稀路面金属井盖在毫米波雷达上的强回波造成虚假目标前车刹车灯的影响让视觉误判“红色区域”点云又无对应大雨时激光雷达点云产生大量噪声图像也模糊隧道出入口的剧烈光照变化桥下阴影内行人的对比度极低视觉特征丢失处理这些场景常规手段是补数据、加增强但更有效的是把多模态缺失和噪声模拟直接做在训练阶段让网络在训练时就看到各种模态退化下的互补信息。最后再分享一点个人体会。多模态融合系统是不是一定要上最重的Transformer不一定。如果场景相对固定、速度不高一个轻量级的特征拼接加卷积也能跑。但如果你想做的是真正能应对风雨、夜间、突发遮挡的可靠感知系统多模态Transformer是目前工程上比较值得投入的方向。它给的是一整套“如何让传感器相互理解”的框架而不只是一个精度更高的检测头。动手做的时候不用一步到位我建议先按这个顺序推进先标定好空间和时间同步再做两个模态的融合实验验证收益后逐步加入第三个模态。每次加一个模态都要检查它在不同场景下的边际收益。跑通了再谈Transformer结构优化和后端量化。这样流程走下来系统虽然不完美但至少配得上“稳定”两个字。