2、动态场景挑战：动态场景定义、运动物体对Occupancy的影响、时序一致性要求、动态场景下的常见问题（遮挡、拖影、鬼影）

好，咱们进入正题。动态场景，说白了就是「会动的世界」。你想想看，自动驾驶的车在路上跑，周围的车也在跑，行人、自行车、甚至飘落的树叶，没一个是静止的。这对Occupancy网络来说，是个不小的考验。

2.1 动态场景定义

我个人习惯把动态场景分成两类：

• 刚性运动物体：比如汽车、卡车。它们整体移动，形状基本不变。
• 非刚性运动物体：比如行人、动物。它们会摆臂、扭动，形状一直在变。

还有一种特殊情况——自运动。也就是我们自己的车在动。这会导致整个背景都在「流动」。嗯，这里要注意，自运动如果不处理好，你会觉得整个世界都在围着你转，Occupancy预测会直接崩掉。

2.2 运动物体对Occupancy的影响

运动物体对Occupancy的影响，我总结为三个「不」：

1. 位置不确定：物体在动，它下一秒在哪？Occupancy网格里该不该标记它？
2. 形状不确定：行人走路时手臂摆动，占用的体素一会儿多一会儿少。
3. 存在不确定：物体可能被遮挡，也可能突然出现。比如一辆车从拐角冲出来。

我在项目中遇到过最头疼的情况——高速公路上，前车突然急刹。我们的Occupancy网络在那一瞬间，对前车的位置预测出现了偏差，差点导致误判。后来我加了一个运动补偿模块，才把这个问题压下去。

2.3 时序一致性要求

时序一致性，说白了就是「前后帧要能对上」。你想想看，如果第1帧检测到一辆车在位置A，第2帧它突然出现在位置C，中间跳过了B，那Occupancy网络就会懵掉——这车是瞬移了吗？

为什么会这样？常见原因有两个：

• 传感器采样率不够：比如激光雷达只有10Hz，对于高速运动的物体，帧间位移可能很大。
• 检测算法不稳定：同一辆车，这一帧检测到了，下一帧漏检了，再下一帧又出现了。Occupancy网格就会忽闪忽闪的。

我记得有一次调试，发现Occupancy预测的车辆位置一直在抖动。查了半天，原来是检测算法的置信度阈值设得太高，导致车辆时有时无。降低阈值后，时序一致性明显好了很多。

2.4 动态场景下的常见问题

动态场景下，有三个问题特别常见：遮挡、拖影、鬼影。咱们一个一个说。

2.4.1 遮挡

遮挡是Occupancy网络的天敌。一辆大卡车从你面前开过，它后面的一切都被挡住了。你的Occupancy网格里，卡车后面就是一片空白。但实际那里可能有一辆小轿车。

怎么处理？我个人习惯用「时序补全」——既然这一帧被挡住了，那就用上一帧的观测来填充。当然，这有个前提：物体不能移动太快。否则上一帧的位置和这一帧的实际位置对不上。

2.4.2 拖影

拖影，就是运动物体在Occupancy网格上留下「尾巴」。比如一辆车快速驶过，它的Occupancy预测会像彗星一样，后面拖着一串模糊的体素。

为什么会这样？因为Occupancy网络在融合多帧信息时，没有及时「遗忘」旧的信息。说白了，就是记忆太长了。

我在项目中遇到过类似问题。当时我们用的一个时序融合模块，权重设置不合理，导致旧帧的贡献太大。结果就是，车都开走了，Occupancy网格上还留着它的影子。后来我把衰减系数调大了一点，拖影就消失了。

2.4.3 鬼影

鬼影比拖影更麻烦。拖影至少还是真实物体的「残影」，鬼影则是完全不存在的东西。比如，一辆车在转弯时，Occupancy网络可能错误地预测出两个车——一个在真实位置，一个在错误位置。

鬼影的成因很复杂。我总结下来，主要有三点：

• 运动模型不匹配：比如你用恒速模型去预测一个正在转弯的车，预测位置就会偏。
• 多模态数据冲突：激光雷达说这里有车，相机说没有，融合后可能产生一个「折中」的错误位置。
• 时序对齐误差：不同传感器的数据时间戳没对齐，导致同一物体被当成两个物体。

2.5 小结

动态场景的挑战，说白了就是「如何在运动中保持清醒」。遮挡、拖影、鬼影，这三个问题你绕不开。我的经验是：

• 遮挡靠「时序补全」和「上下文推理」
• 拖影靠「合理衰减」和「运动置信度」
• 鬼影靠「时间戳同步」和「运动模型匹配」

嗯，这一章的内容就到这里。下一章咱们聊聊具体的时序融合方法，包括怎么设计网络结构来处理这些动态问题。