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+地图融合方案，配合少量锚点，系统在锚点之间的连续定位能力会明显提升。

商用车队和资产追踪也是重要场景。集装箱、牵引车、冷链车在港口、货场、仓库之间穿梭，时常进入信号遮挡区。如果调度平台在遮挡区就看不到车辆位置，运营效率和安全性都会受影响。ST+TomTom这类方案最想解决的就是这种“遮遮掩掩”的复杂场景，让资产在任何一段路径上都能保持tracking。

4.3 传感器选型随场景变化的思路

同样是IMU+地图融合，不同场景对传感器的要求差别很大。消费级无人机、手机、人穿戴设备，用的是几块钱到十几块钱的消费级IMU，零偏稳定性差一点，但胜在体积小、功耗低。汽车和工业AGV则要用车规级或工业级IMU，零偏稳定性、耐温范围、抗振动能力都强很多，价格也高出一个量级。

选型时最怕的就是拿消费级传感器去做长时间高精度定位，最终结果一定是跑偏得没法看。反过来，在成本敏感的设备里强行用车规级传感器，也可能导致产品价格失去竞争力。先明确场景对定位精度、持续时间和安全等级的需求，再回头挑传感器，这个顺序不能乱。

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 一条完整的定位数据流水线

我把整个流程拆成几步，方便你对照自己的项目：

1. 采集IMU原始数据：加速度计和陀螺仪输出，通常是100到200 Hz的采样率。
2. 校准：开机静止采集一定长度数据，计算零偏；有条件下做温度补偿和安装方向标定。
3. 姿态解算：利用陀螺仪积分和加速度计/磁力计观测，输出姿态四元数或欧拉角。
4. 航位推算：把加速度转换到导航坐标系，积分得到速度和位置增量。
5. 外部观测融合：GNSS、里程计、Wi-Fi、蓝牙等观测值进入卡尔曼滤波器，修正推算结果。
6. 地图匹配：滤波结果与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秒系统就会出问题。这个答案决定了你要不要上这套组合，也决定了你后面的算法和硬件选型方向。定位这东西，看起来只是“一个坐标”，真正做起来全是细节，希望这篇能帮你少走几步弯路。