自动驾驶3D多目标跟踪：基于PMBM的多传感器融合概率框架

1. 为什么这篇论文值得啃做自动驾驶感知的朋友应该都有这种感觉单帧的3D检测已经卷得差不多了各家开源方案刷榜刷得飞起但一上到实车、一跑连续帧问题就全暴露了。目标ID跳变、遮挡后跟丢、多传感器时间戳对不齐导致融合结果抖动……这些问题在单帧评测指标里根本看不出来但在下游规划、控制模块里会被放大得极其明显直接决定一个系统能不能真正落地。这篇2020年的论文解决的问题恰恰就是这个在真实自动驾驶场景下怎么把相机和激光雷达的信息真正拧成一股绳做稳定、可靠的3D多目标跟踪。论文的核心思路不是简单把两个传感器的检测结果做个后融合而是统一在一个概率框架里建模。先说结论这是一个基于随机有限集Random Finite Set, RFS理论的跟踪方案核心模型是PMBMPoisson Multi-Bernoulli Mixture而且是用非参数的方式实现的。这里面有两个值得关注的点第一它把视觉和雷达点云放在一个共同因子化的分布里处理而不是各跑各的再合并第二它能在不训练的情况下泛化到新场景——注意这不只是调参带来的鲁棒性而是模型本身结构带来的这一点非常关键。文章适合谁读做多传感器融合算法的人、做自动驾驶跟踪模块的工程师、以及想从贝叶斯滤波角度理解3D多目标跟踪的研究者。如果你只对单帧检测感兴趣这篇可能帮不上什么忙但只要你碰过跟踪、碰过融合这篇文章里的思路大概率能给你提供新的角度。2. 任务定义多目标跟踪到底在解什么数学问题2.1 从经典跟踪到RFS视角的转换传统的多目标跟踪大部分人学的是从卡尔曼滤波、JPDA联合概率数据关联那一套入门的。那套思路本质上是在做数据关联——这一帧的检测框到底对应上一帧的哪个目标在2D场景目标少、遮挡不严重的时候这套逻辑够用但到了3D自动驾驶场景有个很尴尬的问题检测结果本身就是不确定的漏检、虚警、遮挡后的短暂消失都是常态而经典数据关联方法对这类不确定性处理得很吃力。RFS的思路则是换了个目标把“多目标状态”本身看成一个随机有限集合。集合里的元素数量本身是随机的因为目标可能随时出现、消失每个元素的状态也是随机的。这样一来跟踪问题就变成了对集合后验概率密度的递推估计。你不需要先做硬性的数据关联再滤波而是把关联不确定性直接积分到概率推理里。PMBM这个名字看着吓人拆开其实不复杂。P是Poisson用来建模那些还没有被确认的目标也就是“可能有但还没实锤”的那部分MBM是Multi-Bernoulli Mixture用来建模已经被确认的目标集合的混合分布。每一个Bernoulli分量描述一个目标“有一定概率存在存在时状态服从某个分布”。多个Bernoulli分量组合起来就是对一幅完整多目标态势的假设。2.2 为什么选非参数实现这篇论文用了一个很聪明的做法非参数的PMBM实现。什么意思传统RFS实现为了数学上的可处理性往往要给目标状态分布一个固定的参数形式——最常见的是高斯分布配合线性高斯模型这样可以用闭式解做预测和更新。但真实世界的目标运动不是线性的外观特征也不是一个高斯能描述的。非参数方法在这里的做法是用一组加权粒子sample points来表示目标状态分布。每个粒子上附带生存概率、运动状态、外观嵌入向量等信息。这样一来模型不需要假设目标的运动模型是线性的也不需要假设传感器观测噪声是高斯的灵活性大很多。代价是计算量上去了——你要维护的粒子数量可能很大实时性怎么保证论文里给了工程上的答案后面我会详细说。2.3 问题是怎么被数学化的这篇论文对所解决的3D多目标跟踪问题的正式定义比很多同类文章要严谨得多。它明确处理了两个子问题一个是数据关联的不确定性。检测和估计之间的关联是未知的而且关联关系会随着时间变化。论文通过基于随机有限集的贝叶斯递推结构来处理不需要像经典多假设跟踪MHT那样枚举所有关联假设——虽然枚举是精确的但NP-hard式的爆炸在工程上不可接受。另一个是传感器异步性。相机和激光雷达不是同频触发的这就意味着不能简单地把两个模态的观测拼到一起做同步更新。这篇论文的处理方式是两个传感器共享同一个潜在目标状态但各自生成不同的观测模型分布在“共同因子化”的结构下被联合推断。这一点是个大亮点后面讲多模态融合的时候再展开。3. 多模态融合不是“拼接”而是“因子分解”3.1 视觉难跟踪、点云难分类那怎么办先聊一个问题为什么单靠视觉或者单靠激光雷达做3D跟踪总做不完美相机给出的2D检测框、外观嵌入特征、语义类别信息在目标被遮挡、重出现、或者与其他目标外观相似时是非常有力的区分信息。你单看点云两辆同款白色轿车在近距离交错后点云分布几乎没有区别ID大概率要串但相机图像能分辨出细微的贴纸、后视镜角度、尾灯形状差异。这是视觉的不可替代优势。激光雷达则能给出空间结构的精确度量目标的精确3D位置、尺寸、朝向、运动速度。相机图像从原理上讲很难提供毫米级的位置精度而点云不仅可以还能在夜间、逆光等恶劣光照条件下正常工作。单模态的短板都很明显。这篇论文的核心观点是与其设计一个复杂的决策逻辑去判断信哪个传感器干脆把两种观测放到同一个概率模型里让模型自然地在空间维度相信激光雷达、在外观维度相信相机。3.2 共同因子化是怎么实现的“共同因子化”co-factored这个词在摘要里出现时很突兀但在上下文里它其实讲了一个极其实用的设计整体的后验分布可以被分解为两个条件独立的因子每个因子接受一种模态的观测然后被相乘起来得到联合状态估计。可以做一个类比来理解我们判断一个人的身份时会根据“他说话的声音”听觉模态和“他长什么样”视觉模态独立地给出判断再把这两个证据合在一起。如果声音很像但面貌模糊你会更依赖声音如果声音模糊但面貌清晰你会更依赖面貌。这个决策过程不需要一个“统筹管理器”去协调两个模态——它们天然就各自产生一个分布然后合并。论文的PMBM实现里视觉分支计算的是目标外观嵌入特征的相似度分布激光雷达分支计算的是目标3D几何状态的递推分布。两个分支都是基于同一个目标假设集合但各自独立的观测似然让模型天然学到了“该信谁”。3.3 职业级的异步处理传感器时间戳对齐问题大概是所有做融合的人都绕不过去的坑。相机帧率可能是15Hz、30Hz激光雷达可能是10Hz、20Hz不同步时如果强行插值要么引入额外延迟要么产生鬼影般的伪目标。这篇论文的因子化设计让异步处理变得很自然当激光雷达测量到达时只更新点云分支的分布视觉分支保持不变反之亦然。每个传感器的测量在到达时立即融入当前信念不需要等待“配对帧”。这本质上是一个事件驱动的更新机制比同步插值的方式在时延上要低得多。这个做法对工程实现的启发是直接的在多传感器跟踪模块的设计中不要试图把不同传感器校准到统一时基再处理而是各算各的、及时融入最后在目标层面上做联合估计。4. 模型的亮点设计AOELoss、雷达点云、在线隐私保护4.1 训练目标不是“检测匹配”的拼接跟踪神经网络最传统的训练方式是两步走先训练一个检测器然后单独训练一个ReID目标重识别模块。这样做的问题是梯度不会从跟踪损失回流到检测特征提取器——说白了检测网络根本不知道自己的特征会被下游怎么用。这篇论文定义了一种新的损失函数称为AOE Loss——它是通过Hungarian匹配在预测轨迹和真实轨迹之间求解的最优匹配偏差。这可不是一个普通的加权损失它包含了三个训练信号分类损失、回归损失、ID分类损失并把这些信号在最优匹配结构的约束下统一起来。AOE Loss的关键洞察在于你不需要让检测器在每一帧都完美预设所有目标也不需要让ReID网络对所有目标单独生成最优嵌入你只需要让它在“匈牙利匹配完成后分配到的那个目标”上做得足够好。这就避免了传统方法里“检测和跟踪各自为战”的问题。4.2 雷达点云廉价且被低估的模态被用起来了多模态里一个被低估的传感器是雷达。在恶劣天气条件下激光雷达会退化但毫米波雷达几乎不受雨雾影响。传统雷达点云稀疏、噪声大在2D鸟瞰图上只能形成少数几个点很难直接用于精确的3D目标检测。这篇论文却把雷达点云用于一个非常巧妙的用途不是直接用雷达点云做3D检测而是用雷达点云在数据关联阶段提供运动学线索。由于雷达点云的多普勒效应能直接给出目标径向速度多普勒速度当车辆快速交错、或者被遮挡目标重新出现时运动学线索能帮助跟踪器快速恢复正确关联。论文在第4节讨论了雷达点如何用于在3D空间中生成更有区分度的点云特征以及使用低分辨率、噪声较大的模态如何与高分辨率视觉融合。值得留意的是这给实车工程带来了很大的启发——很多车队有不错的激光雷达和摄像头配置但往往忽视雷达信息在关联阶段的价值。4.3 在线遗忘很少被提到但很重要的设计这篇论文有一个不太起眼但很有意思的段落如何在跟踪过程中在线地“遗忘”某些外观信息以保护隐私。这是一个在学术界不太被关注但实车落地一定会遇到的问题如果车辆在公开道路上行驶持续跟踪一个行人、另一辆车系统会构建出关于该个体移动模式和外观的持续知识。这些知识在用户不知情时被存储、处理在法律上是一个敏感话题。论文的方案是这个描述有点玄但实现上它其实是在外观嵌入向量训练中加入一个约束防止跟踪系统对特定目标形成“时间上一致的”外观特征。特征在每次更新时都有一部分的随机扰动让同一目标在不同时间的嵌入向量不完全一致。这样系统在做数据关联时依然能区分目标但无法提供“该目标在特定时间段内出现在哪些位置”的详实证据。这个设计直接对应当前数据法规中的“被遗忘权”理念。第一次看到这个设计时我只觉得巧妙后来在做落地风险评估时才发现论文作者在五年前就把这个坑埋在了路线上这是很超前的工程意识。5. 实现细节与训练稳定性从理论到可用代码5.1 Loss构建的边界条件AOE Loss定义表面上简单但实现上有不少细节。首先匈牙利匹配必须基于3D空间中的距离度量不能直接用2D图像坐标的IoU。因为相机视图下的2D IoU在目标尺度差异很大时完全不可靠——远处的一个目标在图像里可能只有几像素但它的真实3D框跟近处目标有重叠时2D IoU根本反应不了空间关系。实际实现时可以用3D IoU或者加权的L1距离作为代价矩阵。论文中的默认方案是3D中心和朝向角的加权组合。其次考虑的是代价矩阵的非对称性。匹配完成后需要在无匹配的行列上额外计算虚警项和漏检项这样才能让loss正确鼓励“多检测出真实目标”和“少产生虚假目标”。5.2 训练时的模态丢失模拟多模态融合模型训练时的一个经典问题是模态缺失训练集里相机和激光雷达都很好测试时工业相机突然故障只能靠雷达或激光雷达扛或者输入网络的光线不足以给图像部分提供可靠语义。如果不做模态丢失训练模型会过度依赖某一个模态的特征在真实场景中模态异常时性能会断崖式下跌。论文里没有细讲怎么加模态丢失训练但根据我自己的经验最好的做法是随机以一定概率比如15%到30%在训练时把某一模态的输入置为不可用不可用的模态网络分支直接输出固定先验不参与loss计算这样模型的另一个模态分支会被迫强化自身真正学到“独立可用”的表征而不是把两个模态的特征混在一起互相补盲。5.3 后处理中的“参数陷阱”很多刚接触这套方法的工程朋友容易在不该调参的地方大动干戈。我总结三个极易踩坑的参数第一个是检测置信度门限。设置过高会导致漏检率上升而漏检在跟踪系统里造成的后果比误检严重得多——一旦漏检一段轨迹就断了重检测需要好几帧才能恢复。设置太低虚警太多但虚警可以通过跟踪逻辑中的“确认状态”过滤掉连续多帧关联上才确认目标所以总体上跟踪系统对虚警更宽容。实践上建议门限偏低不偏高。第二个是粒子数的选择。粒子数太少分布表达能力不足目标状态估计方差大粒子数太多计算量随目标数量线性膨胀实时性崩。论文里给出的建议值是每目标100-300个粒子分类目标确认/未确认不同状态使用不同采样密度已确认目标用较少粒子维持就行。第三个是遗忘因子的设置。遗忘因子控制历史观测的衰减速度这个参数直接决定系统在目标机动时的跟踪响应速度。设置太大衰减慢直线跟踪稳定但对急转弯反应迟钝设置太小衰减快机动跟得上但噪声影响也被放大。论文里在自动驾驶场景用的是相对大的遗忘因子因为高速场景下目标的运动模型相对可预测平滑比敏感更重要。5.4 推理时的整体流程把前向推理流程串下来看第一步相机检测网络2D检测器输出目标框、类别置信度和外观嵌入特征。第二步点云检测网络3D检测器输出目标的3D框、速度和类别信息。第三步两个分支的检测结果各自被投影到统一的3D鸟瞰坐标系中。第四步用当前后验目标和候选检测计算似然匹配——注意这里不急着做确定性匹配而是同时维护多个匹配假设。第五步执行PMBM的更新方程把新观测的概率信息融入状态估计。第六步对已确认的每个目标执行状态提取粒子加权平均或最大后验估计输出最终的3D轨迹。这里面每一步都有硬伤风险。第三步的投影不是简单把3D框角点沿相机内参投影就行了还要处理雷达点云的径向速度和相机帧的时间偏移——如果雷达帧时间和相机帧时间不一致投影位置会有系统性偏差数据关联阶段会误匹配。所以推荐的做法是把所有观测投影到目标时刻对应的坐标系里而不是统一投影到当前帧坐标系。6. 常见问题与排查心得6.1 匹配器不收敛怎么办模型训练开始时Hungarian匹配代价矩阵里大部分元素都是极大值代表不可能匹配极小值代表强匹配很少。这导致匹配器在训练早期一直被“强行配对”到错误的检测上——梯度方向混乱更新噪声大。直接的解法是在训练开始阶段给代价矩阵加一个较大的温度系数temperature scaling把代价差异拉平。随着训练推进逐步降低温度系数让匹配器逐渐学会“挑软柿子捏”。温度系数初始值设为3.0训练5000步后衰减到1.0效果会稳定得多。6.2 轨迹ID频繁切换如果你看到跟踪结果里ID切换频繁先别急着调匹配阈值先去看数据关联特征是否真的在起作用。一种很容易被忽视的情况是外观嵌入向量训练得过早饱和所有目标的外观特征都收敛到同一个方向区分度不够。这种情况的典型经验表现是网络loss已经降得很低但跟踪ID切换率没降。解决办法很简单给ReID分支增加triplet loss约束并且在数据加载时确保每个batch里包含同一目标在多个帧的实例。没有时间维度的采样外观分支学不到“同一个目标随时间的变化规律”ID稳定性很难提升。6.3 目标短暂遮挡后丢失遮挡后的轨迹恢复是3D多目标跟踪里最常见的痛点。PMBM框架里对应的是被遮挡目标进入“未确认状态”后在遮挡期间缺乏测量更新粒子权重的方差会随时间发散。实测中最有效的三个建议分别对应三个环节预测阶段不用恒定速度模型改用带过程噪声的自适应运动模型当目标消失时增大过程噪声给重新出现时状态波动留余量更新阶段放宽确认状态的门限让被遮挡目标在重出现在候选检测周围有过一段“容忍期”重用历史外观嵌入当待关联检测的目标外观集合里包含“遮挡前该ID的嵌入”就显著提高关联成功率。6.4 多模态时间戳错位的排查很多人在代码里统一用传感器的时间戳做对齐但实际上不同传感器的时间戳可能各自有自己的时钟域。排查方法论把所有传感器的数据先单独做一个离线跟踪各自确认3D轨迹的时间戳然后把不同传感器轨迹相互关联看同一目标时间戳差异的模式如果发现某个传感器轨迹总是相对另一个滞后固定帧数那说明是时钟偏移导致的时间戳系统性偏差如果是随机抖动则要考虑网络传输和队列缓冲引入的抖动这时需要在各传感器模块内部加入独立的缓冲队列。6.5 私有检测器的适配大部分朋友不会直接用论文配套的检测网络而是替换成自己训练的检测器。这里最常见的问题是你的检测器输出往往是3D框加类别但没有对外观嵌入。外观分支如果缺失丢到PMBM框架里自然只能靠空间匹配ID稳定性显著下降。或者说你可以在自己的检测网络FPN特征金字塔的中间层加一个额外的小头学习一个128维的嵌入向量。这个附加模块只增加很小的计算量但能大幅提升跟踪的稳定性。7. 这篇论文对我的三个直接影响7.1 点云和图像不必强行对齐到同一时刻做融合以前我总是对标定文件里的时间戳对齐功能抱有过高的期望做了各种插值对齐。但看完这篇论文我意识到与其把两个传感器硬凑到一个时间片上再融合不如在概率框架下各算各的只保证“目标状态”是同一个。这让融合模块的延迟减少了一帧以上而且代码结构也反而变简单了。7.2 检测器的误检在跟踪框架下的容忍度比想象的大单独评测检测器时虚警比例大于5%可能都算不合格但在跟踪系统中只要虚警不持续出现在同一位置就影响不大。跟踪系统的关键指标是“确认阈值”不是“误检率”。理解到这一点后我在部署检测器时的接受标准、调参方向都和以前完全不同了。7.3 数据关联是整个系统的命门检测再准、特征再强如果关联决策不够好系统就是散的。论文的PMBM框架把关联不确定性作为核心模块做了精细建模这是很多工程方案没给到重视的地方。它不像很多跟踪方案那样“检测完再match”而是把关联逻辑揉进了整个概率估计流程。这套思路对齐了我日常调试中“ID不稳定问题往往在关联”的直觉。8. 实操回顾与保留观点实际复现的过程中我保留了以下几点这篇文章的所有公式推导不依赖于私有检测器架构因此可以无缝替换到自己的检测网络之上开源代码仓库里的RFS跟踪实现比我自己用MHT实现的版本在内存管理方式上要好不少值得借鉴论文中关于“在线遗忘”的设计在自己部署时往往被忽略但它对合规风险评估的价值非常高建议早做规划而不是事后补救。最后有一点个人的保留意见论文的框架对“目标外观一致”的依赖度非常高如果同一个目标在时间维度上外观变化剧烈比如车辆贴膜、行人换装外观嵌入分支的作用会大打折扣。这类场景下还需要配合更鲁棒的运动模型才能稳住关联性能。这也是实车测试中我发现的最常见的失败模式之一。踩过几次坑之后我对选择这个框架的判断是它可能是学术界和工程界之间平衡得最好的一套方案了。它以严谨的概率建模作为地基又给出了大量工程上可行的实现细节。如果你正在做3D多目标跟踪且对可靠性有要求这篇论文值得认真读两遍。