自动驾驶这块我折腾了几年从最早的模块化流水线到后来的 BEV 感知再到这两年大家一窝蜂往上冲的端到端中间踩的坑能写一本书。OmniDrive 是我自己攒的一套全场景多模态驾驶软件栈参考实现名字里的 Omni 不是喊着好听它指三件事全模态输入相机、激光雷达、毫米波、车辆自身状态、全任务输出检测、分割、占用栅格、轨迹预测、规划轨迹、全场景覆盖城市道路、高速、园区低速、泊车。它解决的问题很具体——过去每个模块各练各的感知输出的框抖一下、预测的轨迹偏半米规划那边就得疯狂加安全冗余最后车开起来又怂又顿。OmniDrive 想干的事情是把这些环节在特征层面焊在一起让看见什么直接服务于怎么开。这篇东西适合两类人看。一类是想自己搭一套能跑通、能复现的驾驶感知/规划系统但被各种论文里的名词绕晕的同学另一类是在工程落地阶段卡在时延、掉点、标定漂移这些脏活上的同行。我不打算讲太多公式推导重点是把我实际做的时候的那些决策链条摊开为什么这么选、参数怎么算出来的、哪里最容易翻车。代码和配置我会给到能直接抄的程度但你要清楚任何一套驾驶软件栈搬到自己车上都得重调别指望粘贴就完事。1. 项目缘起与整体思路拆解1.1 为什么要做全场景而不是先把一个场景做透刚开始我也觉得全场景是个伪需求业内主流做法是先啃城市道路或者先啃高速把一个场景的指标刷到能交差再谈别的。但我实际跑下来发现场景切分的代价比想象中大得多。城市路口需要近距离、高精度的行人和非机动车感知高速需要远距离、低误检的车辆跟踪园区低速需要极强的近场盲区覆盖和对低矮障碍物的敏感性——这三套需求如果各做一套模型光模型维护、标定对齐、版本管理就能把一个小团队拖死。更麻烦的是场景边界。真实道路没有加载界面从高速匝道汇入城市快速路的那一刻你的系统需要在几百毫秒内完成场景切换而两套独立模型的特征分布、输出格式、置信度尺度都不一样切换瞬间的抖动几乎是必然的。我见过最离谱的情况是匝道口正好是两套模型的置信度都偏低的位置规划器拿到一堆低置信度目标直接触发急刹。所以 OmniDrive 的第一条设计原则就是一套骨干、一套特征空间、多组任务头。场景差异通过数据采样权重和任务头的轻量分支来解决而不是通过拆模型来解决。这个选择带来的直接好处是切换场景时特征空间是连续的不会出现断崖式的置信度跳变坏处是模型容量必须够大训练数据必须覆盖足够宽的长尾否则很容易出现样样通样样松。这个取舍我后面会用具体的参数来量化。1.2 三种技术路线的对比与最终选型在动手之前我把当时能想到的三条路线摊在桌上做了对比这张表后来被我改过很多次但结论一直没变。路线代表形态优势主要问题我的判断模块化流水线检测→跟踪→预测→规划各模块独立训练可解释性强单模块可独立迭代出问题好定位误差逐级累积模块间信息损失严重联调成本高适合做 baseline 和兜底不适合作为主链路纯端到端传感器输入直接回归控制量或轨迹信息无损上限高代码量少不可解释长尾难覆盖调试像开盲盒安全兜底难做现阶段不敢直接上车只能做研究和小范围验证统一表征 多任务共享 BEV/稀疏 query 表征多任务头 轻量规划头信息共享充分模块边界清晰可单独监督每一项训练难度大任务间可能互相拉扯需要精细调权重最终选择工程可控性和性能的平衡点我最终走第三条核心原因是可监督性。纯端到端最大的问题不是性能而是当车在某个路口表现异常时你无法快速判断是没看见还是看见了但判断错了。统一表征方案里每一项输出都有独立的监督信号我可以单独看 BEV 上的目标召回、看占用栅格的 IoU、看预测轨迹的 ADE定位问题的速度快一个数量级。具体到表征形式我在稠密 BEV 网格和稀疏 query 之间纠结了很久。稠密网格的好处是空间结构规整卷积操作友好可视化直观坏处是分辨率一上去显存就炸。稀疏 query 的好处是算力只花在有东西的地方天然适合长尾坏处是训练收敛慢对初始化敏感。最后我的方案是混合主干用稀疏 query 做目标和地图要素同时保留一路低分辨率0.5 米一格、320×320的稠密 BEV 特征用于占用栅格和可行驶区域预测。这个组合看起来有点冗余但实测下来非常值——稀疏 query 负责精确的实例稠密网格负责模糊的边界规划器两者都要用。1.3 算力预算的倒推先算清楚 100ms 怎么花做架构设计最容易犯的错是先堆模型再想办法优化最后发现根本压不进实时。我的做法是先定预算再定结构。目标平台按 10Hz 输出也就是每帧 100ms 的硬上限。留 30% 余量应对抖动和调度实际可用约 70ms。我把这 70ms 拆成下面这样环节预算说明传感器预处理去畸变、缩放、点云体素化8ms相机缩放可以用硬件单元点云体素化走并行图像骨干网络25ms六路相机输入 704×256点云骨干网络10ms稀疏卷积pillar 0.4m多模态融合12ms交叉注意力query 数量控制在千级任务头检测/分割/占用/预测10ms并行执行取最慢的规划头与后处理5ms轨迹解码 合法性检查这个预算是倒推出来的假设骨干网络在目标平台上单帧能跑 25ms那么它能承载的计算量大概是 90 GFLOPs 左右按有效利用率 40% 估这个数字直接决定了我的输入分辨率和通道宽度。反过来说如果我一开始就按 1080P 全分辨率输入设计光骨干就得 80ms 以上后面全部免谈。注意这里的预算是按推理引擎优化后的稳态算的不包括首次加载、内存分配、动态 shape 重编译这些一次性开销。实车部署时一定要做长时间压测把最坏情况比如某帧突然出现大量目标导致后处理变慢也统计进去。我踩过的一个坑是早期版本只测了平均时延平均值 62ms 看着很稳结果实车跑高速时偶尔出现 130ms 的长尾帧排查半天发现是某一帧检测出的目标数量从常态的 40 个暴涨到 300 多个一段施工区锥桶密集后处理的 NMS 和轨迹关联是 CPU 上串行的直接打爆。后来把后处理也搬到了并行单元上并且加了目标数量的上限截断才把这个长尾压下去。2. 多模态融合的核心细节与实操要点2.1 时间同步差 50ms 就差 1 米这一块是新手最容易低估的地方。很多人以为传感器时间戳对齐就是取最近的帧凑一起实际上在动态场景里这个误差会直接变成空间误差。算一笔账车速 20 m/s72 km/h如果相机和激光雷达的时间戳偏差 50ms那么同一点在两次观测里的纵向位置就差 1 米。1 米的误差在融合特征里意味着一个行人的特征可能被错误地关联到后方 1 米的空地上模型学到的是错的对应关系而且这种错误是系统性的不是随机噪声靠增加数据量也修正不了。我的处理分三层第一层是硬件层尽量用同一路触发信号给所有传感器打时间戳把硬件偏差压到微秒级。第二层是软件层为每个传感器维护一条时间戳队列融合时按目标时刻做线性插值或者运动补偿而不是简单取最近帧。第三层是自检层定期用静止场景下的标定板和多传感器共同观测的静止目标反推时间偏差并报警。运动补偿的公式不复杂本质就是用一个位姿变换把不同时刻的观测搬到同一参考系def compensate_to_target_time(points, pose_at_capture, pose_at_target, ego_speed): points: (N, 3) 传感器坐标系下的点 pose_at_capture: 采集时刻的自车位姿 (4x4) pose_at_target: 目标时刻的自车位姿 (4x4) 返回: 补偿到目标时刻的传感器坐标系下的点 # 相对位姿从采集时刻到目标时刻 rel np.linalg.inv(pose_at_target) pose_at_capture pts_h np.concatenate([points, np.ones((points.shape[0], 1))], axis1) pts_in_target_ego (rel pts_h.T).T[:, :3] # 再变换回传感器坐标系外参固定 return pts_in_target_ego看起来很简单但实际落地有两个细节值得说。一是位姿的精度比补偿算法本身更重要如果自车位姿来自低精度的航位推算补偿反而会把误差放大这时候不如老老实实用最近帧加一个保守的距离门限。二是旋转补偿不能忽略很多人只补偿平移结果车辆在转弯时激光雷达点云的边缘会出现明显的拖影这个拖影在 BEV 上表现为障碍物轮廓变宽直接导致规划器过度保守。2.2 视角转换三种主流做法的取舍把图像特征搬到 BEV 空间业内主要有三条路我在 OmniDrive 里全都实现过一版最后选的是混合方案。做法一深度估计加投影采样。为每个像素预测一个深度分布然后按深度把特征投到 BEV 网格上。优点是有显式的几何约束对遮挡有一定建模能力缺点是对深度预测的精度极度敏感深度分错的像素会把特征撒到完全错误的位置而且这些错误很难在后续融合中纠正。做法二预定义网格加投影采样。在 BEV 网格上预定义一堆 3D 参考点投影到各相机图像上采特征。优点是省掉了深度预测速度快缺点是参考点的高度设置很关键设错了就会在近处采到天空、远处采到地面而且在相机视野边缘采样会越界。做法三稀疏 query 加交叉注意力。不预设网格用一组可学习的 query 去各相机特征图上采样。优点是灵活、不需要显式的深度建模缺点是 query 的初始化很讲究训练初期容易塌缩到少数几个位置。我的最终方案是近场用做法二远场和稀疏实例用做法三做法一保留作为消融对照。原因很实际——近场30 米内对精度要求最高预定义网格的做法在近场几何误差最小而且计算量可控远场本身精度就有限用 query 的灵活性换建模能力更划算。这里有个参数必须算清楚BEV 网格的分辨率。0.25 米一格在 100 米范围内是 400×400显存直接爆0.5 米一格是 200×200占 4 万格勉强能接受但实际上我用了 0.5 米一格覆盖 160 米见方的范围也就是 320×320。为什么不干脆用 1 米因为在 30 米到 60 米这个区间1 米的网格会让相邻两辆并排行驶的摩托车落到同一格里融合后目标边界彻底糊掉。0.5 米是实测下来能分开并排目标和显存能扛的临界点。2.3 点云体素化参数背后的账要算明白激光雷达这一路的参数选择我用的是 pillar 方案而不是完整的 3D 体素核心原因是计算量。算一下如果按 0.075 米的立方体体素覆盖 x∈[-80, 80]、y∈[-80, 80]、z∈[-5, 3] 的空间体素数量是 (160/0.075) × (160/0.075) × (8/0.075) ≈ 2133 × 2133 × 107接近 4.8 亿个格子。就算绝大部分是空的光是索引结构就吃不下。换成 pillar只在水平面离散、高度方向聚合0.4 米一格覆盖 160×160 米得到 400×400 共 16 万个 pillar每个 pillar 最多采样 32 个点。这个规模在显存和时间上都能接受代价是丢失了高度方向的精细结构对于天桥、隧道口、限高杆这类需要区分高度层级的场景会比较吃力。所以我补了一手在 pillar 特征之外额外挂一路高度统计特征就是把每个 pillar 内点云的高度分布压缩成几个分位数比如 5%、50%、95%跟 pillar 特征拼在一起。代价很小但对限高杆、悬空指示牌这类目标的区分度提升明显。这个改动看起来不起眼实测在是否可通行的判断上把误判率降了一大截。注意pillar 内的点采样一定要做随机采样而不是取前 N 个点。点云本身有扫描顺序取前 N 个会让模型学到扫描顺序这个伪特征换一台雷达或者换个安装角度就完全失效。我早期版本就犯过这个错模型在训练集上表现很好换车测试时性能骤降定位了两天才发现是这个原因。2.4 融合时机早融合、中融合、晚融合的实际差异理论上的对比文章很多我只说说实测感受。早融合原始数据层融合在工程上基本不可行因为相机是稠密像素、激光雷达是稀疏点两者的数据组织方式差异太大强行拼在一起精度和效率都不划算。晚融合各自出结果再做后处理融合实现最简单也最容易做模块替换但信息损失严重。举个具体例子激光雷达在远距离对车辆的检测很稳但对行人这类小目标在 60 米外几乎没点相机正好相反远距离能看见人形轮廓但测距不准。晚融合阶段两边各自给一个框融合逻辑只能做加权平均或者置信度投票没法利用相机看到轮廓的位置 雷达测到的地面高度这种跨模态互补信息。中融合特征层融合是我选的方案。具体实现是在 BEV 空间做交叉注意力以图像 BEV 特征为 query点云 BEV 特征为 key/value做一次多头注意力再反过来做一次。这个双向设计是必要的——单向的话强势模态会压制弱势模态。我最初只做了图像查点云结果发现在点云稀疏的雨雾天图像特征的噪声压不住补上反向之后点云的空间结构能对图像特征起到锚定作用。融合层数不能多两层足够。我试过四层指标提升不到 1%时延增加 40%性价比极低。这个结论可能跟具体数据分布有关但我的建议是先把单层融合调透别一上来就堆深度。3. 训练流程与部署落地的完整实操3.1 数据组织采样策略比模型结构更影响结果说句可能得罪人的话在驾驶感知这个领域数据配比比模型结构重要得多。我在这上面花的时间远超调网络。OmniDrive 的训练数据分四个来源城市道路的常规采集、高速长距离采集、园区低速采集、以及大量困难场景的回灌数据。前三个是基础盘第四个决定上限。采样策略上我用的是分层加权采样权重不是拍脑袋定的而是按场景稀缺度 × 任务难度算出来的。具体做法是先跑一遍全量数据统计每个场景标签下的样本数量和当前模型的损失值然后用下面这个公式给每个样本算权重weight (1 / freq[label]) ^ alpha * (loss_i / mean_loss) ^ betafreq[label]是该场景标签的出现频率alpha控制在 0.5 左右取 1 会过度采样稀有场景导致过拟合loss_i是上轮训练的样本损失beta取 0.3 到 0.5作用是让模型多看看还没学会的样本。这套动态加权在训练中期效果很明显尤其是夜间、逆光、雨雪这些场景的指标提升幅度比单纯增加数据量快得多。但它有个副作用训练后期损失曲线会变得很毛因为采样分布一直在变。我的做法是最后 10 个 epoch 关掉动态加权用固定分布做一轮收尾让模型在稳定分布上收敛。注意动态加权一定要设上限单个样本的权重不要超过基准权重的 5 倍否则会出现同一批数据反复喂、模型在这批数据上过拟合、验证集指标反而下降的情况。我吃过这个亏损失曲线看着一路降验证集从第 20 个 epoch 开始就横盘了。3.2 训练配置与显存估算给一份我实际在用的配置骨架参数是按 8 张 80GB 显存训练卡、全局 batch 16 来定的train: epochs: 40 batch_size_per_gpu: 2 grad_accumulate: 1 optimizer: AdamW lr: 2.0e-4 weight_decay: 0.01 warmup_iters: 1000 scheduler: cosine min_lr_ratio: 0.05 clip_grad_norm: 5.0 amp: true ema_decay: 0.999 data: image_size: [704, 256] num_cameras: 6 point_cloud_range: [-80, -80, -5, 80, 80, 3] pillar_size: [0.4, 0.4, 8.0] max_points_per_pillar: 32 max_pillars: 30000 bev_size: [320, 320] bev_resolution: 0.5 loss: cls_weight: 1.0 reg_weight: 2.0 seg_weight: 1.0 occupancy_weight: 1.5 planning_weight: 0.8显存这块我算过单卡 batch 2 的情况下图像骨干占大约 22GB点云骨干 8GB融合层 14GB任务头 6GB加上激活值缓存和优化器状态峰值在 62GB 左右。如果想加 batch最直接的办法是开梯度检查点代价是训练速度慢 25% 左右。训练时长估算假设数据规模 20 万帧全局 batch 16那么一个 epoch 是 12500 次迭代。实测单次迭代约 0.9 秒含数据加载一个 epoch 约 3.1 小时40 个 epoch 约 125 小时也就是五天多。这个时间对于快速迭代来说太长了所以我的做法是先用 1/4 数据跑 15 个 epoch 做结构验证确认结构没问题再上全量。结构验证阶段大概 12 小时出结果能挡掉 80% 的低级错误。3.3 损失函数的权重调试顺序多任务训练的权重不是一起调的必须有顺序否则你根本不知道是哪个任务在拖后腿。我的调试顺序是先单任务跑通再两两组合最后全任务联合。具体来说第一步只开检测损失确认模型能正常收敛BEV 上的目标位置准确。这一步如果都过不了说明数据管线或者标注映射有问题。第二步加分割和占用损失权重从 0.5 开始试。这里最常见的现象是分割损失一加检测的 mAP 掉一两个点——这是因为两个任务对特征的要求有冲突检测要边缘锐利分割要区域平滑。解决办法是给分割头单独加一层轻量适配不要直接共享最后一层特征。第三步加规划损失权重一定要小我从 0.2 开始往上试。规划损失给太大会导致感知特征被带偏——模型会倾向于输出对规划友好但对感知不准确的表征比如把远处的稀疏目标直接抹掉。这个现象我在早期版本里遇到过表现是 BEV 可视化上远处的小目标消失了但规划轨迹看起来很平滑特别有欺骗性。调试阶段开启任务建议初始权重观察指标第一阶段检测1.0各距离段召回率、中心点误差第二阶段检测 分割1.0 / 0.5检测指标是否掉点、分割 IoU第三阶段检测 分割 占用1.0 / 0.5 / 1.0占用栅格的边界准确度第四阶段全任务1.0 / 0.5 / 1.0 / 0.2规划轨迹的平滑度和安全性3.4 量化部署哪些层绝对不能动模型训练完只是开始部署才是真正见功夫的地方。我走的是 INT8 量化路线但不是全模型量化而是分层处理。先说结论骨干网络的前几层和最后几层、以及所有的归一化层必须保留 FP16。原因是前几层处理的是原始像素和点云数值动态范围极大量化损失会很严重最后几层直接决定输出误差会被放大到最终结果上。中间的特征提取层可以安全量化到 INT8。量化掉点的实测数据全模型 INT8 的情况下检测 mAP 掉约 3.5 个点占用栅格的 IoU 掉 4 个点规划轨迹的横向偏差增加 8 厘米。混合精度方案下检测 mAP 只掉 0.8 个点占用 IoU 掉 0.6 个点规划偏差增加不到 2 厘米而时延只比全 INT8 高 12%。这个交换非常划算。校准集的选取也有讲究。不要用训练集里随机抽的样本要用覆盖所有场景类型的小规模代表性集合我一般选 500 到 1000 帧按场景比例分层抽样确保夜间、雨天、隧道、逆光这些极端光照都有覆盖。用纯白天晴天数据校准出来的量化参数到了夜间会掉得很难看。推理时延的实测数据目标平台含前后处理模块FP16 时延混合精度时延备注图像预处理7.2ms7.2ms不支持量化图像骨干26.5ms19.8ms首尾层保留 FP16点云骨干10.4ms7.1ms稀疏卷积量化收益明显融合层11.8ms8.3ms注意力层的 softmax 保留 FP16任务头9.6ms6.4ms检测头输出层保留 FP16后处理5.2ms5.2msCPU 侧未量化合计70.7ms54.0ms满足 100ms 预算这个表是我压了好几轮才达到的。最早版本合计 96ms几乎贴着上限实车一跑就超。主要的优化点有三个把点云体素化从 CPU 挪到并行单元省 6ms、融合层的 query 数量从 2000 降到 900省 4ms、后处理的 NMS 改成并行实现省 3ms。4. 规划器设计感知怎么真正喂给规划4.1 轨迹表示的选择规划输出的表示形式我改过三版。第一版是直接输出未来 3 秒的 30 个离散点间隔 0.1 秒。问题是这 30 个点之间没有运动学约束模型可能输出一条折线看起来每个点都对连起来车根本开不出来。第二版改成输出控制量油门、刹车、转向让模型直接学驾驶行为。问题是控制的频率和数据采集时的控制频率必须严格一致而且不同车型的控制响应特性差异巨大换个车型就得重训泛化性太差。第三版也就是现在用的是输出一条带曲率约束的参数化轨迹给定起点状态位置、朝向、速度、曲率输出一组控制点用三次样条插值成连续轨迹。这样既能保证轨迹的平滑性和运动学可行性又不会绑定具体车型的控制特性。控制层拿到轨迹后自己去做跟踪两边的职责很清晰。这里有个细节控制点的间隔我选的是 0.5 秒一个3 秒一共 7 个点。间隔太密模型容易过拟合到具体的采样时刻间隔太疏轨迹的细节表达不够。0.5 秒是实测下来能表达变道意图和不至于过度参数化的平衡点。4.2 代价函数与安全兜底规划头输出的候选轨迹不止一条我给的是 6 条候选加一个评分头。评分用的代价函数是手工设计的没用纯学习的方式这点我要解释一下原因。纯学习的评分在离线指标上通常更好看但没有下界保证。手工代价函数虽然不够聪明但它能保证撞上障碍物的轨迹代价一定最高这件事是数学上成立的而不是靠模型学出来的。在这个领域可证明的安全下界比指标上的零点几个点重要得多。代价函数的构成大致是这几项加权与障碍物的碰撞风险用占用栅格做距离场、偏离参考线的程度、加速度和加加速度的惩罚、与预测轨迹的交互风险、通行效率奖励。权重是分场景调的低速园区和高速的权重完全是两套。注意安全兜底的逻辑一定要写成独立于模型的规则模块不能依赖模型输出。我见过有团队把紧急制动的判断也放进网络里结果网络在某些极端场景下给出了错误的安全判断。兜底逻辑必须是不管模型说什么只要规则判定有碰撞风险就执行制动。这个优先级不能倒过来。4.3 闭环验证仿真回放比离线指标靠谱离线指标mAP、IoU、ADE只能说明模型学到了东西不能说明车能开。我建了一套回放系统把真实采集的数据按时间顺序喂给完整链路包括感知、预测、规划然后把规划输出和真实的人类驾驶轨迹做对比。对比不是简单的距离误差而是看几个更贴近实际的问题规划轨迹和人类轨迹的终点分布是否一致说明意图判断对不对、横向偏移的时间序列是否平滑说明有没有来回摆动、速度曲线的形态是否合理说明加减速时机对不对。回放系统帮我抓到过一个很隐蔽的问题模型在城市路口右转时倾向于过早开始转向。原因是训练数据里人类驾驶员在这个路口普遍转得比较急模型学到了这个风格。但过早转向会导致车辆切到内侧车道线的位置虽然没有实际碰撞但乘坐体验很差而且不符合通行规则。这个问题在离线指标上完全看不出来因为轨迹的终点误差很小。后来在代价函数里加了转向时机的约束项才把这个行为纠正过来。5. 常见问题与排查技巧实录这一节是我这几年踩坑的浓缩版按现象组织方便你遇到问题时直接对号入座。5.1 训练阶段的高频问题现象可能原因排查手段处理方式损失正常下降但验证集横盘动态采样权重过高导致过拟合检查单样本权重分布看是否集中在少数样本权重上限设为基准的 5 倍最后 10 个 epoch 关闭动态加权检测头正常但规划轨迹抖动感知特征的时序不一致逐帧对比 BEV 特征图的相似度加入时序一致性损失或增加时序融合模块训练中途出现 NaN混合精度下注意力层的 softmax 溢出打开异常检测定位到具体算子注意力计算强制 FP32或加 log-sum-exp 稳定化多卡训练速度不线性数据加载成为瓶颈看 GPU 利用率和数据加载时间占比把解码和增强放到并行进程用共享内存队列分割指标高但占用栅格边界糊分割损失权重过大压制了边界特征可视化两者在目标边缘的响应分割头单独加适配层降低共享程度其中训练中途 NaN这个我遇到过两次都是在小 batch 加混合精度的情况下出现的。表现是训练到几千次迭代突然 loss 变成 nan前面的曲线完全正常。定位方法是打开框架的异常检测开关它会告诉你哪个算子产生了 nan。两次都定位到了注意力层的 softmax输入值过大导致 exp 溢出。解决办法是把 softmax 的计算强制放到 FP32代价是时延增加 1ms 左右完全可以接受。5.2 实车阶段的高频问题标定漂移导致的幽灵障碍物。这个现象特别有迷惑性BEV 上会突然出现一些位置固定、形状模糊的障碍物模型对它们的置信度还不低规划器为了安全就会频繁减速。排查方法是把点云投影到图像上看是否对齐——如果点云的边缘和图像里物体的轮廓错开了就是标定问题。我的经验是车辆每跑 5000 公里左右就应该做一次标定检查尤其是更换过轮胎、做过四轮定位或者有过轻微碰撞之后。时间戳跳变导致的轨迹突变。表现是规划轨迹在某一帧突然横向偏移一大截下一帧又恢复。这个问题的根源往往是某一帧某个传感器的时间戳异常比如丢帧后补了一帧旧数据导致融合时用错了时刻的数据。解决办法是在数据入口加一层时间戳合理性检查如果当前帧的时间戳和上一帧的差值超过正常周期的 1.5 倍就标记为异常帧降级使用单模态结果。量化后的边界效应。量化模型在某些特定距离段比如恰好 45 米左右的检测精度会突然变差。这个问题我排查了很久最后发现是量化参数校准时这个距离段的样本太少导致该区间的激活值范围估计偏了。解决办法是在校准集里按距离分层抽样确保每个距离段都有足够的样本。内存泄漏。长时间跑几个小时之后推理时延缓慢上升最终超时。这个几乎都是资源没释放导致的常见的地方有图像预处理的中间缓冲区没复用、点云的索引结构每次重建、日志缓冲区无限增长。我的做法是跑一个 8 小时的压测每 10 分钟记录一次内存占用和时延画成曲线如果斜率持续为正就说明有问题。5.3 三条不太容易想到的经验第一条永远保留一路简单但可靠的降级链路。我的降级链路是单目相机检测加传统跟踪加上简单的跟车和车道保持逻辑。性能很差但它跑得动、看得见、不会崩。主链路出任何异常超时、输出非法值、置信度异常就切过去。这条链路救过我至少三次实车测试的时候主链路因为一个边缘 case 崩了靠降级链路安全停回路边。第二条指标监控要按场景切片看不能只看总体。总体 mAP 涨了两个点很可能是因为白天场景涨了五个点、夜间掉了一个点。我的做法是维护一份固定的切片清单至少包含白天/夜间/黄昏、晴天/雨天/雪天、城市/高速/园区、远中近三个距离段、大小目标两个尺度。每次训练完自动跑一遍所有切片出一个矩阵报告任何一个切片掉点超过阈值就报警。第三条数据的脏比数据的少更可怕。标注错误、时间戳错乱、标定参数过期这些问题在训练集里占比可能只有百分之一二但它们会系统性地误导模型。我现在的做法是加一道数据质检对每批新数据自动跑一遍一致性检查点云投影和图像对齐、相邻帧的位姿连续性、标注框的尺寸分布是否合理异常的直接进人工复核队列。这个流程会拖慢数据入库速度但比训练完才发现问题再回滚要划算太多。6. 我在这套系统上花的冤枉时间写到这里想聊聊几个当时觉得很难、事后看其实可以绕开的决策。第一个是前期在稠密 BEV 分辨率上抠了太久。我一度执着于把分辨率从 0.5 米做到 0.25 米觉得这是提升小目标检测的关键。折腾了两周显存翻了三倍指标涨了 0.9 个点时延超预算。后来换了个思路保持 0.5 米的稠密网格但把稀疏 query 的分支加强用少量高精度 query 去覆盖小目标效果反而更好时延还降了。这件事让我明白分辨率不是唯一解表征形式的组合往往比单一维度上的暴力提升更有效。第二个是过早追求全场景覆盖。我一开始就想同时把城市、高速、园区都跑通结果是每个场景都只有半成品。后来改成先啃城市道路把数据管线、训练流程、部署链路全部打通形成一个完整闭环然后再逐个扩展到其他场景。第二个场景的接入只花了第一个场景 30% 的时间因为基础设施都现成了。顺序很重要。第三个是低估了评估体系的价值。前半年我基本靠肉眼看 BEV 可视化和轨迹图来判断模型好坏效率极低还容易漏问题。后来花了两周搭自动化评估包括切片指标、回放对比、长尾场景挖掘之后的迭代速度至少快了三倍。如果重来一次我会在写第一行训练代码之前就把评估框架搭好。现在这套 OmniDrive 在我手里已经迭代到第三版最大的感受是驾驶软件栈这件事模型结构的新颖程度远不如工程细节的扎实程度重要。一个平平无奇的结构配上严谨的标定、干净的标注、合理的采样和完整的评估跑出来的结果能甩开一个花哨结构配脏数据一大截。如果你也在做类似的事情我建议先把时间花在数据和评估上模型结构可以慢慢调那部分反而是最容易补的。
自动驾驶这块我折腾了几年从最早的模块化流水线到后来的 BEV 感知再到这两年大家一窝蜂往上冲的端到端中间踩的坑能写一本书。OmniDrive 是我自己攒的一套全场景多模态驾驶软件栈参考实现名字里的 Omni 不是喊着好听它指三件事全模态输入相机、激光雷达、毫米波、车辆自身状态、全任务输出检测、分割、占用栅格、轨迹预测、规划轨迹、全场景覆盖城市道路、高速、园区低速、泊车。它解决的问题很具体——过去每个模块各练各的感知输出的框抖一下、预测的轨迹偏半米规划那边就得疯狂加安全冗余最后车开起来又怂又顿。OmniDrive 想干的事情是把这些环节在特征层面焊在一起让看见什么直接服务于怎么开。这篇东西适合两类人看。一类是想自己搭一套能跑通、能复现的驾驶感知/规划系统但被各种论文里的名词绕晕的同学另一类是在工程落地阶段卡在时延、掉点、标定漂移这些脏活上的同行。我不打算讲太多公式推导重点是把我实际做的时候的那些决策链条摊开为什么这么选、参数怎么算出来的、哪里最容易翻车。代码和配置我会给到能直接抄的程度但你要清楚任何一套驾驶软件栈搬到自己车上都得重调别指望粘贴就完事。1. 项目缘起与整体思路拆解1.1 为什么要做全场景而不是先把一个场景做透刚开始我也觉得全场景是个伪需求业内主流做法是先啃城市道路或者先啃高速把一个场景的指标刷到能交差再谈别的。但我实际跑下来发现场景切分的代价比想象中大得多。城市路口需要近距离、高精度的行人和非机动车感知高速需要远距离、低误检的车辆跟踪园区低速需要极强的近场盲区覆盖和对低矮障碍物的敏感性——这三套需求如果各做一套模型光模型维护、标定对齐、版本管理就能把一个小团队拖死。更麻烦的是场景边界。真实道路没有加载界面从高速匝道汇入城市快速路的那一刻你的系统需要在几百毫秒内完成场景切换而两套独立模型的特征分布、输出格式、置信度尺度都不一样切换瞬间的抖动几乎是必然的。我见过最离谱的情况是匝道口正好是两套模型的置信度都偏低的位置规划器拿到一堆低置信度目标直接触发急刹。所以 OmniDrive 的第一条设计原则就是一套骨干、一套特征空间、多组任务头。场景差异通过数据采样权重和任务头的轻量分支来解决而不是通过拆模型来解决。这个选择带来的直接好处是切换场景时特征空间是连续的不会出现断崖式的置信度跳变坏处是模型容量必须够大训练数据必须覆盖足够宽的长尾否则很容易出现样样通样样松。这个取舍我后面会用具体的参数来量化。1.2 三种技术路线的对比与最终选型在动手之前我把当时能想到的三条路线摊在桌上做了对比这张表后来被我改过很多次但结论一直没变。路线代表形态优势主要问题我的判断模块化流水线检测→跟踪→预测→规划各模块独立训练可解释性强单模块可独立迭代出问题好定位误差逐级累积模块间信息损失严重联调成本高适合做 baseline 和兜底不适合作为主链路纯端到端传感器输入直接回归控制量或轨迹信息无损上限高代码量少不可解释长尾难覆盖调试像开盲盒安全兜底难做现阶段不敢直接上车只能做研究和小范围验证统一表征 多任务共享 BEV/稀疏 query 表征多任务头 轻量规划头信息共享充分模块边界清晰可单独监督每一项训练难度大任务间可能互相拉扯需要精细调权重最终选择工程可控性和性能的平衡点我最终走第三条核心原因是可监督性。纯端到端最大的问题不是性能而是当车在某个路口表现异常时你无法快速判断是没看见还是看见了但判断错了。统一表征方案里每一项输出都有独立的监督信号我可以单独看 BEV 上的目标召回、看占用栅格的 IoU、看预测轨迹的 ADE定位问题的速度快一个数量级。具体到表征形式我在稠密 BEV 网格和稀疏 query 之间纠结了很久。稠密网格的好处是空间结构规整卷积操作友好可视化直观坏处是分辨率一上去显存就炸。稀疏 query 的好处是算力只花在有东西的地方天然适合长尾坏处是训练收敛慢对初始化敏感。最后我的方案是混合主干用稀疏 query 做目标和地图要素同时保留一路低分辨率0.5 米一格、320×320的稠密 BEV 特征用于占用栅格和可行驶区域预测。这个组合看起来有点冗余但实测下来非常值——稀疏 query 负责精确的实例稠密网格负责模糊的边界规划器两者都要用。1.3 算力预算的倒推先算清楚 100ms 怎么花做架构设计最容易犯的错是先堆模型再想办法优化最后发现根本压不进实时。我的做法是先定预算再定结构。目标平台按 10Hz 输出也就是每帧 100ms 的硬上限。留 30% 余量应对抖动和调度实际可用约 70ms。我把这 70ms 拆成下面这样环节预算说明传感器预处理去畸变、缩放、点云体素化8ms相机缩放可以用硬件单元点云体素化走并行图像骨干网络25ms六路相机输入 704×256点云骨干网络10ms稀疏卷积pillar 0.4m多模态融合12ms交叉注意力query 数量控制在千级任务头检测/分割/占用/预测10ms并行执行取最慢的规划头与后处理5ms轨迹解码 合法性检查这个预算是倒推出来的假设骨干网络在目标平台上单帧能跑 25ms那么它能承载的计算量大概是 90 GFLOPs 左右按有效利用率 40% 估这个数字直接决定了我的输入分辨率和通道宽度。反过来说如果我一开始就按 1080P 全分辨率输入设计光骨干就得 80ms 以上后面全部免谈。注意这里的预算是按推理引擎优化后的稳态算的不包括首次加载、内存分配、动态 shape 重编译这些一次性开销。实车部署时一定要做长时间压测把最坏情况比如某帧突然出现大量目标导致后处理变慢也统计进去。我踩过的一个坑是早期版本只测了平均时延平均值 62ms 看着很稳结果实车跑高速时偶尔出现 130ms 的长尾帧排查半天发现是某一帧检测出的目标数量从常态的 40 个暴涨到 300 多个一段施工区锥桶密集后处理的 NMS 和轨迹关联是 CPU 上串行的直接打爆。后来把后处理也搬到了并行单元上并且加了目标数量的上限截断才把这个长尾压下去。2. 多模态融合的核心细节与实操要点2.1 时间同步差 50ms 就差 1 米这一块是新手最容易低估的地方。很多人以为传感器时间戳对齐就是取最近的帧凑一起实际上在动态场景里这个误差会直接变成空间误差。算一笔账车速 20 m/s72 km/h如果相机和激光雷达的时间戳偏差 50ms那么同一点在两次观测里的纵向位置就差 1 米。1 米的误差在融合特征里意味着一个行人的特征可能被错误地关联到后方 1 米的空地上模型学到的是错的对应关系而且这种错误是系统性的不是随机噪声靠增加数据量也修正不了。我的处理分三层第一层是硬件层尽量用同一路触发信号给所有传感器打时间戳把硬件偏差压到微秒级。第二层是软件层为每个传感器维护一条时间戳队列融合时按目标时刻做线性插值或者运动补偿而不是简单取最近帧。第三层是自检层定期用静止场景下的标定板和多传感器共同观测的静止目标反推时间偏差并报警。运动补偿的公式不复杂本质就是用一个位姿变换把不同时刻的观测搬到同一参考系def compensate_to_target_time(points, pose_at_capture, pose_at_target, ego_speed): points: (N, 3) 传感器坐标系下的点 pose_at_capture: 采集时刻的自车位姿 (4x4) pose_at_target: 目标时刻的自车位姿 (4x4) 返回: 补偿到目标时刻的传感器坐标系下的点 # 相对位姿从采集时刻到目标时刻 rel np.linalg.inv(pose_at_target) pose_at_capture pts_h np.concatenate([points, np.ones((points.shape[0], 1))], axis1) pts_in_target_ego (rel pts_h.T).T[:, :3] # 再变换回传感器坐标系外参固定 return pts_in_target_ego看起来很简单但实际落地有两个细节值得说。一是位姿的精度比补偿算法本身更重要如果自车位姿来自低精度的航位推算补偿反而会把误差放大这时候不如老老实实用最近帧加一个保守的距离门限。二是旋转补偿不能忽略很多人只补偿平移结果车辆在转弯时激光雷达点云的边缘会出现明显的拖影这个拖影在 BEV 上表现为障碍物轮廓变宽直接导致规划器过度保守。2.2 视角转换三种主流做法的取舍把图像特征搬到 BEV 空间业内主要有三条路我在 OmniDrive 里全都实现过一版最后选的是混合方案。做法一深度估计加投影采样。为每个像素预测一个深度分布然后按深度把特征投到 BEV 网格上。优点是有显式的几何约束对遮挡有一定建模能力缺点是对深度预测的精度极度敏感深度分错的像素会把特征撒到完全错误的位置而且这些错误很难在后续融合中纠正。做法二预定义网格加投影采样。在 BEV 网格上预定义一堆 3D 参考点投影到各相机图像上采特征。优点是省掉了深度预测速度快缺点是参考点的高度设置很关键设错了就会在近处采到天空、远处采到地面而且在相机视野边缘采样会越界。做法三稀疏 query 加交叉注意力。不预设网格用一组可学习的 query 去各相机特征图上采样。优点是灵活、不需要显式的深度建模缺点是 query 的初始化很讲究训练初期容易塌缩到少数几个位置。我的最终方案是近场用做法二远场和稀疏实例用做法三做法一保留作为消融对照。原因很实际——近场30 米内对精度要求最高预定义网格的做法在近场几何误差最小而且计算量可控远场本身精度就有限用 query 的灵活性换建模能力更划算。这里有个参数必须算清楚BEV 网格的分辨率。0.25 米一格在 100 米范围内是 400×400显存直接爆0.5 米一格是 200×200占 4 万格勉强能接受但实际上我用了 0.5 米一格覆盖 160 米见方的范围也就是 320×320。为什么不干脆用 1 米因为在 30 米到 60 米这个区间1 米的网格会让相邻两辆并排行驶的摩托车落到同一格里融合后目标边界彻底糊掉。0.5 米是实测下来能分开并排目标和显存能扛的临界点。2.3 点云体素化参数背后的账要算明白激光雷达这一路的参数选择我用的是 pillar 方案而不是完整的 3D 体素核心原因是计算量。算一下如果按 0.075 米的立方体体素覆盖 x∈[-80, 80]、y∈[-80, 80]、z∈[-5, 3] 的空间体素数量是 (160/0.075) × (160/0.075) × (8/0.075) ≈ 2133 × 2133 × 107接近 4.8 亿个格子。就算绝大部分是空的光是索引结构就吃不下。换成 pillar只在水平面离散、高度方向聚合0.4 米一格覆盖 160×160 米得到 400×400 共 16 万个 pillar每个 pillar 最多采样 32 个点。这个规模在显存和时间上都能接受代价是丢失了高度方向的精细结构对于天桥、隧道口、限高杆这类需要区分高度层级的场景会比较吃力。所以我补了一手在 pillar 特征之外额外挂一路高度统计特征就是把每个 pillar 内点云的高度分布压缩成几个分位数比如 5%、50%、95%跟 pillar 特征拼在一起。代价很小但对限高杆、悬空指示牌这类目标的区分度提升明显。这个改动看起来不起眼实测在是否可通行的判断上把误判率降了一大截。注意pillar 内的点采样一定要做随机采样而不是取前 N 个点。点云本身有扫描顺序取前 N 个会让模型学到扫描顺序这个伪特征换一台雷达或者换个安装角度就完全失效。我早期版本就犯过这个错模型在训练集上表现很好换车测试时性能骤降定位了两天才发现是这个原因。2.4 融合时机早融合、中融合、晚融合的实际差异理论上的对比文章很多我只说说实测感受。早融合原始数据层融合在工程上基本不可行因为相机是稠密像素、激光雷达是稀疏点两者的数据组织方式差异太大强行拼在一起精度和效率都不划算。晚融合各自出结果再做后处理融合实现最简单也最容易做模块替换但信息损失严重。举个具体例子激光雷达在远距离对车辆的检测很稳但对行人这类小目标在 60 米外几乎没点相机正好相反远距离能看见人形轮廓但测距不准。晚融合阶段两边各自给一个框融合逻辑只能做加权平均或者置信度投票没法利用相机看到轮廓的位置 雷达测到的地面高度这种跨模态互补信息。中融合特征层融合是我选的方案。具体实现是在 BEV 空间做交叉注意力以图像 BEV 特征为 query点云 BEV 特征为 key/value做一次多头注意力再反过来做一次。这个双向设计是必要的——单向的话强势模态会压制弱势模态。我最初只做了图像查点云结果发现在点云稀疏的雨雾天图像特征的噪声压不住补上反向之后点云的空间结构能对图像特征起到锚定作用。融合层数不能多两层足够。我试过四层指标提升不到 1%时延增加 40%性价比极低。这个结论可能跟具体数据分布有关但我的建议是先把单层融合调透别一上来就堆深度。3. 训练流程与部署落地的完整实操3.1 数据组织采样策略比模型结构更影响结果说句可能得罪人的话在驾驶感知这个领域数据配比比模型结构重要得多。我在这上面花的时间远超调网络。OmniDrive 的训练数据分四个来源城市道路的常规采集、高速长距离采集、园区低速采集、以及大量困难场景的回灌数据。前三个是基础盘第四个决定上限。采样策略上我用的是分层加权采样权重不是拍脑袋定的而是按场景稀缺度 × 任务难度算出来的。具体做法是先跑一遍全量数据统计每个场景标签下的样本数量和当前模型的损失值然后用下面这个公式给每个样本算权重weight (1 / freq[label]) ^ alpha * (loss_i / mean_loss) ^ betafreq[label]是该场景标签的出现频率alpha控制在 0.5 左右取 1 会过度采样稀有场景导致过拟合loss_i是上轮训练的样本损失beta取 0.3 到 0.5作用是让模型多看看还没学会的样本。这套动态加权在训练中期效果很明显尤其是夜间、逆光、雨雪这些场景的指标提升幅度比单纯增加数据量快得多。但它有个副作用训练后期损失曲线会变得很毛因为采样分布一直在变。我的做法是最后 10 个 epoch 关掉动态加权用固定分布做一轮收尾让模型在稳定分布上收敛。注意动态加权一定要设上限单个样本的权重不要超过基准权重的 5 倍否则会出现同一批数据反复喂、模型在这批数据上过拟合、验证集指标反而下降的情况。我吃过这个亏损失曲线看着一路降验证集从第 20 个 epoch 开始就横盘了。3.2 训练配置与显存估算给一份我实际在用的配置骨架参数是按 8 张 80GB 显存训练卡、全局 batch 16 来定的train: epochs: 40 batch_size_per_gpu: 2 grad_accumulate: 1 optimizer: AdamW lr: 2.0e-4 weight_decay: 0.01 warmup_iters: 1000 scheduler: cosine min_lr_ratio: 0.05 clip_grad_norm: 5.0 amp: true ema_decay: 0.999 data: image_size: [704, 256] num_cameras: 6 point_cloud_range: [-80, -80, -5, 80, 80, 3] pillar_size: [0.4, 0.4, 8.0] max_points_per_pillar: 32 max_pillars: 30000 bev_size: [320, 320] bev_resolution: 0.5 loss: cls_weight: 1.0 reg_weight: 2.0 seg_weight: 1.0 occupancy_weight: 1.5 planning_weight: 0.8显存这块我算过单卡 batch 2 的情况下图像骨干占大约 22GB点云骨干 8GB融合层 14GB任务头 6GB加上激活值缓存和优化器状态峰值在 62GB 左右。如果想加 batch最直接的办法是开梯度检查点代价是训练速度慢 25% 左右。训练时长估算假设数据规模 20 万帧全局 batch 16那么一个 epoch 是 12500 次迭代。实测单次迭代约 0.9 秒含数据加载一个 epoch 约 3.1 小时40 个 epoch 约 125 小时也就是五天多。这个时间对于快速迭代来说太长了所以我的做法是先用 1/4 数据跑 15 个 epoch 做结构验证确认结构没问题再上全量。结构验证阶段大概 12 小时出结果能挡掉 80% 的低级错误。3.3 损失函数的权重调试顺序多任务训练的权重不是一起调的必须有顺序否则你根本不知道是哪个任务在拖后腿。我的调试顺序是先单任务跑通再两两组合最后全任务联合。具体来说第一步只开检测损失确认模型能正常收敛BEV 上的目标位置准确。这一步如果都过不了说明数据管线或者标注映射有问题。第二步加分割和占用损失权重从 0.5 开始试。这里最常见的现象是分割损失一加检测的 mAP 掉一两个点——这是因为两个任务对特征的要求有冲突检测要边缘锐利分割要区域平滑。解决办法是给分割头单独加一层轻量适配不要直接共享最后一层特征。第三步加规划损失权重一定要小我从 0.2 开始往上试。规划损失给太大会导致感知特征被带偏——模型会倾向于输出对规划友好但对感知不准确的表征比如把远处的稀疏目标直接抹掉。这个现象我在早期版本里遇到过表现是 BEV 可视化上远处的小目标消失了但规划轨迹看起来很平滑特别有欺骗性。调试阶段开启任务建议初始权重观察指标第一阶段检测1.0各距离段召回率、中心点误差第二阶段检测 分割1.0 / 0.5检测指标是否掉点、分割 IoU第三阶段检测 分割 占用1.0 / 0.5 / 1.0占用栅格的边界准确度第四阶段全任务1.0 / 0.5 / 1.0 / 0.2规划轨迹的平滑度和安全性3.4 量化部署哪些层绝对不能动模型训练完只是开始部署才是真正见功夫的地方。我走的是 INT8 量化路线但不是全模型量化而是分层处理。先说结论骨干网络的前几层和最后几层、以及所有的归一化层必须保留 FP16。原因是前几层处理的是原始像素和点云数值动态范围极大量化损失会很严重最后几层直接决定输出误差会被放大到最终结果上。中间的特征提取层可以安全量化到 INT8。量化掉点的实测数据全模型 INT8 的情况下检测 mAP 掉约 3.5 个点占用栅格的 IoU 掉 4 个点规划轨迹的横向偏差增加 8 厘米。混合精度方案下检测 mAP 只掉 0.8 个点占用 IoU 掉 0.6 个点规划偏差增加不到 2 厘米而时延只比全 INT8 高 12%。这个交换非常划算。校准集的选取也有讲究。不要用训练集里随机抽的样本要用覆盖所有场景类型的小规模代表性集合我一般选 500 到 1000 帧按场景比例分层抽样确保夜间、雨天、隧道、逆光这些极端光照都有覆盖。用纯白天晴天数据校准出来的量化参数到了夜间会掉得很难看。推理时延的实测数据目标平台含前后处理模块FP16 时延混合精度时延备注图像预处理7.2ms7.2ms不支持量化图像骨干26.5ms19.8ms首尾层保留 FP16点云骨干10.4ms7.1ms稀疏卷积量化收益明显融合层11.8ms8.3ms注意力层的 softmax 保留 FP16任务头9.6ms6.4ms检测头输出层保留 FP16后处理5.2ms5.2msCPU 侧未量化合计70.7ms54.0ms满足 100ms 预算这个表是我压了好几轮才达到的。最早版本合计 96ms几乎贴着上限实车一跑就超。主要的优化点有三个把点云体素化从 CPU 挪到并行单元省 6ms、融合层的 query 数量从 2000 降到 900省 4ms、后处理的 NMS 改成并行实现省 3ms。4. 规划器设计感知怎么真正喂给规划4.1 轨迹表示的选择规划输出的表示形式我改过三版。第一版是直接输出未来 3 秒的 30 个离散点间隔 0.1 秒。问题是这 30 个点之间没有运动学约束模型可能输出一条折线看起来每个点都对连起来车根本开不出来。第二版改成输出控制量油门、刹车、转向让模型直接学驾驶行为。问题是控制的频率和数据采集时的控制频率必须严格一致而且不同车型的控制响应特性差异巨大换个车型就得重训泛化性太差。第三版也就是现在用的是输出一条带曲率约束的参数化轨迹给定起点状态位置、朝向、速度、曲率输出一组控制点用三次样条插值成连续轨迹。这样既能保证轨迹的平滑性和运动学可行性又不会绑定具体车型的控制特性。控制层拿到轨迹后自己去做跟踪两边的职责很清晰。这里有个细节控制点的间隔我选的是 0.5 秒一个3 秒一共 7 个点。间隔太密模型容易过拟合到具体的采样时刻间隔太疏轨迹的细节表达不够。0.5 秒是实测下来能表达变道意图和不至于过度参数化的平衡点。4.2 代价函数与安全兜底规划头输出的候选轨迹不止一条我给的是 6 条候选加一个评分头。评分用的代价函数是手工设计的没用纯学习的方式这点我要解释一下原因。纯学习的评分在离线指标上通常更好看但没有下界保证。手工代价函数虽然不够聪明但它能保证撞上障碍物的轨迹代价一定最高这件事是数学上成立的而不是靠模型学出来的。在这个领域可证明的安全下界比指标上的零点几个点重要得多。代价函数的构成大致是这几项加权与障碍物的碰撞风险用占用栅格做距离场、偏离参考线的程度、加速度和加加速度的惩罚、与预测轨迹的交互风险、通行效率奖励。权重是分场景调的低速园区和高速的权重完全是两套。注意安全兜底的逻辑一定要写成独立于模型的规则模块不能依赖模型输出。我见过有团队把紧急制动的判断也放进网络里结果网络在某些极端场景下给出了错误的安全判断。兜底逻辑必须是不管模型说什么只要规则判定有碰撞风险就执行制动。这个优先级不能倒过来。4.3 闭环验证仿真回放比离线指标靠谱离线指标mAP、IoU、ADE只能说明模型学到了东西不能说明车能开。我建了一套回放系统把真实采集的数据按时间顺序喂给完整链路包括感知、预测、规划然后把规划输出和真实的人类驾驶轨迹做对比。对比不是简单的距离误差而是看几个更贴近实际的问题规划轨迹和人类轨迹的终点分布是否一致说明意图判断对不对、横向偏移的时间序列是否平滑说明有没有来回摆动、速度曲线的形态是否合理说明加减速时机对不对。回放系统帮我抓到过一个很隐蔽的问题模型在城市路口右转时倾向于过早开始转向。原因是训练数据里人类驾驶员在这个路口普遍转得比较急模型学到了这个风格。但过早转向会导致车辆切到内侧车道线的位置虽然没有实际碰撞但乘坐体验很差而且不符合通行规则。这个问题在离线指标上完全看不出来因为轨迹的终点误差很小。后来在代价函数里加了转向时机的约束项才把这个行为纠正过来。5. 常见问题与排查技巧实录这一节是我这几年踩坑的浓缩版按现象组织方便你遇到问题时直接对号入座。5.1 训练阶段的高频问题现象可能原因排查手段处理方式损失正常下降但验证集横盘动态采样权重过高导致过拟合检查单样本权重分布看是否集中在少数样本权重上限设为基准的 5 倍最后 10 个 epoch 关闭动态加权检测头正常但规划轨迹抖动感知特征的时序不一致逐帧对比 BEV 特征图的相似度加入时序一致性损失或增加时序融合模块训练中途出现 NaN混合精度下注意力层的 softmax 溢出打开异常检测定位到具体算子注意力计算强制 FP32或加 log-sum-exp 稳定化多卡训练速度不线性数据加载成为瓶颈看 GPU 利用率和数据加载时间占比把解码和增强放到并行进程用共享内存队列分割指标高但占用栅格边界糊分割损失权重过大压制了边界特征可视化两者在目标边缘的响应分割头单独加适配层降低共享程度其中训练中途 NaN这个我遇到过两次都是在小 batch 加混合精度的情况下出现的。表现是训练到几千次迭代突然 loss 变成 nan前面的曲线完全正常。定位方法是打开框架的异常检测开关它会告诉你哪个算子产生了 nan。两次都定位到了注意力层的 softmax输入值过大导致 exp 溢出。解决办法是把 softmax 的计算强制放到 FP32代价是时延增加 1ms 左右完全可以接受。5.2 实车阶段的高频问题标定漂移导致的幽灵障碍物。这个现象特别有迷惑性BEV 上会突然出现一些位置固定、形状模糊的障碍物模型对它们的置信度还不低规划器为了安全就会频繁减速。排查方法是把点云投影到图像上看是否对齐——如果点云的边缘和图像里物体的轮廓错开了就是标定问题。我的经验是车辆每跑 5000 公里左右就应该做一次标定检查尤其是更换过轮胎、做过四轮定位或者有过轻微碰撞之后。时间戳跳变导致的轨迹突变。表现是规划轨迹在某一帧突然横向偏移一大截下一帧又恢复。这个问题的根源往往是某一帧某个传感器的时间戳异常比如丢帧后补了一帧旧数据导致融合时用错了时刻的数据。解决办法是在数据入口加一层时间戳合理性检查如果当前帧的时间戳和上一帧的差值超过正常周期的 1.5 倍就标记为异常帧降级使用单模态结果。量化后的边界效应。量化模型在某些特定距离段比如恰好 45 米左右的检测精度会突然变差。这个问题我排查了很久最后发现是量化参数校准时这个距离段的样本太少导致该区间的激活值范围估计偏了。解决办法是在校准集里按距离分层抽样确保每个距离段都有足够的样本。内存泄漏。长时间跑几个小时之后推理时延缓慢上升最终超时。这个几乎都是资源没释放导致的常见的地方有图像预处理的中间缓冲区没复用、点云的索引结构每次重建、日志缓冲区无限增长。我的做法是跑一个 8 小时的压测每 10 分钟记录一次内存占用和时延画成曲线如果斜率持续为正就说明有问题。5.3 三条不太容易想到的经验第一条永远保留一路简单但可靠的降级链路。我的降级链路是单目相机检测加传统跟踪加上简单的跟车和车道保持逻辑。性能很差但它跑得动、看得见、不会崩。主链路出任何异常超时、输出非法值、置信度异常就切过去。这条链路救过我至少三次实车测试的时候主链路因为一个边缘 case 崩了靠降级链路安全停回路边。第二条指标监控要按场景切片看不能只看总体。总体 mAP 涨了两个点很可能是因为白天场景涨了五个点、夜间掉了一个点。我的做法是维护一份固定的切片清单至少包含白天/夜间/黄昏、晴天/雨天/雪天、城市/高速/园区、远中近三个距离段、大小目标两个尺度。每次训练完自动跑一遍所有切片出一个矩阵报告任何一个切片掉点超过阈值就报警。第三条数据的脏比数据的少更可怕。标注错误、时间戳错乱、标定参数过期这些问题在训练集里占比可能只有百分之一二但它们会系统性地误导模型。我现在的做法是加一道数据质检对每批新数据自动跑一遍一致性检查点云投影和图像对齐、相邻帧的位姿连续性、标注框的尺寸分布是否合理异常的直接进人工复核队列。这个流程会拖慢数据入库速度但比训练完才发现问题再回滚要划算太多。6. 我在这套系统上花的冤枉时间写到这里想聊聊几个当时觉得很难、事后看其实可以绕开的决策。第一个是前期在稠密 BEV 分辨率上抠了太久。我一度执着于把分辨率从 0.5 米做到 0.25 米觉得这是提升小目标检测的关键。折腾了两周显存翻了三倍指标涨了 0.9 个点时延超预算。后来换了个思路保持 0.5 米的稠密网格但把稀疏 query 的分支加强用少量高精度 query 去覆盖小目标效果反而更好时延还降了。这件事让我明白分辨率不是唯一解表征形式的组合往往比单一维度上的暴力提升更有效。第二个是过早追求全场景覆盖。我一开始就想同时把城市、高速、园区都跑通结果是每个场景都只有半成品。后来改成先啃城市道路把数据管线、训练流程、部署链路全部打通形成一个完整闭环然后再逐个扩展到其他场景。第二个场景的接入只花了第一个场景 30% 的时间因为基础设施都现成了。顺序很重要。第三个是低估了评估体系的价值。前半年我基本靠肉眼看 BEV 可视化和轨迹图来判断模型好坏效率极低还容易漏问题。后来花了两周搭自动化评估包括切片指标、回放对比、长尾场景挖掘之后的迭代速度至少快了三倍。如果重来一次我会在写第一行训练代码之前就把评估框架搭好。现在这套 OmniDrive 在我手里已经迭代到第三版最大的感受是驾驶软件栈这件事模型结构的新颖程度远不如工程细节的扎实程度重要。一个平平无奇的结构配上严谨的标定、干净的标注、合理的采样和完整的评估跑出来的结果能甩开一个花哨结构配脏数据一大截。如果你也在做类似的事情我建议先把时间花在数据和评估上模型结构可以慢慢调那部分反而是最容易补的。
