1. 先把“合集”当成一个系统来看20期内容为什么不能简单堆在一起做自动驾驶合集做到第20期最直观的感受是单篇讲一个模块读者看得懂把20篇摞在一起反而没人看得懂。原因不复杂前19期大多是“点状突破”——这一期聊激光雷达点云怎么滤波下一期聊卡尔曼滤波怎么调Q和R再下一期聊仿真场景怎么造。每一篇单独看都有用但拼不成一条完整的链路。所以第20期合集真正要解决的不是“再讲一个新知识点”而是把散落的东西按一条真实的数据流重新串起来。这也是我做这个自动驾驶合集20时最先定下的原则按数据在车端和云端怎么流动来组织而不是按教科书里的感知、决策、控制三大块来组织。这个合集适合谁看我的判断是三类人。第一类是刚进这个方向、能看懂论文但没跑通过完整链路的同学合集能帮你把“论文里的模块”和“车上跑的进程”对上号。第二类是做单一模块做久了、想往系统层走的人比如一直做检测模型训练想知道自己的模型输出到下游规划手里会发生什么。第三类是带小团队的技术负责人需要一份可以拿去对齐讨论的清单看看自己项目里哪些环节其实一直是个黑盒。不适合谁指望靠一篇文章学会写自动驾驶全栈的人这里没有那种东西任何一个环节单独拎出来都够写一本书。“合集”这个词还有一层隐含意思它是可以反复翻的。所以我在组织内容时尽量让每一节都能独立成立同时又在关键处留了交叉引用——讲标定的地方会提示你去看时间同步那一节讲规划抖动的地方会把你引回控制周期。这种写法看起来啰嗦但实际用起来省事出了问题时你不需要从头读直接跳到对应小节就能对上号。另外要提前说清楚一点下面涉及的所有具体数值、参数、代码片段都是我在模拟项目和几个小规模验证环境里跑过的常见配置不代表任何特定量产方案。不同传感器、不同算力平台、不同车型参数一定要重算直接抄数字是最容易翻车的行为。2. 整体设计与思路拆解一条链路、两个闭环、三层工具2.1 为什么按“数据流”组织而不是按“模块”组织按模块组织最省事感知一章、预测一章、规划一章、控制一章写完收工。但真到了车上出问题故障从来不按模块出现。我印象很深的一次排查车辆在某个路口反复出现轻微画龙一开始所有人都在看控制参数查了两天没结果最后发现是感知输出的目标航向角在低速时有约1.5度的系统性偏差规划拿这个航向去拟合曲线控制再跟着追抖动被放大了一倍。这种问题只有在数据流视角下才能看见——你得知道一个数字从哪个进程产生、经过几次坐标变换、在哪个节点被平滑过。所以合集的骨架是这条链路传感器原始数据 → 时间同步与运动补偿 → 标定与外参校验 → 感知检测/分割/占用→ 目标跟踪与状态估计 → 预测轨迹/意图→ 规划路径速度→ 控制转向/驱动/制动→ 执行器反馈以及挂在旁边的两条闭环车端实时闭环和云端数据闭环。车端闭环要求确定性一切以“这一帧必须在100毫秒内算完”为约束云端闭环追求覆盖度关心的是“这一个月采集的数据里有多少种长尾场景被真正喂进了训练集”。这两条闭环的节奏、工具、评价标准完全不同混在一起谈必然乱。2.2 20期内容的分层哪些是“必须自己做”哪些可以“买改”合集里我反复强调一个分层思路按“是否构成差异化”来切层级内容建议策略理由基础层中间件通信、时间同步、日志回放、标定工具优先用成熟开源方案少造轮子这些做不出差异化但做不好会拖垮整条链路感知层检测、分割、占用栅格、跟踪自研为主开源模型做基线直接决定安全边界且与自家传感器布置强绑定预测层轨迹预测、交互建模自研大量数据验证场景强相关通用模型落地效果普遍打折规划控制路径优化、速度规划、跟踪控制自研规则与优化混合直接关联乘坐体感和安全兜底工具链数据标注、仿真、回放、评测能买则买自研只做胶水层投入大、迭代慢容易变成无底洞这张表的价值不在于结论多新鲜而在于它逼着团队回答一个问题我们的钱和人到底该压在哪儿。我见过的小团队最常见的失误是工具链自研上瘾——花半年做了一个标注平台功能还不如现成的等想追感知进度时人已经散了。反过来也有另一种失误感知全靠外部方案等到要针对自己的传感器布置做优化时发现连中间特征都拿不到。2.3 方案选型从“堆传感器”到“重感知、轻地图”的取舍逻辑这几年最明显的变化是地图依赖在下降。早期方案高度依赖高精地图提供先验车道线好处是规划省事坏处是地图更新成本高、覆盖范围受限一旦进入未采集区域就退化。转向“重感知”之后车道线、路口拓扑、可行驶区域都从传感器实时推断地图退化成一层薄薄的先验大致走向、路口存在性。这个转向不是审美选择是成本账。高精地图的单公里采集与维护成本在城区规模铺开时是数量级问题而感知侧靠数据闭环迭代边际成本是递减的。但它带来的代价也很实在感知一旦出错没有任何兜底。以前地图能告诉你“这里应该是三车道”现在只能靠模型自己判断。所以采用轻地图方案时我在合集里一直强调两件事必须同步做一是感知的不确定性输出要显式建模不要只给一个类别和置信度就完事二是规划必须能接受“拓扑不确定”这种输入而不是假设输入永远干净。3. 核心细节解析五个最容易被低估的环节3.1 时间同步所有诡异问题的第一嫌疑人如果让我给刚入行的人一句忠告那就是车上出现无法解释的行为先查时间戳再查别的。多传感器融合的本质是“把同一时刻的不同观测对齐”一旦时间戳有偏差融合结果就是错的而且错得很隐蔽——它不会报错只会让跟踪目标的位置轻微跳动让规划以为前车在犹豫。常见的时间源有三种精度档次软件打时间戳毫秒到十几毫秒抖动够用但别指望精确、网络时间同步协议局域网内可以做到亚毫秒到毫秒级、硬件触发同步传感器曝光时刻由同一路信号触发误差在微秒级。做融合尤其是相机和激光雷达融合我建议至少做到硬件触发或严格的事件对齐否则后面所有运动补偿都在给时间误差打工。判断同步做得好不好有个很土但有效的办法让车以固定速度直线行驶正前方放一块垂直于地面的标定板同时录相机和点云。把点云投影到图像上如果边缘出现与速度成正比的错位基本就是时间不同步或外参有问题。速度越快错位越明显这个特征很好辨认。3.2 标定与外参校验一次标定管不了一辈子外参标定不是“出厂做一次”的事。悬挂高度变化、碰撞、温度导致的支架微变形、甚至换胎都会让外参漂移。漂移量可能只有0.2度但投射到50米外就是17厘米的横向误差足以让融合把两个目标判成一个。我的做法是分三层静态标定在受控场地用标定板或标定场做得到基准外参。在线校验每一帧用可行驶地面的平面拟合、车道线重合度、静态目标的重投影残差做健康度打分超过阈值就报警降级。定期复标按里程或时间周期强制复标哪怕健康度看起来没问题。在线校验里最实用的是重投影残差把点云里稳定存在的静态结构杆子、墙面、地面边缘投影到图像上算边缘距离的统计量。正常状态下残差中位数应该很小且稳定一旦漂移中位数会缓慢爬升。这个指标不需要额外硬件纯软件就能算性价比极高。3.3 从2D检测到BEV再到占用栅格每一层的动机早期做2D检测图像上框得很准但要落到自车坐标系就得靠逆投影深度信息全靠猜误差大。BEV鸟瞰图的思路是把多视角图像特征统一变换到一个俯视平面在这个平面上做检测和分割输出天然就是自车坐标系下的位置。这一步解决了“相机看到的东西怎么变成车能用的坐标”这个根本问题。BEV的分辨率选择是个实打实的取舍。取0.5米每像素、覆盖前后左右各50米特征图就是200×200如果取0.25米每像素同样范围就是400×400显存和算力直接翻四倍。城区低速场景0.25米有意义高速场景0.5米足够。我自己在模拟项目里常用的配置是城区0.2~0.25米高速0.4~0.5米按ODD切换两套模型而不是硬撑一套。BEV再往上就是占用栅格Occupancy。BEV本质还是“在地面上铺一层”对悬空物体、异形障碍物、施工围挡这类不在地面平面上的东西无能为力。占用把空间切成体素每个体素判断是否被占据。体素分辨率0.2米、范围前后各40米、左右各40米、高度从-3米到5米算下来是400×400×40六百多万个体素直接做稠密预测不现实所以工程上普遍用稀疏表示或者先降高度维度再恢复。3.4 预测模块别把它当成一个“轨迹回归”问题新手最容易把预测理解成“输入历史轨迹输出未来轨迹”然后拿一个序列模型去拟合。这么做的结果通常是在简单场景跟车、直行看着还行一进路口就崩。原因是路口的行为主要不是由自身历史决定的而是由交互决定的对向车让不让、旁边车加不加塞、行人有没有启动意图。所以我更推荐把预测拆成三块意图分类直行/左转/右转/变道/掉头、轨迹生成每个意图下生成若干候选、概率打分结合交互和规则约束给每条候选打分。这样拆的好处是可解释、可调试——出问题时你能明确知道是意图判错了还是轨迹形状不对。端到端直接出轨迹的方案当然也有但调起来像开盲盒。3.5 规划与控制规则兜底与优化求解的分工规划这一层我的经验是不要追求纯优化。纯优化在约束完备时很优雅但真实场景里总有一些没法写成光滑约束的东西比如“这个路口不能停在斑马线上”。所以实际方案通常是分层先有一个基于规则的决策层走/停/让/绕再由优化层在决策给出的可行域里求解平滑轨迹。规则层负责正确性优化层负责舒适性。控制侧最常见的组合是前馈加反馈转向用纯跟踪或Stanley做前馈叠加PID做反馈纵向用MPC做速度跟踪因为MPC能显式处理加速度约束和舒适性惩罚。这里有个容易忽略的点控制周期必须和规划周期匹配。如果规划10Hz出轨迹控制却是50Hz那控制在这50毫秒里跟踪的是一条“上一帧的、已经稍微过期”的轨迹高速时会产生滞后。常见做法是规划给出一条带时间参数化的轨迹控制按当前时刻做插值而不是死盯轨迹点。4. 实操过程从数据采集到闭环跑通的关键步骤4.1 数据采集与标注闭环先想清楚“要什么”再决定“采什么”数据闭环最容易犯的错是“先采了再说”。车跑了几百公里盘里堆了几十TB回头一看全是直道跟车真正需要的学习场景一个没有。我的建议是先把触发规则写清楚再出去跑。触发规则可以很朴素感知置信度低于阈值的帧前后各截取若干秒规划出现急刹、急打方向、人工接管的片段与历史轨迹偏离超过阈值的场景按场景标签做配额采样比如路口、施工、夜间、雨天各占一定比例标注环节要区分“训练标注”和“评测标注”。训练标注追求量大评测标注追求准两套人马、两套流程千万不要混用。我在模拟项目里见过最坑的情况是评测集里的标注是从训练集复用的模型在评测集上分数漂亮得不像话一上实车全线崩盘。4.2 一个最小可跑通的闭环先仿真再实车在新环境里我一般先搭一个最小闭环只有三个进程一个假数据源按固定频率吐目标一个规划进程吃目标吐轨迹一个控制进程吃轨迹吐控制量控制量回灌给一个极简的车辆运动学模型再生成下一帧状态。链路跑通、频率对得上、延迟可测再往里换真模块。下面这段是车辆运动学模型的简化实现用来在仿真里闭环。参数都是常见量级直接能跑import math class KinematicBicycle: 简化运动学自行车模型用于闭环验证不追求精度 def __init__(self, wheelbase2.7): self.L wheelbase # 轴距单位米 self.x 0.0 self.y 0.0 self.yaw 0.0 self.v 0.0 def step(self, accel, steer, dt): # 加速度限幅避免仿真里出现物理上不可能的跳变 accel max(-4.0, min(2.0, accel)) # 低速时限制转角变化率模拟转向执行器响应 max_steer math.radians(35) steer max(-max_steer, min(max_steer, steer)) self.v max(0.0, self.v accel * dt) # 自行车模型yaw_rate v * tan(steer) / L yaw_rate self.v * math.tan(steer) / self.L self.yaw yaw_rate * dt self.x self.v * math.cos(self.yaw) * dt self.y self.v * math.sin(self.yaw) * dt # 更新后立刻夹住角度防止长时间仿真后数值漂移 self.yaw math.atan2(math.sin(self.yaw), math.cos(self.yaw)) return self.x, self.y, self.yaw, self.v这段代码看着简单但它把几个容易忽略的工程点固化了加速度限幅、转角限幅、角度归一化。少了任何一条长时间仿真就会出现“车越跑越快”或者“航向角累积到几万度”这种假故障白白浪费排查时间。4.3 MPC参数整定先算清楚“要多远”再定“看几步”速度跟踪用MPC参数不是拍脑袋定的先从物理量倒推。核心是预测时域它必须覆盖“从当前速度刹停所需的时间”。制动距离近似为 v²/(2a)取v15米每秒、a3米每二次方秒制动距离约37.5米对应时间约2.5秒。如果采样周期取0.05秒那预测步数至少要50步。但50步的优化问题在车端算起来很吃力尤其还带约束。所以实际做法是“预测长、控制短”预测时域覆盖2.5秒50步控制时域只优化前10步后面保持最后一步的控制量不变。这样既能看见足够远的后果又不会让求解规模失控。代价函数我常用的形式是J Σ (w_v * (v_ref - v_k)^2 w_a * a_k^2 w_jerk * (a_k - a_{k-1})^2 w_slack * slack_k^2)其中w_v管跟踪精度w_a管舒适性加速度惩罚w_jerk管平顺性冲击度惩罚slack是约束松弛量防止无解。权重比例比绝对值重要我的经验起点是 w_v : w_a : w_jerk ≈ 10 : 1 : 5先跑通再微调。w_jerk给得偏大时车会变得“肉”加速慢腾腾给得太小车会一顿一顿。这个只能在闭环里试纸上算不出来。4.4 端到端模型训练集与验证集的切分要按“场景”切不能按“帧”切现在端到端很热但落地时最容易糊弄自己的就是数据切分。按帧随机切分相邻两帧几乎一模一样一帧进训练一帧进验证验证集分数虚高。正确做法是按行驶片段切分甚至按场景簇切分同一个路口的几百个片段只能全进训练或全进验证否则模型等于背答案。我在模拟项目里用的切分比例是 训练:验证:测试 7:1.5:1.5且三个集合在地理区域上不重叠。这样测出来的分数会难看不少但它更接近实车表现早难看比晚难看强。4.5 车端部署的算力预算先列表再砍功能算力不够是常态功能优先级得靠数字说话。下面这张表是我常用的预算模板单位是按某主流车端推理芯片的等效算力折算的相对占比具体数值要按自己平台重算模块单帧计算占比延迟预算降级策略图像预处理与BEV变换15%10ms降分辨率、减视角检测与分割主干35%30ms换轻量主干、降通道占用栅格20%25ms降高度维度、稀疏推理跟踪与预测10%15ms减候选轨迹数规划与控制10%10ms缩短预测时域兜底与监控10%常驻不降级这张表最有用的不是数字而是最后一列——它逼着每个模块负责人回答“如果算力砍一半你砍哪里”。答不上来的模块通常是没做过分级设计的模块真到资源紧张时就是整车的瓶颈。5. 常见问题与排查技巧实录5.1 一份可以对着查的故障速查表现象高概率原因快速验证方法处理方向融合目标位置轻微跳动时间戳不同步匀速直线标定板看点云投影错位是否随速度增大改用硬件触发或严格事件对齐远处目标横向偏移外参漂移看静态结构重投影残差中位数是否缓慢爬升在线健康度报警周期复标低速画龙感知航向角系统性偏差对比感知航向与真值航向的均值差修正感知输出或规划侧加死区路口频繁急刹预测把对向车当成本车道目标回放看预测输入的目标关联是否正确修目标关联逻辑别急着调规划权重规划轨迹忽快忽慢规划周期与控制周期不匹配打点看控制拿到的轨迹时间戳延迟轨迹按时间参数化控制做插值模型离线指标好、实车差数据切分按帧泄漏改为按片段/场景切分重训重建验证集接受分数下降夜间/雨天性能断崖训练数据分布缺失统计各场景样本占比按场景配额补采别只加数据量5.2 三个我踩过的坑第一个坑是过度相信离线指标。有段时间检测模型的mAP一路涨实车却越来越差。后来发现问题出在标注规范新加入的标注员把“被遮挡一半以上的车”也标成了正样本模型学会了预测一堆看不见的车。这类问题离线指标完全看不出来只有回放实车数据才能发现。解决办法是把标注规范变成可执行的检查脚本比如遮挡比例超过阈值的目标自动打标记而不是靠人盯。第二个坑是日志打得太少。早期为了省存储只记录关键结果不记录中间量出问题时只能猜。后来改成关键节点全量打点包括每帧的时间戳、坐标变换矩阵、各模块耗时、输入输出的关键字段存储成本涨了三倍但排查效率涨了不止三倍。我的经验值是中间结果的价值在你不需要它的时候最低在你需要它的时候最高所以宁可多打。第三个坑是仿真场景造得太理想。仿真里传感器没有噪声、标定永远准确、目标永远不遮挡模型在仿真里表现完美实车一塌糊涂。后来我在仿真链路里强制注入三类扰动传感器噪声、外参小偏差、随机丢帧。这三样加上之后仿真分数掉了不少但仿真和实车的差距明显缩小了。5.3 几个提高排查效率的习惯第一个习惯是给每个模块加耗时打点并画成时序图。不是为了优化性能而是为了定位“偶发延迟”。很多诡异问题都是某一帧某个模块突然耗时涨了十倍导致的没有打点你根本想不到。第二个习惯是保留原始数据。处理后的数据体积小但一旦处理逻辑有bug你连回退重算的机会都没有。原始数据存一段时间处理链路的版本号一起记出问题能重放。第三个习惯是建立“已知问题清单”并定期复盘。同一个问题在不同项目里反复出现说明它不是偶发而是流程缺陷。清单不用复杂一列现象、一列根因、一列是否已修坚持记一年价值远超任何文档。6. 工程协作与验收合集里最不性感但最要命的部分6.1 版本与数据管理模型、代码、数据三者必须能对上号自动驾驶项目里最让人崩溃的场景是三个月前跑出一个很好的结果现在想复现复现不出来。原因通常是三者没有绑定——代码有版本管理模型有权重文件但训练用的数据集是“当时那一版”没人记得是哪一版。我的做法是给每次训练生成一个唯一的实验标识里面记录代码提交号、数据集版本号、标注规范版本号、训练配置、随机种子、评估脚本版本。这六样缺一不可。听起来麻烦但用脚本自动生成就是几行代码的事手工记则一定会漏。数据版本管理还有个细节删除数据要留痕。有时候发现一批标注有问题就把它删了过几个月发现另一批也有同样问题想回溯影响范围却查不到。所以数据只做“标记失效”不做物理删除失效原因写清楚。6.2 验收标准不要用“感觉还行”作为交付条件模块交付前必须有可量化的验收标准而且要区分“功能验收”和“性能验收”。功能验收看行为对不对性能验收看指标达没达标。我在模拟项目里用的验收清单大致是这样功能规定场景集里通过率、人工接管次数、急刹次数性能单帧耗时P99、内存峰值、启动时间、异常恢复时间鲁棒性注入噪声/丢帧/外参偏差后的指标衰减幅度可观测性关键中间量是否可打点、日志是否可回放最后一栏经常被忽略但它决定了出问题时你能不能查。一个不可观测的模块本质上是不可维护的模块哪怕它现在跑得很好。6.3 团队分工上的一个反直觉经验早期我倾向于按模块切分感知组、规划组、控制组各管一摊。跑了一段时间发现模块边界上的问题没人认领——融合输出的目标质量差感知说是跟踪的问题跟踪说是关联的问题关联说是预测的问题最后谁都不改。后来改成“按链路切分按问题认领”日常开发还是按模块但每个跨模块问题必须有一个明确的负责人负责到底哪怕最后发现根因在别人模块里也由他推动。这个改动看着只是流程调整实际效果比想象中大得多因为跨模块问题的本质是“没人对端到端结果负责”。7. 这套合集后续还能怎么用如果你手上正好在搭一条类似的链路我的建议是别从第1节顺序读而是先跳到第3节看那五个容易被低估的环节对照自己项目里哪些是黑盒把黑盒列出来再回头按第2节的分层表决定哪些自研哪些用现成的。这个顺序能省不少时间因为大部分项目的瓶颈不在“缺一个新算法”而在“某个基础环节一直没做扎实”。参数部分尤其是MPC权重、BEV分辨率、体素尺寸这些千万别照抄。我在模拟项目里的配置换个传感器布置、换个算力平台效果就会明显不同。正确的用法是把我给的推导过程拿去套自己的物理约束先算清楚“必须看多远”再倒推步数再算算力够不够不够就砍控制时域一层层往下推。这个过程本身比最终那几个数字值钱得多。最后说一句实操里的体会自动驾驶这条链路单点做深不难难的是让二十个环节在同一帧里同时不出错。所以真正拉开差距的往往不是某个模块多先进而是标定准不准、时间戳齐不齐、日志全不全、验收严不严这些“不性感”的事。我见过太多团队在算法上死磕半年最后被一个外参漂移拖住整个进度。把基础环节做成可检查、可报警、可回滚的比追新模型划算得多。
