基于定位的出发地异常问题治理

前言

哈啰作为一家出行互联网公司，定位这种基础能力是深度融入在各业务的核心链路中的，笔者所在的地图团队经常会收到定位相关的badcase，但苦于定位的复杂与较难回收出价值，一直没有针对性去解决此类问题，那在各大互联网厂商都在做下沉市场注重用户体验的今天，我们重新捡起了这个话题。

问题梳理

无位置

由于APP启动时未获取到位置，会给用户提示并阻塞发单，用户需要使用POI搜索或拖动地图的方式选择出发地进行发单。

定位漂移

定位漂移是定位最影响订单履约的问题。由于它不阻塞发单，问题的暴露节点往往在司机到达订单出发地后等待乘客上车的环节，司机接不到乘客导致糟糕的用户体验甚至取消订单，严重影响品牌口碑。

举个🌰：

经后台日志查看，这笔订单发单定位不准导致车主找不到用户，造成了订单取消。用户于11:10:48.650时启动APP ->11:10:50.417设备定位在东方康罗->11:10:51.241 这个时间定位恢复到现代物流大厦。

用户启动后请求上车点时的经纬度是一个噪点，在用户定位恢复后并没有重新刷新位置请求新的上车点，造成了使用漂移的定位为出发地最终影响订单履约。而为什么iOS设备经常出现首次定位不准会在下一章见详解。

现状概括

哈啰目前使用的高德的定位SDK，遇到问题要通过向高德提工单的方式解决，但由于定位的badcase有着较强的环境干预因素无法在高德的demo中复现，且高德本身对于定位SDK也没有相关的日志（数据量级过大且很难有价值），反馈的定位问题基本无法解决，最后只能一句“这是系统问题，没办法解决”而草草了事。

定位的复杂

由于定位的badcase五花八门，要搞清楚不同平台的手机定位原理和差异是首要问题，在与哈啰的使用现状相结合，知己知彼后续才能制定出针对性的解决方案。要明确不准的原因有什么？高德定位的机制是什么？我们能做什么？我在整理前也就只知道个大概，遮挡啊、信号差啊啥的，但没有形成系统理论，接下来我会详细整理定位这个大课题，为我们后续的优化提供一定的理论基础。

定位原理

手机厂商的定位能力都是自己实现的，但是各自的规格都不一样，使用高德SDK可以打平Android各厂商之间实现的差异， 定位能力包括GNSS、DR（航迹推算）、MM（地图匹配）、视觉定位和网络定位等。

1.卫星定位
卫星定位系统的英文是Global Navigation Satellite System(GNSS），虽然直接翻译过来是导航卫星系统，但它真正提供的能力是定位，能定位后，导航就变得相对简单了。卫星定位的原理，是利用卫星播发时间信号，当设备接收到后，可以根据信号发射时间和本地时间，计算出信号传输时间，再结合光速获得卫星-设备距离。

有了多颗卫星的信号，可以列出一组方程，求解4个未知数：设备的三维坐标x/y/z，以及本地时间与GNSS系统的时间差。式中的代表卫星j的三维坐标，这个坐标可以通过卫星星历计算获得。

星历是描述卫星运行轨道的一组参数，卫星轨道是一个椭圆，通过几个参数和时间，可以唯一确定卫星的准确位置。

星历的获取有两种方式，一种是卫星直接播发，这种方式的好处是定位过程不依赖卫星信号以外的任何输入，即使没有网络也可以定位成功，但问题是卫星链路带宽很小，要下载完整星历，需要30秒左右的时间，早期的手机和一些车载设备定位过程很慢，就是由于这个原因。

另一种方式，是通过互联网播发，这种方式叫A-GNSS，具体的传输协议叫SUPL(Secure User Plane Location)，这种数据一般不对应用层透出，在手机上操作系统会在底层定时请求SUPL数据，然后将获得的星历注入GNSS芯片。有了A-GNSS，设备就可以在秒级获得定位，不需要任何等待过程，目前所有的手机都支持这种方式。A-GNSS的服务提供商，主要是通信运营商，以及一些定位服务商，比如谷歌、千寻等。

卫星不间断的向地面广播信号，这个信号主要包括以下信息：

• 卫星编号：用于从星历中查找卫星轨道，再结合时间戳获得当前卫星位置
• 当前时间戳：用于获得卫星位置，另一方面计算伪距。伪距是(本地时间-信号发射时间)*光速，之所以叫伪距，是因为本地时间与卫星时间不同步，所以这个距离并不是真正的设备-卫星距离。
• 星历数据：用于计算卫星位置。

像其他所有的通信技术一样，这些信息也是以报文的形式发送的，以GPS为例，卫星会每隔6秒发出一个包，而这个包会分解为数据位-CA码序列-载波波形，通过天线发射到地面。地面设备持续锁定卫星，在解算时，计算每颗卫星当前时刻的时间戳（用最近一次收到的时间戳加上报文偏移量），然后进行位置解算。

载波的频率是1.5G左右，波长20厘米左右，比移动通信的波长稍长一些，所以信号的穿透性还是比较好的（波长越长，越容易绕开障碍物），可以穿透比较薄的墙壁或屋顶，所以在一些情况下即使无法直接看到天空，也是能定位的。但是卫星信号是从上往下，在室内很难穿越多层建筑。

定位误差来源与精度提升

卫星定位虽然已经很准确了，但是在某些场景下，还是无法满足需求，比如，打车的时候定位点离车辆有一定距离、步导的时候难以区分方向甚至会定位到马路对面、静止的时候定位点总数飘来飘去、室内的时候定位点乱飘。这需要从卫星信号的发射、传输、接收过程来解释。

卫星信号从发射到被设备接收，需要经过大气层，其中，大气电离层有数千公里厚，这部分大气非常稀薄，但是存在大量被电离的电子，这部分电子会让电磁波变慢一点，从而产生延迟。在对流层，也会产生一定的延迟。在地表附近，由于各种建筑、山体、水面的影响，卫星信号可能被反射或折射（多径效应），产生延迟。

在卫星信号发射侧和接收侧，也有很多系统相关的误差，比如时钟偏差、处理延迟等，这些延迟加上传输延迟，使得卫星信号的传输时间，并不是准确的等于物理距离/光速，另一方面，卫星的星历也有误差，卫星位置和真实位置存在偏差，最终造成了定位结果产生偏差。

双频GNSS：不同频率的电磁波通过电离层时会有不同的延迟，人们发现，对两个或多个频率的观测值进行线性组合，可以消除电离层误差，从而能提升精度。这就是双频GNSS定位的原理。小米8是业界第一款支持双频GNSS定位的手机，后续各大厂商均进行了跟进，一些高端手机均采用双频定位。消除电离层误差后，定位精度可以提升到5米以内。iPhone 14 Pro 和 iPhone 14 Pro Max 才支持双频 GPS 定位。

设备差异
iOS设备
iOS设备的定位能力是完全封闭的，对外只透出定位结果，外部基本无法拿到任何定位相关的原始观测量，比如卫星数量、类型等。好消息是，iPhone12终于开始支持北斗了。从苹果的API上，外界甚至无法区分定位结果到底是来自卫星定位还是网络定位（目前仅能通过速度的符号来判断，但苹果对此没有任何承诺）。所以，基于iOS设备高德基本无法做出优化，iOS设备上高德地图的定位点都是iOS底层直接提供的。

Android设备

Android设备比iOS设备开放的多，在定位能力方面提供了一系列API：

• 可以单独获取卫星定位结果或网络定位结果，也可以同时进行两种定位。
• 提供了NMEA格式（一种卫星定位结果的规范化表达）的结果数据，可以获取每颗卫星的ID、类型、信号强度，以及xDOP等细粒度的误差描述。
• 提供了GnssStatus来描述每颗卫星的状态，内容比NMEA更全面。
• 提供了GnssMeasurement来描述原始观测量，包括伪距测量值、载波相位测量值、卫星锁定状态等。
• 提供了GnssClock描述本地时钟的状态。
• 提供了GnssNavigation透出最原始的未解码报文。

2.网络定位

网络定位是通过客户端扫描到的WiFi和基站信息来进行定位的一种定位方式。网络定位能力是GNSS定位的有力补充，在GNSS无法定位或者定位较慢的时候（例如地铁、高架、室内等场景），网络定位都可以快速给出位置。网络定位能力也是高德能够深植于各类手机厂商（提供系统级网络定位能力）和APP（出行、社交、O2O、P2P、旅游、新闻、天气等诸多领域）的原因之一。

注：高德网络定位只存在于Android平台上，在iOS上由于苹果公司未开放任何定位相关的指纹数据（WiFi、基站列表等），定位结果全部来自于iOS自身。

高德Android设备优化

网络定位分为离线训练和在线定位两个过程：

• 离线训练：是在用户有GPS位置时采集周边的WiFi和基站（以下统称为AP）信息，通过对采集数据进行聚类和关联，得到两类数据产品：AP库和指纹库;
• 在线定位：与离线训练的过程正好相反，当用户没有GPS定位时，可以通过扫描到的周边WiFi和基站信号，结合离线训练出的AP库和指纹库来进行实时定位。

AP库和指纹库这两类数据产品中：

• AP库：以WiFi的mac地址或者基站的ID（gsm基站为mcc_mnc_lac_cid，cdma基站为mcc_sid _bsid_nid ）为主键，以WiFi或者基站的物理坐标信息（经纬度或者地理栅格坐标信息）为内容。
• 指纹库：以物理坐标位置对应的特征指纹信息为内容，这些特征指纹信息可以包括扫描到的WiFi或者基站的信号强度分布，采集点频次等统计信息，也可以是通过神经网络提取出的特征信息。

典型的AP库数据只包含挖掘出的物理坐标信息和覆盖半径，这种“点圆模型”是对AP发射信号的一种理想化，没有考虑任何实际场景中的信号遮挡、反射等情况，所以AP库大多用来进行粗略定位（WiFi覆盖半径50-100米 基站 1km-10km ）。而指纹库直接与位置相关，可以刻画比“点圆模型”更细致的分布信息，所以指纹库可以用来进行精细定位，不同场景算法不同，室内室外、场站高架。高德的指纹库主要包括特有的室内指纹和全场景指纹信息两种。

网络定位问题
网络定位的基本思路类似聚类，假设用户手机扫描到的AP列表中的AP的位置均比较固定，则我们可以以这些AP位置为锚点，来确定用户位置。现实世界中，锚点（即AP库中的AP）的位置通过大数据来进行挖掘，并不一定完全准确，甚至出现严重错误，大多数网络定位问题都发生在聚簇中，由于定位依据不足，WiFi少、信号弱等。

针对WiFi而言，移动WiFi、克隆WiFi、搬家WiFi等都可能造成AP位置的错误。移动WiFi包含手机热点，4g移动路由器，公交车/地铁/高铁上的WiFi热点等，这些WiFi的移动属性较强，位置频繁变化，如下图所示。

如果以移动WiFi作为锚点，因为这些锚点的位置不固定，极可能会导致用户的定位出现极大误差。克隆WiFi指不同的WiFi设备使用了同一个mac地址，国内的腾达和斐讯等路由器厂商制造了大量这样的WiFi设备（例如大部分mac前缀为“c8:3a:35”的即为腾达的克隆WiFi），克隆WiFi导致AP库中同一个mac地址对应的锚点位置有多个。搬家WiFi指某些因为搬家而发生位置变化的WiFi，数据挖掘存在一定的滞后性，搬家后AP库中的位置未及时更新，也会造成定位错误。以下为定位点散布的实例。

高德通过训练分类模型的形式将这些非固定WiFi的属性在AP库中标记出来，以“移动WiFi识别”为例，由于AP库中的WiFi数量十分庞大，高德根据人工规则的判定结果提取了一批确定性较高的样本，使用人工强特征训练第一版模型，之后将第一版模型的预测结果与线上人工规则的结果进行全量比较，提取出模糊样本进行人工标注。在标注样本的过程中发现问题，持续特征工程，不断迭代模型。这部分距离我们比较遥远不再展开了，感兴趣的同学可以阅读参考文献。
苹果iOS设备优化

无网基站定位

传统的基站定位需要连接云端服务器，产生网络流量，iOS 4对其进行了优化，可以在没有网络连接时支持无网定位，因为苹果预先已经将一些重要基站（几十公里选一个）提前存储在iOS系统中，在无网情况下，不用上网也能通过这些本地基站信息定位到用户位置，但这个误差范围更大，在10公里到50公里。

注意：您的手机能接受到内置在手机中的那些“重要基站”的信号，不一定是您手机所属运营商，只要能收到信号就可以了。

无网WiFi定位
传统的WiFi定位需要网络，但是iOS对其进行了优化，可以实现无网WiFi定位。原理是iOS设备在您有网络连接时，会大致定位出您的位置，并自动下载您所在地区周围（几个街区宽度或者更多）所有的WiFi热点的信息到本地。之后，当您在周围行走并WiFi定位的时候，即使没有网络，iOS照样可以利用之前下载的WiFi热点信息定位出您的位置。关于自动下载的热点个数和范围，这个是苹果根据当地热点的密度动态决定的，当地热点很多时（如市中心），可能只下载几条街道范围的所有热点，当地热点密度很小时（例如海滨城市），可能会下载整个城市的所有热点。

注意：无网WiFi定位的前提是您在这个区域附近曾经成功上过网，如果初次到一个陌生的地方，是无法定位的。

常见问题：

1.为什么iPhone当前定位误差有几百或者上千米?
iPhone初始定位都是用基站或者无网基站定位，误差几百或几公里。之后，如果无法搜索到WiFi信号，或者无法搜索到卫星信号，就会一直是这个精度。
您可以打开WiFi功能（不用连上，只需要打开即可），或者到窗户边，或者户外以便收到卫星信号;
解决方法: 多等一会儿，开启数据流量（定位之后即可关闭），或者到户外去。

2.为什么我的位置总是变来变去?
iOS根据当前网络环境，会不断调整和修正定位方式，可能您所处地区基站和WiFi信号太复杂或者太微弱，比如一会儿连上这个基站，一会儿连上另一个基站，导致iOS计算位置的时候不稳定。
解决方法: 打开WiFi功能，开启数据流量（定位之后即可关闭），或者到户外去。

3.无手机信号可以定位吗？无数据流量可以定位吗?
情况1：【没有手机信号，没有WiFi信号，没有上网】则定位只能在户外利用GPS进行，初次定位时间可能很长，可能需要数分钟，之后定位正常。
情况2：【没有手机信号， 有WiFi信号，没有上网】如果之前在周围上过网，下载了附近的热点，则利用无网WiFi定位可以找到位置，否则，和情况1一样。
情况3：【没有手机信号， 有WiFi信号，可以上网】利用WiFi定位找到位置，并且在定位时还会下载大量的周围很大一个区域的所有WiFi热点信息，用于今后无网WiFi定位。
情况4：【有手机信号， 没有WiFi信号，没有上网】如果能收到iOS内置的“重要基站”的信号，则使用这些基站进行无望基站定位，否则，无法定位。
情况5：【有手机信号， 没有WiFi信号，可以上网】使用基站定位联网查询进行定位，同时可能会更新本地“重要基站”信息。

打开WiFi开关是一个提升定位的好方法，以前都没注意过。我看网上还有说“为了提高iPhone上的GPS精度，您需要允许设备根据您的时区自动设置日期和时间。这样，智能手机就可以了解您的身处，并确定可以连接的GPS卫星。”这种方法的。

关键提炼

• 定位结果由卫星定位或网络定位返回，两者互为补充且各有些原因导致其准确性降低
• 高德的网络定位只适用于Android设备，iOS设备使用的是系统的定位，所以Android的国内定位效果要好一些
• iOS设备定位会初始一个精度较差的值（iPhone初始定位都是用基站或者无网基站定位，误差几百或几公里），然后不断地更新精度（如更新不到则一直保持此精度）
• Android设备能获取到更为丰富的信息如卫星编号，WiFi列表等，而iOS设备能获取到的额外信息几乎没有
• 打开WiFi开关是一个提升定位的好方法，可以让设备使用到网络定位

对症下药

基于以上原理分析，我们制定了一系列的优化方案，重点解决无定位与定位漂移的问题。

构建监控体系

做任何优化工作的第一步永远都是补齐埋点、建立口径、摸清现状，也方便后续回收效果，用数据说话。由于定位相关的埋点量级过大，全量埋点对服务器的压力很大，而且定位异常只是小概率事件，绝大多数的数据全是无用数据，因此我们选择对关键节点进行监控，对首次获取和用当前定位作为出发地的订单进行监控并能量化出异常定位对普惠订单的影响。

无定位优化

在上述定位原理章节我们了解到提示用户打开WiFi可以帮助用户使用网络定位，能高效提升用户室内定位的准确性，此外在与高德同学的排查沟通中，我们了解到当我们设置的定位阈值设置过精时，如果当时达不到设置的精度要求可能不会返回位置。基于以上两点，我们落地两个产品逻辑，无定位WiFi开关打开提示和无定位时降低精度阈值重新请求的兜底逻辑。

定位漂移优化

从最终结果看定位漂移实际反馈到交易体感上的影响就是由设备定位位置到用户真实位置的误差反馈到订单起点与用户真实位置的误差，基于此我们发起了通过程序主动与被动的方式解决用户基于定位的出发地发单异常识别与修复专题，整体方案逻辑如下：

出发地远距离提示
在识别到用户出发地位置与用户真实位置距离较远时，在UI层面给予用户提示，帮助用户主动确认出发地是否符合预期，而在用户发单的节点会对用户的当前位置与出发地进行二次确认逻辑，如过远会对用户进行弹窗提示，完成最终把关。

为何在发单环节还要进行阻塞干预？

讲一个有趣的小故事，笔者在听抖音关于直播间技术的分享时有一个问题是讲抖音是如何识别监控直播间卡顿的？这无疑是个非常复杂的问题，是个例还是共性？是主播发送链路还是家人们的接收链路？是移动端还是服务端问题？相信不同角色的工程师对于这个问题都会在各自的领域内给出一个专业的答案，如客户端工程师会关注手机播放器的性能、网络工程师会关注上下行的流量、后端工程师会检测自己服务的性能等等，哪种方案都无法完全覆盖直播间卡顿这个超复杂问题，而抖音给出的解决方案确实让我眼前一亮：通过监测直播间的弹幕如卡了、不动了等关键字。这个方案太妙了，妙在它是一种思维方式的转变，像抖音直播间是否流畅播放明显是一个端到端解决方案，他们在整个端到端的终态也就是给用户呈现的层面进行监控，可以覆盖整个端到端链路，同理像用户从选择起点到发单也是一个端到端场景，中间涉及到用户使用定位、拖拽地图、选择POI、推荐上车点的召回、用户线下的不确定性动作等等行为，而在发单节点进行校验是一个端到端尾节点的干预逻辑，更能影响最终结果，在我们分析的时候确实是有一部分用户在选完出发地后自己又走了一段距离后忘了更新出发地直接发单了导致订单出发地离用户真实位置较远的badcase。

噪点识别与纠偏

我们通过定位&IMU(Inertial measurementunit 惯性测量单元)&算法实现了一套软件+硬件相结合的解决方案，识别出噪点并进行纠偏干预。

纠偏为何放到端上去做？

在端上部署纠偏算法更适用于出行这种网络与定位环境复杂，在无或弱网络信号和定位信号的场景进行补救的场景，节省持续大量计算数据传输到后端运算后在传回端上的耗时操作，在无网络成本的情况下更好的赋能出行业务，且我们的算法对性能消耗的较少不会产生性能问题。

PDR

PDR (Pedestrian Dead Reckoning 行人航位推算) 是一种定位技术，用于在室内或无 GPS 信号的环境中跟踪行人的位置。它通过使用传感器数据（如加速度计、陀螺仪和磁力计）来估计行人的步长、方向和位置变化。PDR 技术在室内导航、室内定位和增强现实等应用中具有重要的作用，特别是在缺乏 GPS 信号或需要高精度定位的环境中。然而，PDR 技术也存在一些挑战，如传感器误差累积、行人步行模式的变化和环境干扰等，需要采取适当的算法和校准方法来解决这些问题。

• 步长估计：PDR 的第一步是通过加速度计来估计行人的步长。加速度计可以测量行人每一步的加速度变化。通过检测加速度的峰值和谷值，并结合行人的身高和步行模式，可以估计出平均步长。这个步长估计可能会受到行人的个体差异和步行环境的影响。
• 步频估计：除了步长，PDR 还需要估计行人的步频，即每分钟的步数。通过使用加速度计和滤波算法，可以检测步行的周期性模式，并估计出步频。
• 方向估计：PDR 需要估计行人的方向变化。这可以通过使用陀螺仪和磁力计来实现。陀螺仪可以测量设备的旋转速度，而磁力计可以提供地磁信息。通过结合这些传感器的数据，可以估计出行人的方向变化。
• 位置计算：基于步长、步频和方向的估计，PDR 可以计算行人的位置变化。初始位置通常是通过其他定位技术（如起始位置的 GPS 或 Wi-Fi 定位）获得的。通过累积每一步的位移和方向变化，可以计算出行人的当前位置。
• 误差校正：PDR 的实现中需要进行误差校正，以提高准确性和稳定性。这包括校准传感器的误差、校准步长和步频的变化、校准方向的漂移等。常见的校准方法包括使用滤波算法、定位校准算法和环境校准算法。
• 结合其他定位技术：为了提高定位的准确性和稳定性，PDR 可以与其他定位技术结合使用。例如，可以使用地磁定位来校准方向数据，使用 WiFi 定位来校正位置漂移，并使用惯性导航系统来补偿传感器的误差。

卡尔曼滤波：简单地说就是可以根据gps纠正传感器数据推算产生的偏差，并在定位发生漂移时使用传感器推算出的点以减少漂移对位置产生的影响。

卡尔曼滤波尤其适用于动态系统，这种方法对于内存要求极低而运算速度快，且能够保持较好的计算精度，这使得这种方法非常适合解决实时问题和应用于嵌入式系统，也就是说，卡尔曼滤波天然的适用于解决舰艇指控系统的航迹推算问题。

• 优点：内存占用小、运行快
• 缺点：要先离线跑出基准值

IMU

包括陀螺仪和加速度计。陀螺仪测量物体三轴的角速率，用于计算载体姿态；加速度计测量物体三轴的线加速度，可用于计算载体速度和位置。

• 优点：不要求通视，定位范围为全场景；
• 缺点：定位精度不高，且误差随时间发散。

导致定位漂移直接原因是GPS定位精度差。GPS定位精度由观测环境决定，难以改善。通过对当前GPS精准度、短期内的历史点集分布、IMU惯性传感器（加速计+陀螺仪）与路网数据分析，排除漂移位置，减少因为定位漂移导致的出发地异常问题。

加速度计

加速度计是惯性导航和惯性制导系统的基本测量元件之一，加速度计本质上是一个振荡系统，安装于运动载体的内部，可以用来测量载体的运动加速度。

采集数据中重力加速计在手机停放在桌面（左图）与手握手机步行状态（右图）时加速计的情况，可以看出步行状态下手机加速计的变化是有较明显的周期性的，其周期与步行状态可对应上。

** 颜色说明：x\y\z\a分别为红、绿、蓝、黄

陀螺仪

手机里的陀螺仪芯片内部包括有一块微型磁性体，能够在手机进行旋转运动时发生的科里奥力效果下向X，Y，Z三个方向发生位移，运用这个原理便能够测出手机的运动方向。

在采集数据中，不仅包含偏航（Yaw）、翻滚（Roll）、俯仰（Pitch）等直接角度指标，同时也包含四元数、旋转速率等中间指标，甚至包含北向偏角（heading）指标，详细采集数据可见附件链接。但最终发现北向偏角与实际差值在30度左右，且容易受拿取手机的姿势影响，所以陀螺仪数据最终在方案中仅作为参考方向；

计算位置

由于手机是非固定设备（如反拿、摇晃、揣兜晃动等）导致方向的不确定性，我们采用定位的数据为主，传感器数据为辅测算最远距离半径的形式，推算出他所能运动的最远距离与算法拟合的新位置，在定位精度低于信任值的情况下判断距离是否超过最远距离，判断是否使用拟合点。

算法落地

整个流程分为数据的离线采集确定用户行为与算法超参的基准值产出初版算法，数据的在线采集与离线训练，算法的线上部署三个流程。

离线采集

基于上述理论支撑，我们需要对一些标准行为与真实的异常定位场景进行数据采集，分析其中数据转换关系定义基准值，完成算法的初版，并可通过离线数据还原出用户发单前的定位情况。

定位与IMU数据采集（采用iPhone8设备，定位精度设置为最高）

线上采集

整个采集流程需注意以下几个问题：

• 灰度放量：未防止性能与网络消耗（1条传感器数据目前2k 可接受，传感器采集频率设置为3s消耗很低，可忽略不计）与稳定性要小步放量
• 对APP启动流程的影响：为减少对启动的影响，整个采集开启定在APP启动3s后，APP启动期间会有多条定位数据更新（本地查看为7条），由于前序的定位数据对整个算法的初始值设置非常重要，so决定将启动期间的定位数据保存到内存中，3s后在补报
• 按时关闭：原定义的流程为采集到用户发单为止，但由于灰度用户未必为普惠用户且未必有发单诉求，需要额外机制关闭采集，否则会一直采集浪费性能，参考目前平均发单时长进行手动关闭
• 多线程问题：上锁（手动狗头）

综上，整个采集逻辑如下:

算法部署

整体卡尔曼滤波的算法流程图如下，其中‘prediction’步主要根据历史情况进行当前结果的估计，而‘update’步主要是结合最新定位位置得到最终结果。其中“A”值需要通过历史速度、加速度、加速计、陀螺仪的值计算得出。

X：状态矩阵---车辆位置

X^,：预测状态

A：状态转移矩阵---单位矩阵

u：状态转移偏差---同维单位阵

P：状态误差-状态无转移

P^,：预测步误差

Q：转移误差---根据漂移识别结果生成

z：观测结果---最新车辆位置

R：观测噪声---定位点协方差矩阵

H：旋转矩阵---单位方阵

K：卡尔曼增益---过程参数

算法效果

采集逻辑上线后，我们通过对线上异常定位发单case进行回溯，通过用户真实的离线数据训练算法，达到真实修复异常定位的结果。

原始（左图）vs 修正后（右图）：

case描述：手机一直在旭辉楼内，但是原始位置出现偏移较大的点，经过修正，偏移点偏移距离明显缩小。

原始（左图）vs 修正后（右图）：

case描述：拿着手机从莘庄中心楼中，绕到西子背后，再进入西子1号楼中，最后回到莘庄中心的连续轨迹，其中院士轨迹在新装楼中与进入西子楼中时有明显偏移，经修正后整体轨迹更符合实际情况，其中起始点处有少许点优化后仍较乱，但是走一段之后在进入西子时所有异常点都被修复。

总结

通过数据指标建立我们摆脱了定位“两眼一抹黑”的时代，并明确了定位漂移对于普惠订单的相关的影响，对定位原理的刨析我们制定了一系列的优化策略，并取得了阶段性的收益，但由于定位的复杂后续仍需投入时间分析case迭代算法。

作者简介:

陈东冉、高婷、刘永奎、 陈煜、 冉印。