- 积分
- 11
- 下载分
- 分
- 威望
- 点
- 原创币
- 点
- 下载
- 次
- 上传
- 次
- 注册时间
- 2017-10-31
- 精华
|
6#
发表于 2017-12-23 10:32:25
|
只看该作者
来自: LAN 来自 LAN
看到蔡神的形式化描述,这里结合工程实践完善一下这个问题。
主要以WiFi为例,基站虽存在可解释性编码,但施用原理相似。
问题定义:
输入-手机WiFi芯片所能搜索到的WiFi列表(MAC地址及信号强度)
输出-经纬度坐标
原理:
Theoretically,只要手机所处环境WiFi足够密集,在任意一个不同的地点,它所能搜索到的上述WiFi列表都是完全不一样的,这样我们实际上可以建立一种“WiFi列表~位置”的一一对应关系。
WiFi list 1 - latitude,longitude 1
WiFi list 2 - latitude,longitude 2
...
WiFi list n - latitude,longitude n 这样,只要我们采集并存储了所有位置的WiFi列表,当一个未知位置的WiFi列表来请求定位服务时,
WiFi list x - ?, ?
我们直接去查询这个WiFi列表所对应的位置就可以了。
工程化:
实际工程化的时候当然不会那么理想,可能面临
- 信号强度扰动大;
- 手机芯片不稳定;
- 存储代价;
- 稀疏区域;
- WiFi动态变化及更新;
等问题
工程上一般也并不会直接存储上文中提到的WiFi列表,往往会对上述对应关系做处理。
传统上较流行的方法是三角定位,即先确定每个WiFi热点位置,再通过相对关系定位。(这种方法目前仍用于室内定位)
之后兴起的是指纹定位,即将空间预先划分为网格,在每个网格中建立WiFi指纹(表征WiFi列表联合分布的数据结构),将query映射到相应网格中。
篇幅所限,下面两点改进不展开
算法改进:
工程改进:
数据来源:
各家在提供定位服务的同时,也会不停的采集WiFi列表,如果手机的GPS也处于打开状态,便同时采集GPS返回的坐标,这样便有了原理中提到的对应关系数据。
路测结果:
滴滴定位项目启动半年时在真实环境中测试各地图产品定位服务效果,利用GPS&人工标注作为真值,测试定位误差中位数(20-30m)及80%(30-60m),90%分位数(45-70m)。
在不同场景区域,结果有较大差别,但总体而言表现从好到差为
百度>高德>滴滴>腾讯 极端场景下,百度定位中位数误差已经接近理论极限10m,非常厉害
苹果系统自带定位服务没有同时进行评估,但从badcase反馈情况来看,大约介于滴滴和腾讯之间
利益相关说明
本人负责滴滴定位项目
附一张采集覆盖示意图
|
|