自动驾驶这四个字真正落到日常工作上八成时间花在标定、对齐、回灌、复现、调参这些不上台面的事情上剩下两成才轮到算法创新。这次整理的是我笔记本里攒到第 20 批的条目来源很杂有现场调试时蹲在车边临时记的有半夜被报警叫起来排查完补的也有评审会上被问住、回去翻资料才想明白的。之所以把20留在标题里是因为这批条目有个共同点——每一条都对应过一个真实卡住进度的问题而不是我们应该重视某某这种空话。下面按环节拆开讲融合的时间同步、标定与漂移、数据回灌与仿真、规控调参、长尾场景挖掘、车端部署能直接抄的参数我给到具体数值需要按自己平台调整的地方我会说清楚为什么这么取。先说清楚适合谁看。刚入行、正在搭第一套数据链路的同学可以把第 2、4 章当施工图照着做已经能把车开起来、但被偶发异常折磨的同行重点看第 3、6、8 章做部署落地的第 7 章的延迟拆账方法应该能省你不少扯皮时间。所有数值都是经验量级不是标准答案你们平台的传感器型号、车体尺寸、域控算力一变参数就得跟着动这个前提请务必记住。1. 为什么把第20批经验单独拎出来成篇1.1 入选标准必须能对应一个具体的卡点我把笔记里的条目按复现成本排了个序越靠前的越值得写。所谓复现成本指的是别人照着你写的做法需要多少额外条件才能重现这个问题。需要特定场地、特定天气、特定车型才能复现的我基本只留一句话提示而那些在任意一台测试车上、用一段普通数据包就能重现的我写到了可以直接操作的程度。这个筛选标准带来的一个副作用是很多高级内容反而被砍掉了。比如端到端模型的结构设计、大模型上车的话题写出来好看但读者照着做不了也没有明确的验证路径最后只会变成互相复读。我更愿意写相机和激光雷达的时间戳差了 8 毫秒怎么用数据证明这 8 毫秒确实存在以及怎么把它压到 1 毫秒以内这种东西枯燥但谁用谁知道。还有一类条目被我刻意保留了就是那种看起来是算法问题、实际是工程问题的坑。这类坑最耗人因为方向一开始就错了越努力偏得越远。第 8 章会集中讲几个。1.2 六个环节的依赖顺序别跳着做新手最容易犯的错是拿到一套数据就开始调检测模型结果发现框在图像上抖得厉害折腾两周才发现是时间同步没做对。所以我按依赖关系给这六个环节排了序你可以理解为一条装配线顺序环节出问题时的典型症状修复代价1时间同步高速运动目标框飘、融合后目标重影低改配置即可2标定与漂移远处目标投影偏移、车道线对不齐中需要场地和工具3数据回灌同一段数据跑两次结果不一样中涉及平台改造4规控调参车能开但乘客晕、频繁小幅修正低纯参数5长尾挖掘评测分数虚高、路上频繁接管高涉及数据生产6车端部署离线效果好在车上打折高涉及模型改造这个顺序的意思是前一项没稳定后一项的所有指标都不可信。第 3 项尤其容易被忽略很多团队在回灌平台上看到的指标和实车对不上根因就是回放不确定这个坑我在第 4 章详细拆。提醒一句如果你的团队现在连同一段数据回放两次输出逐比特一致都做不到那么后面所有的 A/B 对比、所有调参收益的结论都要打个问号。2. 多传感器时间同步几毫秒错位如何在融合层被放大2.1 时间戳的三种来源别混着用先说个基础但经常被搞混的事一个传感器数据包上的时间戳至少有三种可能来源含义完全不同。第一种是传感器硬件自己打的比如相机在曝光中点触发的信号、激光雷达在一帧起始角度触发的信号这个最接近物理世界发生的时刻。第二种是主机收到数据时由驱动或内核打的接收时间戳它包含了传输、缓冲、中断处理的所有延迟。第三种是中间件转发时打的又叠加了一层队列等待。三种时间戳混用是融合层错位的高发区。典型场景相机用接收时间戳激光雷达用硬件时间戳两者之间差了一个不固定的传输延迟短的时候两三毫秒网络拥塞时能到十几毫秒而且这个延迟还随负载波动你在标定阶段测出来的固定偏移量根本对不上。正确的做法是全链路统一到同一个时钟源上各传感器尽量都用硬件时刻接收时间戳只用来监控链路健康度不参与融合计算。再补一个容易被忽略的细节相机的帧时间戳到底代表哪一刻。卷帘快门的传感器是逐行曝光的第一行和最后一行可能差十几毫秒如果只给一个帧级时间戳高速运动物体在图像里是斜的你在畸变校正和运动补偿时就需要知道每一行的曝光时刻。工程上的常见做法是把帧时间戳定义为中间行的曝光中点然后用行偏移量补偿这个约定必须写进接口文档否则换个人接手就会按第一行曝光时刻去理解全盘错位。2.2 把误差压到毫秒以下硬件触发与网络对时的组合拳讲具体做法。误差预算是这样算的车速 20 米每秒约 72 公里每小时时间偏差 10 毫秒对应空间位移 0.2 米。对于近距离切入的目标0.2 米的横向偏移足以让检测框和点云团对不上融合关联的阈值就得放宽放宽之后误关联又变多。所以我的经验目标是相机与激光雷达之间的对齐误差控制在 1 毫秒以内IMU 与它们之间控制在 0.5 毫秒以内。达到这个量级纯软件方案基本没戏必须上硬件。常见的组合是一台支持高精度对时的交换机作为主时钟各传感器和计算单元作为从时钟走网络对时协议同时用秒脉冲信号给相机和激光雷达做硬件触发。相机由同一个触发源驱动曝光时刻就是触发时刻加上固定延迟这个固定延迟可以标定出来。激光雷达如果支持外部触发也接到同一路信号上不支持的话那就依赖它内部的时钟与主时钟对齐这时要关注它是否会周期性重置计数器。网络对时的实现细节上有个坑值得说很多交换机的对时功能默认关闭或者只在特定端口开启。我见过一个项目配置都写对了但交换机上联口没开对时导致所有跨交换机的时间戳都偏了几毫秒排查了两天才发现是端口配置问题。建议在系统启动时加一个自检脚本把所有设备的时间戳读出来做两两比对偏差超过阈值就报警不要等到融合效果变差才反推。2.3 一套能落地的同步验证方法不用专业设备说完原理说验证。手里没有高精度时间分析仪也不要紧有两个土办法够用。第一个是静态重投影法车停着前方摆几根竖直的杆状物或者角反射器把激光雷达点云按外参投影到图像上看边缘是否对齐。这个方法只能验证外参验证不了时间偏移因为车没动。所以要做第二个动态扫描法。让车以恒定速度直线行驶对着静止的杆状物采集一段数据然后人为给点云加一个时间偏移 Δt从 -20 毫秒扫到 20 毫秒每扫一个值就做一次重投影计算点云边缘与图像边缘的吻合度取吻合度最高的那个 Δt 就是当前的时间偏差。这个方法我在三个不同平台上用过测出来的偏差和硬件方案的理论值基本吻合误差在 0.5 毫秒量级。实际执行时注意两点杆状物要选细的、边缘清晰的粗柱子对精度不敏感车速不要太快也不要太慢10 到 15 米每秒比较合适太快了运动模糊会糊掉边缘太慢了偏移量本身太小扫描曲线太平缓找不到峰值。做完把 Δt 补进配置隔一段时间复测一次看看它是否随时间漂移——如果漂移明显那就不是时间同步的问题了多半是硬件时钟本身的稳定性有问题。3. 标定这活儿出厂一次不等于路上一直准3.1 内参、外参、时间延迟三类标定别混在一起做这三个东西经常被笼统地叫标定但它们的物理含义、误差特性、复标周期完全不同混在一起做只会互相污染。内参描述的是相机自身的成像几何焦距、主点位置、畸变系数。它跟安装位置无关装车前后测出来应该基本一致除非镜头被撞过或者对焦机构动过。评价指标是重投影误差用棋盘格或者圆点靶标采二十组以上不同姿态误差做到 0.3 像素以内算合格超过 0.5 像素就要检查靶标平整度和拍摄距离。有个细节靶标不要只在一个距离上采近中远都要有否则焦距和畸变系数会耦合你在近处标得准远处就偏。外参描述的是各传感器之间的相对位姿。评价指标是点云投影到图像后的边缘吻合度或者用地面平面拟合的一致性。外参的复标周期跟安装刚度强相关刚性好的支架能撑很久柔性支架可能几百公里就要复检。时间延迟是第三类经常被漏掉。它描述的是两个传感器数据在时间轴上的固定偏移前面第 2 章讲的扫描法测的就是它。三类一起做的时候正确顺序是先内参、再时间延迟、最后外参因为时间延迟没对齐时外参标定用的动态数据会带入额外误差。3.2 外参漂移的诱因以及怎么在线监测外参漂移是实车部署里最烦人的问题之一因为它表现为模型效果慢慢变差而不是突然坏掉很容易被误判成模型老化。我见过的诱因有这几类温度循环导致支架和车体热膨胀不一致路面冲击和长期振动导致紧固件微松动装配应力缓慢释放轻微剐蹭。前两类最常见第三类最隐蔽。在线监测的思路是找一个稳定的约束源持续计算残差并跟踪它的趋势。常用的约束有三种地面平面约束用点云拟合地面与标定时的地面参数比对能捕捉俯仰和滚转漂移。杆状物或车道线约束图像中提取车道线与点云或地图投影比对能捕捉偏航和横向平移。静止目标一致性停车等红灯时对同一批静态目标做前后帧一致性检查。工程上的做法是自动采集这些残差按里程或时间窗口统计均值画一条趋势曲线。均值绝对值不重要重要的是变化率——如果残差在几百公里内单调上升就说明外参在漂该安排复标了。我给的经验阈值是重投影残差均值比基线上升超过 30%或者连续三个统计窗口单调上升就触发复标提醒。3.3 复标策略与标定场布置的几个细节复标策略按触发条件分三类按里程或时间定期复标比如每五千公里或者每三个月按残差阈值触发按事件触发比如更换传感器、拆装支架、发生过碰撞。三类并行最稳妥单独用任何一类都会漏。标定场的布置有几个实测出来的细节值得说。第一场地地面要平但不要求绝对水平要求的是标定时的地面参数被记录下来后续在线监测用的就是这个基准地面本身有点坡度不影响。第二靶标布置要覆盖整个视场尤其是图像四角四角的畸变最大也最容易被漏标。第三靶标距离要分层相机和激光雷达的共同有效区域通常有限近处目标用于标定外参的平移分量远处目标用于标定角度分量两者缺一不可。还有一个省事的做法把标定流程做成可回放的脚本采集数据、自动检测靶标、求解、输出残差报告全流程不依赖人的经验判断。这样做的价值不在于省时间而在于把标定质量变成一个可量化的数字谁做的、什么时候做的、残差多少一目了然。我待过的一个项目就是因为标定流程全靠老师傅手工做老师傅一休假没人能复现他的操作出问题只能干等。4. 数据回灌与仿真闭环让跑过的路可以反复跑4.1 录包、切片与索引回灌平台的三块地基数据回灌的价值在于让路上跑过的每一段路都变成可反复使用的测试用例。这件事看起来简单——把包录下来再播一遍不就行了——实际做起来光是录这一步就有很多讲究。录制策略上我的原则是原始数据优先能录原始就不录压缩后的。相机如果必须压缩选择帧内压缩或者低延迟的编码配置避免帧间依赖导致随机访问困难。数据量级心里要有数八路 1080p、30 帧每秒的相机低码率压缩后每路约 8 兆比特每秒八路合计约每秒 8 兆字节一小时接近 30 吉字节激光雷达单帧点云几兆字节10 赫兹就是每秒几十兆字节一小时上百吉字节。所以车上存储的写入带宽是硬约束必须提前算账否则就是录一半丢一半。切片和索引是第二块地基。原始包动不动几百吉字节检索起来非常痛苦所以要按事件切成短片段同时建立元数据索引时间、位置、车速、触发类型、目标数量、是否接管、天气标签。索引的价值在半年后体现——当你要找雨天、傍晚、有电动车横穿的片段时有索引就是几秒钟的事没索引就是翻几十个包。一个踩过的坑切片时用绝对时间做主键换了车、换了时钟源之后时间轴不连续导致不同车的数据没法拼在一起训练。后来改成采集批次号 相对时间的复合主键才解决。4.2 确定性回放为什么难怎么做到同输入同输出回灌平台最常见也最致命的问题是同一段包回放两次结果不一样。这时候你做的任何调参对比都不可信因为你分不清差异是来自参数还是来自随机性。不确定性的来源我总结成四类。第一类是时钟回放时如果用真实系统时钟各模块的调度顺序每次都不同改成仿真时钟、所有模块订阅同一个时钟源能解决大半。第二类是并发多线程队列满了就丢、部分算子是异步的解决办法是给关键链路加确定性队列满队列时阻塞而不是丢弃。第三类是随机数初始化里的随机采样、噪声注入要把种子固定下来。第四类是 GPU 上的非确定性算子某些并行归约操作的累加顺序不固定浮点结果会有微小差异这个最麻烦只能通过输出比对定位到具体算子然后换实现或者接受容差。验证确定性有个简单办法同一段包连跑三次把所有中间输出检测框、跟踪结果、规划轨迹存下来做逐字段比对。如果只有浮点末位差异可以设容差如果差异会传导到决策层比如某个目标一会儿被关联一会儿不被关联必须修不能忍。4.3 场景库分层实车回放、软件在环、硬件在环各管一段场景库别做成一个大杂烩按真实度分层更实用。最底层是实车回放输入是真实的传感器数据真实度最高但只能测已经发生过的情况。中间层是软件在环把感知和规控跑在仿真环境里场景可以泛化比如把一段真实的切入场景参数化变换相对速度、距离、切入角度生成上百个变体。最上层是硬件在环把真实的域控接进来测的是算力、时序和接口不测算法。分层的意义在于成本。实车回放几乎零边际成本但覆盖不了没发生过的情况软件在环能泛化但仿真器里的传感器模型永远和真实有差距硬件在环最贵只用来做上线前的冒烟测试。我的经验配比是日常回归九成用实车回放一成用软件在环版本上线前加一轮硬件在环。5. 横向纵向控制调参从能跟住到坐得舒服5.1 横向跟踪三个方案的实际差异横向控制的主流方案就三个我都实际调过说说各自的手感。纯跟踪法的逻辑是找一个前视点让车沿圆弧追过去参数只有一个前视距离。它的优点是鲁棒、不会震荡缺点是弯道内侧切得厉害前视距离调大一点就切得更多调小一点又容易在直道上画龙。工程上的做法是把前视距离做成速度的函数低速小、高速大常见的经验式是前视距离等于基础值加系数乘以车速基础值取 3 到 5 米系数取 0.2 到 0.4 秒。Stanley 方法用前轴到参考路径的横向误差加航向误差优点是直道上贴线很准缺点是低速时对航向误差过于敏感容易抖。调参的关键是给航向项加一个软化系数避免误差接近零时增益发散。LQR 和模型预测控制的思路是优化能同时兼顾跟踪精度和平顺性代价是参数多、调起来慢。我的建议是如果只是做园区低速或者简单的车道保持纯跟踪足够如果要做高速变道、曲率连续变化的匝道上 LQR 或模型预测控制多花的调试时间能换回明显的乘坐体验。5.2 纵向的舒适性红线乘客感知的是 jerk纵向控制里减速度的绝对值不是最关键的最关键的是减速度的变化率也就是 jerk。人对恒定减速度的耐受度其实不错但对顿一下极其敏感。经验阈值是这样的日常跟车和舒适制动纵向 jerk 控制在 2 米每三次方秒以内做到 1 以内就相当平顺紧急制动可以放开到 5 以上但要注意触发条件必须明确不能因为一个误检就一脚重刹。横向也一样横向加速度的舒适阈值大约 1.5 米每二次方秒超过 2.5 就开始有人抱怨横向 jerk 控制在 0.5 米每三次方秒以内比较好。这些数字不是拍脑袋是大量乘坐评价实验收敛出来的量级不同车型、不同悬架会有偏移但量级不会差太多。调参的实操顺序建议是先调纵向把速度跟踪做平再调横向。因为纵向的抖动会耦合到横向你横着调半天根因可能是纵向在抽。具体做法是固定横向参数让车在直道上做加速、匀速、减速的循环看速度曲线的超调和 jerk 曲线把纵向调平之后再进弯道。5.3 一份可以直接抄的起步参数表下面这张表是我常用的起步值意思是从这里开始试不是最终值。车重、轴距、执行器响应速度一变都得重新扫。参数低速场景30 km/h中速30-60高速60纯跟踪前视基础值3 m5 m8 m前视速度系数0.25 s0.3 s0.4 s横向加速度上限1.0 m/s²1.5 m/s²1.5 m/s²横向 jerk 上限0.4 m/s³0.5 m/s³0.5 m/s³跟车时距1.2 s1.5 s1.8 s舒适减速度1.5 m/s²2.0 m/s²2.5 m/s²纵向 jerk 上限1.5 m/s³2.0 m/s³2.0 m/s³用法是先按车速区间取表值跑一段看实际曲线有没有超调或者滞后。执行器响应慢的平台比如商用车的气压制动所有减速度参数要往下压三成jerk 上限也要放宽因为物理上做不到那么细的控制。反过来小型电动车响应快可以调得激进一点。6. 长尾场景挖掘在海量数据里捞出那千分之几6.1 规则触发器仍然是最划算的第一层筛子一说长尾挖掘很多人直接想到用模型找异常。我的经验是别急着上模型规则触发器能解决七成问题而且成本低、可解释、好维护。常用的触发器有这么几类。第一类是行为触发紧急制动触发、人工接管、方向盘转角突变、加速度超阈值。这类最直接几乎不用调。第二类是目标触发目标数量突变、近距离切入、跟踪 ID 频繁切换、目标从出现到消失的时间极短。第三类是模型触发检测置信度骤降、多帧结果不一致、跟踪预测残差突然变大。第四类是环境触发雨刷开启、大灯开启、光照传感器突变。触发器的组合比单个更有效。比如近距离切入 置信度骤降这个组合捞出来的基本都是遮挡或者截断的困难样本比单独用任何一个精准得多。我一般会维护一张触发器组合表按历史捞出的有效率排序定期淘汰低效的。有个反直觉的经验不要追求触发器的召回率。触发器的任务是缩小候选集把它从几万段缩到几百段就够了剩下的交给人工和模型排序。追求召回只会让候选集膨胀最后还是要人看等于白做。6.2 用模型不确定性做第二层排序规则筛完之后候选集还有几百上千段人工看不过来这时候用模型打分排序。可用的信号有几类检测头的分类熵、多个模型的预测分歧度、时序一致性残差、特征空间里的新颖度。新颖度这个思路值得展开说。把每帧的感知特征聚合成一个向量对全量数据做降维和聚类那些落在稀疏区域的样本就是没见过的情况。具体实现上可以算每个样本到最近邻的距离距离大的排前面。这个方法的好处是不需要标注纯无监督对从未见过的场景类型特别敏感缺点是对见过但很难的样本不敏感。所以它要和置信度类信号配合用一个管新、一个管难。排序完之后不要直接送去标注先做一轮快速人工过筛每段只看前几秒判断这段有没有价值。这个过筛环节效率很高熟练的标注员一小时能过几百段比直接标注省得多。6.3 标注预算怎么分才不浪费标注预算是有限的分配策略直接决定模型提升的天花板。我见过的典型浪费是把八成预算花在常见但模型已经做得不错的场景上因为这些场景数据好找、标起来也顺手团队有成就感。结果模型在常见场景上从 95 分提到 96 分长尾上原地踏步。更合理的分配是按边际收益来。先做一次错误分析把当前模型的问题按类型归类统计每类错误的出现频次和严重程度算出修好这一类能带来多少收益。然后按收益除以标注成本排序优先标性价比高的。经验上长尾场景的标注成本是常规场景的三到五倍因为目标小、遮挡多、需要多帧上下文判断所以只有当收益明显更高时才值得投入。还有一点标注规范要针对长尾场景细化。常规场景的标注规范往往对遮挡、截断、极小目标的处理很模糊长尾数据里全是这些情况规范不细化标出来的质量参差不齐训练时反而引入噪声。7. 车端部署的算力账延迟预算要拆到每个环节7.1 把端到端延迟拆成可归因的几段我们的延迟是 100 毫秒这种说法没有意义因为没人知道该从哪优化。有用的做法是拆账拆到每一段都能归因、都能单独测。我常用的拆法是这样的从物理事件发生到执行器动作分成曝光与采集、传输与解包、预处理、推理、后处理、融合与跟踪、规划、控制、执行器响应九段。每一段都打上时间戳跑一段真实数据统计每段的耗时分布不只看均值要看 95 分位和最大值。拆完之后你会发现瓶颈经常不在你以为的地方——我遇到过推理只占 15 毫秒但前处理里的图像缩放加色彩转换占了 25 毫秒的情况优化前处理比换模型收益大得多。还有一个隐藏的延迟来源是排队。多路相机同时到达时如果处理是串行的第三路和第四路的等待时间会显著拉长。这种延迟在平均值上看不出来但在最坏情况下很明显。解决办法是流水线化或者并行化但要注意并行化会带来资源竞争得配合限流。7.2 量化的收益与精度回退的止损线模型量化是部署阶段最常用的一招收益也确实明显常见能拿到两到三倍的速度提升。但量化的坑在于精度回退不是均匀分布的往往在特定类别、特定尺度上突然掉一大截而总体指标看起来只掉了一点点。我的做法是分层看指标不能只看总体均值。具体是按目标尺寸分桶小、中、大、按距离分桶、按类别分桶、按光照条件分桶每一桶都对比量化前后。只要有任何一桶掉了超过设定的止损线就要回头查。止损线怎么定我的经验是关键类别行人、骑行者、近距离车辆单桶召回率下降不超过 1 个百分点其他类别不超过 2 个百分点。超了就不接受宁可少提点速度。技术上减少回退的手段有校准集要覆盖真实数据分布别用训练集的子集凑数对敏感层保留高精度通常是第一层和最后一层以及检测头逐层做敏感度分析找出掉点最狠的层单独处理。这些操作加起来通常能把回退压到可接受范围内。7.3 功耗和散热的现实约束算力账算完还要算功耗账。车端的域控通常是密封的、被动散热的功耗上去温度就上去温度上去就降频降频之后延迟又不稳定。这个链条在实验室里体现不出来夏天实车跑两小时就原形毕露。经验做法是设计阶段就按最坏工况估功耗把峰值算力需求打七折使用留出的余量就是散热余量。同时监控温度并做降频策略温度到阈值时优先降非关键任务比如日志上传、离线建图保住感知和规划。另外模型推理的功耗不是线性的批大小从 1 加到 4功耗可能翻倍但吞吐提升有限实时场景下批大小为 1 往往是最优的。8. 几条写不进正式文档的杂项经验8.1 评测集必须冻住否则调参就是在骗自己这条我放在最前面说因为它影响最大。很多团队在调参过程中会不自觉地用评测集的结果去反向指导参数选择一轮两轮看不出来十轮之后模型就对这个评测集过拟合了指标一路涨实车表现没变化。正确做法是把评测集分成两部分一部分是开发集调参时可以随便看另一部分测试集锁起来只在上线前跑跑完记录结果不许回头改参数。测试集规模不用太大但要保证场景覆盖均衡且不能和训练数据有同源重复同一段路的不同时段也算同源会高估。我见过更严格的做法是保留一个完全没参与过任何环节的第三集合一年只在年度评审时跑一次作为最终裁决。8.2 出问题时先查数据链路再查算法最后一个经验也是我这些年最省时间的习惯任何异常先怀疑数据链路再怀疑算法。具体的检查顺序是时间戳有没有跳变或者倒退话题有没有丢帧丢帧位置是否和异常时间吻合坐标变换树是否完整有没有某个节点断开导致回退到默认值标定文件版本是否和当前配置一致传感器是否在异常时刻报了内部错误但被日志淹没了。这一套查下来通常十分钟能解决一半以上的玄学问题。我印象最深的一次是跟踪 ID 频繁跳变算法同事研究了三天关联逻辑最后发现是点云里混入了一帧时间戳错误的旧数据导致目标位置突然跳了一下关联自然就断了。从那以后我在每个处理节点的入口都加了一条断言输入时间戳必须单调递增违反就打日志并丢弃该帧。加上这条之后同类问题的定位时间从几天缩短到几分钟。这类防御性检查加起来不过几十行代码收益却很高。我的建议是每修完一个由数据链路导致的问题就把它变成一条断言慢慢积累你的系统会越来越自解释。