隧道场景的商用车数据采集圈外人听起来可能觉得不就是往隧道里跑一趟装几个传感器嘛但真正干过的人都知道这条赛道几乎是数据采集领域最硬核的试炼场之一。无GPS信号只是最表面的问题粉尘、震动、温差、电磁干扰、光照突变、活塞风每一项单独拎出来都能让一套精心调好的采集系统当场翻车。我这两年跟着某商用车自动驾驶团队做过隧道场景的多模态数据采集系统从传感器选型到融合定位再到数据处理踩了不少坑也沉淀了一套相对完整的方法论这里系统梳理一遍。这套方案适合谁参考如果你正在做矿区、隧道、地下车库、高架桥下这些GNSS遮蔽场景的商用车数据采集或者你在做组合导航、多传感器融合相关的项目这篇文章应该能帮你少走几个月弯路。我会把传感器怎么选、装在哪儿、同步怎么做、定位怎么融合、恶劣工况怎么防护以及我们实测时遇到的那些教科书里不会写的问题全部摊开来讲。1. 隧道为什么被称为数据采集的天然考场1.1 无GPS并不只是没信号这么简单很多人对隧道内无GPS的理解停留在收不到卫星信号定位失效这个层面但实际上对于商用车数据采集系统来说问题远不止于此。首先是信号遮蔽的突然性。车辆进入隧道往往是在行驶状态下瞬间发生的GPS信号从满格到完全丢失可能只有几十米距离。这意味着组合导航系统必须在极短时间内完成从卫星修正到纯推算的状态切换如果切换逻辑设计得不好位置输出会出现明显的跳变而这些跳变会直接污染采集到的轨迹真值后续用来训练感知模型或验证控制算法时这些带跳变的数据根本没法用。其次是多路径效应的残留。隧道口附近往往还有一部分折射、反射的卫星信号能被接收机捕获这些信号带有巨大的伪距误差如果融合算法没有针对性地做置信度管理就会把错误但有信号当成可靠修正导致定位结果比完全没有GPS时还要糟。我们测试时发现有些商用组合导航模块在隧道口附近的位置误差能达到几十米罪魁祸首就是这种残留多路径信号。再就是隧道长度和结构的差异。短隧道可能一两百米就出来了系统还没来得及完全进入纯推算模式就又恢复了GPS而长达数公里的隧道完全依赖惯导和轮速推算累积误差会呈时间的三次方增长。如果隧道内部还有弯道、坡道、分岔推算难度更是直线上升。不同隧道的工况差异极大这就要求数据采集系统的定位方案要有很强的自适应能力而不是一套参数打天下。1.2 恶劣工况清单从粉尘到杂散电流商用车本身的工作环境就不干净隧道里更是把恶劣程度拉满了。我列一下我们实测时遇到的主要干扰源每一条都在真实项目里给系统制造过麻烦。粉尘和油污是最直观的。隧道施工阶段或未完全清洁的运营隧道里扬尘浓度很高粉尘会附着在激光雷达的窗口和摄像头的镜片上导致点云出现大量噪点、图像对比度下降。商用车底盘的油泥还会被轮胎甩起来打在传感器外壳上如果不做防护设计两个小时的数据质量可能就明显劣化了。湿度和凝露问题同样不容小视。隧道内常年高湿度尤其是南方雨季或山区隧道传感器外壳、连接器接口处容易出现凝露轻则导致电气接触不良重则直接短路烧毁设备。我们有一台IMU就是死在凝露上的排查了很久才发现是外壳密封圈老化导致水汽渗入。振动冲击是商用车独有的麻烦。商用车自重十几吨起步行驶在隧道接缝、不平整路面或减速带上时底盘振动频率低但幅值很大瞬时冲击可以轻松超过好几个g。这对IMU这类对运动敏感的传感器是严峻考验安装方式不当的话测出来的角速度和加速度数据会带着大量结构性噪声。温差造成的热漂移也是被很多人忽略的坑。隧道内外温差在冬季可以达到二三十度设备从外部环境进入隧道后机箱内部温度快速变化IMU的零偏会随之漂移如果是精度要求高的惯导系统这种温漂在长隧道里的累积误差是非常可观的。还有电磁干扰特别是铁路隧道或电气化公路隧道。接触网、轨道回流产生的杂散电流会在附近形成较强的电磁场未做屏蔽处理的信号线容易耦合进共模干扰表现为数据帧校验错误率升高、传感器输出出现毛刺。这是很隐蔽的问题因为设备在常规环境下测试一切正常只有到隧道现场才会暴露。2. 传感器选型与布置先想清楚每个传感器在隧道里到底靠什么活着2.1 各传感器的任务边界划分多模态系统这个词听着高级但落到工程实现上第一个问题就是每个传感器负责干什么它的能力边界在哪里。边界划分不清融合算法就会无所适从。我们在隧道场景采集系统里用的传感器组合是这样的激光雷达主要负责三维环境感知和建图。隧道内结构特征明显墙壁、拱顶、管道、灯具都是天然的几何特征非常适合激光雷达发挥。考虑到商用车采集需要较大的垂直视场角和较远的有效测距我们选择了多线机械式雷达兼顾隧道顶部结构和前方远距离目标的探测。毫米波雷达负责速度测量和远距离目标跟踪。隧道内光线条件差摄像机会受光照影响但毫米波雷达对光照完全不敏感在粉尘和烟雾环境下的穿透能力也比激光雷达强不少。它被用于补充激光雷达在恶劣视觉条件下的感知冗余。摄像头提供语义信息和交通标志识别。隧道内的限速标志、警示灯、车道线、洞口轮廓这些信息激光雷达和毫米波雷达都提供不了必须靠视觉。我们用了高动态范围的工业相机因为隧道口的光照突变是所有相机厂商都绕不过去的坎。IMU和轮速传感器组成航位推算的核心。IMU提供三轴角速度和加速度轮速传感器提供纵向车速约束这两者是隧道内无GPS时定位的救命稻草。我们选IMU时特别看重零偏稳定性和温度特性而不是单纯追求指标上的高精度。气压计和高精度地图作为辅助修正手段。气压计可以估算高程变化用于坡道识别高精度地图则提供了隧道内道路拓扑和里程标志信息配合里程计可以做地图匹配修正。每个传感器的任务边界必须在方案设计阶段就定清楚否则到了融合阶段数据打架的概率会非常高。比如摄像头补光是否会影响激光雷达毫米波雷达探测到的隧道墙壁回波怎么和激光雷达点云对应这些问题不提前规划后面每个都能让人挠头。2.2 布置位置与安装细节的坑传感器选型定下来之后布置位置就成了决定数据质量的关键一环。我们在这上面踩过的坑基本可以编一本小册子了。激光雷达我们最终选择安装在驾驶室顶部偏前方的位置用定制支架固定。这个位置的好处是视野开阔能看到车头前方的完整路况和隧道顶部结构缺点是离地高度大商用车行驶在隧道内时颠簸会被放大雷达的振动比想象中要剧烈得多。我们第一版支架用的是刚性连接结果点云里出现了可见的高频抖动伪影后来在支架和车顶之间增加了减振橡胶垫抖动问题才基本消除。摄像头布了四个前视主摄、前视广角、后视、侧视。前视主摄负责车道线和交通标志广角负责隧道口的视野覆盖。这里有个很关键的细节——摄像头安装角度必须预留调整余量因为商用车空载和满载时车身姿态差别很大载重会导致车头抬高或压低如果安装角度没有余量满载工况下视场角可能会完全偏移出需要观测的区域。IMU和轮速传感器的安装更是讲究。IMU应该尽量安装在车辆质心附近因为这个位置的运动学特性最接近整车运动模型同时要确保安装面平整、刚性强如果装在一个容易发生局部形变的钣金件上IMU测到的就是钣金的运动而不是车辆的运动。商用车车架纵梁是相对理想的安装位置自带一定的刚度但要注意远离发动机、变速箱这些振动源。轮速传感器的安装有很多商用车特有的坑。商用车的轮速信号通常来自ABS系统的轮速齿圈信号是脉冲形式。这个信号虽然可以直接接出来用但要注意几个问题一是齿圈齿数不同车辆不一样必须精确配置脉冲当量二是ABS系统在车辆急刹车或车轮抱死时会有特殊逻辑轮速信号可能被切断或替换这会让里程计瞬间失准三是商用车双胎并装的轮位左右轮速差信息几乎没用不能用乘用车的轮速差模型来估算横摆角速度。数据采集主机的安装位置我们放在了车厢前部独立隔舱用工业级工控机加固态硬盘阵列。这里要特别提醒的一点是商用车的电气系统是24V部分车型是12V而且整车电压波动比乘用车大得多启动瞬间电压跌落和发电机电压浪涌都很常见。所有采集设备都必须经过稳压电源模块供电最好再加一级隔离电源否则一次发动机启动就可能烧掉一片设备。2.3 传感器防护与线束整理的工程化处理防护设计看起来是体力活但恰恰是最能体现工程经验的地方。激光雷达的窗口我们做了定制的防护罩既能挡飞溅的泥水又不会遮挡扫描视场角。防护罩材质选的是高强度聚碳酸酯耐磨且透光率损失小用了一个多月也没有明显的透过率衰减。所有外露连接器都选用了工业级防水航空插头等级至少IP67连接器尾部做了热缩管加防水胶双重密封。线束在车架上的走向要避开排气管和高压线缆前者是热源后者是电磁干扰源。信号线全程使用屏蔽双绞线屏蔽层单端接地这个细节能显著降低电磁耦合噪声。还有一个容易被忽视的点是线束的长度余量。商用车在行驶中车架会有扭转线束如果没有足够余量长期弯折会导致内部导线断裂这种故障非常隐蔽表现是间歇性的数据丢失排查起来极度痛苦。我们在所有关节位置都留了足够的回弯弧度并且用波纹管包裹实测下来可靠性提升非常明显。3. 无GPS时组合定位怎么做从航位推算到场景匹配3.1 组合导航的基本盘惯导与轮速隧道内没有任何卫星信号可用时定位的核心逻辑是航位推算——从已知位置出发通过测量车辆的加速度、角速度和轮速逐步推算后续的位置和航向。这个过程中惯导和轮速各自扮演不同角色。IMU提供的三轴角速度可以推算航向变化率三轴加速度经过姿态变换后可以推算速度变化。但IMU有一个致命弱点——零偏。陀螺仪的零偏会使航向角积分误差随时间增长而航向角误差一旦出现整个位置推算都会沿着错误的方向越走越远。加速度计的零偏则会让速度积分产生偏移最终反映为位置误差的加速增长。轮速传感器在纵向速度测量上比IMU可靠得多它直接测量车轮的旋转速度换算成车速不存在零偏漂移问题。所以工程上通常的做法是横向和航向变化主要由IMU负责推算纵向速度和里程约束由轮速传感器提供。两者结合构成一个二维平面上的航位推算模型这是无GPS定位的基本盘。但轮速也不是无条件可信的。商用车在湿滑路面或急加速时驱动轮会有打滑急刹车时车轮会有抱死拖滑。这两种情况都会导致轮速信号和真实车速严重偏离。为了抑制这个问题我们引入了前后轮速一致性校验——商用车通常多个轮位都有轮速传感器当各个轮位的脉冲速度差异超过阈值时判定当前处于打滑或滑移状态里程计对这个时段的数据打上低置信度标签融合算法里自动降低权重。3.2 隧道场景特有的修正手段光靠惯导和轮速误差累积仍然无法避免。隧道场景里还有一些特有的修正手段可以利用这些是我们在项目里逐渐摸索出来的。气压计测高程。隧道虽然是近似水平的但很多市政隧道和山区隧道内部是有纵坡的坡度从百分之几到百分之十几都有。气压计对高度变化敏感可以辅助判断当前是否在上坡或下坡从而修正高程方向的位置估算。但这里有坑——隧道内车辆通行产生的活塞风会造成局部气压波动气压计读数会叠加一个随时间变化的噪声。我们试过用低通滤波把活塞风的动态分量滤掉只保留缓变的纵向分量效果尚可但滤波时间常数需要针对不同隧道长度做标定是一个需要耐心调试的过程。高精度地图匹配。如果在采集前已经获得了隧道内的高精度地图包含道路中心线、里程桩、车道边界、洞口位置等就可以把推算轨迹和地图做匹配当航位推算的位姿与地图几何吻合时置信度高偏离时置信度低。这本质上是一种先验约束能把漂移限制在一定范围内。我们用的是车道级地图加里程计融合的方式在隧道内定位误差可以被限制在米级甚至亚米级完全能满足数据采集对轨迹精度的需求。车体运动学约束。商用车不是全向移动的点它有阿克曼转向或铰接转向的运动学约束前后轴的运动轨迹之间存在几何关系。在融合算法里加入车体运动学约束可以过滤掉一部分不符合车辆运动规律的推算结果。这个约束在隧道内的直线段几乎不起作用但在弯道段效果非常明显能把横向漂移拉回来不少。3.3 状态切换逻辑与初始化前面说过GPS从有到无是渐变过程系统需要在不同状态之间平滑切换这是融合定位方案里最容易出问题也最容易被忽视的地方。我们的做法是设计了一个四级状态机完全GPS修正、GPS弱修正、纯航位推算、地图匹配修正。状态切换的判据不仅包括卫星数量、定位精度因子这些常规指标还包括卫星信号的多路径特征量。当检测到多路径特征量异常升高时即使卫星数量还够系统也会主动降级到弱修正模式避免被错误信号带偏。初始化也是关键一环。车辆进入隧道前如果系统没有完成良好的姿态初始化那么进入隧道后的航位推算精度会大打折扣。我们会在车辆进入隧道前的开阔路段主动做一段直线加速和匀速行驶的标定流程让融合算法收敛姿态和轮速比例因子确保带着满状态进隧道。长隧道里如果中途停车比如遇到前方拥堵或施工管制IMU零偏需要重新估计不能沿用停车前的零偏值。我们在系统里实现了一个停车检测功能利用轮速信号和车辆加速度综合判断车辆是否静止一旦检测到静止状态持续两秒以上立即触发零偏在线估计用静止时的IMU读数来更新陀螺仪零偏。这个功能在实测中非常管用能把重新起步后的航向漂移压低一个数量级。4. 数据链路与时间同步多模态系统最容易翻车的地方4.1 时间戳统一所有传感器必须说同一种时间多模态数据采集的核心价值在于多个传感器的数据可以对齐到同一时刻用于后续的感知融合、标注和模型训练。如果每个传感器的时间基准各说各话那这套系统采集的数据在应用层面基本等于废品。我们遇到的第一个问题是时钟源不统一。激光雷达和摄像头都有自己的系统时钟IMU有自己的采样率如果各传感器独立计时哪怕每天只差几毫秒累积起来也会导致严重的数据不同步。我们的解决方案是引入统一的PTP精确时间同步协议由数据采集主机作为时间主时钟各传感器作为时间从设备通过PTP协议自动对时。在硬件层面我们为所有关键传感器都配置了硬件触发线。激光雷达的每一帧扫描都会输出一个触发脉冲信号这个脉冲同时送给摄像头和采集主机摄像头收到脉冲后立刻抓拍一帧图像采集主机则在脉冲时刻为这帧数据打上精确的时间戳。这样一来激光雷达和摄像头的帧就天然同步了。IMU虽然无法用硬件触发对齐到帧级但它的采样率远高于其他传感器我们通过插值把IMU数据重采样到激光雷达的帧时间上。时间同步的精度直接影响融合算法的效果。举个例子如果摄像头图像和激光雷达点云的时间差超过几十毫秒车在高速运动时同一个目标在图像和点云中的位置就会出现明显的视角差异导致标注困难甚至错误。经过PTP加硬件触发双重保障我们系统的同步误差可以控制在1毫秒以内基本满足所有下游应用的需求。4.2 数据回传与存储的工程细节隧道内的数据采集有一个特殊问题——数据传输和存储必须在离线条件下完成。隧道内没有可靠通信网络指望实时回传数据到云端是不现实的所有原始数据必须在本地的存储阵列里暂存等车辆出隧道后统一回传。存储系统的设计要比想象中复杂。激光雷达点云多路视频IMU高频数据总数据速率可以达到每秒几百兆字节一趟长隧道测试下来就是上百GB甚至几个TB的数据量。我们用了双盘位冗余存储方案数据实时写入两块独立固态硬盘做镜像防止单块硬盘故障导致数据丢失。硬盘选的是工业级宽温型号因为装在车上要考虑高温季节驾驶室驻车后内部温度上升的场景普通消费级硬盘在这个温度下很容易掉盘。掉电保护是商用车场景的独有需求。商用车驻车时可能会被司机直接断开总电闸如果不做处理突然断电会导致文件系统损坏、正在写入的数据块丢失。我们在存储系统上加了超级电容模组检测到断电瞬间能给系统提供几秒的续航时间让程序有时间写完当前文件并安全卸载文件系统。这套机制救了我们好几次有一次数据采集过程中车辆电瓶亏电整车上电瞬间全部设备掉电超级电容撑住了最后的写入过程硬盘上连一个损坏文件都没有。文件命名和目录结构也是需要提前规划的细节。我们的命名规则包含了日期、时段、路线编号、传感器类型、工况标记等字段这样任何一段数据都能快速定位到对应的采集条件和环境信息给后续的数据管理减轻了大量负担。5. 实测排查实录三个典型的翻车案例5.1 轮速脉冲丢失导致的定位跳变某次在一条长约三公里的隧道里做测试车辆行驶到隧道中段时融合定位输出突然出现了约十几米的横向跳变然后又慢慢拉回来。一开始我们以为是IMU数据问题但回放日志发现跳变发生的瞬间轮速传感器出现了连续数百毫秒的脉冲丢失。排查过程是这样的先检查轮速传感器的电气连接发现连接器端子有些许氧化迹象但清理后问题依旧再检查齿圈和传感器探头之间的间隙发现商用车在重载工况下后桥变形量较大探头和齿圈的间隙会发生变化间隙过大时信号幅度衰减严重偶尔会低于整形电路的门限电压导致脉冲丢失。解决思路有两个方向。一个是从硬件上换用间隙适应性更好的传感器或者弹簧加载式的探头另一个是从软件上对轮速信号做质量监控和预测补偿。我们两个方向都做了硬件上选用了磁阻式轮速传感器替代原来的磁电式产品信号幅度和间隙适应性都有改善软件上引入了一个基于车辆动力学的轮速速度估计器当检测到轮速丢失时用上一时刻的纵向加速度和当前挡位来推断合理的车速范围把跳变控制在一个可接受的小范围内。这个案例给我们的启示是商用车底盘是高度非线性的系统任何传感器的安装状态都会随着载荷、温度、磨损而变化不能指望标定一次就永远可靠系统必须要有实时监测和自适应能力。5.2 气压计被活塞风干扰导致高度误判另一个让我们挠头许久的问题出现在气压计辅助高程定位上。某段隧道坡度较大系统在爬坡段输出的高度值却出现了一个先上升再下降的驼峰式误差和实际的纵坡曲线明显不符。起初我们怀疑是气压计的灵敏度不够但换了更高精度的传感器后问题依旧。后来查阅气象资料和隧道通风设计规范才想明白问题出在隧道内车辆快速通过时产生的活塞效应。当一辆大车在前面高速行驶时会在隧道内形成明显的局部气压梯度传感器感受到的气压变化和真实高度变化混合在一起很难区分。处理思路是增加一个环境气压参考通道。我们在采集车之外设置了一个静止的参考气压计部署在隧道外的气象站位置同时记录隧道外的实时气压采集车上的气压读数减去参考气压后再换算高度变化。这样能消除大部分天气性气压波动但对于隧道内动态的活塞风干扰还是需要配合滤波处理我们最终采用了一个自适应陷波滤波器能够识别活塞风的特征频率并做针对性衰减。这个组合方案应用后高度误差显著减小。这个案例给我们的教训是隧道内的微气候环境复杂程度远超普通室外场景任何依赖环境物理量的传感器都必须评估环境因素被信号污染的风险并设计与之对抗的机制。5.3 摄像头在隧道口强光切换下的过曝车辆从明亮的隧道外驶入昏暗的隧道内光线强度在短短一两秒内变化几个数量级摄像头如果自动曝光调整跟不上会出现一段较长时间的过曝或欠曝画面感知算法在这种画面上基本处于失效状态。我们一开始使用的工业相机自动曝光速度不够快从进隧道到画面恢复正常大约需要两三秒这期间图像完全是白的什么信息都采集不到。后来换了一款支持HDR和多帧融合的相机情况有所改善但在最极端的光照突变下依然有可见的调整延迟。最终的解决方案是软硬结合。硬件上使用了大靶面、全局快门、HDR模式的相机并且在前视方向加装了一片渐变灰滤镜——上暗下亮能够让天空区域的进光量被适当压低保留路面区域的信息。软件上我们修改了自动曝光算法增加了对GPS位置和隧道入口拓扑的先验利用当车辆接近判定为隧道入口的区域时主动将曝光目标值调到暗光模式提前应对即将到来的光线变化。这套组合下来隧道口的光照突变问题基本被解决画面恢复时间从两三秒缩短到几百毫秒感知算法在更多的时候处于有效工作状态。6. 从数据采集到模型落地这套方案还能怎么用6.1 数据质量评估指标采集了这么多数据如果质量没法量化评估下游用起来还是不放心。我们在项目里建立起了一套针对隧道场景的数据质量评估体系主要包括几个维度。时间同步质量通过多传感器触发延迟的方差来衡量我们把各传感器之间的触发时间差以毫秒为单位记录在日志里统计P95值要求全程低于2毫秒。定位轨迹质量上重点关注纯航位推算段落的累计漂移率通常用每公里的横向误差和纵向误差来衡量隧道场景下横向误差控制在1.5米以内就算合格。传感器健康状态则包括点云反射率异常比例、图像模糊度评分、IMU温漂速率等指标。这些指标会在每条数据采集任务结束后自动生成一份质量报告高于阈值的段落被标记为可用低于阈值的段落标记为需复核或废弃。这样数据团队在交付前就能心中有数不需要下游工程师拿到数据后才发现一堆用不了的东西。6.2 后续扩展方向这套多模态采集方案虽然是为隧道场景设计的但其实验和沉淀下来的方法论可以外推得很远。地下车库场景本质上和隧道高度相似只是车速更低、楼层结构更复杂矿区场景的粉尘和颠簸比隧道还要苛刻但我们的防护和减振设计可以直接平移过去高架桥下方的城市道路也是典型的GNSS遮蔽场景同样能受益于这套航位推算加地图匹配的方案。我们在规划的下一个迭代方向是引入更多的4D毫米波雷达它能够直接测量高度维对隧道内遮挡目标的检测能力比传统毫米波雷达更强。另一个方向是边缘计算网关的升级在采集的同时完成一部分数据清洗和预处理减少回传和人工标注的成本。有一个让我印象很深的小插曲一次测试结束后我们检查存储数据发现有一段视频记录了隧道顶部长期渗水形成的矿物结晶从车灯的反射光里呈现出非常漂亮的纹理。这种在普通环境下根本见不到的细节恰恰说明了隧道场景的复杂性——它不只是考验数据的采集能力更考验一个人对极端环境的感知和理解。干这个项目最大的收获不是某一块具体的传感器参数调好了而是你开始真正敬畏环境决定方案这条铁律。在隧道里纸上谈兵永远是行不通的。 
长河君 · 2026/10/20 7:41:41 · 阅读 1.2k 隧道场景商用车多模态数据采集：GNSS遮蔽下的融合定位与工程实践
隧道场景的商用车数据采集圈外人听起来可能觉得不就是往隧道里跑一趟装几个传感器嘛但真正干过的人都知道这条赛道几乎是数据采集领域最硬核的试炼场之一。无GPS信号只是最表面的问题粉尘、震动、温差、电磁干扰、光照突变、活塞风每一项单独拎出来都能让一套精心调好的采集系统当场翻车。我这两年跟着某商用车自动驾驶团队做过隧道场景的多模态数据采集系统从传感器选型到融合定位再到数据处理踩了不少坑也沉淀了一套相对完整的方法论这里系统梳理一遍。这套方案适合谁参考如果你正在做矿区、隧道、地下车库、高架桥下这些GNSS遮蔽场景的商用车数据采集或者你在做组合导航、多传感器融合相关的项目这篇文章应该能帮你少走几个月弯路。我会把传感器怎么选、装在哪儿、同步怎么做、定位怎么融合、恶劣工况怎么防护以及我们实测时遇到的那些教科书里不会写的问题全部摊开来讲。1. 隧道为什么被称为数据采集的天然考场1.1 无GPS并不只是没信号这么简单很多人对隧道内无GPS的理解停留在收不到卫星信号定位失效这个层面但实际上对于商用车数据采集系统来说问题远不止于此。首先是信号遮蔽的突然性。车辆进入隧道往往是在行驶状态下瞬间发生的GPS信号从满格到完全丢失可能只有几十米距离。这意味着组合导航系统必须在极短时间内完成从卫星修正到纯推算的状态切换如果切换逻辑设计得不好位置输出会出现明显的跳变而这些跳变会直接污染采集到的轨迹真值后续用来训练感知模型或验证控制算法时这些带跳变的数据根本没法用。其次是多路径效应的残留。隧道口附近往往还有一部分折射、反射的卫星信号能被接收机捕获这些信号带有巨大的伪距误差如果融合算法没有针对性地做置信度管理就会把错误但有信号当成可靠修正导致定位结果比完全没有GPS时还要糟。我们测试时发现有些商用组合导航模块在隧道口附近的位置误差能达到几十米罪魁祸首就是这种残留多路径信号。再就是隧道长度和结构的差异。短隧道可能一两百米就出来了系统还没来得及完全进入纯推算模式就又恢复了GPS而长达数公里的隧道完全依赖惯导和轮速推算累积误差会呈时间的三次方增长。如果隧道内部还有弯道、坡道、分岔推算难度更是直线上升。不同隧道的工况差异极大这就要求数据采集系统的定位方案要有很强的自适应能力而不是一套参数打天下。1.2 恶劣工况清单从粉尘到杂散电流商用车本身的工作环境就不干净隧道里更是把恶劣程度拉满了。我列一下我们实测时遇到的主要干扰源每一条都在真实项目里给系统制造过麻烦。粉尘和油污是最直观的。隧道施工阶段或未完全清洁的运营隧道里扬尘浓度很高粉尘会附着在激光雷达的窗口和摄像头的镜片上导致点云出现大量噪点、图像对比度下降。商用车底盘的油泥还会被轮胎甩起来打在传感器外壳上如果不做防护设计两个小时的数据质量可能就明显劣化了。湿度和凝露问题同样不容小视。隧道内常年高湿度尤其是南方雨季或山区隧道传感器外壳、连接器接口处容易出现凝露轻则导致电气接触不良重则直接短路烧毁设备。我们有一台IMU就是死在凝露上的排查了很久才发现是外壳密封圈老化导致水汽渗入。振动冲击是商用车独有的麻烦。商用车自重十几吨起步行驶在隧道接缝、不平整路面或减速带上时底盘振动频率低但幅值很大瞬时冲击可以轻松超过好几个g。这对IMU这类对运动敏感的传感器是严峻考验安装方式不当的话测出来的角速度和加速度数据会带着大量结构性噪声。温差造成的热漂移也是被很多人忽略的坑。隧道内外温差在冬季可以达到二三十度设备从外部环境进入隧道后机箱内部温度快速变化IMU的零偏会随之漂移如果是精度要求高的惯导系统这种温漂在长隧道里的累积误差是非常可观的。还有电磁干扰特别是铁路隧道或电气化公路隧道。接触网、轨道回流产生的杂散电流会在附近形成较强的电磁场未做屏蔽处理的信号线容易耦合进共模干扰表现为数据帧校验错误率升高、传感器输出出现毛刺。这是很隐蔽的问题因为设备在常规环境下测试一切正常只有到隧道现场才会暴露。2. 传感器选型与布置先想清楚每个传感器在隧道里到底靠什么活着2.1 各传感器的任务边界划分多模态系统这个词听着高级但落到工程实现上第一个问题就是每个传感器负责干什么它的能力边界在哪里。边界划分不清融合算法就会无所适从。我们在隧道场景采集系统里用的传感器组合是这样的激光雷达主要负责三维环境感知和建图。隧道内结构特征明显墙壁、拱顶、管道、灯具都是天然的几何特征非常适合激光雷达发挥。考虑到商用车采集需要较大的垂直视场角和较远的有效测距我们选择了多线机械式雷达兼顾隧道顶部结构和前方远距离目标的探测。毫米波雷达负责速度测量和远距离目标跟踪。隧道内光线条件差摄像机会受光照影响但毫米波雷达对光照完全不敏感在粉尘和烟雾环境下的穿透能力也比激光雷达强不少。它被用于补充激光雷达在恶劣视觉条件下的感知冗余。摄像头提供语义信息和交通标志识别。隧道内的限速标志、警示灯、车道线、洞口轮廓这些信息激光雷达和毫米波雷达都提供不了必须靠视觉。我们用了高动态范围的工业相机因为隧道口的光照突变是所有相机厂商都绕不过去的坎。IMU和轮速传感器组成航位推算的核心。IMU提供三轴角速度和加速度轮速传感器提供纵向车速约束这两者是隧道内无GPS时定位的救命稻草。我们选IMU时特别看重零偏稳定性和温度特性而不是单纯追求指标上的高精度。气压计和高精度地图作为辅助修正手段。气压计可以估算高程变化用于坡道识别高精度地图则提供了隧道内道路拓扑和里程标志信息配合里程计可以做地图匹配修正。每个传感器的任务边界必须在方案设计阶段就定清楚否则到了融合阶段数据打架的概率会非常高。比如摄像头补光是否会影响激光雷达毫米波雷达探测到的隧道墙壁回波怎么和激光雷达点云对应这些问题不提前规划后面每个都能让人挠头。2.2 布置位置与安装细节的坑传感器选型定下来之后布置位置就成了决定数据质量的关键一环。我们在这上面踩过的坑基本可以编一本小册子了。激光雷达我们最终选择安装在驾驶室顶部偏前方的位置用定制支架固定。这个位置的好处是视野开阔能看到车头前方的完整路况和隧道顶部结构缺点是离地高度大商用车行驶在隧道内时颠簸会被放大雷达的振动比想象中要剧烈得多。我们第一版支架用的是刚性连接结果点云里出现了可见的高频抖动伪影后来在支架和车顶之间增加了减振橡胶垫抖动问题才基本消除。摄像头布了四个前视主摄、前视广角、后视、侧视。前视主摄负责车道线和交通标志广角负责隧道口的视野覆盖。这里有个很关键的细节——摄像头安装角度必须预留调整余量因为商用车空载和满载时车身姿态差别很大载重会导致车头抬高或压低如果安装角度没有余量满载工况下视场角可能会完全偏移出需要观测的区域。IMU和轮速传感器的安装更是讲究。IMU应该尽量安装在车辆质心附近因为这个位置的运动学特性最接近整车运动模型同时要确保安装面平整、刚性强如果装在一个容易发生局部形变的钣金件上IMU测到的就是钣金的运动而不是车辆的运动。商用车车架纵梁是相对理想的安装位置自带一定的刚度但要注意远离发动机、变速箱这些振动源。轮速传感器的安装有很多商用车特有的坑。商用车的轮速信号通常来自ABS系统的轮速齿圈信号是脉冲形式。这个信号虽然可以直接接出来用但要注意几个问题一是齿圈齿数不同车辆不一样必须精确配置脉冲当量二是ABS系统在车辆急刹车或车轮抱死时会有特殊逻辑轮速信号可能被切断或替换这会让里程计瞬间失准三是商用车双胎并装的轮位左右轮速差信息几乎没用不能用乘用车的轮速差模型来估算横摆角速度。数据采集主机的安装位置我们放在了车厢前部独立隔舱用工业级工控机加固态硬盘阵列。这里要特别提醒的一点是商用车的电气系统是24V部分车型是12V而且整车电压波动比乘用车大得多启动瞬间电压跌落和发电机电压浪涌都很常见。所有采集设备都必须经过稳压电源模块供电最好再加一级隔离电源否则一次发动机启动就可能烧掉一片设备。2.3 传感器防护与线束整理的工程化处理防护设计看起来是体力活但恰恰是最能体现工程经验的地方。激光雷达的窗口我们做了定制的防护罩既能挡飞溅的泥水又不会遮挡扫描视场角。防护罩材质选的是高强度聚碳酸酯耐磨且透光率损失小用了一个多月也没有明显的透过率衰减。所有外露连接器都选用了工业级防水航空插头等级至少IP67连接器尾部做了热缩管加防水胶双重密封。线束在车架上的走向要避开排气管和高压线缆前者是热源后者是电磁干扰源。信号线全程使用屏蔽双绞线屏蔽层单端接地这个细节能显著降低电磁耦合噪声。还有一个容易被忽视的点是线束的长度余量。商用车在行驶中车架会有扭转线束如果没有足够余量长期弯折会导致内部导线断裂这种故障非常隐蔽表现是间歇性的数据丢失排查起来极度痛苦。我们在所有关节位置都留了足够的回弯弧度并且用波纹管包裹实测下来可靠性提升非常明显。3. 无GPS时组合定位怎么做从航位推算到场景匹配3.1 组合导航的基本盘惯导与轮速隧道内没有任何卫星信号可用时定位的核心逻辑是航位推算——从已知位置出发通过测量车辆的加速度、角速度和轮速逐步推算后续的位置和航向。这个过程中惯导和轮速各自扮演不同角色。IMU提供的三轴角速度可以推算航向变化率三轴加速度经过姿态变换后可以推算速度变化。但IMU有一个致命弱点——零偏。陀螺仪的零偏会使航向角积分误差随时间增长而航向角误差一旦出现整个位置推算都会沿着错误的方向越走越远。加速度计的零偏则会让速度积分产生偏移最终反映为位置误差的加速增长。轮速传感器在纵向速度测量上比IMU可靠得多它直接测量车轮的旋转速度换算成车速不存在零偏漂移问题。所以工程上通常的做法是横向和航向变化主要由IMU负责推算纵向速度和里程约束由轮速传感器提供。两者结合构成一个二维平面上的航位推算模型这是无GPS定位的基本盘。但轮速也不是无条件可信的。商用车在湿滑路面或急加速时驱动轮会有打滑急刹车时车轮会有抱死拖滑。这两种情况都会导致轮速信号和真实车速严重偏离。为了抑制这个问题我们引入了前后轮速一致性校验——商用车通常多个轮位都有轮速传感器当各个轮位的脉冲速度差异超过阈值时判定当前处于打滑或滑移状态里程计对这个时段的数据打上低置信度标签融合算法里自动降低权重。3.2 隧道场景特有的修正手段光靠惯导和轮速误差累积仍然无法避免。隧道场景里还有一些特有的修正手段可以利用这些是我们在项目里逐渐摸索出来的。气压计测高程。隧道虽然是近似水平的但很多市政隧道和山区隧道内部是有纵坡的坡度从百分之几到百分之十几都有。气压计对高度变化敏感可以辅助判断当前是否在上坡或下坡从而修正高程方向的位置估算。但这里有坑——隧道内车辆通行产生的活塞风会造成局部气压波动气压计读数会叠加一个随时间变化的噪声。我们试过用低通滤波把活塞风的动态分量滤掉只保留缓变的纵向分量效果尚可但滤波时间常数需要针对不同隧道长度做标定是一个需要耐心调试的过程。高精度地图匹配。如果在采集前已经获得了隧道内的高精度地图包含道路中心线、里程桩、车道边界、洞口位置等就可以把推算轨迹和地图做匹配当航位推算的位姿与地图几何吻合时置信度高偏离时置信度低。这本质上是一种先验约束能把漂移限制在一定范围内。我们用的是车道级地图加里程计融合的方式在隧道内定位误差可以被限制在米级甚至亚米级完全能满足数据采集对轨迹精度的需求。车体运动学约束。商用车不是全向移动的点它有阿克曼转向或铰接转向的运动学约束前后轴的运动轨迹之间存在几何关系。在融合算法里加入车体运动学约束可以过滤掉一部分不符合车辆运动规律的推算结果。这个约束在隧道内的直线段几乎不起作用但在弯道段效果非常明显能把横向漂移拉回来不少。3.3 状态切换逻辑与初始化前面说过GPS从有到无是渐变过程系统需要在不同状态之间平滑切换这是融合定位方案里最容易出问题也最容易被忽视的地方。我们的做法是设计了一个四级状态机完全GPS修正、GPS弱修正、纯航位推算、地图匹配修正。状态切换的判据不仅包括卫星数量、定位精度因子这些常规指标还包括卫星信号的多路径特征量。当检测到多路径特征量异常升高时即使卫星数量还够系统也会主动降级到弱修正模式避免被错误信号带偏。初始化也是关键一环。车辆进入隧道前如果系统没有完成良好的姿态初始化那么进入隧道后的航位推算精度会大打折扣。我们会在车辆进入隧道前的开阔路段主动做一段直线加速和匀速行驶的标定流程让融合算法收敛姿态和轮速比例因子确保带着满状态进隧道。长隧道里如果中途停车比如遇到前方拥堵或施工管制IMU零偏需要重新估计不能沿用停车前的零偏值。我们在系统里实现了一个停车检测功能利用轮速信号和车辆加速度综合判断车辆是否静止一旦检测到静止状态持续两秒以上立即触发零偏在线估计用静止时的IMU读数来更新陀螺仪零偏。这个功能在实测中非常管用能把重新起步后的航向漂移压低一个数量级。4. 数据链路与时间同步多模态系统最容易翻车的地方4.1 时间戳统一所有传感器必须说同一种时间多模态数据采集的核心价值在于多个传感器的数据可以对齐到同一时刻用于后续的感知融合、标注和模型训练。如果每个传感器的时间基准各说各话那这套系统采集的数据在应用层面基本等于废品。我们遇到的第一个问题是时钟源不统一。激光雷达和摄像头都有自己的系统时钟IMU有自己的采样率如果各传感器独立计时哪怕每天只差几毫秒累积起来也会导致严重的数据不同步。我们的解决方案是引入统一的PTP精确时间同步协议由数据采集主机作为时间主时钟各传感器作为时间从设备通过PTP协议自动对时。在硬件层面我们为所有关键传感器都配置了硬件触发线。激光雷达的每一帧扫描都会输出一个触发脉冲信号这个脉冲同时送给摄像头和采集主机摄像头收到脉冲后立刻抓拍一帧图像采集主机则在脉冲时刻为这帧数据打上精确的时间戳。这样一来激光雷达和摄像头的帧就天然同步了。IMU虽然无法用硬件触发对齐到帧级但它的采样率远高于其他传感器我们通过插值把IMU数据重采样到激光雷达的帧时间上。时间同步的精度直接影响融合算法的效果。举个例子如果摄像头图像和激光雷达点云的时间差超过几十毫秒车在高速运动时同一个目标在图像和点云中的位置就会出现明显的视角差异导致标注困难甚至错误。经过PTP加硬件触发双重保障我们系统的同步误差可以控制在1毫秒以内基本满足所有下游应用的需求。4.2 数据回传与存储的工程细节隧道内的数据采集有一个特殊问题——数据传输和存储必须在离线条件下完成。隧道内没有可靠通信网络指望实时回传数据到云端是不现实的所有原始数据必须在本地的存储阵列里暂存等车辆出隧道后统一回传。存储系统的设计要比想象中复杂。激光雷达点云多路视频IMU高频数据总数据速率可以达到每秒几百兆字节一趟长隧道测试下来就是上百GB甚至几个TB的数据量。我们用了双盘位冗余存储方案数据实时写入两块独立固态硬盘做镜像防止单块硬盘故障导致数据丢失。硬盘选的是工业级宽温型号因为装在车上要考虑高温季节驾驶室驻车后内部温度上升的场景普通消费级硬盘在这个温度下很容易掉盘。掉电保护是商用车场景的独有需求。商用车驻车时可能会被司机直接断开总电闸如果不做处理突然断电会导致文件系统损坏、正在写入的数据块丢失。我们在存储系统上加了超级电容模组检测到断电瞬间能给系统提供几秒的续航时间让程序有时间写完当前文件并安全卸载文件系统。这套机制救了我们好几次有一次数据采集过程中车辆电瓶亏电整车上电瞬间全部设备掉电超级电容撑住了最后的写入过程硬盘上连一个损坏文件都没有。文件命名和目录结构也是需要提前规划的细节。我们的命名规则包含了日期、时段、路线编号、传感器类型、工况标记等字段这样任何一段数据都能快速定位到对应的采集条件和环境信息给后续的数据管理减轻了大量负担。5. 实测排查实录三个典型的翻车案例5.1 轮速脉冲丢失导致的定位跳变某次在一条长约三公里的隧道里做测试车辆行驶到隧道中段时融合定位输出突然出现了约十几米的横向跳变然后又慢慢拉回来。一开始我们以为是IMU数据问题但回放日志发现跳变发生的瞬间轮速传感器出现了连续数百毫秒的脉冲丢失。排查过程是这样的先检查轮速传感器的电气连接发现连接器端子有些许氧化迹象但清理后问题依旧再检查齿圈和传感器探头之间的间隙发现商用车在重载工况下后桥变形量较大探头和齿圈的间隙会发生变化间隙过大时信号幅度衰减严重偶尔会低于整形电路的门限电压导致脉冲丢失。解决思路有两个方向。一个是从硬件上换用间隙适应性更好的传感器或者弹簧加载式的探头另一个是从软件上对轮速信号做质量监控和预测补偿。我们两个方向都做了硬件上选用了磁阻式轮速传感器替代原来的磁电式产品信号幅度和间隙适应性都有改善软件上引入了一个基于车辆动力学的轮速速度估计器当检测到轮速丢失时用上一时刻的纵向加速度和当前挡位来推断合理的车速范围把跳变控制在一个可接受的小范围内。这个案例给我们的启示是商用车底盘是高度非线性的系统任何传感器的安装状态都会随着载荷、温度、磨损而变化不能指望标定一次就永远可靠系统必须要有实时监测和自适应能力。5.2 气压计被活塞风干扰导致高度误判另一个让我们挠头许久的问题出现在气压计辅助高程定位上。某段隧道坡度较大系统在爬坡段输出的高度值却出现了一个先上升再下降的驼峰式误差和实际的纵坡曲线明显不符。起初我们怀疑是气压计的灵敏度不够但换了更高精度的传感器后问题依旧。后来查阅气象资料和隧道通风设计规范才想明白问题出在隧道内车辆快速通过时产生的活塞效应。当一辆大车在前面高速行驶时会在隧道内形成明显的局部气压梯度传感器感受到的气压变化和真实高度变化混合在一起很难区分。处理思路是增加一个环境气压参考通道。我们在采集车之外设置了一个静止的参考气压计部署在隧道外的气象站位置同时记录隧道外的实时气压采集车上的气压读数减去参考气压后再换算高度变化。这样能消除大部分天气性气压波动但对于隧道内动态的活塞风干扰还是需要配合滤波处理我们最终采用了一个自适应陷波滤波器能够识别活塞风的特征频率并做针对性衰减。这个组合方案应用后高度误差显著减小。这个案例给我们的教训是隧道内的微气候环境复杂程度远超普通室外场景任何依赖环境物理量的传感器都必须评估环境因素被信号污染的风险并设计与之对抗的机制。5.3 摄像头在隧道口强光切换下的过曝车辆从明亮的隧道外驶入昏暗的隧道内光线强度在短短一两秒内变化几个数量级摄像头如果自动曝光调整跟不上会出现一段较长时间的过曝或欠曝画面感知算法在这种画面上基本处于失效状态。我们一开始使用的工业相机自动曝光速度不够快从进隧道到画面恢复正常大约需要两三秒这期间图像完全是白的什么信息都采集不到。后来换了一款支持HDR和多帧融合的相机情况有所改善但在最极端的光照突变下依然有可见的调整延迟。最终的解决方案是软硬结合。硬件上使用了大靶面、全局快门、HDR模式的相机并且在前视方向加装了一片渐变灰滤镜——上暗下亮能够让天空区域的进光量被适当压低保留路面区域的信息。软件上我们修改了自动曝光算法增加了对GPS位置和隧道入口拓扑的先验利用当车辆接近判定为隧道入口的区域时主动将曝光目标值调到暗光模式提前应对即将到来的光线变化。这套组合下来隧道口的光照突变问题基本被解决画面恢复时间从两三秒缩短到几百毫秒感知算法在更多的时候处于有效工作状态。6. 从数据采集到模型落地这套方案还能怎么用6.1 数据质量评估指标采集了这么多数据如果质量没法量化评估下游用起来还是不放心。我们在项目里建立起了一套针对隧道场景的数据质量评估体系主要包括几个维度。时间同步质量通过多传感器触发延迟的方差来衡量我们把各传感器之间的触发时间差以毫秒为单位记录在日志里统计P95值要求全程低于2毫秒。定位轨迹质量上重点关注纯航位推算段落的累计漂移率通常用每公里的横向误差和纵向误差来衡量隧道场景下横向误差控制在1.5米以内就算合格。传感器健康状态则包括点云反射率异常比例、图像模糊度评分、IMU温漂速率等指标。这些指标会在每条数据采集任务结束后自动生成一份质量报告高于阈值的段落被标记为可用低于阈值的段落标记为需复核或废弃。这样数据团队在交付前就能心中有数不需要下游工程师拿到数据后才发现一堆用不了的东西。6.2 后续扩展方向这套多模态采集方案虽然是为隧道场景设计的但其实验和沉淀下来的方法论可以外推得很远。地下车库场景本质上和隧道高度相似只是车速更低、楼层结构更复杂矿区场景的粉尘和颠簸比隧道还要苛刻但我们的防护和减振设计可以直接平移过去高架桥下方的城市道路也是典型的GNSS遮蔽场景同样能受益于这套航位推算加地图匹配的方案。我们在规划的下一个迭代方向是引入更多的4D毫米波雷达它能够直接测量高度维对隧道内遮挡目标的检测能力比传统毫米波雷达更强。另一个方向是边缘计算网关的升级在采集的同时完成一部分数据清洗和预处理减少回传和人工标注的成本。有一个让我印象很深的小插曲一次测试结束后我们检查存储数据发现有一段视频记录了隧道顶部长期渗水形成的矿物结晶从车灯的反射光里呈现出非常漂亮的纹理。这种在普通环境下根本见不到的细节恰恰说明了隧道场景的复杂性——它不只是考验数据的采集能力更考验一个人对极端环境的感知和理解。干这个项目最大的收获不是某一块具体的传感器参数调好了而是你开始真正敬畏环境决定方案这条铁律。在隧道里纸上谈兵永远是行不通的。