1. 卡车无人驾驶里轨迹和建图准确性到底卡在哪干卡车无人驾驶这行久了会发现一个挺有意思的现象刚入行的人聊得最多的是感知算法、是识别率、是各种新奇的模型结构但真正在车上跑过几万公里、在港口和矿区熬过几个通宵的人最后都会回到两个最朴素的问题上——车知道自己在地图里的哪个位置误差有多大车知道自己接下来该压在哪条线上偏了多少。前一个问题就是建图和定位的准确性后一个问题就是轨迹的准确性。这两个东西一旦松动后面所有的避障、决策、油耗优化全都是空中楼阁。我接触过的项目里感知能力的提升往往是渐进式的多一路激光雷达、换一个更好的模型指标能往上走几个点但定位和建图的精度一旦踩坑表现是断崖式的——车在直道上跑得好好的一进弯道就贴着路沿走在空载时对位很准装满货之后停靠位置就偏出去二三十厘米地图采集那天下了一场雨之后一个月都在跟莫名其妙的横向抖动较劲。这类问题的排查成本极高因为它不像感知误检那样有明确的场景复现它更像慢性病今天差三厘米明天差五厘米等你发现的时候已经积累了几百公里的坏数据。这篇东西想聊的就是这块内容卡车无人驾驶系统里轨迹精度和建图精度是怎么被定义、被拆解、被实现、被验证的中间的误差是怎么一层层传下去的哪些环节是真正的瓶颈以及我在实际项目里踩过的那些坑。内容会偏向工程实现会给出具体的参数、计算过程和配置思路。适合三类人看刚接手定位建图模块、还不太清楚误差预算怎么分的同学正在选型传感器和融合方案、想知道别人怎么权衡的工程师以及做系统集成、需要向别人解释“为什么这台车必须做到这个精度”的负责人。基础概念我会用生活化的类比带过但该硬的地方不会软。需要先说清楚一点卡车无人驾驶不是一个场景它是好几个场景。港口内集卡、矿区宽体车、干线物流重卡、厂区内短驳这四个场景对轨迹和建图精度的要求能差出一个数量级。港口要的是厘米级对位矿区要的是在扬尘和颠簸里的鲁棒性干线要的是在高速下的长距离稳定性厂区短驳要的是低成本可复制。所以后面所有的参数和方案我都会标明它适用的场景你抄作业之前先对号入座。2. 为什么卡车这个载体把定位精度逼到了墙角2.1 一辆重卡和一辆乘用车差的不只是尺寸很多人下意识觉得卡车就是放大版的乘用车算法平移过去调调参数就行。实际做过就会发现完全不是一回事。半挂牵引车加挂车总长接近十七米宽两米五五满载总重能到四十九吨这套几何和质量参数带来的第一个直接后果是横向容错空间被压得极窄。一条标准车道三米五车宽两米五五理论上的单侧余量只有四十七点五厘米而且这还是理想状态——现实中车道线有磨损、路面有修补、有些厂区道路压根没画线。也就是说横向误差超过二十厘米在很多场景下就已经是压线甚至侵入对向车道了而这二十厘米要分给定位误差、地图误差、控制跟踪误差、执行器延迟每一块都紧巴巴。第二个后果是转弯时的扫掠路径。卡车的后轴跟随特性决定了它在转弯时内轮差很大挂车更是会切内弯。乘用车过弯时稍微压一点内侧没人计较卡车过弯时挂车轮胎是真的会把路沿石压碎、把护栏刮掉。这意味着轨迹规划给出的参考线不能只是“车头走过的路径”而必须是整车包括挂车扫掠包络的中心线对轨迹精度的要求从“车头对准”升级成了“整列车队形对准”。第三个后果是执行环节的滞后。气压制动的建压时间、缓速器的工作区间、AMT变速箱换挡时的动力中断这些都让卡车的纵向控制响应比乘用车慢半拍以上。你给出的轨迹点如果只考虑几何不考虑动力学车跟起来一定是切弯、外抛、然后靠反馈硬拉回来表现出来的就是画龙。2.2 一个小角度误差是怎么被放大成米级的这里必须讲清楚一个容易被忽略的数学事实航向角误差对横向位置的影响是随距离线性放大的。航向偏零点五度往前看一百米横向偏差就是一百乘以正切零点五度大约是零点八七米。这个数字很吓人——你在车屁股上量出来“只偏了半度”放到一百米外就是快一米。这就解释了为什么干线物流场景下航向角的精度要求通常要卡到零点一度到零点二度这个量级而不是大家直觉里的“一度也还行”。反过来在港口这种低速、短距离、频繁启停的场景车速只有十几公里每小时前瞻距离几十米航向角放宽到零点五度也能接受。所以精度指标必须和场景的车速、前瞻距离绑定来定不能拍脑袋写一个通用值。同样的逻辑也适用于纵向。满载四十九吨的车从八十公里时速刹停制动系统建压加上驾驶员或控制器反应的时间差不多要零点九秒这零点九秒里车已经跑出去二十米按三点五米每二次方秒的减速度算制动距离还要七十米。加起来九十米的停车距离意味着纵向定位误差如果达到半米在某些工况下就是“多冲出去半个车身”的概念。这也是为什么重卡的纵向定位不能只靠GNSS必须要融合轮速、IMU和地图匹配——GNSS在隧道、桥下、高架旁的纵向跳变经常是好几个车身。2.3 精度指标到底该定成什么样我在项目里见过两种极端一种是把指标定得极其漂亮横向正负五厘米结果工程上根本达不到团队天天在做无效优化另一种是完全不定指标靠“看着还行”来验收最后系统集成时和规划控制模块互相甩锅。比较务实的做法是按场景分层定指标并且把指标拆到每个子模块头上。下面这张表是我在一个厂区加港口混合场景项目里用过的分层指标可以直接参考场景类型典型车速横向精度要求航向精度要求纵向定位要求建图绝对精度港口吊装对位5 到 15 km/h±10 cm±0.3°±5 cm对位点±5 cm矿区固定路线运输15 到 30 km/h±20 cm±0.5°±30 cm±10 cm厂区短驳10 到 25 km/h±15 cm±0.5°±20 cm±10 cm干线物流60 到 90 km/h±25 cm±0.15°±100 cm±50 cm注意干线物流那一行横向要求看着比港口宽松但航向要求反而最严原因就是前面说的线性放大。这张表拿去用的时候要记得一件事——表里的数字是“整车级”的验收指标不是某个传感器模块的指标模块指标要按误差预算往下分。3. 从误差预算倒推传感器与融合架构怎么选3.1 误差预算怎么一步步倒推出来我一直建议团队在写第一行代码之前先把这张误差预算表填了。它的逻辑很简单先把整车允许的总误差定下来然后按误差合成的方式分配给各个环节。之所以用平方和开根而不是直接相加是因为这些误差源之间基本相互独立用均方根合成更接近实际统计结果也不会把每个模块都逼死。举个实际的例子。港口场景横向总指标是正负十厘米也就是单边十厘米。我按下面这样分误差来源分配值说明地图自身几何误差±5 cm建图时点云配准和控制的残差定位解算误差±5 cm融合后的位姿输出误差轨迹跟踪控制误差±6 cm控制器稳态跟踪偏差执行器与通信延迟折算±3 cm延迟乘以车速车辆坐标系与传感器外参残差±2 cm标定误差按均方根合成根号下25 25 36 9 4等于根号九十九约等于九点九五厘米刚好压线。这个结果说明这套分配是可行的但也说明没有余量——任何一项翻倍总量就会超。所以我当时定了一个原则任何单项误差超过分配值的一点五倍就必须停下来查不能靠别的模块“匀”回来因为误差合成里不存在匀这个概念。这个表最大的价值不是算出来的数而是它会逼着你去问一些平时不会问的问题地图精度我到底怎么测控制稳态误差我在什么车速下测外参标定残差我怎么验证没有这张表这些工作会一直往后拖拖到联调阶段集中爆发。3.2 传感器配置的三种档位和各自适用边界卡车无人驾驶的定位传感器组合市面上基本收敛成三档我把它们的特点和适用范围摆出来配置档位组成优势短板适用场景基础档双天线 GNSS 轮速 中低精度 MEMS IMU成本低、易维护无 GNSS 时迅速退化厂区短驳、开阔矿区主力档双天线 GNSS 战术级 IMU 单激光雷达 轮速有激光匹配兜底失锁后仍能撑住依赖地图质量港口、矿区、绝大多数量产方案冗余档主力档 第二路激光 视觉里程计 高精度光纤 IMU单点失效仍可用成本与标定复杂度翻倍高速干线、无安全员运行选型上有个特别想提醒的点不要为了省成本把 IMU 降级却指望激光匹配补回来。激光匹配在结构化的厂区、港口环境里确实好用但卡车经常要面对的是长直空旷路段、大面积水泥地、矿区扬尘和雨雾这些时候激光点云的特征匹配质量会掉得很厉害撑住位姿连续性的实际上是 IMU 的短时推算能力。我见过项目用消费级 IMU 去配激光结果每次进空旷区域航向就开始缓慢漂移出来之后要花好几秒靠激光重新拉回来这几秒里车已经在画龙了。另一个建议是双天线 GNSS 尽量装在车顶前部、远离金属遮挡、基线尽量长。天线基线长度直接决定静态航向精度基线一米和基线两米航向精度能差一倍。这个改动几乎零成本但很多项目因为走线方便把两天线装得只隔四十厘米非常可惜。3.3 时间同步和标定所有精度的地基这部分我想单独拎出来说因为它是最容易被轻视、一旦出问题又最难排查的环节。定位融合本质上是把不同传感器在不同时刻的观测放到同一个时空基准下做优化只要时间戳错了后面全是错的。常见的做法是硬件同步加软件对齐双保险。硬件上用 GNSS 的秒脉冲给整个系统做时间基准激光雷达、相机支持 PPS 触发的就走触发不支持的就靠 PTP 或 GPS 授时模块同步。软件上在数据接口层做一次时间戳校验把各个传感器相对秒脉冲的偏差记录下来超过阈值的帧直接丢弃而不是硬用。下面这段是我常用的一个时间偏差检查脚本跑在车上的工控机上实时打印各路的偏差# 时间同步健康度检查各传感器上报本地时间与PPS的偏差单位毫秒 import time THRESHOLD_MS {lidar: 2.0, camera: 2.0, imu: 1.0, gnss: 1.0} def check_sync(sensor, offset_ms): limit THRESHOLD_MS.get(sensor) if limit is None: return True if abs(offset_ms) limit: print(f[SYNC-WARN] {sensor} 偏差 {offset_ms:.2f}ms 超过阈值 {limit}ms本帧建议丢弃) return False return True实测下来激光雷达的时间戳如果偏差超过两毫秒在车速二十公里每小时的情况下单帧点云的纵向错位就有约一点一厘米在干线高速场景下九十公里每小时对应五厘米。这还没算运动畸变补偿本身的残差。所以时间同步不是一个“差不多就行”的东西它是精度的乘数项。标定这边外参标定比内参更容易出问题。卡车的特点是车头车挂可以分离、货箱会更换、载重会变化这意味着传感器支架一旦有轻微形变外参就漂了。我建议的做法是把外参分成两类维护一类是相对刚性、只在维修后重标的比如激光到 IMU 的变换另一类是每次启动时用地面点云做在线校核的比如激光相对车体坐标系的俯仰和横滚。在线校核不用做完整标定只做一到两个自由度的修正成本很低但能挡掉大量“今天跑得好好的明天就偏了”的问题。3.4 融合架构松耦合、紧耦合和因子图怎么选架构选择这块我自己的经验是分阶段走。早期做原型用松耦合就够了——各路传感器各自解算位姿再用一个卡尔曼滤波做加权融合。好处是每个模块可以独立调试、独立看曲线出问题容易定位。缺点也明显GNSS 失锁时滤波只能靠 IMU 推算误差随时间平方增长而且松耦合没法利用 GNSS 的原始观测做约束。到了工程化阶段主流方案会切到紧耦合也就是把 GNSS 的伪距、载波相位、多普勒直接放进滤波或优化里。它的好处是卫星数量少、几何构型差的时候还能挤出信息城市和厂区里边角遮挡场景的可用性比松耦合高不少。代价是状态维度上去了调试复杂度也上去了尤其是整周模糊度这块没有一定经验很难调稳。再往上就是因子图优化也就是滑窗或者全局优化的框架。它最大的优势是支持回环和地图约束可以把激光匹配、GNSS 观测、轮速、闭环检测统统当成因子扔进去最后求一个全局一致的解。港口、矿区这种路线固定、大量重复经过同一地点的场景因子图的收益非常明显因为反复经过的位置可以形成强约束把长期漂移压下去。缺点是对算力有要求滑窗长度、边缘化策略、鲁棒核函数的参数都需要调而且一旦某个因子写错症状会非常隐蔽。我一般给的选型建议是固定路线、有高精地图、需要长期无安全员运行直接上因子图开放道路、以安全员监督为主、迭代速度快先用紧耦合滤波两者之间的过渡期用紧耦合滤波做输出、因子图做后台修正跑一段时间看效果再决定收敛到哪边。4. 建图准确性地图偏了后面全是白工4.1 建图之前必须先做的现场勘察我特别反对的一件事是“车开过去跑一圈回来就出图”。建图质量的上限在现场勘察阶段就已经决定了。勘察要看的东西很具体路面的材质和起伏水泥地和沥青地对激光反射率差别不小有没有大面积的重复结构比如成排的集装箱、一模一样的仓库门、整齐停放的车辆这些是回环误匹配的重灾区GNSS 的可见性怎么样有没有长时间的高架遮挡、树冠遮挡、贴墙行驶路段天气和季节影响积水、扬尘、落叶、雪都会改变点云特征。我在一个港口项目里吃过亏仓库区一整排完全相同的立柱间距规则点云匹配在单帧内几乎无法区分结果建图时出现了整排错位生成的地图看起来“很整齐”但整体旋转了几度。这个错误在地图上看不出来因为所有立柱还是对齐的直到把车开进去跑自动驾驶才发现每次经过仓库区横向都会突然跳一下。后来补救的办法是在勘察阶段就在仓库区布设了几个已知坐标的控制靶标建图后用靶标做全局校正同时把这段路的匹配策略从纯点云改成“点云加轮速里程计加人工标记约束”。所以我的勘察清单通常包括标志物布设方案、控制点坐标获取方式、分段建图的切分点、每段的行驶方向尽量双向跑能显著改善回环约束、以及每段的行驶速度。行驶速度这个点很多人忽略建图时车速过快会导致点云运动畸变加剧尤其是机械式激光雷达在十赫兹转速下四十公里每小时行驶单帧内车已经移动了一点一米如果补偿做得不好墙面会明显变厚。4.2 点云建图的流程和几个关键参数完整流程大致是数据采集、时间对齐、运动畸变补偿、前端里程计、回环检测、后端全局优化、点云拼接与栅格化、地图切分与索引、精度验证。每一步都有能翻车的点我挑几个最关键的讲。运动畸变补偿这块很多人直接用手里的 IMU 做插值但卡车的振动频谱和乘用车差别很大柴油机的怠速振动、气囊悬挂的低频晃动、路面接缝的冲击都会污染 IMU 的角速度积分。比较稳的做法是先用低通滤波把高频振动滤掉再用轮速做平移的补强——因为激光雷达帧率只有十赫兹IMU 积分到一百毫秒的漂移不可忽视。参数上我一般把角速度低通截止频率设在三十到五十赫兹之间具体值要在目标车上实测振动谱之后定。回环检测是建图精度的胜负手。纯几何的回环在重复结构场景下误匹配率很高我倾向于加两层约束几何相似度之外再加一个基于 GNSS 粗位置的候选筛选只有距离候选回环点在比如五米半径内的才允许匹配然后对匹配结果做一致性检查要求连续若干帧的回环候选都指向同一位置才确认为真回环。这个“连续性确认”的门槛看起来保守实际上能挡掉绝大部分误闭环而误闭环对地图的破坏是不可逆的——它会把你本来正确的整段地图强行扭曲。后端优化的参数上我给一组在港口和矿区都跑得住的起点值滑窗大小取二十到三十帧回环的鲁棒核函数用 Huber阈值设在零点一米左右位姿图的边信息矩阵里激光匹配的平移权重高于旋转权重因为旋转在长距离上更容易累积错误GNSS 约束在开阔段给较高权重在遮挡段降到接近零避免被跳变带偏。地图的最终形态也要提前想好。纯点云地图信息全但体积大一个港区跑下来可能几十个 GB车上加载和查询都吃力语义矢量地图体积小、查询快但丢失了纹理和细节激光匹配时就没那么好用。我比较推荐的组合是分层地图底层是降采样后的点云用作匹配中层是矢量化车道线和路面边界用作规划和横向误差检查上层是语义标注点比如停车位、吊装对位点、装卸货口。三层各自独立更新互不干扰。4.3 地图做完了怎么证明它是准的这是我觉得最应该被重视、但实际项目里最敷衍的环节。很多团队的地图精度验证就是“把车开进去跑一圈看看偏不偏”这等于没验证。比较靠得住的做法有三种成本从高到低排第一种是用独立测量设备打控制点。建图区域内均匀布设二十到三十个靶标用高精度全站仪或者静态后处理测量获取坐标然后在地图里量取同一批靶标的坐标算残差。这套方法能给出地图的绝对精度也能看出误差在空间上的分布规律——是整体平移还是局部扭曲。缺点是费时费力通常只在首次建图和重大更新时做。第二种是用双天线 GNSS 的固定解做轨迹比对。让车沿地图中心线行驶记录高精度的 RTK 固定解轨迹再和地图中心线做最近点距离统计看横向偏差的均值和标准差。这个方法快但只能验证地图的“相对形状”准不准验证不了绝对坐标因为两者可能整体一起偏。第三种是重复建图对比。同一区域隔一周再建一次图做配准后看残差分布。如果两次建图的一致性在五厘米以内说明建图流程稳定如果差很多说明有随机因素没控住。这个方法对发现“偶发误闭环”特别有效。我自己习惯把二和三组合用日常更新时跑一遍成本可控一到两个月做一次带控制点的完整验证。建图质量报告里我会固定放三个指标控制点残差的均方根、重复建图配准残差、以及沿路线分段统计的横向偏差分布。第三个指标特别有用它能直接把问题定位到具体路段而不是给一个笼统的全局数字。4.4 地图版本管理和更新策略地图不是一次做完就完事的资产它是会烂的。路面在修、标识在换、集装箱的堆放在变、路边的树在长这些都会让地图和现实逐渐脱节。工程上必须有版本管理每张地图带版本号、采集时间、采集车辆、覆盖范围、校验码车上加载时校验版本是否匹配不匹配就拒绝启动自动驾驶。更新策略上我建议分三档小版本增量更新只更新发生变化的局部区域比如某个路口重新铺了路面这种更新频率可以高一两周一次中版本全量重建覆盖整个运营区域一两个月一次配合控制点验证大版本重规划涉及路线调整、新增区域、地图格式升级按项目节点走。增量更新最容易出的问题是新旧地图的接缝处不连续处理办法是在重叠区域强制做一次联合优化把新旧点云一起扔进图里接缝处的残差要单独检查。还有一个实操细节地图文件在车上的加载时间和内存占用要实测。我遇到过地图文件太大导致启动时加载超时、定位模块初始化失败的案例最后靠地图分块加载加空间索引解决。这个坑在建图阶段就该想到不要等到实车上线才发现。5. 轨迹准确性从定位输出到车轮压线的完整链路5.1 定位链路分层每一层都要能单独看清我习惯把定位拆成四层来看每一层都有独立的精度指标出问题的时候可以逐层往下剥第一层是传感器原始观测GNSS 的定位解、卫星数、PDOP、固定解状态IMU 的角速度和加速度激光点云的匹配得分和匹配点数量轮速的脉冲计数和推算速度。这一层的健康度决定了后面所有东西的上限我一般会在诊断界面把这几个值实时打出来其中激光匹配得分和匹配点数量是最灵敏的预警指标突然掉下来基本就意味着环境变化或者地图过期。第二层是航位推算靠 IMU 加轮速做短时推算。这层的核心指标是零偏稳定性尤其是陀螺的 Z 轴。这里有个容易糊涂的地方——很多规格书上写的零偏稳定性是度每小时看着特别小但那是长时间平均后的指标短时推算里真正起作用的是角度随机游走和标定残差。所以我不看规格书直接看实测把车停在原地两个小时看航向输出漂了多少再让车跑一段已知的直线看推算出来的轨迹和实测轨迹差多少。以战术级 IMU 为例标定良好的情况下六十秒纯推算的航向漂移能压在零点二度以内这个水平配激光匹配足够用了。第三层是融合解算把观测和推算放在一起优化输出最终的位姿。这层的指标是融合后的位置协方差和实际误差的匹配度。这里特别想强调一句协方差一定要诚实地反映实际误差。我见过太多项目为了“好看”调小协方差结果规划模块拿到一个“高置信度”的错误位姿直接按这个位姿做决策后果比报个大协方差严重得多。第四层是坐标变换到车体把定位输出的后轴中心位姿变换到规划控制用的参考点再考虑挂车的几何关系。这一层看着简单实际上是标定残差最容易堆积的地方尤其是卡车后轴中心的位置测量本身就有几厘米的不确定性。5.2 航向角那个最容易被低估的误差源前面算过航向误差的放大效应这里说几个实际处理它的小技巧。第一个技巧是在直道上做航向的精细标定。找一段至少五百米的笔直路段用双天线 GNSS 固定解跑双向取两趟的平均方向作为真值然后对比系统输出的航向偏差就是系统性的航向零偏。这个方法能把航向零偏标到零点一度以内而且不需要额外设备。跑双向是为了消掉天线安装偏差和侧风的影响。第二个技巧是在融合里给航向单独设约束。位置误差有 GNSS 直接约束但航向在低速时 GNSS 几乎给不出有效观测这时候航向完全靠 IMU 撑着一旦 IMU 零偏没标好就会一路漂。解决办法是在融合模型里加一个“航向变化率与实际转向的约束”如果方向盘转角为零、横摆角速度接近零那么航向应该基本不变把这个作为软约束加进去能有效抑制低速直行时的航向缓慢漂移。这一条在港口低速场景里效果特别明显我们当时靠这个把低速画龙的问题压下去了大半。第三个技巧是用地图的车道线方向做辅助观测。地图里已经存了车道的矢量方向当激光匹配确认车辆在当前车道内时可以把车道方向作为航向的弱观测。弱观测的意思是权重要给得很低只用来做长期漂移的抑制不能让它主导短时输出否则遇到地图过期或者车道线标注误差反而会引入错误。5.3 挂车铰接角卡车独有的那一块挂车的存在是卡车无人驾驶区别于所有其他车辆平台的标志性难点。牵引车和挂车之间是一个自由铰接倒车时这个系统是不稳定的也就是俗称的折刀前进时也存在着挂车切入内弯的问题。要控制好整列车的轨迹就必须知道铰接角。获取方式主要有三种角度传感器直接测、视觉或激光测挂车相对牵引车的角度、以及基于运动学模型的估计。角度传感器最直接最准但需要机械改装、易损、维护成本高量产方案里不太受欢迎。视觉方案是在挂车前部装标记板用相机测角度成本低但对遮挡和光照敏感。运动学估计是纯软件的用牵引车的横摆角速度、车速和挂车轴距去推算问题是它依赖于“挂车没有侧滑”这个假设在低附着路面或者急转弯时误差会变大。我自己的实践是主用运动学估计加激光辅助校正把角度传感器作为标定阶段的真值来源。具体做法是先用角度传感器跑几天采集各种工况下的真实铰接角数据同时记录牵引车的运动状态拟合出一套修正后的运动学参数挂车等效轴距、铰接点位置然后撤掉角度传感器用修正后的模型在线估计。实测下来在正常路面和转弯半径大于十五米的工况估计误差能控制在两度以内在低速大转角时误差会到三四度这时候靠激光对挂车侧面的观测做修正。为什么两度的铰接角误差可以接受因为铰接角主要影响的是挂车的扫掠包络挂车长度按十三米算两度对应挂车尾端的横向偏差约零点四五米这个量级在规划阶段留了余量的情况下是能兜住的。但如果你的场景是港口窄通道对位那这个精度就不够了必须要上直接测量。5.4 轨迹跟踪控制把误差摁在轮子上轨迹跟踪这块纯跟踪、Stanley、LQR、MPC 这几类方法各有拥趸我这里不展开算法推导只讲和精度直接相关的工程细节。第一个细节是前瞻距离的选取。前瞻太短车会追着参考线抖前瞻太长弯道会切内。我用的经验公式是按车速线性给低速时十到十五米高速时按“车速乘以一点五秒”给但这个值一定要按车型实调。卡车的特点是响应慢前瞻要比乘用车给得长一些我一般在这个公式基础上再乘一点二到一点三。实调的办法是找一个标准弯道每次只改前瞻看横向误差曲线找一个既不抖又不切的值。第二个细节是执行器延迟补偿。前面说过卡车气刹建压慢其实转向也有延迟尤其是液压助力转向从给指令到车轮实际到位有一百到两百毫秒。这个延迟在低速时影响不大在高速时就是几米的位置误差。补偿办法是在控制器里做预测把当前时刻的指令作用到未来某个时刻的车辆状态上预测的时长用实测延迟标定。延迟标定一定要按车、按载重分别做满载和空载的转向响应差别不小。第三个细节是横向误差的分频段评价。只看一个均方根误差是不够的因为它掩盖了误差的性质。我一般把横向误差做频谱分析看低频段对应稳态偏移多是标定或地图问题、中频段对应跟踪参数问题、高频段对应传感器噪声或振动问题各自占多少。这个分析做一次问题的方向基本就清楚了。下面这个脚本可以快速算出来# 横向误差分频段统计输入为等间隔采样的横向误差序列米采样率 10Hz import numpy as np def band_report(err, fs10.0): err np.asarray(err, dtypefloat) err err - err.mean() # 先去掉直流分量单独看稳态偏移 spec np.abs(np.fft.rfft(err)) ** 2 freqs np.fft.rfftfreq(len(err), 1.0 / fs) bands [(0.0, 0.3), (0.3, 1.5), (1.5, fs / 2)] total spec.sum() 1e-12 for lo, hi in bands: mask (freqs lo) (freqs hi) print(f{lo:4.1f}-{hi:4.1f} Hz 能量占比 {spec[mask].sum() / total * 100:5.1f}%)用这个跑一遍如果低频占大头别去调控制器参数去查地图和标定如果中频占大头再回头调前瞻和增益。这个顺序搞反了会浪费很多时间。6. 实测验证真值从哪来怎么把问题钉死6.1 真值这件事没有捷径评价精度必须要有真值而真值恰恰是最贵的东西。几个常用的获取方式和它们的边界我列一下真值获取方式精度水平成本适用场合局限全站仪控制点毫米级高建图精度验证、对位点验证只能测点不能测连续轨迹静态后处理 GNSS厘米级中轨迹真值、地图形状验证需要开阔天空遮挡段无效RTK 固定解实时记录分米级到厘米级低日常对比、趋势观察多路径环境下会突变双天线航向基准0.1 度级中航向精度验证基线要够长、要远离遮挡地面标线人工量测厘米级极低快速抽检受量测手法影响大实际做的时候我的建议是双轨并行用静态后处理的轨迹作为主要真值做定量的精度统计同时用地面标线加卷尺抽检做定性的交叉验证。后者看起来很土但特别有效——车停在标线旁边真人下去量一下轮胎到线的距离和系统报的横向偏移对比五分钟就能判断系统有没有大问题。这个方法我在现场调试阶段天天用比看任何曲线都直观。6.2 数据回放能力决定了排查效率我坚持认为一个定位建图团队的能力一半体现在数据回放工具的完善程度上。车上的问题往往转瞬即逝没有完好的记录和回放就只能靠“再跑一遍试试”效率极低。记录的东西要足够全所有传感器的原始数据、时间戳、各模块的中间输出、融合后的位姿和协方差、控制指令、车辆实际状态、以及诊断标志位。存储上要注意激光雷达原始数据量很大全量记录不现实通常的做法是全量记录低频信号激光点云按关键帧加抽帧记录出问题之后再针对性做全量录制。回放工具要做到三件事能任意倍速、能逐帧单步、能同时看位姿和点云的叠加。第三点尤其重要很多时候问题一眼就能看出来——把当前帧点云和地图叠在一起看如果墙面出现了明显的双层那基本就是位姿偏了不用再猜。6.3 测试矩阵别只跑顺利的路线测试设计上我踩过的最大的坑是“总在好天气、空载、同一条路线上测”。这样的测试结果会非常好但没有任何意义。一套比较务实的测试矩阵至少要覆盖这几个维度载重维度空载、半载、满载制动和转向响应差别很大天气维度晴天、雨天、夜间雨天还要看路面积水程度交通维度空旷、有静止障碍、有动态车辆、有人工干预地图维度最新地图、过期一个月的地图、故意偏移若干厘米的地图故障维度单路 GNSS 失效、激光被遮挡、IMU 通信丢帧。这里面我最看重的是故意偏移地图这一项。把地图人为平移或旋转几厘米看系统能不能检测出来、会不会告警、退化到什么程度。这一项能直接把“地图过期”这个最常见的长期风险暴露在测试阶段而不是等运营三个月后在路上爆发。7. 常见问题与排查实录7.1 排查速查表下面这些是我这些年遇到频率最高的问题按症状整理成表遇到类似情况可以先对号症状表现高概率原因快速验证方法处理方向低速直行时缓慢左右摆航向零偏未标定、IMU 温漂静止两小时看航向漂移重标航向零偏加温度补偿进弯道贴内侧路沿前瞻过短、挂车扫掠未计入换长前瞻复测调前瞻规划改整车包络空旷路段横向突然跳变激光特征不足、GNSS 多路径看匹配点数量曲线提高 IMU 权重加地图辅助一段路稳定偏十厘米地图局部误差控制点复核该段局部重建地图重复结构中位姿整体旋转误闭环对比重复建图结果加回环连续性校验重优化满载后对位偏移变大载重导致车体姿态变化对比空满载外参加悬挂高度补偿雨天精度明显下降点云被雨雾干扰看噪点比例点云滤波降激光权重起步瞬间定位跳变时间戳未对齐、静止检测误判查同步偏差日志修时间同步改静止判定7.2 几个印象深的坑第一个坑是悬挂高度引起的“隐形”外参漂移。空载和满载时卡车的气囊悬挂高度能差十几厘米车身俯仰角也跟着变。我们当时把激光雷达装在车顶认为它相对车体的外参是固定的结果满载时激光打出去的角度和空载差了一点几度匹配时点云和地图对不齐横向误差直接多了五厘米。后来在悬挂上加装了高度传感器把车身姿态的补偿加进外参变换里问题才解决。这件事给我的教训是在卡车上“刚性连接”这四个字要打问号凡是能被载重改变相对位置的东西都要考虑补偿。第二个坑是地图的坐标系定义不一致。建图时用的是激光雷达坐标系作为世界原点定位模块默认用的是后轴中心规划模块用的是前保险杠中心三个模块各自做了变换但变换的方向搞反了一次。表现是车在直道上偏了一个固定值怎么调控制参数都没用最后是靠打印三个模块的坐标变换矩阵对比才发现的。这种问题非常低智但排查成本极高因为每个模块单独看都对。解决办法是在项目早期就明确规定唯一的世界坐标系和车体坐标系定义写进接口文档并且提供一个坐标变换的自检用例每次集成时跑一遍。第三个坑是 GNSS 天线被货物遮挡。干线物流场景货箱装得高一点就会挡住天线导致卫星数骤降。这个问题在测试时很难发现因为我们测试时货箱都是标准高度。后来在运营车上遇到表现是某些路段频繁从固定解掉到浮点解定位精度掉一个数量级。处理方式是天线位置上移并做遮挡仿真同时把卫星数和固定解状态纳入运行时的健康度判断一旦掉出阈值就主动降级而不是硬撑着跑。第四个坑是长时间运行后的地图漂移累积。我们的地图是全量重建的每次重建都用上一次的地图做初始对齐结果连续重建十几次之后整张地图相对于最初的控制点慢慢转了零点几度。这个偏差单次看不出来累积起来就致命了。后来改成每次重建都必须和最初的控制点做绝对对齐不允许链式继承问题彻底解决。这件事说明一个道理增量式的做法在工程上很诱人但一定要有一个绝对基准定期把漂移拉回来。7.3 几条不写在文档里的经验经验一精度问题九成出在标定和时间同步而不是算法。我带的每个新人遇到精度问题的第一反应都是改融合算法、调滤波参数我一般会拦住让他先把所有外参重新标一遍、把时间同步日志翻一遍。十次里有六七次问题就在这儿。算法的上限是标定给的天花板天花板低了算法再好也顶不上去。经验二给每个模块留一条能独立跑通的“裸奔”路径。也就是说即使融合模块挂了也要能用纯激光匹配跑起来即使激光挂了也要能用 GNSS 加 IMU 跑个降级模式。这条路径平时用不上但现场出问题的时候它是唯一能帮你快速定位故障点的手段。经验三把指标的测量做成自动化的。每次跑完数据自动出精度报告横向误差分布、航向误差、固定解占比、匹配得分统计全部落成图表存档。这样做的价值不在于报告本身而在于你能看到趋势。精度从八厘米慢慢退化到十二厘米单次看都“还行”但趋势图一眼就能看出来这时候介入的成本最低。经验四不要迷信高精地图的“高精”。地图精度再高如果更新不及时它的实际价值是负的因为它会给你一个错误的信心。我现在更看重的是地图的时效性和可信度指标每块地图都带采集时间和置信度过期区域主动降权宁可让车跑得保守一点也不让它拿着过期地图撒欢。经验五现场的厘米比实验室的毫米值钱。实验室里跑出来的均方根误差很漂亮但现场一个坑洼、一片积水、一次临时堆放就能把指标打回原形。所以我坚持所有的精度验收都在实际运营场景、实际载重、实际天气下做实验室数据只用来做回归对比。最后分享一个我自己一直在用的判断方法当我不确定某个精度问题到底出在地图还是定位还是控制的时候我会做一件事——把车手动开到某个已知位置用卷尺量出轮胎到参照物的实际距离然后和系统三路输出地图坐标、定位坐标、控制反馈分别对比。哪一路和实测对不上问题就在哪一路。这个方法很笨但每次都能在半小时内把范围缩到最小比对着曲线猜有效率得多。地图和定位这件事说到底没有捷径所有的精度都是靠一遍遍测量、一遍遍对齐、一遍遍验证堆出来的。