面向车辆导航的多用户云端地磁匹配定位技术研究*

赵 航纪新春*陆 一魏东岩袁 洪

(1.中国科学院空天信息创新研究院，北京 100094；2.中国科学院大学，北京 100049)

传统车载导航通常采用全球导航卫星系统(Global Navigation Satellite System，GNSS)与微机电系统(Micro Electro Mechanical System，MEMS)-捷联惯性导航系统(Strap-down Inertial Navigation System，SINS)组合的方式实现定位。

但在隧道、地下车库等环境下，由于多径效应与非视距的存在，GNSS信号质量会变差，低成本微机电惯性测量单元(MEMS-based Inertial Measurement Unit，MIMU)的漂移误差会使MIMU-SINS的组合导航性能迅速下降[1-2]。在此情况下，利用地磁匹配[3]定位提供的绝对位置信息可替代GNSS观测量，对MIMU-SINS的累积误差进行修正。近年来，智能手机导航已逐渐取代专用导航终端而成为大众车辆导航的主流方式[4]，利用智能手机搭载的MIMU、磁传感器以及通过蓝牙通信获取的车载诊断系统(On-Board Diagnostic，OBD)中的里程计信息进行融合，可实现低成本的车辆长时间无GNSS的准确定位[5]。

在地磁匹配过程中，地磁测量值与基准库的匹配计算量较大，并且随着路段的增加，地磁数据库的存储会越来越大，因此地磁匹配需要更大的算力和存储支撑，而利用手机端资源来进行地磁匹配计算具有很大局限性。基于云计算[6]，将地磁匹配算法置于云端服务器上执行，智能手机仅作为数据采集、信息传输终端的方案，可解决上述问题，并且能实现多终端用户的接入，共享地磁匹配定位服务。同时，将地磁数据基准库存储在云端，利用云计算资源统一调度的优势，可在云上对其统一进行管理与更新，同时减少智能手机端定位软件的部署成本。利用云端服务器的计算资源，地磁匹配可采用更加高效的算法，进一步提高地磁匹配精度。另外还保证了地磁数据库的安全性，减少了地磁敏感信息泄漏的风险。

针对地磁匹配定位在智能手机、车载平台上计算资源消耗大，存储资源占用大的问题，本文研究了多用户在线接入与云-端实时双向通信等云定位关键技术，搭建了面向多用户车辆地磁匹配定位的云平台。经测试，基于云平台的地磁匹配定位精度上与在智能手机本地进行解算时相当，性能上可保证多用户同时接入下导航定位服务的实时性与稳定性，具有较强的实用意义和推广意义。

1 地磁匹配定位技术

车辆地磁匹配定位分为离线建库和在线匹配两个阶段[7]，如图1所示。离线建库阶段，利用地磁异常场的特性与基准导航系统构建路网地磁基准模型，建立地磁基准库；在线匹配阶段，利用磁传感器对地磁场强进行采集，结合车辆里程计信息完成实测地磁数据里程刻度化，与地磁基准库匹配得到地磁匹配输出，进而与惯性解算的结果进行数据融合，得到最终的位置信息。

图1 车辆地磁匹配定位总体流程图

由于车辆行驶速度不尽相同，地磁匹配定位两个阶段的磁测量数据无法空间对齐，导致无法利用磁场空间分布特征进行匹配定位。为解决上述问题，需要将地磁测量值由时间序列转换为空间序列，利用里程刻度实现在线阶段实测数据与离线基准库数据的空间尺度对齐。图2所示为磁测量值等里程间隔空间转换过程。

图2 磁测量值时间序列变换至等里程间隔空间序列

1.1 离线基准库建立

在离线地磁建库的过程中，高精度基准导航系统以及磁传感器分别提供空间位置坐标、航向和三轴磁场强度值。基准位置同时用来计算车辆行驶里程，利用里程信息完成地磁特征线性格点的构建，可表示为:

式中:X表示空间坐标，θ为航向，T为时间，M为地磁测量值，(Mk，Xk，θk)map表示第k个地磁基准库格点。

利用式(1)完成行驶路径的线性地磁基准库构建后，通过转弯检测、交点检测和重复路段剔除处理，实现行驶路径的路段分割。然后，利用起始点位置、航向等信息，对各个路段的连接关系进行判别，得到路段间的关联矩阵，进而完成路网地磁基准库的构建，该流程如图3所示。

图3 路网地磁基准库建模流程

1.2 地磁在线匹配

为了减少单点匹配可能产生的误匹配，在车辆行驶里程上取距离为Dw＝w·d长度的实测地磁数据与基准库地磁数据进行滑动窗口匹配。其中，w表示窗口长度，d为里程采样间隔。匹配过程如图4所示。

图4 在线数据匹配示意图

2 云定位

采用滑动窗口以及零均值相关系数法进行地磁匹配计算量较大，在保证实时性的前提下，需要占用更多的资源。同时，地磁数据库需要占用一定存储空间，更新较为繁琐，仅依赖智能手机不能够满足实际推广使用的需求，基于此，本文研究了一种面向多用户车辆云端地磁匹配定位技术，可提供公共的地磁匹配定位服务。

2.1 地磁匹配云定位架构

为了实现地磁匹配云定位，需要搭建搭载地磁匹配定位算法的云平台。云平台基于Python的Flask Web框架构建后端程序，实现定位解算与智能手机的数据通信。智能手机通过Android APP实现对各传感器数据的采集、与云平台的通信以及定位结果的显示。在智能手机上，APP调用手机传感器获取地磁、MIMU数据，利用蓝牙连接车载OBD接口获取车辆轮速信息，将上述数据打包并通过互联网发送到云端。在云平台上，利用手机发送来的轮速、地磁数据与云端的地磁基准库进行匹配，得到实时地磁位置输出，再与MIMU数据进行融合解算，得到最终位置信息，将其返回到智能手机上并进行数据显示，如图5所示。

图5 地磁匹配云定位架构图

2.2 云-端双向实时通信与多用户接入

云平台在接收智能手机的原始定位信息的同时，还需要将定位结果返回，这就需要合适的消息推送方式。WebSocket是HTML5新增的一种全双工通信协议，客户端和服务端通过HTTP三次握手建立连接后，服务器会将HTTP协议升级为WebSocket协议，实现持久性的连接，该流程如图6所示。相比于传统的HTTP轮询方式，WebSocket可实现数据的双向传输，客户端向服务器发起请求，同时服务器也可主动向客户端推送消息[8]，从而实现云-端实时双向通信。基于WebSocket，智能手机可将地磁匹配定位所需的原始数据发送到云平台进行解算，同时在解算完成后，云平台可在第一时间向智能手机推送定位输出结果，避免了原先采用轮询所造成的计算负担和资源消耗，WebSocket的主动式推送可进一步保证地磁匹配定位的实时性。

图6 WebSocket通信流程

在输出定位结果之前，地磁匹配算法需要先通过用户多次发送的定位信息来累积初始数据，然后以滑动窗口的方式进行匹配，因而每个接入用户需要有单独的内存空间用于存储窗口的临时定位数据。为了保证不同用户定位服务的独立性，本文基于多进程(Multiprocessing)技术[9]，采用生产者-消费者模型(Producer-Consumer Model)与消息队列(Message Queue)设计了支持多用户在线接入的架构[10]。在该架构下，云平台中的生产者进程负责接收智能手机发送的定位数据并放入消息队列；消费者进程负责从消息队列中获取原始定位数据进行融合解算，再将定位结果发送给智能手机。每个接入的用户都会创建新的消费者进程用于该用户数据的处理，同时为每个用户创建单独的消息队列，进而保证不同用户定位请求的独立性。消费者进程通过Socket.IO[11]建立与Flask主进程的WebSocket连接，实现进程间通信，并将解算结果与用户ID一同发送到Flask主进程，进而再将其发送到对应的接入用户，该过程如图7所示。

图7 多用户通信流程框架图

3 测试验证

为验证地磁匹配云定位架构的有效性和实用性，本文针对多用户接入与城市复杂环境定位两方面的性能进行了测试。实验由智能手机和云平台组成的地磁匹配云定位系统来完成，其中智能手机通过4G公网与云平台实现通信，测试环境如表1所示。

表1 实验环境

图8为云平台多用户接入地磁匹配定位解算的轨迹显示，其中标号1、2、3对应路径分别表示三个用户的行驶轨迹。

图8 云平台多用户定位轨迹

图9为智能手机端定位轨迹显示(虚线部分)，智能手机仅作为数据采集与信息传输终端，实时发送定位数据到云平台，并接收返回的定位结果进行显示。

图9 手机端定位结果展示

3.1 多用户接入性能

考察在一定规模用户同时接入的场景下，地磁匹配云定位的实时性和稳定性。由于实验条件的限制，本研究采用Apache开发的压力测试工具JMeter来模拟多用户接入同时定位的情况[12]，并利用长度为9 km左右的普通城市道路所采集的原始导航数据来进行实验。

表2为多用户在线接入的定位延时的测试结果，这里的定位延时指单用户单次定位延时的平均值。表中平均/最大用户定位延时是针对用户之间定位延时的对比指标。

表2 多用户在线接入的定位延时 单位:ms

结果表明，多用户在线接入下不同用户的定位延时差异较小。同时，随着用户接入数量的增加，平均用户定位延时有所增加，原因在于单台服务器性能受限，多用户接入下资源占用较大。若采用多个云服务器节点，利用负载均衡的技术，则在理论上可实现无限多用户的接入，并且系统性能对于定位延时的影响也会大大降低。

图10为基于200个用户接入的条件，单个用户单次定位的延时大小变化。结果显示，在4 000次的连续定位请求过程中，测试用户单次定位延时在一定范围内波动，单次平均延时为80 ms左右，单次最大延时为96 ms，表明地磁匹配云定位可以满足用户定位实时性的要求。

图10 单用户定位延时变化曲线

为了测试系统和算法运行的稳定性，在接入用户为200的条件下，随机选取5组云平台定位解算结果与同样路线下对应的智能手机本地定位解算结果，分别对比两者与基准定位结果的误差(RMS)，测试数据如表3所示。其中一组定位结果误差曲线如图11所示。结果显示，智能手机解算与服务器解算定位误差等级相当，RMS在3 m左右，数据上的差异主要是由于智能手机和云平台地磁匹配解算中滑动窗口的时间点不同，表明地磁匹配云定位程序解算的稳定性和准确性满足要求。

表3 云平台与智能手机定位结果误差RMS对比 单位:m

图11 云平台与智能手机定位误差曲线对比

3.2 城市复杂环境定位性能

为了对比在不同城市环境下地磁匹配云定位系统的性能，开展了实际跑车实验。路线区域如图12所示，包括普通城市道路、京新高速(高速路)、北五环入口(高架桥)、大屯路隧道(隧道)等典型城市环境，长度约40 km。

图12 实验道路区域

定位误差曲线如图13所示，结果可看出，地磁匹配云定位在普通城市道路、高速路、隧道、桥梁等环境下的测试误差相近，RMS在3 m左右，这是由于上述城市环境下地磁特征均较为丰富，可以实现较好的地磁匹配效果。结果表明，地磁匹配定位对城市综合环境的适应性较强。

图13 不同城市道路定位误差曲线对比

4 结束语

针对地磁匹配定位算法计算量大、地磁数据存储量大以及定位过程实时性高的要求，本文研究了多用户接入与云-端实时双向通信的云定位关键技术，搭建了一种面向多用户车辆地磁匹配定位的云平台，实现了在普通城市道路、高速路、高架桥、隧道等城市环境下实时稳定的多用户接入车载定位服务。实际道路跑车测试结果显示车辆定位误差(RMS)可以保持在3 m左右，能够实现车辆的连续精准定位。对地磁匹配云定位进行了实验测试，结果表明其能满足多用户接入下实时、连续定位的需求，定位算法能够保持长时间稳定运行。