ST与TomTom联手，GNSS失效下的连续定位方案解析

ST和TomTom这个名字放在一起很多人第一反应是一家做芯片的一家做地图的怎么突然组队搞地理定位了但你要是做过车载导航、AGV调度或者哪怕只是在CBD写字楼地下车库找过车大概就能理解这门生意有多硬。GNSS在城市峡谷、隧道、地下停车场和密集厂房里经常直接失锁或者狂跳几十米而这个行业又不允许系统的定位在一个关键节点上突然消失几分钟所以你必须有一套“断了GPS也能撑住”的备份方案。这次合作说白了就是用ST的传感器和射频产品把“身体”做好用TomTom的地图和定位算法把“大脑”补上组合出一套不依赖纯GNSS信号的连续定位工具方案。对开发者来说这其实是一个很明显的信号——传感器融合加地图匹配已经从前几年的论文选题变成可以批量落地的工程方案了。这篇文章我就从这个合作的底层逻辑聊起把GNSS失效的本质、惯性导航和地图匹配的原理、真实场景怎么落地、以及我自己做类似定位项目时踩过的坑一次性说清楚。1. 从两个“老牌玩家”的合作看定位行业缺了什么1.1 ST和TomTom各自的底牌ST在定位圈子里的存在感一直很强只是普通人不太注意。它的Teseo系列GNSS接收机芯片覆盖了汽车和工业市场支持多星座、多频段是很多车载导航模块的“心脏”。另一边ST的MEMS惯性传感器也是出货量巨大的产品线比如LSM6DSOX、ISM330IS、ASM330LHHX这些其中ISM330IS内置了智能传感器处理单元可以直接在传感器内部跑一些轻量级算法ASM330LHHX则是车规级的六轴IMU面向功能安全要求较高的场景。再加上STM32生态ST手里其实握着一整套“感知处理”的硬件链条。TomTom这边很多人对它的印象还停留在“卖导航仪的老牌公司”但它现在的核心资产是地图数据、实时交通信息和定位服务。TomTom的地图覆盖了全球主要道路并且有车道级甚至高精地图产品线定位API和Indoor Mapping室内定位方案也是他们在重点推的服务。换句话说TomTom握着的是“位置语义”和“地图拓扑”这两张牌。这两家各自的底牌放一起看互补性非常明显。一个能提供位置信号的物理来源一个能提供位置信号落地后的参照系。问题是很多项目在这两者之间缺了一座桥而这恰恰是这次合作被行业关注的原因。1.2 这种合作补的是什么短板搞过GNSS项目的人都有一种体会天线放得再好、接收机再贵也架不住环境遮挡。纯GNSS的定位结果可以用四个字概括——时好时坏。这在消费级导航里忍忍就算了在车规、物流、机器人应用里是没法接受的。比如一个自动泊车系统进地库后GNSS一丢如果没有任何别的定位手段车直接不知道自己在哪这车你让它怎么停业界早就知道解法在哪把惯性传感器、轮速、地图、甚至Wi-Fi和蓝牙观测都拉进来做多源融合。但真正把“硬件软件地图”全部打通的产品化方案一直不多。原因很简单这是一个跨行业的系统工程需要半导体公司、地图公司、算法公司一起磨接口和标定流程。ST和TomTom的合作本质上就是在补这个工程化短板。TomTom的定位算法需要接入高精度的传感器数据ST的传感器需要一个能持续修正漂移的上层手段两边谁也不太可能靠单干把这个闭环做完整。这次合作把GNSS接收机、MEMS惯性传感器、地图约束这几个环节串起来形成一个开箱即用的工具包对下游厂商来说省掉了自己找算法、找数据、再调硬件的漫长过程。2. GNSS“翻车”现场城市峡谷、隧道、地下停车场2.1 信号丢失不是概率问题是必然问题很多非定位行业的朋友会问GPS不是到处都有信号吗答案在测试场地里非常直观。我做过一个车载定位的实测从城市快速路进入隧道的一瞬间GNSS定位点还在路上正常走隧道里开过几秒后定位点要么突然跳到路外的楼群里要么干脆停在原地不动等到出隧道重新搜星又猛地弹回真实位置。这一段“失联”如果发生在自动驾驶系统里后果不用多讲。隧道、地下车库、密集厂区、立交桥下这些场景都有一个共同点卫星信号被物理遮挡。GNSS接收机需要同时锁定至少4颗卫星才能解算出三维位置环境稍微一变可见卫星数掉到3颗以下定位结果就直接不可用。更复杂的是高楼之间虽然看得见天空但信号被反复反射定位结果同样不可信。所以严格说GNSS在城市场景里的短暂丢失不是小概率事件而是每天都会发生的常态。2.2 多路径效应和卫星几何差如何把定位精度带偏就算卫星没完全丢城市峡谷里的定位精度也会大打折扣。直接信号被高楼反射后会和直达信号一起进入接收机产生多路径效应。反射信号走过的路径更长到达时间偏晚这会让接收机算出的伪距出现误差反映到定位结果上就是位置被带偏。如果反射信号比直达信号强接收机还可能锁定错误信号一跳就是几十米。还有一个容易被忽略的问题叫卫星几何分布。定位精度除了取决于测距误差还取决于天空中可见卫星的空间分布。在高楼密集区域卫星集中在头顶很小的角度范围几何结构很差即便测距精度不变最终的水平定位误差也会被放大好几倍。这时候你会发现GNSS定位点在一个点上绕圈或者缓慢漂移根本无法满足车道级判断。RTK和PPP这类增强手段在一定范围内能改善精度但RTK依赖参考站的差分改正数信号遮挡严重时改正数链路一样会断PPP则需要较长的收敛时间动态场景下不太实用。所以行业后来都转向了同一件事别让GNSS唱独角戏给它配一个能在信号丢失时顶上的“惯性备份”。3. 惯性导航地图匹配这套方案的核心技术拼图3.1 IMU怎么从零开始推算位置IMU的核心器件是加速度计和陀螺仪。加速度计测量物体受到的比力陀螺仪测量角速度。有了这两样理论上就可以实现惯性导航先通过陀螺仪数据解算出当前的姿态再把加速度转换到导航坐标系对它做一次积分得到速度再做一次积分得到位移。原理听着不复杂但工程上有个让人头疼的问题积分会把误差越积越大。加速度计有一个零偏误差传感器静止时输出的加速度不是精确的0而是一个很小的偏差。这个偏差在两次积分之后会导致位置误差随时间平方增长。举个直观的例子一台消费级IMU的零偏如果有0.01g在没有任何修正的情况下10秒后推算出的位置就可能偏出去好几米。所以纯惯性导航注定只能“短时维持”没法“长期精确”。业内通常把惯性导航的持续可靠时间定义为从几秒到几分钟不等取决于传感器等级和运行环境。这也决定了任何IMU定位系统都不能只靠自己运行必须有一颗“外部约束”来定期纠偏。3.2 传感器融合卡尔曼滤波与地图约束传感器融合最常用的工具是卡尔曼滤波。你可以把它理解成一个大脑在做“闭眼走路偶尔睁眼”的协同闭眼时靠IMU积分往前走位置会逐渐漂移睁眼时用GNSS定位或地图特征把位置拉回正确位置同时大脑还能根据睁眼时的偏差反过来修正闭眼时IMU的零偏估计让下一次闭眼走得更准。工程实现上松耦合和紧耦合是两种常见策略。松耦合简单粗暴把GNSS解算出的位置、速度直接作为观测值喂给滤波器紧耦合则深入到卫星观测层面用伪距、载波相位等原始观测参与融合精度更高但实现复杂度明显上升。车载和机器人项目里松耦合因为开发周期短、调试方便仍然占据主流。地图约束则是另一层纠偏手段。融合后的轨迹位置如果直接落在马路牙子上、楼顶、河里说明定位结果和现实不符。地图匹配算法会拿当前轨迹和道路网络比对把位置“吸”到最合理的路段上。常用的算法是基于隐马尔可夫模型HMM的匹配每个定位点是观测状态每条道路是隐含状态通过计算定位点到道路的距离、车辆航向与道路方向的夹角来判断当前最可能在哪条路上并保留多个候选路径等后续观测来排除歧义。3.3 TomTom地图数据在方案里的角色TomTom在整套方案里最重要的角色是提供“具有拓扑约束的世界模型”。普通导航地图只有道路级别高精地图则有车道级别、路肩、护栏、标线等精细信息。GNSS信号弱的时候车道级地图能把定位误差约束到“车辆在第三车道”这个级别而不仅仅是“在某某路上”。TomTom的Indoor Mapping还覆盖室内场景比如商场、停车场、机场。配合蓝牙、Wi-Fi、地磁观测系统可以在GNSS完全失效的室内空间继续维持定位。这种地图数据与传感器融合算法的深度耦合正是普通“GNSS模块供应商”做不出来的部分。因为地图不只是一堆坐标线它还包含拓扑关系哪些道路互通、哪些方向禁止转向、停车场有几层、坡道怎么连接这些语义信息对定位推理有决定性的修正作用。4. 从汽车到机器人哪些场景真正需要这类方案4.1 汽车隧道、地库、ADAS功能汽车是这套方案最大的需求方。车载导航从最早“显示一个箭头”发展到现在的高精地图导航、ADAS辅助驾驶、自动泊车对连续定位的依赖越来越强。隧道里导航必须继续显示车辆位置地库自动泊车必须知道车相对车位在哪高快路上的车道级引导需要知道当前处于哪条车道。车规场景还有一个特殊要求功能安全。定位模块如果失效可能会影响整个系统安全决策所以硬件要满足ASIL等级要求软件要有诊断机制。ST的ASM330LHHX这类车规IMU在出厂时就考虑了这些温度范围宽、零偏稳定性好、漂移小而且能在故障时输出诊断标志。TomTom的地图服务则要做OTA更新保证道路变化后地图依然有效。4.2 物流与机器人连续定位是刚需自动叉车、AGV、服务机器人这些产品工作环境往往是室内或半室内。工厂车间里没有GNSS信号AGV通常需要依靠激光雷达、UWB、地面二维码来定位这些方式各有局限。UWB需要布基站二维码需要贴地面激光雷达在灰尘大、环境空旷的仓库里容易退化。如果能引入IMU地图融合方案配合少量锚点系统在锚点之间的连续定位能力会明显提升。商用车队和资产追踪也是重要场景。集装箱、牵引车、冷链车在港口、货场、仓库之间穿梭时常进入信号遮挡区。如果调度平台在遮挡区就看不到车辆位置运营效率和安全性都会受影响。STTomTom这类方案最想解决的就是这种“遮遮掩掩”的复杂场景让资产在任何一段路径上都能保持tracking。4.3 传感器选型随场景变化的思路同样是IMU地图融合不同场景对传感器的要求差别很大。消费级无人机、手机、人穿戴设备用的是几块钱到十几块钱的消费级IMU零偏稳定性差一点但胜在体积小、功耗低。汽车和工业AGV则要用车规级或工业级IMU零偏稳定性、耐温范围、抗振动能力都强很多价格也高出一个量级。参数消费级IMU工业级IMU车规级IMU零偏稳定性较差常见几十度/小时较好几度/小时级别好稳定且经过校准工作温度0到70摄氏度-40到85摄氏度-40到105摄氏度抗振动/冲击一般较强强含诊断功能成本较低中等较高典型应用手机、穿戴、玩具机器人、无人机汽车、功能安全场景选型时最怕的就是拿消费级传感器去做长时间高精度定位最终结果一定是跑偏得没法看。反过来在成本敏感的设备里强行用车规级传感器也可能导致产品价格失去竞争力。先明确场景对定位精度、持续时间和安全等级的需求再回头挑传感器这个顺序不能乱。5. 开发者怎么上手从硬件评估板到定位API集成5.1 硬件和软件栈怎么选如果你现在想复现一套类似的方案我建议从ST的评估板起步。ST的SensorTile.box、X-NUCLEO-IKS01A3扩展板、Nucleo开发板都能很快跑起来如果目标直接是车规可以关注基于ASM330LHHX的评估套件。软件方面用STM32CubeMX生成工程加上X-CUBE-MEMS1扩展包能够直接读取传感器原始数据和姿态解算结果省去很多底层开发时间。地图侧注册TomTom开发者账号拿到API Key就能开始调用地图显示、搜索、路径规划、定位等开发接口。TomTom的文档和示例代码做得比较完善有JavaScript、Android、iOS多种SDK适合快速做原型验证。5.2 一条完整的定位数据流水线我把整个流程拆成几步方便你对照自己的项目采集IMU原始数据加速度计和陀螺仪输出通常是100到200 Hz的采样率。校准开机静止采集一定长度数据计算零偏有条件下做温度补偿和安装方向标定。姿态解算利用陀螺仪积分和加速度计/磁力计观测输出姿态四元数或欧拉角。航位推算把加速度转换到导航坐标系积分得到速度和位置增量。外部观测融合GNSS、里程计、Wi-Fi、蓝牙等观测值进入卡尔曼滤波器修正推算结果。地图匹配滤波结果与TomTom道路网络做HMM匹配输出最终位置。伪代码层面的逻辑大致是while running: acc, gyro read_imu() if not calibrated: accumulate_bias(acc, gyro) continue attitude update_attitude(gyro, acc) velocity, position dead_reckon(attitude, acc, dt) if gnss_fix_available: kalman.update(gnss_position, gnss_velocity) if map_available: matched match_to_map(position, heading) kalman.correct(matched) output(position, confidence)这个框架足够做原型验证了。真正的产品化还需要加传感器故障诊断、异常跳变检测、日志回放等外围机制。5.3 接入TomTom服务的调试节奏我给新手的建议是分三步走。第一步先不要接任何地图服务把传感器的数据采集和姿态解算跑通静态和动态都测一测自己心里有底。第二步接入TomTom地图显示API把滤波后的轨迹直接在底图上画出来这一步能直观看到算法在实景里的表现。第三步再考虑地图匹配和路径约束因为地图匹配调起来比较费时间如果前面数据质量差调多久都白搭。整个调试过程一定要记录原始传感器日志和GNSS日志最好带时间戳统一保存。定位问题有很强的偶发性今天这条路线好好的明天同一地点就飘了。没有日志回放你根本没法分析是传感器漂了、观测跳了还是匹配算法走到了岔路上。6. 实战中容易翻车的几个细节6.1 零偏校准与温度漂移零偏校准是所有IMU应用的第一道坎也是最常见的问题来源。很多新手把传感器往板子上一焊上电就读数静止状态下发现加速度计输出在0.005g附近乱跳陀螺仪输出也不是完美的0号数组直接就开始积分求位置。结果小车停在那里导航轨迹却在匀速向前“跑”。我的习惯是每次上电后强制设备保持静止至少3到5秒采样一批数据做平均作为本次启动的零偏估计。这能解决大部分静态零偏问题。但温度漂移是另一个坑传感器温度从冷启动到稳定运行可能上升十几度零偏也会跟着缓慢变化。带温度补偿的传感器会好很多但如果你用的是低成本的消费级IMU最好在算法里加一个温度变化检测温度变化大的时候重新估计零偏或者降低积分输出的置信度。6.2 坐标系对齐不矫正直接集成后面全是坑IMU安装到设备上之后它的测量轴和车体/机体坐标系不可能天然对齐。装歪几度看起来是个小误差但在航位推算里会被积分放大。陀螺仪的角速度偏差会让姿态越解越歪加速度投影到错误的方向上位置误差会以肉眼可见的速度增长。我在一个项目里就吃过这个亏。IMU装在一个测试支架上当时手头没有量角工具凭感觉大概装正了结果跑了一段直线测试轨迹偏了接近车道宽度。后来用六面静止法做了安装矩阵标定把IMU坐标轴到车体坐标轴的旋转关系算出来再跑同一段路轨迹就正常了。坐标系的统一这种细节只靠代码评审是看不出来的必须在装配工艺和软件里同时约定清楚最好在设备出厂时做一次自动标定。6.3 融合参数和地图匹配的野值处理卡尔曼滤波的参数设置是另一个容易翻车的点。观测噪声协方差设得太大滤波器会过度信任IMU推算GNSS已经在路口拐了弯轨迹才慢慢被拽过去设得太小又会轻信单个跳变的GNSS观测位置在隧道进出口疯狂抖动。这里没有一劳永逸的参数我的做法是把GNSS接收机输出的位置标准差、速度标准差实时接进滤波器作为自适应的观测噪声效果比固定参数好不少。地图匹配也有类似的“野值”问题。GNSS偶尔会在短时间内跳到大楼旁边如果单点匹配轨迹会被错误地吸引到一条岔路上。后来我改成滑动窗口匹配拿最近一段轨迹和道路网络做整体匹配确认当前最可能的道路再在候选道路上细化位置。这样单个野值的影响会被前后轨迹约束住不会把整条路线带歪。还有一个在现场经常出现的坑GNSS和IMU的采样时间没有严格对齐。GNSS通常输出频率低而且不固定IMU是高频率输出两个数据源的时间基准不一致融合前必须做时间同步。时间差哪怕只有100毫秒在高速运动场景下也可能造成好几米的误差。这个听起来不起眼但在用多传感器融合时几乎是必踩的坑。如果你也在做类似的定位项目或者正准备评估ST和TomTom这套方案我建议你拿到评估板后第一件事不是跑demo而是先搞清楚自己的使用场景对“连续可靠定位”的要求到底有多高——是丢失5秒可以接受还是丢失1秒系统就会出问题。这个答案决定了你要不要上这套组合也决定了你后面的算法和硬件选型方向。定位这东西看起来只是“一个坐标”真正做起来全是细节希望这篇能帮你少走几步弯路。