★ FEATURED ARTICLE 传感器测到同一个目标结果一个说“置信度0.8是车”另一个说“置信度0.7是卡车”到底信谁这不是数学考试是自动驾驶环境感知每天都在面对的真实问题。目标级融合的本质就是把这些来自不同传感器、不同来源、甚至互相矛盾的感知结果在“目标”这个粒度上统一成一个可信、稳定、可决策的表示。我这段时间一直在用Matlab做一套基于Dempster-Shafer证据理论的目标级融合实现把毫米波雷达、激光雷达和摄像头的检测输出揉在一起解决的就是这类“你说你的、我说我的”问题。如果你也在做多传感器融合或者刚接触DS证据理论、信息矩阵融合这些词正愁找不到一套能直接跑起来的参考实现那这篇内容应该是你的菜。我会把DS融合的核心原理、Matlab代码架构、以及我在实际调试中踩过的坑一次讲清楚。1. 项目概述与核心思路1.1 为什么做目标级融合而不是像素级或特征级多传感器融合一般分三档像素级、特征级、目标级。很多入门教程一上来就讲像素级融合看着很高端但落地的时候你会发现像素级融合对硬件平台和时间同步的要求极其苛刻摄像头图像和激光雷达点云要精确配准到每个像素计算量直接爆炸而且对通信带宽的要求也让人头疼。做自动驾驶量产项目目标级融合才是主流路线。目标级融合的意思很简单每个传感器先各自完成目标检测和跟踪输出一个“目标列表”每个目标带有位置、速度、类型、置信度等属性。融合算法要做的就是把多个传感器送来的目标列表进行关联、合并、冲突消解最终输出一个统一的、带可信度评估的目标列表。这样做的好处非常明显传感器内部处理可以各自优化融合模块只需要处理结构化的目标信息实时性容易保证各个传感器之间的时间同步要求也相对宽松。我在项目里选型的逻辑就两条第一传感器种类不同检测原理差异大目标级抽象能最大程度保留各自优势第二融合结果要能直接送到下游的决策规划模块目标级输出天然就是规划模块需要的输入格式。所以这套方案的定位不是学术demo而是尽量贴近工程实践。1.2 为什么选Dempster-Shafer而不是贝叶斯很多人会问目标级融合用卡尔曼滤波加贝叶斯不就够了吗确实如果所有传感器对目标的观测都服从高斯分布、误差特性稳定、目标类型只有“是或否”两种状态贝叶斯是最优的。但真实场景里有个麻烦事传感器给出的判断往往不是“是或不是”而是“可能是A也可能是B”。比如摄像头看到一个轮廓模糊的物体它给出的结果是“车0.6、卡车0.3、不确定0.1”这种带认知不确定性的输出贝叶斯框架很难自然地表达。Dempster-Shafer证据理论也就是常说的DS证据理论最大的特点就是可以显式表达“未知”和“不确定”。它不要求你对一个命题必须给出完整概率分布而是允许你给“车”、“卡车”、“车或卡车”、“未知”各自分配一个基本概率分配值。这在传感器输出天然带有不确定性的场景下特别合适。DS融合还有一个贝叶斯不具备的优势它不假设各传感器对同一命题的判定在逻辑上完全一致。当两个传感器给出矛盾结论时组合规则会通过归一化自动处理冲突保留一个合理的合成结果。当然冲突过大时DS也有自己的问题这个后面我会专门讲也是我在项目中花时间最多的部分。1.3 信息矩阵融合和DS的关系标题里的“信息矩阵融合”容易让人误解。我最初也以为信息矩阵融合是独立于DS的另一套方法后来在建模梳理时才发现信息矩阵融合更多是指融合算法在状态估计层面的表现形式把多个观测信息以信息矩阵和信息向量的形式叠加得到融合后的状态估计。卡尔曼滤波在信息形式下做状态更新本质上就是信息矩阵的叠加。DS证据理论解决的是“目标属性/类型的置信度融合”信息矩阵解决的是“目标运动状态的参数估计”两者在完整的目标级融合管线里是分工合作的。举个例子毫米波雷达给出目标位置、速度测量激光雷达给出同样的状态观测这部分的融合我用信息矩阵形式实现等价于一个信息滤波。摄像头给出的“这个目标是车还是卡车还是行人”的分类置信度则走DS证据理论融合。最后把状态估计和类型判定组合起来输出一个结构完整的目标。这个设计让我在工程实现上思路非常清晰状态连续量用信息滤波类型离散量用DS融合各管一摊互不纠缠。2. 核心原理拆解从基本概率分配到DS合成2.1 识别框架与基本概率分配DS融合的第一步是定义识别框架通常用希腊字母Θ表示它是一个互斥且完备的假设集合。在自动驾驶目标分类场景里识别框架一般定义为Θ {车辆, 行人, 自行车, 其他}所有可能的目标类型假设都从这个框架里取。DS的关键概念是基本概率分配函数BPA记作m(A)它对框架的每一个子集A分配一个0到1之间的数值表示该证据对“目标是A”这个命题的支持程度。注意这里A可以是单个元素也可以是多个元素的并集。举个例子摄像头对前方一个目标的输出可能是m({车辆}) 0.55 m({行人}) 0.10 m({车辆, 行人}) 0.25 m(Θ) 0.10最后一个m(Θ)0.10表示“我不知道它是什么但它肯定是Θ里的某一种”的未知程度。这种“把不知道的单独列出来”的做法就是DS和贝叶斯最直观的区别。贝叶斯要求所有概率之和为1且必须分配到互斥的单元素DS却允许你把一部分概率分配到“集合”上甚至允许保留“完全未知”的残余质量。这个特性在传感器融合中价值很大。比如大雨天激光雷达点云严重衰减它给出的目标类型BPA里“未知”占比就会很高天气好的时候“未知”占比很低。融合算法可以通过“未知”质量自动感知每个传感器当次观测的可靠程度而不需要额外去建一个复杂的传感器置信度模型。2.2 Dempster-Shafer组合规则与归一化两个独立证据m1和m2的组合用DS正交和公式计算m12(A) (1 / (1 - K)) * Σ_{B∩CA} m1(B) * m2(C)其中K是冲突系数定义为K Σ_{B∩C∅} m1(B) * m2(C)K的物理意义是这两个证据互相矛盾的程度。当K0时两个证据完全一致不需要归一化K越接近1冲突越大K1时归一化分母为零组合规则失效这就是DS理论最著名的悖论场景。我试着用生活化的方式理解这个公式假设你请两位朋友判断一个罐子里是硬币还是纽扣。第一位朋友有70%把握是硬币拿不准的概率是30%第二位朋友有60%把握是硬币拿不准的概率是40%。组合时先把两个人给出“硬币”的质量相乘再考虑一人说“硬币”另一人说“不知道”的情况网上算出来的结果会倾向硬币而且“不知道”的总体质量会被大幅压缩。如果两人给出的结论完全相反比如一个人强认为硬币、另一个人强认为纽扣那K就会很大最后合成结果的分母1-K会很小放大了分歧部分的相对权重。归一化因子1/(1-K)是DS组合的“双刃剑”。一方面它保证了合成结果仍是一个正规BPA所有质量之和为1另一方面当冲突很大时它会把那些微小的一致意见放大到不合理的高度。这也是我在项目中特别警惕的地方后面会详细讲如何处理。2.3 冲突处理与折扣“冲突太大该怎么处理”这个问题几乎是我在项目里被问得最多的。实际场景中摄像头认为目标是一辆小轿车毫米波雷达却因为多径反射得到一个“目标突然消失”的检测结果激光雷达则给出“目标类型未知”。三种证据一组合K值可能超过0.8直接套用原始组合公式融合结果会变得很不稳定。处理冲突的第一个常用手段是折扣。每个传感器的BPA在进入融合之前先乘以一个可靠性系数α同时把被扣掉的质量转移到“未知”上m(A) α * m(A), 对A ≠ Θ m(Θ) 1 - α α * m(Θ)这个操作的逻辑是如果传感器整体可靠性只有0.8那它提供的所有具体判断都要打八折剩下的0.2的质量全部归入“未知”表示“这个传感器这次的话我们不敢全信”。折扣不仅能平滑冲突还能让“未知”质量变成一个可以动态变化的缓冲池。另一个手段是替换组合规则比如使用Yager规则、Dubois-Prade规则或者干脆在K值超过阈值时降低融合输出更新的权重。我在Matlab实现里同时保留了几种规则通过参数开关控制方便做对比实验。对工程项目来说没有万能的融合公式只有针对场景数据验证出来的经验配置。2.4 目标级融合管线的完整设计DS融合不是孤立的一个函数它必须嵌入到完整的感知管线里。我设计的整体流程是各个传感器模块独立输出目标列表。融合模块对目标进行时空对齐。使用全局最近邻或联合概率数据关联完成目标关联。对关联上的目标组分别进行状态信息融合和类型证据融合。根据融合后的置信度进行目标决策决定保留还是删除目标。输出融合目标列表给下游规划模块。状态信息融合和信息矩阵有关如果两个传感器对同一个目标都提供了位置、速度观测我转成信息形式叠加等价获得更高精度的状态估计。类型融合则走DS组合规则把各传感器的分类BPA合成一个综合BPA。这两套数据在同一目标序号下并行处理互不干扰。这个架构最大的特点是模块边界清楚。我在代码里把数据关联、状态融合、证据融合、冲突处理分成独立的类函数后面想换关联算法或者想引入新的传感器类型改动范围都被限制在很小的模块内部不需要动整个主程序。对于打算长期迭代的项目来说这种解耦带来的收益是实实在在的。3. Matlab实现流程与关键代码3.1 场景与传感器配置先说实验场景。我用Matlab模拟了一个高速公路同向行驶场景自车以100km/h巡航前方有两辆目标车一辆在正前方约50米一辆在左前方约70米右侧路肩上有一个行人静止目标。三路传感器分别是毫米波雷达测距测速更新频率20Hz、激光雷达点云聚类后输出目标位置和类型候选更新频率10Hz、摄像头输出目标类别置信度更新频率15Hz。为了模拟真实测量特性我给每种传感器都加了不同的噪声和漏检概率雷达噪声小但存在多径引起的偶发野值激光雷达位置噪声中等但偶尔会因为遮挡丢失目标摄像头不到雨天不会失效但分类输出里经常出现“车/卡车”混淆。在Matlab里我用一个结构体数组保存每个时间步的模拟真值再基于真值生成各传感器的观测。这样做的优势是可以拿到融合结果的误差基准方便做定量评估。如果你的项目里有实车数据直接把真实传感器报文替换掉模拟生成模块即可。3.2 目标检测与量测建模由于我这里重点在融合目标检测模块不做太复杂。每个传感器的输出都被整理成一个统一的目标结构体这个设计非常关键。结构体字段包括targetID目标序号timestamp观测时间戳position目标位置x, yvelocity目标速度vx, vytypeProb分类概率向量对应识别框架existenceProb目标存在概率统一结构的好处是融合模块不需要关心上游是雷达还是摄像头所有信息都以同一种格式进入融合算法。我强烈建议你在自己的项目里也这么做哪怕只是写个demo也能少踩很多类型转换的坑。模拟雷达观测的代码大概是这样的% 模拟毫米波雷达目标观测 function obs generateRadarObservation(trueTarget, t) obs.targetID trueTarget.id; obs.timestamp t; obs.position trueTarget.position randn(2,1) .* [0.3; 0.3]; obs.velocity trueTarget.velocity randn(2,1) .* [0.5; 0.5]; % 雷达对目标的类型判别能力弱基本概率都放在“其他”或“未知” obs.typeProb [0.3; 0.1; 0.1; 0.5]; % 车辆、行人、自行车、其他 obs.existenceProb 0.9; end摄像头模块的分类输出会按不同目标类型给出置信度function obs generateCameraObservation(trueTarget, t) obs.targetID trueTarget.id; obs.timestamp t; obs.position trueTarget.position randn(2,1) .* [0.8; 0.8]; obs.velocity trueTarget.velocity randn(2,1) .* [1.2; 1.2]; % 摄像头分类能力强但容易混淆车辆和卡车这里简化为车辆\行人两种类型 switch trueTarget.type case vehicle obs.typeProb [0.7; 0.2; 0.05; 0.05]; case pedestrian obs.typeProb [0.1; 0.75; 0.1; 0.05]; otherwise obs.typeProb [0.2; 0.2; 0.2; 0.4]; end obs.existenceProb 0.95; end这里我把摄像头的识别框架也压成了和雷达一致的4类方便后面做DS组合。实际工程中摄像头类别可能更多可以后续扩展。3.3 证据构建与BPA生成传感器输出的分类概率不能直接作为BPA用原因在于它们的“不确定”语义不一致。雷达说“其他”概率0.5其实是“我测不准只能猜”摄像头说“其他”概率0.05其实是“我基本认出来了”。如果直接拿这两个概率做DS融合雷达的“其他”会压过摄像头的明确分类导致融合后目标变成“未知”这显然不合理。我采用的方法是先把传感器分类概率转换为BPA转换规则如下function bpa probToBPA(prob, alpha) % prob: 各类型概率向量, alpha: 传感器可靠性系数 n numel(prob); bpa zeros(1, (1 n) - 1); % 简化起见只对单元素焦点元素做BPA unknown 1 - alpha * sum(prob); for i 1:n bpa(1 (i-1)) alpha * prob(i); end % 最后一个位置表示识别框架Θ也就是“未知” bpa(end) unknown; end这个转换做了两件事乘以可靠性系数α体现传感器整体可信度把剩余质量转移到“未知”。α的选取我在4.4小节里专门讲这里先按经验值给雷达0.85激光雷达0.9摄像头0.95。需要说明的是这个朴素转换假设每个传感器输出的是互斥类上的概率忽略了“车或卡车”这类复合焦元。要表达复合焦元可以将prob向量某些分组合并再分配质量到集合元素。我代码里预留了扩展接口但在默认场景下先用简单形式因为这样对融合结果的分析更直观。3.4 DS融合核心函数接下来是整套代码的核心DS组合函数。我用了一个朴素的实现把BPA表示成一个长度为2^n-1的向量下标和焦点集合的按位编码对应。这样的好处是代码简单调试方便缺点是指数级存储空间只能用于目标类型数量较少的场景。我的识别框架只有4类所以2^4-115个元素完全够用。function [bpaFused, K] dsCombo(bpa1, bpa2, n) % 输入: bpa1,bpa2 分别是长度为2^n-1的基本概率分配向量 % 输出: bpaFused 融合后的BPA, K 冲突系数 numFocal 2^n - 1; bpaFused zeros(1, numFocal); K 0; for i 1:numFocal if bpa1(i) 0 continue; end for j 1:numFocal if bpa2(j) 0 continue; end % 将下标i和j对应的焦点集合做交运算 interIndex bitand(i, j); if interIndex 0 K K bpa1(i) * bpa2(j); else bpaFused(interIndex) bpaFused(interIndex) bpa1(i) * bpa2(j); end end end if K 1 bpaFused bpaFused / (1 - K); else warning(DS组合规则失效: K1, 证据完全冲突); end end这里用bitand做集合交集非常巧妙如果第i位表示“含第i类目标”那么B∩C的下标就是按位与的结果。比如“车辆”在识别框架{车辆,行人,自行车,其他}中对应第1位编码1“车或行人”对应两位都是1编码3两个焦点集合的交集就是编码按位与。这个技巧让代码变得非常紧凑也能避免写一堆集合运算函数。值得注意的是循环里我跳过了零质量的焦点元素这不仅能减少计算而且能避免一些无谓的零乘以无穷大的问题。如果某个焦点集合质量为零跳过它对结果没有影响。3.5 决策与输出融合后的BPA还得转成可供决策使用的形式。常用的决策规则有三种最大BPA决策直接选择BPA最大的单元素集合。简单直接但可能漏掉信息。最大可信度决策计算每个假设的信任函数Bel和似然函数Pl取Pl或Bel综合最大的。带阈值的决策要求最大BPA超过设定阈值且和其他单元素BPA的差值也超过阈值否则判定为“不确定”。我在项目里用第三种因为单独的最大值决策很容易被噪声带偏。比如某个目标融合结果是“车辆0.44、行人0.42、未知0.14”直接用最大值决策会判成“车辆”但本质上它是个“车还是行人都说不准”的边缘目标。自动驾驶里这种目标恰恰是最危险的正确做法是输出“不确定”同时附带两种可能性的概率让下游决策模块自己决定如何处理。function decision decideTarget(bpaFused, n, threshold) % 计算单元素焦元的BPA singleProbs zeros(1, n); for i 1:n singleProbs(i) bpaFused(1 (i-1)); end [maxProb, idx] max(singleProbs); sortedProbs sort(singleProbs, descend); if maxProb threshold (maxProb - sortedProbs(2)) 0.1 decision idx; else decision 0; % 表示不确定 end end这里threshold我通常取0.5当单元素BPA没能压倒性胜出时会明确告诉你“这个目标没法用现有证据可靠分类”。这样设计的好处是融合系统的拒识别率可量化。如果拒识别率过高说明传感器质量或可靠性系数设置有问题而不是系统在盲目决策。3.6 完整主程序框架把上面的模块串起来主程序结构如下% 主循环 for t 0.05:0.05:10 % 1. 生成三路传感器的目标列表 radarObs getRadarTargets(trueTargets, t); camObs getCameraTargets(trueTargets, t); lidarObs getLidarTargets(trueTargets, t); % 2. 目标关联这里用全局最近邻简化依据位置距离 matchedRadar associateTargets(predictedTracks, radarObs); matchedCam associateTargets(predictedTracks, camObs); matchedLidar associateTargets(predictedTracks, lidarObs); % 3. 对每个融合目标做状态信息融合信息滤波/卡尔曼信息形式 fusedTrack fuseState(predictedTracks, matchedRadar, matchedLidar); % 4. 对每个融合目标做类型证据融合 bpaBase getTrackBPA(fusedTrack); % 历史证据 if ~isempty(matchedRadar) bpaBase dsCombo(bpaBase, probToBPA(radarObs.typeProb, alphaRadar), n); end if ~isempty(matchedCam) bpaBase dsCombo(bpaBase, probToBPA(camObs.typeProb, alphaCam), n); end if ~isempty(matchedLidar) bpaBase dsCombo(bpaBase, probToBPA(lidarObs.typeProb, alphaLidar), n); end fusedTrack.bpa bpaBase; % 5. 决策输出 fusedTrack.type decideTarget(bpaBase, n, 0.5); % 6. 管理目标生命周期 updateTrackManagement(fusedTrack); end这个主程序不是完整的可直接运行版本工程上还需要加时间对齐、航迹管理、传感器延迟补偿等模块。但它已经把融合系统的骨架完整地勾勒出来了你按照这个骨架填充代码比从零开始自己搭架构要省事得多。我在项目里就是先把这个主程序跑通再逐步替换掉简化的关联和状态融合模块。4. 常见问题与排查技巧实录4.1 空集冲突与组合规则失效我在实验中最先遇到的问题是雷达和摄像头同时给出高度耦合的证据时K值很容易接近1。举个例子摄像头以0.85的置信度认为目标是车辆雷达以0.8的置信度认为目标是行人两者BPA交集为空此时K≈0.68虽然不到1但合成结果会出现一个非常畸形的BPA融合后“车辆”反而成了几乎唯一的置信来源而“行人”信息被压制到极低。这个结果在物理上是不合理的因为雷达的测距信息很可靠摄像头对车辆/行人的分类大概率也是对的两者冲突恰恰说明需要谨慎而不是直接否定雷达。后来我采用的方案是在进入DS组合之前先计算两两证据之间的冲突系数K。当K超过0.6时触发冲突处理分支不再使用标准组合规则。分支里做的第一件事是检查时间对齐很多冲突其实是时间戳不对齐造成的雷达上一帧的数据和摄像头这一帧的数据本来就不是同一目标。第二件事是对低可靠性传感器做额外折扣把它的质量更多转移到“未知”降低它对融合结果的干扰。第三件事才是更换组合规则我测试了Yager规则和Dubois-Prade规则工程上更稳的是Dubois-Prade它在空集交叠时不抛弃冲突质量而是放入并集焦点元素保持了更多原始信息。这里想给个明确的提示不要一上来就用复杂规则。先用标准DS跑通流程再把K值分布统计出来看哪些场景容易触发高冲突再针对性地处理。很多冲突其实在数据关联阶段就应该被消化掉如果关联错了融合规则再高级也白搭。4.2 焦点元素爆炸与计算量控制有人会担心DS融合的指数复杂度。识别框架有4类目标时BPA向量长度是15扩展到10类目标时长度变成1023如果传感器输出大量复合焦元计算量会快速上升。我在实验中发现10类目标、每秒20次融合计算纯Matlab实现会明显卡顿尤其在多个目标并行处理时。解决思路有三个。第一是限制焦点元素数量只保留质量大于某阈值比如0.01的焦点元素其余的质量折入“未知”。这样每路传感器的BPA有效条目数通常能控制在个位数以内组合复杂度大幅下降。第二是考虑用幂集索引的稀疏表示只存非零项不存全向量。第三是用查表法因为识别框架固定两个焦点的按位与结果可以预先算好存成一个稀疏矩阵运行时直接查表能省掉大量重复的bitand计算。我在实际实现里同时用了第一和第三两个思路。效果非常明显原来一次融合循环需要十几毫秒优化后降到两毫秒左右基本满足实时性要求。一定要记住Matlab里避免在热点循环里用动态解析和对象属性访问把常量预先计算好性能差距会大到超出你的预期。4.3 时间同步与异步融合传感器更新频率不一致是目标级融合最容易踩的坑。雷达20Hz、摄像头15Hz、激光10Hz如果不做时间对齐融合结果的时序会很乱。我一开始偷懒直接用当前收到的观测更新航迹结果融合后的目标位置抖动非常厉害尤其在车辆加减速时误差一下从0.5米涨到2米。正确做法是给每条融合航迹维护一个预测器用恒速度或恒加速度模型把航迹预测到最新量测时刻再执行状态融合。Matlab里可以直接用trackingFilter或stateEstimatorFilter来实现。对于DS证据这边时间同步相对宽松因为目标类型不会在几十毫秒内突变只要保证路由到同一目标序号即可。我把所有传感器消息都加上时间戳在融合模块内部统一维护一个最近时刻所有证据按“预测到当前时刻”的逻辑处理这套机制让融合后的状态误差重新回到0.5米以内。这里有个经验供你参考目标级融合的容错能力不差但时间戳必须是纳秒级精度。如果上游模块输出的时间戳是系统启动后的相对时间而不是UTC时间建议在系统设计时就统一时间基准否则后面做多传感器数据回放和分析会非常痛苦。4.4 评价指标与阈值选取融合系统做出来总得回答“它到底好不好”这个问题。我用的评价指标体系分三块第一块是状态估计误差用均方根误差RMSE衡量融合后的目标位置、速度与真值的偏差对比单个传感器单独使用时的误差。第二块是类型识别正确率把融合后的目标类型判定和真值比较计算混淆矩阵和总体正确率。第三块是DS特有的“不确定率”也就是决策输出“不确定”的比例。不确定率太高说明传感器证据不足太低说明阈值太宽、系统可能在瞎猜。阈值选取我用了网格搜索加场景验证两步走。先在Matlab里对每个阈值组合跑一遍完整离线数据画出准确率和不确定率的Pareto曲线然后选一个能让准确率不低于95%且不确定率不超过20%的点。这里有个反直觉的发现阈值调高后虽然不确定率上升但最终误判率反而下降。因为下游规划模块对“不确定”目标会采取更保守的策略减少急刹车或误变道整体安全性反而更好。做融合决策时不要一味追求“必须给出类型”适当留白是对系统负责。4.5 调参心得可靠性系数α怎么设α是影响DS融合效果最直接的参数但也是最容易拍脑袋定的参数。我的建议是用“漏检时的未知质量”来标定而不是猜。具体方法是收集一段传感器数据统计该传感器在目标真实存在但检测失败的概率这个概率就是1-α的初始值。比如毫米波雷达在大车遮挡下漏检率约20%那么αRadar取0.8到0.85比较合理。之后在场景里跑验证根据融合后目标类型置信度是否合理做微调。另外α不应该是固定值。我在后期引入了基于信噪比的动态α雷达目标信噪比高时α取0.95信噪比低时降为0.7。这样处理让雷达在近距强反射场景下不会因为偶尔的野值带偏融合结果。实现起来也不复杂每个传感器消息里增加一个质量评价字段在probToBPA里读取它动态计算α就可以。5. 个人经验与扩展建议5.1 实测中的体会这套系统我在模拟场景下连续跑了上千个时间步对比了单独传感器和融合后的表现。最直观的感受是融合后的目标航迹稳定度明显提升摄像头的单帧抖动和雷达的野值都被有效抑制。类型融合方面纯摄像头对车辆和行人的分类正确率约为92%融合后提升到97%左右同时不确定率维持在15%附近。这个提升看似不大但对下游决策模块来说多出的5个百分点的准确意味着大量边界场景从危险变为可控。我在调试过程中还发现DS融合对传感器“过度自信”的纠错能力很强。摄像头在逆光场景下经常以0.95的高置信度把行人判成车辆单纯使用摄像头输出非常危险。但雷达在这个时刻给出的目标类型BPA虽然置信度不高却包含“可能是行人”的支持经过DS组合后融合结果会明显降低“车辆”的置信度。这个特性让我意识到多传感器融合最大的价值不是锦上添花而是互相兜底。5.2 后续可以做的扩展这套框架继续往深做有几个方向值得探索。一是用自适应折扣因子替换固定α结合传感器工作状态、天气信息、场景复杂度在线调节让融合系统在恶劣环境下自动降低不可靠传感器的权重。二是引入模糊逻辑来处理连续型的目标属性比如把“速度是快还是慢”这类语言变量也纳入证据框架让融合结果对规划模块更友好。三是把DS融合的输出作为端到端感知的一部分直接输入到决策规划模块做博弈式路径规划这样“知”和“行”能形成一个闭环。最后再分享一个小技巧DS融合的中间结果一定要可视化。我在Matlab里把每个目标的BPA向量、冲突系数K、不确定率都画出来逐帧检查。这样做能非常快速定位是哪个传感器在哪类场景下出了问题比只看最终的准确率指标高效得多。调试多传感器融合最怕的就是“结果错了但不知道错在哪一步”把中间过程摊开来看问题往往一眼就能找到。
阅读完成 · 觉得有帮助？
