第一次让我意识到激光雷达算法不能只盯着单帧检测是一场雨夜路测。感知链路的模型在离线评测集上刷得很漂亮检测框精度也说得过去可一上路问题全暴露出来了前车稍微被侧方障碍遮一下框就开始跳朝向、尺寸、类别在几帧之间反复横跳后端的预测和规划模块被这些抖动信号折腾得苦不堪言。那一刻我才彻底想明白激光雷达感知的瓶颈在很多场景下已经不是“能不能检出目标”而是“能不能稳定地输出一条连续、可信的目标状态”。这一章的话题就落在这里。前几章我们把点云预处理、地面分割、聚类、3D目标检测和分类讲完了从零搭起一个“能检测”的系统并不难难点在于检测结果只是一堆离散的、带着噪声的框要真正成为智能驾驶可用的感知信息必须经过跨帧关联、状态滤波和多传感器融合。第9章面向的读者是已经掌握基础检测算法、准备做系统集成的开发者或者在实际项目中已经被“框乱跳、目标跟丢、单传感器失效”折磨过的人。这一章的目标很直接在检测输出的基础上建立可靠的目标轨迹再通过激光雷达与摄像头的融合把两路传感器信息拧成一股绳最终得到一个不会因为一两帧遮挡就丢目标、也不会因为单一传感器退化就瘫痪的感知结果。1. 链路定位到了第9章感知的主战场已经移到了时间与空间1.1 单帧检测解决的是“有没有”跟踪解决的是“稳不稳”单帧检测的作用范围是“这一帧点云里有哪些目标、各自在什么位置、什么尺寸、什么类别”。这个能力在第八章节我们已经搭完了模型给定一系列框输出。但智能驾驶对感知的要求并不止于此下游决策模块需要的是连续时间内对同一目标的稳定描述这辆车从50米外开到我旁边它的横向位置变化是多少它的速度是多少它有没有可能突然插入我的车道如果只依赖单帧检测就会出现一个尴尬局面。传感器噪声、遮挡、反射率变化都会让同一目标在不同帧里的检测分数剧烈波动某几帧甚至直接漏检。你盯着可视化界面看明明路上就一辆车检测框却一会儿偏左、一会儿偏右偶尔消失半秒钟又冒出来。这种“不连贯”对下游模块是灾难级的预测算法分不清目标是真的闪躲还是传感器抽风规划算法也不敢在这种信号上做激进决策。跟踪模块解决的就是这个问题。它维护每个目标的历史轨迹把当前帧的检测结果与已有轨迹关联起来通过状态估计平滑位置、速度、尺寸和朝向并在目标短暂漏检时依靠运动模型做合理外推。换句话说单帧检测给你的是“快照”跟踪给你的是“档案”。稳定性、连续性、可预测性这些真正影响系统体验的指标基本都是跟踪环节贡献的。1.2 从检测框到轨迹一条完整的目标级感知流水线为了说清楚第9章在整个感知链路中的位置我把一条最典型的目标级感知流水线完整串一遍。原始点云进入预处理模块先做体素化、离群点滤除、地面点抑制然后送入3D检测网络输出一组带类别、尺寸、朝向、置信度的3D框检测框经过后处理的非极大值抑制和分数阈值过滤之后并不会直接送出去而是进入跟踪模块。跟踪模块内部大致分四步。第一步是预测根据每条轨迹的运动模型外推它们在当前帧的期望位置第二步是门控先把明显不可能关联的检测框和轨迹排除掉缩小匹配范围第三步是关联把当前帧的检测框和已有的轨迹做最优匹配第四步是更新用匹配上的检测结果刷新轨迹状态同时管理轨迹的生命周期比如新轨迹需要连续命中几帧才能转正老轨迹丢失几帧之后才被删除。这里的轨迹生命周期值得多说一句。很多第一次写跟踪的人会犯同一个错误把检测框直接当成轨迹检测框没了就删轨迹。这样做的后果是系统对噪声毫无抵抗力偶尔一帧误检就能产生一条“幽灵轨迹”。成熟的跟踪系统会给轨迹设置状态机常见的有“未确认”“已确认”“丢失中”三种状态。未确认轨迹必须连续关联上若干帧才升级为已确认轨迹已确认轨迹允许一段时间内的漏检超过时限才删除。这个机制简单却能在很大程度上过滤掉单帧误检带来的干扰。1.3 第9章怎么读最有效如果你是按顺序读下来的前几章的内容是本章的基础尤其是3D框的表达方式、点云坐标系和各类检测头的输出定义。这一章不需要你重新训练模型建议把重点放在“如何设计跟踪状态机”“如何选关联代价”“如何做融合降级”这几个工程问题上。学习的时候找一个离线录制的数据包把检测结果预存下来单独调试跟踪模块效率会高很多。一个比较容易踩的误区是急于把跟踪和融合同时接上去。建议分两步走先把激光雷达单传感器的跟踪调稳确认轨迹在遮挡、密集场景下不乱跳再着手加摄像头融合。融合模块引入后一旦出现问题最少还有一个“单传感器模式”可以用来对照排查。工程调试最怕多个模块互相纠缠隔离变量是永远值得的。2. 跨帧目标关联与状态估计所有稳定性的根源2.1 卡尔曼滤波处理点云也在处理运动跟踪模块的核心不外乎“状态预测”和“观测更新”。工程上用的最多的还是卡尔曼滤波以及它的非线性版本扩展卡尔曼滤波。很多刚接触的人一看到五个公式就头大其实直觉非常简单系统有一个运动模型比如假定目标在极短时间内匀速运动滤波器根据这个模型预测目标下一帧的位置等到真实检测到了把预测值和实测值按不确定度加权得到一个新的估计值。预测和实测哪个更可信就更偏向哪一边。用公式描述状态预测是 x_k F x_{k-1}协方差更新是 P_k F P_{k-1} F^T Q卡尔曼增益是 K P_k H^T (H P_k H^T R)^{-1}最后用观测 z 更新状态 x_k x_k K(z - H x_k)。F是状态转移矩阵H是观测矩阵Q是过程噪声R是测量噪声。调参的时候Q和R的比例决定滤波器的响应速度Q大R小滤波器更相信检测结果响应快但噪声大Q小R大滤波器更依赖模型预测输出平缓但滞后明显。在激光雷达目标跟踪里我的习惯状态向量是“中心点坐标(x,y,z) 尺寸(长宽高) 航向角 速度(vx,vy)”。如果目标有强烈的转弯运动还可以加上角速度变成恒定转率和速度模型。但要注意模型越复杂参数越多调起来越麻烦。城市道路场景下恒定速度模型加上适当的噪声项已经能覆盖绝大多数情况只有频繁大角度转弯的十字路口场景才需要切换更复杂的运动模型。有一个调参细节很关键检测模型的噪声并非处处相等。近距离目标的检测误差小远距离目标即使检测到了位置偏差也往往很大。所以在设置测量噪声R时不要给一个固定值最好随距离动态调整。近距离给较小的R让滤波信任检测远距离给较大的R让滤波更多依赖预测轨迹会明显平滑。这个改动逻辑简单效果却非常直接。2.2 匹配策略匈牙利算法、级联匹配与关联代价跟踪的另一半是数据关联也就是把当前帧的检测框和历史轨迹一一对应起来。如果场景里只有一个目标这事不难但道路上经常同时出现几十个目标两个目标可能距离很近、互相遮挡还有新目标不断进入视野这就需要一套严格的匹配机制。最经典的做法是把它建模成“最优指派问题”构造一个“轨迹数 × 检测数”的代价矩阵矩阵里每个元素表示某条轨迹和某个检测框之间的关联代价然后用匈牙利算法在多项式时间内找到全局总代价最小的匹配方案。代价怎么定义直接决定了关联的好坏。最常见的是组合几个指标BEV平面中心距离、3D IoU、航向角差、尺寸一致性。两个框距离越近、形状越接近、朝向越一致代价越小。光有代价矩阵还不够还需要“门控”。距离过远、尺寸差别过大、朝向差异离谱的轨迹和检测直接不进入代价矩阵先把代价设为无穷大。门控的目的是减少无效计算同时避免做出明显错误的跨目标匹配。比如一辆朝东开、位置差了三四十米的轨迹和一个刚出现的行人理论上就不应该有任何关联的可能。级联匹配则是一个更精细的顺序策略。新进入的轨迹和已经稳定跟踪很久的轨迹在可信度上是不同的。稳定轨迹的预测位置可信度高应该优先匹配新轨迹因为历史信息少预测位置本身就不太可靠放在后面匹配。这样安排可以避免新轨迹“抢”掉稳定轨迹本该匹配到的检测框减少ID切换。实现上就是把轨迹按“已连续命中帧数”分组从高到低逐级执行匈牙利匹配。2.3 BEV空间里关联的细节激光雷达的3D检测结果通常投影到BEV平面做关联也就是从正上方俯瞰的二维平面。做BEV投影本身没什么难度把z轴信息和高度特征压缩掉就行。但在实际工程中这里有几个细节特别容易出问题值得单独拿出来说。第一个是关联哪些维度。计算代价时用的是BEV平面上的中心距离但目标的高度信息不能完全丢弃。高架桥上的车和地面上的车在BEV平面上可能完全重叠如果不把z方向差异纳入门控就会发生上下两层目标互相抢框的乱象。我的做法是BEV中心距离作为主代价z轴高度差作为硬门控超过一定阈值的直接不允许关联。第二个是时间戳对齐。检测模型是有推理延迟的假设传感器数据到达时间是T0检测输出真正出来已经到T040毫秒了。如果跟踪模块不修正这个延迟直接把迟到的检测框和当前时刻的轨迹做关联预测位置就会出现系统性偏差尤其在高速场景下特别明显。处理方法是在跟踪模块里记录每帧点云的真实采集时间预测轨迹状态时把时间差考虑进去这里一个简单的时间补偿逻辑能省掉后续大量莫名其妙的跟踪抖动。第三个是密集场景下的局部匹配。车辆密集路段两辆并排的SUV在BEV上可能贴得很近单靠中心距离区分它们非常吃力。这时候要引入更严格的IoU约束和航向约束甚至可以对不同类型的目标使用不同的代价权重。比如行人和车辆用不同的中心距离阈值因为行人体量小、移动灵活速度和位置的不确定性本来就大。3. 激光雷达与摄像头的融合一整套取舍3.1 融合层级选型数据级、特征级、目标级激光雷达在3D几何信息上有优势摄像头在纹理、颜色、语义细节上有优势把这俩融合起来几乎是必然选择。但“融合”这个词在工程里有完全不同的实现层级选错层级项目周期和效果都会差很多。数据级融合发生在底层把激光雷达点云和图像像素做配准让每个点带上对应的颜色或语义信息再统一送入检测模型。它的优点是信息保留完整缺点是系统复杂对时间同步和空间标定的要求极高而且一旦一方数据异常整个模型输出都可能劣化。特征级融合是目前精度上限最高的一类做法摄像头图像和激光雷达点云分别在网络里提取特征再在共享的BEV特征空间里合并让模型自己学出两种模态之间的关系。缺点是训练成本高、对标定误差敏感偏向于从零搭建整套感知系统的团队使用。目标级融合最朴素激光雷达单独跑一个检测器摄像头单独跑一个检测器两边分别输出带置信度的目标框算法再把它们按空间位置对齐和合并。这个方案的精度上限不如特征级融合但在工程稳健性、调试便利性、算力开销上明显占优。尤其当你是在已有单传感器检测系统上做迭代升级目标级融合几乎是唯一务实的选择。我的建议是大多数量产项目先从目标级融合做起上线验证价值之后再决定是否投入资源换特征级。3.2 融合实现投影公式、时间戳对齐与置信度合并目标级融合的第一步是把激光雷达坐标系下的3D框投影到图像平面。假设外参已经把激光雷达坐标变换到了相机坐标点的齐次坐标变换为 p_cam R · p_lidar t其中R是旋转矩阵t是平移向量。接着用相机内参做透视投影u f_x · x_cam / z_cam c_xv f_y · y_cam / z_cam c_y。这里f_x、f_y是焦距c_x、c_y是像主点坐标。做完这一步激光雷达框的中心点就变成了图像上的一个像素坐标可以用来和摄像头检测框做重叠判断。时间戳对齐是融合里最容易被低估的环节。激光雷达和摄像头的工作频率往往不一致激光雷达10赫兹、摄像头30赫兹是常见组合。比较省事的做法是“就近取帧”加“时间外推”找到与摄像头帧时间最近的一帧激光雷达点云再根据目标速度和两帧时间差把点云或3D框平移到摄像头帧的真实采集时刻。时间偏差超过50到80毫秒时融合结果会出现肉眼可见的拖影位置和摄像头框对不上严重时还会引发下游误判断所以这一步不能省。置信度合并也有讲究。最简单的是给两个传感器设定固定权重做加权平均比如激光雷达框权重0.6、摄像头框权重0.4。但更加稳妥的做法是让权重动态化检测置信度低的一边自动降权历史跟踪状态稳定的一边适当提权不同类别可以单独设权重比如行人目标更依赖摄像头车辆目标更依赖激光雷达。目标类别冲突时建议以历史轨迹的类别稳定性为准而不是单帧硬投票。3.3 外参漂移的代价0.1°偏差在50m外意味着什么融合链路里外参标定误差是最大的隐形杀手。这里做一个简单的计算。假设目标在激光雷达前方50米处标定外参的航向角偏差是0.1°。小角度下横向偏移近似等于距离乘以角度的弧度值0.1°约等于0.001745弧度50米乘以0.001745约等于0.087米也就是8.7厘米。这个量级在车辆宽度两米左右的场景下还不至于让激光雷达框和摄像头框完全分离但已经会让两者的重叠面积下降关联分数被压低。如果外参偏差到了0.5°同样在50米处横向偏移就是50乘以0.00873大约是43.6厘米。这个偏差已经非常可观足够让激光雷达投影框和摄像头检测框发生明显错位融合算法很可能会把它们判定成两个目标导致同一个物理物体输出两个轨迹。80米外的目标即使外参只偏0.3°也会有大约0.42米的位置错位足以破坏融合的稳定性。所以我在融合调试前都会先做一桩“标定体检”把点云按外参投影到图像上肉眼确认点云轮廓与图像中的物体边缘是否吻合检查车道线位置是否对齐再看目标框在不同距离下的贴合程度。这一步听起来原始却能在十分钟内暴露大部分外参问题比任何融合算法上的优化都管用。4. 实战里反复出现的鲁棒性问题4.1 高反、黑车这类点云稀疏问题激光雷达对材质和颜色是“有脾气”的。高反射率物体比如金属护栏、反光标识、湿润路面会产生大量异常回波点云在这些区域又密又乱低反射率物体尤其是一身黑色漆面的轿车回波能量弱近距离还可能看得到距离稍远就只剩稀稀拉拉几个点检测器很难从中回归出稳定的尺寸和朝向。应对高反问题优先从传感器层面想办法。很多雷达支持多回波这时可以把最后一次回波用于地面目标的检测因为第一次回波往往是空气中的悬浮物或边缘伪影造成的最后一次回波更接近真实表面。如果传感器不支持就只能在预处理里加入基于局部密度和强度的“异常点滤除”把团状异常点当噪声处理不让它们影响聚类或检测。黑车点云稀疏的问题单靠一帧很难根治。我试过比较有效的做法是“历史帧累积”把前几帧的点云按运动补偿叠加到当前帧变相增加点云密度。这相当于用时间换空间代价是引入一点延迟但对低速城市工况非常友好。跟踪模块也要配合偏好在“点少但稳定的轨迹”上继续外推而不是一帧少见就立刻判死。4.2 遮挡截断下的轨迹保持策略目标被遮挡是所有跟踪系统都绕不开的问题。行人被公交车挡住、车辆被绿化带截断检测器输出自然中断。如果跟踪逻辑是“检测框消失就删轨迹”那目标再出现时就会生成一条新轨迹下游模块会把它当成新目标处理在决策上造成不必要的急刹或变道。正确的思路是区分“目标真的消失”和“目标被临时遮挡”。操作上可以做三件事。第一给轨迹设置丢失容忍时间通常0.5到1秒在这个窗口内继续用运动模型外推目标位置外推结果参与下轮匹配但不直接对外输出高置信度第二扩展遮挡期间的门控范围因为目标恢复可见时位置很可能比预测偏差更大第三对静止目标和移动目标区别对待静止目标丢失后可以保持更久移动目标的存活时间则要短一些否则外推位置误差会越来越大。轨迹恢复是另一个容易忽视的点。目标重新出现后旧轨迹和新检测框完成关联需要立刻修正被外推“带偏”的位置和速度。正确做法是把当前检测框的状态作为强观测快速把滤波器状态拉回真实值。如果这里做得太保守轨迹会继续漂移好几帧看起来就像目标被“吸”在原地一样。4.3 类别不平衡与小目标漏检行人和骑行者这类目标在公开数据里天然是少数类再加上体积小、点云数量少模型很容易对它们漏检。很多团队习惯只看“整体检测精度”觉得指标不错就没有问题可一旦单独统计行人召回率才发现低得可怜。解决方向是分层的。训练侧可以增加小目标类别的采样权重或者使用类别平衡的损失函数让模型在训练时不再被车辆目标“带偏”。后处理侧可以给不同类别设置不同的分数阈值对行人适当放宽宁可多一些低置信度候选也要保证召回率。跟踪侧也要同步调整关联代价权重行人允许的匹配距离可以比车辆小因为它体积小、点云中心估计更容易抖动。小目标还有一个特点中心点估计不稳定。一个行人远距离时可能只有三五个有效点检测框的中心会在不同帧之间来回偏。这时单靠几何中心做跟踪关联会很不稳定可以尝试把检测框的底部中心作为关联锚点因为底部中心通常更接近地面真实位置受点云稀疏的影响更小行人跟踪的连续性会提升不少。4.4 外参在线标定漂移与降级处理车辆跑一段时间后摄像头和激光雷达之间的外参会因为长期振动、热胀冷缩等原因慢慢漂移这不是偶发事件而是量产后的固有问题。我见过不少开发阶段表现不错的融合系统跑到几千公里后精度明显下降最终排查下来就是外参漂了。应对漂移有两层策略。第一层是主动标定定期做在线自动标定利用车道线、地面平面、目标边缘等自然特征在车辆运行过程中持续修正外参。第二层是健康监控加降级。融合模块要持续统计激光雷达框和摄像头框的关联成功率、重叠率、位置偏差的滑动均值一旦这些指标持续恶化说明标定可能已经出问题这时候要有策略地降低摄像头权重或切回单激光雷达模式并上报标定异常告警。降级策略在融合系统里不是可有可无的设计而是安全底线。宁可牺牲一些感知精度也不能在标定异常时继续强行融合因为错误的融合输出比单传感器输出更具误导性。合理做法是设置清晰的降级矩阵正常时双传感器融合摄像头置信度异常时退化为纯激光雷达激光雷达数据异常时退化为纯摄像头两者都异常时系统输出未知状态。4.5 算力受限平台的推理优化智能驾驶的算力是有上限的。车载平台往往要在几百毫瓦到几十瓦的功耗约束下完成整个感知链路无法像离线训练那样随便堆算力。因此激光雷达算法在部署时要做大量取舍。常用的优化手段有几类。一是量化把模型从浮点推理压到int8量化精度损失通常在可接受范围内但推理速度能提升两到三倍。二是稀疏化点云数据本身是稀疏的体素化后绝大多数体素为空专门处理稀疏卷积的算子能把无效计算大量省掉。三是后处理裁剪非极大值抑制、框的编解码等后处理逻辑看起来不起眼实测中往往能占到推理总耗时的两成以上值得花时间优化算法实现。四是距离分块近处用小体素、远处用大体素或者对超过一定距离的点云做降采样算法性能不会明显下降但计算量能降一大截。调优经验上我会先做性能剖析把检测网络、预处理、后处理、跟踪各自耗时打点看清楚时间到底花在哪再动手优化。很多团队一上来就调模型结构结果发现瓶颈根本不在模型本身而在一行低效的坐标变换代码这种亏我吃过不止一次。4.6 不同传感器型号之间的域差异从开发到量产甚至同一车型的不同批次都可能使用不同品牌或不同线束的激光雷达。换了传感器同样一套算法性能就可能明显下跌这就是典型的“域差异”问题。不同的垂直视场角、线束密度、探测距离会让点云分布产生肉眼可见的区别固定阈值类型的后处理代码更是首当其冲。最简单的处理是数据层面适配。收集新传感器数据的真值做微调或数据增强让模型学着适应新的点云分布。同时后处理里不要写死绝对阈值比如“聚类点数少于20就当成噪声”这类规则换个传感器就失效了。更好的做法是把阈值建模成距离和传感器参数的函数让逻辑对传感器变化更鲁棒。最后在系统层面保留一个传感器配置模块不同型号对应不同的预处理参数、检测阈值、跟踪关联参数切换时只要加载对应配置而不是重写代码。如果是多车型同步开发我建议团队从一开始就定义一套统一的中间表示点云统一成规范化的体素或指定坐标系统的稀疏张量而把上游传感器差异封存在预处理层。这样后续算法迭代只需要面向中间表示做不会被某个具体传感器的癖好绑架。5. 调试环境与参数配置笔记5.1 检测后处理、跟踪与融合的参数示例给出一套我常用参数配置具体数值需要根据传感器和场景微调但结构可以直接参考。detector: score_threshold: 0.35 nms_iou_threshold: 0.5 class_thresholds: vehicle: 0.35 pedestrian: 0.25 cyclist: 0.25 tracker: state_dim: 9 motion_model: constant_velocity # 生命周期管理 confirm_hits: 2 max_lost_age_ms: 800 remove_if_low_score_frames: 5 # 关联代价权重 association: gate_center_distance_m: vehicle: 3.0 pedestrian: 1.5 cyclist: 2.0 gate_max_height_diff_m: 1.2 cost_weights: center_distance: 1.0 yaw_difference: 0.3 size_similarity: 0.2 # 卡尔曼噪声 process_noise_position: 0.5 process_noise_velocity: 1.0 measurement_noise_base: 0.8 measurement_noise_scale_per_meter: 0.02 fusion: mode: target_level time_align_window_ms: 50 merge_weights: lidar: 0.6 camera: 0.4 degrade: continuous_misalignment_frames: 20 trigger_sensor_cache: lidar_only这些参数背后的逻辑是检测分数阈值按类别分开因为行人和骑行者的不确定度天然比车辆高统一阈值会伤召回关联门控按类别给不同距离上限避免大车和小车、行人的匹配相互干扰卡尔曼的测量噪声随距离线性放大对应远距离点云精度下降的现实融合权重只是起始值权重随后续健康监控动态调整。调试时我习惯用一个“回放器”把这些参数一次性加载进去然后逐帧检查同一目标的轨迹ID是否稳定、两路传感器框的重叠情况。一轮跑下来参数调优的时间可以从几天压缩到几小时。5.2 调试时优先看的三个指标参数配置完成后到底该怎么评估系统好坏评估指标很多但实际调试我只优先盯三个。第一个是ID切换率即同一物理目标在跟踪过程中轨迹ID被切换的次数这个指标最直观反映关联是否稳定。两辆外观相近、并排行驶的SUV是测试ID切换的绝佳场景如果在这种工况下ID都能稳住其他场景问题不大。第二个是轨迹断裂率指一条轨迹在中途断裂、再生成新轨迹的次数。这个指标和遮挡保持策略强相关。做法是统计完整轨迹长度和中断次数在“每百帧轨迹中断”这个口径上做对比。这里可以明确看到max_lost_age_ms这个参数的作用设得太短目标被挡一下就断设得太长外推位置发飘恢复关联时容易错配。第三个是融合位置一致性误差也就是目标级融合后激光雷达框中心和摄像头框中心之间的距离统计。这个指标直接暴露标定漂移和时间对齐问题。可以定期在后台统计这个误差的均值与标准差如果均值超过20厘米且持续上升优先检查标定而不是急着改融合算法。调试工具也很重要。把点云投影到图像上同时绘制激光雷达框、摄像头框和轨迹ID三路信息叠在一个画面上逐帧回放几乎能一眼定位是检测问题、跟踪问题还是融合问题。可视化工具的作用就是让异常从指标变成肉眼可见的“违和感”这一步在感知系统调试里是不可替代的。做激光雷达感知这几年我有一个很深的体会把一套系统从“离线指标好看”打磨到“实车稳定能用”功夫往往花在不那么迷人的环节上。跟踪状态机怎么设计、关联代价怎么配、外参漂移了怎么降级、算力不够了怎么砍这些才是真正决定系统下限的东西。如果你正在为自己的感知项目发愁不妨先把模型精度放一放回到这一章讨论的这些环节上做一轮系统体检很多让人头疼的“疑难杂症”反而会迎刃而解。 
长河君 · 2026/10/17 11:24:45 · 阅读 1.2k 激光雷达感知进阶：从单帧检测走向稳定目标跟踪与多传感器融合
第一次让我意识到激光雷达算法不能只盯着单帧检测是一场雨夜路测。感知链路的模型在离线评测集上刷得很漂亮检测框精度也说得过去可一上路问题全暴露出来了前车稍微被侧方障碍遮一下框就开始跳朝向、尺寸、类别在几帧之间反复横跳后端的预测和规划模块被这些抖动信号折腾得苦不堪言。那一刻我才彻底想明白激光雷达感知的瓶颈在很多场景下已经不是“能不能检出目标”而是“能不能稳定地输出一条连续、可信的目标状态”。这一章的话题就落在这里。前几章我们把点云预处理、地面分割、聚类、3D目标检测和分类讲完了从零搭起一个“能检测”的系统并不难难点在于检测结果只是一堆离散的、带着噪声的框要真正成为智能驾驶可用的感知信息必须经过跨帧关联、状态滤波和多传感器融合。第9章面向的读者是已经掌握基础检测算法、准备做系统集成的开发者或者在实际项目中已经被“框乱跳、目标跟丢、单传感器失效”折磨过的人。这一章的目标很直接在检测输出的基础上建立可靠的目标轨迹再通过激光雷达与摄像头的融合把两路传感器信息拧成一股绳最终得到一个不会因为一两帧遮挡就丢目标、也不会因为单一传感器退化就瘫痪的感知结果。1. 链路定位到了第9章感知的主战场已经移到了时间与空间1.1 单帧检测解决的是“有没有”跟踪解决的是“稳不稳”单帧检测的作用范围是“这一帧点云里有哪些目标、各自在什么位置、什么尺寸、什么类别”。这个能力在第八章节我们已经搭完了模型给定一系列框输出。但智能驾驶对感知的要求并不止于此下游决策模块需要的是连续时间内对同一目标的稳定描述这辆车从50米外开到我旁边它的横向位置变化是多少它的速度是多少它有没有可能突然插入我的车道如果只依赖单帧检测就会出现一个尴尬局面。传感器噪声、遮挡、反射率变化都会让同一目标在不同帧里的检测分数剧烈波动某几帧甚至直接漏检。你盯着可视化界面看明明路上就一辆车检测框却一会儿偏左、一会儿偏右偶尔消失半秒钟又冒出来。这种“不连贯”对下游模块是灾难级的预测算法分不清目标是真的闪躲还是传感器抽风规划算法也不敢在这种信号上做激进决策。跟踪模块解决的就是这个问题。它维护每个目标的历史轨迹把当前帧的检测结果与已有轨迹关联起来通过状态估计平滑位置、速度、尺寸和朝向并在目标短暂漏检时依靠运动模型做合理外推。换句话说单帧检测给你的是“快照”跟踪给你的是“档案”。稳定性、连续性、可预测性这些真正影响系统体验的指标基本都是跟踪环节贡献的。1.2 从检测框到轨迹一条完整的目标级感知流水线为了说清楚第9章在整个感知链路中的位置我把一条最典型的目标级感知流水线完整串一遍。原始点云进入预处理模块先做体素化、离群点滤除、地面点抑制然后送入3D检测网络输出一组带类别、尺寸、朝向、置信度的3D框检测框经过后处理的非极大值抑制和分数阈值过滤之后并不会直接送出去而是进入跟踪模块。跟踪模块内部大致分四步。第一步是预测根据每条轨迹的运动模型外推它们在当前帧的期望位置第二步是门控先把明显不可能关联的检测框和轨迹排除掉缩小匹配范围第三步是关联把当前帧的检测框和已有的轨迹做最优匹配第四步是更新用匹配上的检测结果刷新轨迹状态同时管理轨迹的生命周期比如新轨迹需要连续命中几帧才能转正老轨迹丢失几帧之后才被删除。这里的轨迹生命周期值得多说一句。很多第一次写跟踪的人会犯同一个错误把检测框直接当成轨迹检测框没了就删轨迹。这样做的后果是系统对噪声毫无抵抗力偶尔一帧误检就能产生一条“幽灵轨迹”。成熟的跟踪系统会给轨迹设置状态机常见的有“未确认”“已确认”“丢失中”三种状态。未确认轨迹必须连续关联上若干帧才升级为已确认轨迹已确认轨迹允许一段时间内的漏检超过时限才删除。这个机制简单却能在很大程度上过滤掉单帧误检带来的干扰。1.3 第9章怎么读最有效如果你是按顺序读下来的前几章的内容是本章的基础尤其是3D框的表达方式、点云坐标系和各类检测头的输出定义。这一章不需要你重新训练模型建议把重点放在“如何设计跟踪状态机”“如何选关联代价”“如何做融合降级”这几个工程问题上。学习的时候找一个离线录制的数据包把检测结果预存下来单独调试跟踪模块效率会高很多。一个比较容易踩的误区是急于把跟踪和融合同时接上去。建议分两步走先把激光雷达单传感器的跟踪调稳确认轨迹在遮挡、密集场景下不乱跳再着手加摄像头融合。融合模块引入后一旦出现问题最少还有一个“单传感器模式”可以用来对照排查。工程调试最怕多个模块互相纠缠隔离变量是永远值得的。2. 跨帧目标关联与状态估计所有稳定性的根源2.1 卡尔曼滤波处理点云也在处理运动跟踪模块的核心不外乎“状态预测”和“观测更新”。工程上用的最多的还是卡尔曼滤波以及它的非线性版本扩展卡尔曼滤波。很多刚接触的人一看到五个公式就头大其实直觉非常简单系统有一个运动模型比如假定目标在极短时间内匀速运动滤波器根据这个模型预测目标下一帧的位置等到真实检测到了把预测值和实测值按不确定度加权得到一个新的估计值。预测和实测哪个更可信就更偏向哪一边。用公式描述状态预测是 x_k F x_{k-1}协方差更新是 P_k F P_{k-1} F^T Q卡尔曼增益是 K P_k H^T (H P_k H^T R)^{-1}最后用观测 z 更新状态 x_k x_k K(z - H x_k)。F是状态转移矩阵H是观测矩阵Q是过程噪声R是测量噪声。调参的时候Q和R的比例决定滤波器的响应速度Q大R小滤波器更相信检测结果响应快但噪声大Q小R大滤波器更依赖模型预测输出平缓但滞后明显。在激光雷达目标跟踪里我的习惯状态向量是“中心点坐标(x,y,z) 尺寸(长宽高) 航向角 速度(vx,vy)”。如果目标有强烈的转弯运动还可以加上角速度变成恒定转率和速度模型。但要注意模型越复杂参数越多调起来越麻烦。城市道路场景下恒定速度模型加上适当的噪声项已经能覆盖绝大多数情况只有频繁大角度转弯的十字路口场景才需要切换更复杂的运动模型。有一个调参细节很关键检测模型的噪声并非处处相等。近距离目标的检测误差小远距离目标即使检测到了位置偏差也往往很大。所以在设置测量噪声R时不要给一个固定值最好随距离动态调整。近距离给较小的R让滤波信任检测远距离给较大的R让滤波更多依赖预测轨迹会明显平滑。这个改动逻辑简单效果却非常直接。2.2 匹配策略匈牙利算法、级联匹配与关联代价跟踪的另一半是数据关联也就是把当前帧的检测框和历史轨迹一一对应起来。如果场景里只有一个目标这事不难但道路上经常同时出现几十个目标两个目标可能距离很近、互相遮挡还有新目标不断进入视野这就需要一套严格的匹配机制。最经典的做法是把它建模成“最优指派问题”构造一个“轨迹数 × 检测数”的代价矩阵矩阵里每个元素表示某条轨迹和某个检测框之间的关联代价然后用匈牙利算法在多项式时间内找到全局总代价最小的匹配方案。代价怎么定义直接决定了关联的好坏。最常见的是组合几个指标BEV平面中心距离、3D IoU、航向角差、尺寸一致性。两个框距离越近、形状越接近、朝向越一致代价越小。光有代价矩阵还不够还需要“门控”。距离过远、尺寸差别过大、朝向差异离谱的轨迹和检测直接不进入代价矩阵先把代价设为无穷大。门控的目的是减少无效计算同时避免做出明显错误的跨目标匹配。比如一辆朝东开、位置差了三四十米的轨迹和一个刚出现的行人理论上就不应该有任何关联的可能。级联匹配则是一个更精细的顺序策略。新进入的轨迹和已经稳定跟踪很久的轨迹在可信度上是不同的。稳定轨迹的预测位置可信度高应该优先匹配新轨迹因为历史信息少预测位置本身就不太可靠放在后面匹配。这样安排可以避免新轨迹“抢”掉稳定轨迹本该匹配到的检测框减少ID切换。实现上就是把轨迹按“已连续命中帧数”分组从高到低逐级执行匈牙利匹配。2.3 BEV空间里关联的细节激光雷达的3D检测结果通常投影到BEV平面做关联也就是从正上方俯瞰的二维平面。做BEV投影本身没什么难度把z轴信息和高度特征压缩掉就行。但在实际工程中这里有几个细节特别容易出问题值得单独拿出来说。第一个是关联哪些维度。计算代价时用的是BEV平面上的中心距离但目标的高度信息不能完全丢弃。高架桥上的车和地面上的车在BEV平面上可能完全重叠如果不把z方向差异纳入门控就会发生上下两层目标互相抢框的乱象。我的做法是BEV中心距离作为主代价z轴高度差作为硬门控超过一定阈值的直接不允许关联。第二个是时间戳对齐。检测模型是有推理延迟的假设传感器数据到达时间是T0检测输出真正出来已经到T040毫秒了。如果跟踪模块不修正这个延迟直接把迟到的检测框和当前时刻的轨迹做关联预测位置就会出现系统性偏差尤其在高速场景下特别明显。处理方法是在跟踪模块里记录每帧点云的真实采集时间预测轨迹状态时把时间差考虑进去这里一个简单的时间补偿逻辑能省掉后续大量莫名其妙的跟踪抖动。第三个是密集场景下的局部匹配。车辆密集路段两辆并排的SUV在BEV上可能贴得很近单靠中心距离区分它们非常吃力。这时候要引入更严格的IoU约束和航向约束甚至可以对不同类型的目标使用不同的代价权重。比如行人和车辆用不同的中心距离阈值因为行人体量小、移动灵活速度和位置的不确定性本来就大。3. 激光雷达与摄像头的融合一整套取舍3.1 融合层级选型数据级、特征级、目标级激光雷达在3D几何信息上有优势摄像头在纹理、颜色、语义细节上有优势把这俩融合起来几乎是必然选择。但“融合”这个词在工程里有完全不同的实现层级选错层级项目周期和效果都会差很多。数据级融合发生在底层把激光雷达点云和图像像素做配准让每个点带上对应的颜色或语义信息再统一送入检测模型。它的优点是信息保留完整缺点是系统复杂对时间同步和空间标定的要求极高而且一旦一方数据异常整个模型输出都可能劣化。特征级融合是目前精度上限最高的一类做法摄像头图像和激光雷达点云分别在网络里提取特征再在共享的BEV特征空间里合并让模型自己学出两种模态之间的关系。缺点是训练成本高、对标定误差敏感偏向于从零搭建整套感知系统的团队使用。目标级融合最朴素激光雷达单独跑一个检测器摄像头单独跑一个检测器两边分别输出带置信度的目标框算法再把它们按空间位置对齐和合并。这个方案的精度上限不如特征级融合但在工程稳健性、调试便利性、算力开销上明显占优。尤其当你是在已有单传感器检测系统上做迭代升级目标级融合几乎是唯一务实的选择。我的建议是大多数量产项目先从目标级融合做起上线验证价值之后再决定是否投入资源换特征级。3.2 融合实现投影公式、时间戳对齐与置信度合并目标级融合的第一步是把激光雷达坐标系下的3D框投影到图像平面。假设外参已经把激光雷达坐标变换到了相机坐标点的齐次坐标变换为 p_cam R · p_lidar t其中R是旋转矩阵t是平移向量。接着用相机内参做透视投影u f_x · x_cam / z_cam c_xv f_y · y_cam / z_cam c_y。这里f_x、f_y是焦距c_x、c_y是像主点坐标。做完这一步激光雷达框的中心点就变成了图像上的一个像素坐标可以用来和摄像头检测框做重叠判断。时间戳对齐是融合里最容易被低估的环节。激光雷达和摄像头的工作频率往往不一致激光雷达10赫兹、摄像头30赫兹是常见组合。比较省事的做法是“就近取帧”加“时间外推”找到与摄像头帧时间最近的一帧激光雷达点云再根据目标速度和两帧时间差把点云或3D框平移到摄像头帧的真实采集时刻。时间偏差超过50到80毫秒时融合结果会出现肉眼可见的拖影位置和摄像头框对不上严重时还会引发下游误判断所以这一步不能省。置信度合并也有讲究。最简单的是给两个传感器设定固定权重做加权平均比如激光雷达框权重0.6、摄像头框权重0.4。但更加稳妥的做法是让权重动态化检测置信度低的一边自动降权历史跟踪状态稳定的一边适当提权不同类别可以单独设权重比如行人目标更依赖摄像头车辆目标更依赖激光雷达。目标类别冲突时建议以历史轨迹的类别稳定性为准而不是单帧硬投票。3.3 外参漂移的代价0.1°偏差在50m外意味着什么融合链路里外参标定误差是最大的隐形杀手。这里做一个简单的计算。假设目标在激光雷达前方50米处标定外参的航向角偏差是0.1°。小角度下横向偏移近似等于距离乘以角度的弧度值0.1°约等于0.001745弧度50米乘以0.001745约等于0.087米也就是8.7厘米。这个量级在车辆宽度两米左右的场景下还不至于让激光雷达框和摄像头框完全分离但已经会让两者的重叠面积下降关联分数被压低。如果外参偏差到了0.5°同样在50米处横向偏移就是50乘以0.00873大约是43.6厘米。这个偏差已经非常可观足够让激光雷达投影框和摄像头检测框发生明显错位融合算法很可能会把它们判定成两个目标导致同一个物理物体输出两个轨迹。80米外的目标即使外参只偏0.3°也会有大约0.42米的位置错位足以破坏融合的稳定性。所以我在融合调试前都会先做一桩“标定体检”把点云按外参投影到图像上肉眼确认点云轮廓与图像中的物体边缘是否吻合检查车道线位置是否对齐再看目标框在不同距离下的贴合程度。这一步听起来原始却能在十分钟内暴露大部分外参问题比任何融合算法上的优化都管用。4. 实战里反复出现的鲁棒性问题4.1 高反、黑车这类点云稀疏问题激光雷达对材质和颜色是“有脾气”的。高反射率物体比如金属护栏、反光标识、湿润路面会产生大量异常回波点云在这些区域又密又乱低反射率物体尤其是一身黑色漆面的轿车回波能量弱近距离还可能看得到距离稍远就只剩稀稀拉拉几个点检测器很难从中回归出稳定的尺寸和朝向。应对高反问题优先从传感器层面想办法。很多雷达支持多回波这时可以把最后一次回波用于地面目标的检测因为第一次回波往往是空气中的悬浮物或边缘伪影造成的最后一次回波更接近真实表面。如果传感器不支持就只能在预处理里加入基于局部密度和强度的“异常点滤除”把团状异常点当噪声处理不让它们影响聚类或检测。黑车点云稀疏的问题单靠一帧很难根治。我试过比较有效的做法是“历史帧累积”把前几帧的点云按运动补偿叠加到当前帧变相增加点云密度。这相当于用时间换空间代价是引入一点延迟但对低速城市工况非常友好。跟踪模块也要配合偏好在“点少但稳定的轨迹”上继续外推而不是一帧少见就立刻判死。4.2 遮挡截断下的轨迹保持策略目标被遮挡是所有跟踪系统都绕不开的问题。行人被公交车挡住、车辆被绿化带截断检测器输出自然中断。如果跟踪逻辑是“检测框消失就删轨迹”那目标再出现时就会生成一条新轨迹下游模块会把它当成新目标处理在决策上造成不必要的急刹或变道。正确的思路是区分“目标真的消失”和“目标被临时遮挡”。操作上可以做三件事。第一给轨迹设置丢失容忍时间通常0.5到1秒在这个窗口内继续用运动模型外推目标位置外推结果参与下轮匹配但不直接对外输出高置信度第二扩展遮挡期间的门控范围因为目标恢复可见时位置很可能比预测偏差更大第三对静止目标和移动目标区别对待静止目标丢失后可以保持更久移动目标的存活时间则要短一些否则外推位置误差会越来越大。轨迹恢复是另一个容易忽视的点。目标重新出现后旧轨迹和新检测框完成关联需要立刻修正被外推“带偏”的位置和速度。正确做法是把当前检测框的状态作为强观测快速把滤波器状态拉回真实值。如果这里做得太保守轨迹会继续漂移好几帧看起来就像目标被“吸”在原地一样。4.3 类别不平衡与小目标漏检行人和骑行者这类目标在公开数据里天然是少数类再加上体积小、点云数量少模型很容易对它们漏检。很多团队习惯只看“整体检测精度”觉得指标不错就没有问题可一旦单独统计行人召回率才发现低得可怜。解决方向是分层的。训练侧可以增加小目标类别的采样权重或者使用类别平衡的损失函数让模型在训练时不再被车辆目标“带偏”。后处理侧可以给不同类别设置不同的分数阈值对行人适当放宽宁可多一些低置信度候选也要保证召回率。跟踪侧也要同步调整关联代价权重行人允许的匹配距离可以比车辆小因为它体积小、点云中心估计更容易抖动。小目标还有一个特点中心点估计不稳定。一个行人远距离时可能只有三五个有效点检测框的中心会在不同帧之间来回偏。这时单靠几何中心做跟踪关联会很不稳定可以尝试把检测框的底部中心作为关联锚点因为底部中心通常更接近地面真实位置受点云稀疏的影响更小行人跟踪的连续性会提升不少。4.4 外参在线标定漂移与降级处理车辆跑一段时间后摄像头和激光雷达之间的外参会因为长期振动、热胀冷缩等原因慢慢漂移这不是偶发事件而是量产后的固有问题。我见过不少开发阶段表现不错的融合系统跑到几千公里后精度明显下降最终排查下来就是外参漂了。应对漂移有两层策略。第一层是主动标定定期做在线自动标定利用车道线、地面平面、目标边缘等自然特征在车辆运行过程中持续修正外参。第二层是健康监控加降级。融合模块要持续统计激光雷达框和摄像头框的关联成功率、重叠率、位置偏差的滑动均值一旦这些指标持续恶化说明标定可能已经出问题这时候要有策略地降低摄像头权重或切回单激光雷达模式并上报标定异常告警。降级策略在融合系统里不是可有可无的设计而是安全底线。宁可牺牲一些感知精度也不能在标定异常时继续强行融合因为错误的融合输出比单传感器输出更具误导性。合理做法是设置清晰的降级矩阵正常时双传感器融合摄像头置信度异常时退化为纯激光雷达激光雷达数据异常时退化为纯摄像头两者都异常时系统输出未知状态。4.5 算力受限平台的推理优化智能驾驶的算力是有上限的。车载平台往往要在几百毫瓦到几十瓦的功耗约束下完成整个感知链路无法像离线训练那样随便堆算力。因此激光雷达算法在部署时要做大量取舍。常用的优化手段有几类。一是量化把模型从浮点推理压到int8量化精度损失通常在可接受范围内但推理速度能提升两到三倍。二是稀疏化点云数据本身是稀疏的体素化后绝大多数体素为空专门处理稀疏卷积的算子能把无效计算大量省掉。三是后处理裁剪非极大值抑制、框的编解码等后处理逻辑看起来不起眼实测中往往能占到推理总耗时的两成以上值得花时间优化算法实现。四是距离分块近处用小体素、远处用大体素或者对超过一定距离的点云做降采样算法性能不会明显下降但计算量能降一大截。调优经验上我会先做性能剖析把检测网络、预处理、后处理、跟踪各自耗时打点看清楚时间到底花在哪再动手优化。很多团队一上来就调模型结构结果发现瓶颈根本不在模型本身而在一行低效的坐标变换代码这种亏我吃过不止一次。4.6 不同传感器型号之间的域差异从开发到量产甚至同一车型的不同批次都可能使用不同品牌或不同线束的激光雷达。换了传感器同样一套算法性能就可能明显下跌这就是典型的“域差异”问题。不同的垂直视场角、线束密度、探测距离会让点云分布产生肉眼可见的区别固定阈值类型的后处理代码更是首当其冲。最简单的处理是数据层面适配。收集新传感器数据的真值做微调或数据增强让模型学着适应新的点云分布。同时后处理里不要写死绝对阈值比如“聚类点数少于20就当成噪声”这类规则换个传感器就失效了。更好的做法是把阈值建模成距离和传感器参数的函数让逻辑对传感器变化更鲁棒。最后在系统层面保留一个传感器配置模块不同型号对应不同的预处理参数、检测阈值、跟踪关联参数切换时只要加载对应配置而不是重写代码。如果是多车型同步开发我建议团队从一开始就定义一套统一的中间表示点云统一成规范化的体素或指定坐标系统的稀疏张量而把上游传感器差异封存在预处理层。这样后续算法迭代只需要面向中间表示做不会被某个具体传感器的癖好绑架。5. 调试环境与参数配置笔记5.1 检测后处理、跟踪与融合的参数示例给出一套我常用参数配置具体数值需要根据传感器和场景微调但结构可以直接参考。detector: score_threshold: 0.35 nms_iou_threshold: 0.5 class_thresholds: vehicle: 0.35 pedestrian: 0.25 cyclist: 0.25 tracker: state_dim: 9 motion_model: constant_velocity # 生命周期管理 confirm_hits: 2 max_lost_age_ms: 800 remove_if_low_score_frames: 5 # 关联代价权重 association: gate_center_distance_m: vehicle: 3.0 pedestrian: 1.5 cyclist: 2.0 gate_max_height_diff_m: 1.2 cost_weights: center_distance: 1.0 yaw_difference: 0.3 size_similarity: 0.2 # 卡尔曼噪声 process_noise_position: 0.5 process_noise_velocity: 1.0 measurement_noise_base: 0.8 measurement_noise_scale_per_meter: 0.02 fusion: mode: target_level time_align_window_ms: 50 merge_weights: lidar: 0.6 camera: 0.4 degrade: continuous_misalignment_frames: 20 trigger_sensor_cache: lidar_only这些参数背后的逻辑是检测分数阈值按类别分开因为行人和骑行者的不确定度天然比车辆高统一阈值会伤召回关联门控按类别给不同距离上限避免大车和小车、行人的匹配相互干扰卡尔曼的测量噪声随距离线性放大对应远距离点云精度下降的现实融合权重只是起始值权重随后续健康监控动态调整。调试时我习惯用一个“回放器”把这些参数一次性加载进去然后逐帧检查同一目标的轨迹ID是否稳定、两路传感器框的重叠情况。一轮跑下来参数调优的时间可以从几天压缩到几小时。5.2 调试时优先看的三个指标参数配置完成后到底该怎么评估系统好坏评估指标很多但实际调试我只优先盯三个。第一个是ID切换率即同一物理目标在跟踪过程中轨迹ID被切换的次数这个指标最直观反映关联是否稳定。两辆外观相近、并排行驶的SUV是测试ID切换的绝佳场景如果在这种工况下ID都能稳住其他场景问题不大。第二个是轨迹断裂率指一条轨迹在中途断裂、再生成新轨迹的次数。这个指标和遮挡保持策略强相关。做法是统计完整轨迹长度和中断次数在“每百帧轨迹中断”这个口径上做对比。这里可以明确看到max_lost_age_ms这个参数的作用设得太短目标被挡一下就断设得太长外推位置发飘恢复关联时容易错配。第三个是融合位置一致性误差也就是目标级融合后激光雷达框中心和摄像头框中心之间的距离统计。这个指标直接暴露标定漂移和时间对齐问题。可以定期在后台统计这个误差的均值与标准差如果均值超过20厘米且持续上升优先检查标定而不是急着改融合算法。调试工具也很重要。把点云投影到图像上同时绘制激光雷达框、摄像头框和轨迹ID三路信息叠在一个画面上逐帧回放几乎能一眼定位是检测问题、跟踪问题还是融合问题。可视化工具的作用就是让异常从指标变成肉眼可见的“违和感”这一步在感知系统调试里是不可替代的。做激光雷达感知这几年我有一个很深的体会把一套系统从“离线指标好看”打磨到“实车稳定能用”功夫往往花在不那么迷人的环节上。跟踪状态机怎么设计、关联代价怎么配、外参漂移了怎么降级、算力不够了怎么砍这些才是真正决定系统下限的东西。如果你正在为自己的感知项目发愁不妨先把模型精度放一放回到这一章讨论的这些环节上做一轮系统体检很多让人头疼的“疑难杂症”反而会迎刃而解。