定位

阿里云联袂「龙蜥社区」生态，推出全新的「利用诊断剖析平台」，它是一款剖析功能丰富、诊断能力齐备的平台，它能够帮忙用户高效定位利用性能、异样行为、内存透露、程序解体等问题。

导读高德定位业务包括云上定位和端上定位两大模块。其中，云上定位主要解决Wifi指纹库、AGPS定位、轨迹挖掘和聚类等问题；端上定位解决手机端和车机端的实时定位问题。近年来，随着定位业务的发展，用户对在城市峡谷（高楼、高架等）的定位精度提出了更高的要求。 特别是车机端定位，由于定位设备安装在车上，一方面，它可以搭载更丰富的定位传感器来解决特殊场景的问题，另一方面，各个传感器之间相互固连，有利于高精度的算法设计。这两点为车机端进一步提高导航精度的提供了可能。 城市峡谷一直是车机端定位的痛点。原因是城市峡谷的环境使用户无法接收到GPS信号或GPS信号受干扰，导致GPS无定位结果或定位精度差。这是“有源定位”固有的缺点，无法从算法上来克服。 针对这个问题，以GPS+IMU的多传感器融合方案越来越受到重视，因为“无源定位”的IMU恰好可以弥补GPS的短板。此外，车机还可以搭载里程计、视觉设备形成更丰富的多传感器融合方案。 对高德而言，地图数据是定位业务的灵魂。多传感器融合只是定位业务中的一部分，如何把多传感器与地图数据结合起来，始终是我们在思考的问题。 针对车机应用，我们使用GPS、IMU、里程计等传感器，结合高德地图的地图优势，提出了一种结合地图匹配（Map Matching）的多传感器融合算法——GPS/IMU/MM融合（软件+硬件的解决方案）。 本文概述了车载多传感器融合定位项目背景，该项目确立是为了向用户提供好的导航定位服务。为了解决用户反馈的三大痛点问题：偏航重算、无法定位和抓路错误，结合算法和数据，提出了一套软件+硬件的解决方案。最后，用实测数据验证对用户反馈问题的改善程度。 车载应用的痛点偏航重算：是指在高架或城市峡谷，信号遮挡引起位置点漂移；无法定位：是指在无信号区域（停车场、隧道）推算的精度低，导致出口误差大；抓路错误：是指主辅路、高架上下抓路错误。其中，导致偏航重算和无法定位直接原因是GPS定位精度差和DR航位推算精度差。GPS定位精度由观测环境决定，难以改善；DR航位推算精度与DR算法性能有关，尤其是里程计系统误差和陀螺零偏的标定精度。对于抓路错误，直接原因是正确道路与误抓道路相隔太近，受定位精度限制无法区分；根本原因是只使用位置信息进行抓路，没有发挥其它数据的价值。 相关名词GPS(GlobalPositioning System)：指美国国防部研制的全球定位系统。用户设备通过接收GPS信号，得到用户设备和卫星的距离观测值，经过特定算法处理得到用户设备的三维坐标、航向等信息。使用不同类型的观测值和算法，定位精度为厘米级到10米级不等。GPS的优点是精度高、误差不随时间发散，缺点是要求通视，定位范围无法覆盖到室内。 IMU(Inertial measurementunit)：指惯性测量单元。包括陀螺仪和加速度计。陀螺仪测量物体三轴的角速率，用于计算载体姿态；加速度计测量物体三轴的线加速度，可用于计算载体速度和位置。IMU的优点是不要求通视，定位范围为全场景；缺点是定位精度不高，且误差随时间发散。GPS和IMU是两个互补的定位技术。 MM(Map matching)：指地图匹配。该技术结合用户位置信息和地图数据，推算用户位于地图数据中的哪条道路及道路上的位置。 技术方案车机融合定位项目解决的是道路级的定位问题，受限于硬件性能，目前市场上通用的技术方案有两种，如下表1所示： 这两种技术方案涉及到3种技术手段，在场景覆盖和精度上，它们各有所长，互相补充。如表2所示： 表1表明，目前市面上存在的通用方案并不能完全解决偏航重算、无法定位和抓路错误这三个问题，尤其是抓路错误。为此，在技术层面上，我们将两套通用方案进行融合，提出了一套软+硬（GNSS+MM+DR）方案；在算法层面上，依靠高德的数据优势，以数据融合模块为核心，一方面提高定位结果可靠性，弥补硬件性能上的不足，另一方面对抓路错误问题进行专门的算法设计。 更进一步，将用户反馈的三个问题解构为算法上解决的三个问题：器件误差标定、场景识别和数据融合。如图2所示： 功能模块车机融合定位包括数据适配层（DataAdaptive Layer）、算法支撑层(Aided Navigation Layer)和融合层(NavigationLayer)。数据适配层负责将不同输入标准化、将信号同步；算法支撑层计算中间结果，为融合层服务；融合层是整个系统的核心，它负责融合算法支撑层输出的数据，得到可靠的导航信息。图3列出了各层所处位置及每个层的具体功能模块： 下面，将功能模块分为基础模块和特色功能两个部分分别进行介绍。 基础模块 GPS质量评估 GPS质量评估模块的功能是计算GPS位置、速度、航向角和全局可靠性指标。根据可靠性指标的大小将其投影到状态空间（GOOD、DOUBT、BAD、ABNORMAL）中，状态空间的值表征GPS数据质量的好坏。如图4所示： 评估GPS质量有两个目的：第一，决定是否使用GPS数据进行器件误差标定或某些状态的判断（如转弯行为、动静状态等）；第二，在数据融合模块，为设定GPS观测量的方差—协方差阵提供参考。 器件补偿 无GPS信号环境时，定位只能依靠DR算法。DR算法精度主要取决于IMU（陀螺仪和加速度计）和测速仪的误差，陀螺仪误差将引起位置误差随时间的二次方增长，测速仪误差将引起位置误差随时间线性增长，如图5所示： 为改善无GPS信号环境的定位精度，必须进行器件误差补偿。 补偿模块的主要功能是利用GPS数据来补偿速度敏感器误差参数（比例因子）和IMU的误差参数（陀螺仪天向比例因子和陀螺仪三轴零偏）。补偿的目的是在无GPS信号或弱GPS信号的场景，仅靠DR算法也能得到较为可靠的导航信息。 DR算法 DR(DeadReckoning，航位推算)算法是指已知上一时刻导航状态（状态、速度和位置），根据传感器观测值推算到下一时刻的导航状态。DR算法包括姿态编排和位置编排两个部分。 姿态编排使用的是AHRS（Attitude andheading reference system ）融合算法，处理后输出车机姿态信息。姿态编排流程如图6所示： 位置编排是指结合姿态编排结果，对测速仪观测值进行积分后得到车机位置。 融合算法 车机融合定位项目使用了GNSS、MM和DR三项技术，每项技术能够提供全部或部分车机导航信息，如表3所示。以位置信息为例，GNSS、MM和DR都输出车机位置，但由于不同技术手段有各自的误差源，致使不同技术的定位结果并不相同。 因此，融合算法有两个目的：第一，将不同技术的导航信息融合成唯一导航信息，使之可靠性高于未融合前的；第二，估计器件误差（陀螺仪零偏、测速仪尺度误差和导航误差等）。 融合算法基于Kalman滤波实现，其关键在于模型建立和模型参数设置。Kalman滤波模型由状态转移方程和观测方程构成。状态转移方程表示相邻导航状态之间的转移关系，它通过构建导航误差微分方程实现；模型参数是指状态转移噪声和观测噪声，观测噪声的设置与GPS质量评估模块相关。 经Kalman滤波处理后，得到导航误差的最优估值，如图7所示。即经过补偿得到了导航信息的最优估值。 特色功能 主辅路识别 以往的主辅路识别策略是通过DR输出的位置和方向与两条候选路的关系，选择最接近的候选路作为输出。但对于道路级定位系统而言，DR输出误差与两条路的差异在同一量级，误判的概率较高，所以，需要从一些驾驶特征来解决此问题，例如，路口附近的转弯、变道等。 如图所示，具体步骤为： 提取驾驶行为特征，求特征信息的转移概率；根据DR精度分类计算卷积和，求最终概率。 高架识别 过去，高架识别策略是通过高程积分和阈值法来判断，识别效果受坡角误差和速度误差的影响。其中，速度误差与高程积分误差成正比，是影响高架识别准确率的主要原因。为克服这一缺点，我们结合MM技术，计算道路坡度与输出pitch角的接近程度，以避免引入速度误差。高架识别流程如图所示： ...

一：实现定位及到指定位置导航所需组件及API 1：组件：map(地图组件) 2：API：wx.getLocation(Object object)(获取当前的地理位置、速度)，wx.openLocation(Object object)(使用微信内置地图查看位置) 二：代码实现 1：wxml <view><map id="map"longitude="{{longitude}}"latitude="{{latitude}}"scale="14"markers="{{markers}}"bindmarkertap="markertap"bindregionchange="regionchange"show-locationstyle="width: 100%; height: 300px;"></map></view><view><button type="primary" bindtap="navigate">导航</button></view>2：js //jsPage({/** * 页面的初始数据 */data: {//设置标记点markers: [{iconPath: "/images/ljx.png",id: 4,latitude: 31.938841,longitude: 118.799698,width: 30,height: 30}],//当前定位位置latitude:'',longitude: '',},navigate() {////使用微信内置地图查看标记点位置，并进行导航wx.openLocation({latitude: this.data.markers[0].latitude,//要去的纬度-地址longitude: this.data.markers[0].longitude,//要去的经度-地址})},onLoad() {//获取当前位置wx.getLocation({type: 'gcj02',success: (res) => {console.log(res)this.setData({latitude: res.latitude,longitude: res.longitude})}})}})根据如上即可实现自身定位及到指定位置的导航，如下：

导读与手机导航不同，高德地图的车机版（AMAP AUTO）直接面对各大车厂和众多设备商。这些B端用户采用的硬件参数参差不齐，提出的业务需求涉及到渲染中诸多复杂技术的应用，这对渲染性能提出了极高的要求。 最初车机版沿用手机版的当前屏渲染模式，每一帧都需要实时的将地图元素渲染出来。但在业务实践过程中，我们发现在多屏渲染和多视图渲染场景下，CPU负载急剧增高。以鹰眼图场景为例，在鹰眼图场景下，地图存在多视图渲染的状态：一张是主地图，一张是鹰眼小地图，因此渲染引擎同时渲染了两个地图实例对象，下图右下角即为鹰眼图： 鹰眼图绘制后，平均帧率下降了2帧，如下图所示： 针对上述情况，除了对渲染细节、批次和纹理等进行常规优化外，我们还需要寻找一种全局性的技术优化手段，大幅度提升引擎的渲染性能。为此，我们深入地研究了离屏渲染技术，并结合导航业务，提出了一种基于离屏渲染技术对特定地图的视图进行性能优化的方法。 优化原理在OpenGL的渲染管线中，几何数据和纹理通过一系列变换和测试，最终被渲染成屏幕上的二维像素。那些用于存储颜色值和测试结果的二维数组被称为帧缓冲区。当我们创建了一个供OpenGL绘制用的窗体后，窗体系统会生成一个默认的帧缓冲区，这个帧缓冲区完全由窗体系统管理，且仅用于将渲染后的图像输出到窗口的显示区域。我们也可以使用在当前屏幕缓冲区以外开辟一个缓冲区进渲染操作。前者即为当前屏渲染，后者为离屏渲染。 与当前屏渲染相比，离屏渲染： 在变化的场景下，因为离屏渲染需要创建一个新的缓冲区，且需要多次切换上下文环境，所以代价很高；在稳定的场景下，离屏渲染可以采用一张纹理进行渲染，所以性能较当前屏渲染有较大提升。从上述对比可以看出，在稳定场景下使用离屏渲染的优势较大。但因为地图状态随时都在变化，所以地图渲染通常处于前台动态渲染状态。那么有没有相对稳定的场景呢？答案是肯定的，我们将地图的状态分为沉浸态和非沉浸态。顾名思义，在地图处于变化状态的称为非沉浸态，进入稳定状态称为沉浸态。 进入沉浸态的地图，为我们使用离屏渲染提供了条件。经过统计，地图处于前台状态的场景下，沉浸态时间基本上和非沉浸态时间相当，这样我们采用一张纹理，即可将处于非沉浸态场景下的地图渲染出来，大大降低了系统开销。在鹰眼图，矢量路口大图等特定的视图场景下，地图基本上均处于沉浸态。所以这些视图下采用离屏渲染技术进行优化，取得的收益将是巨大的。 工程实践将以上的技术优化原理，代入到实际的导航应用中，流程如下： 离屏渲染通常使用FBO实现。FBO就是Frame Buffer Object，它可以让我们的渲染不渲染到屏幕上，而是渲染到离屏Buffer中。但是通常的离屏渲染FBO对象不具备抗锯齿能力，因此开启了全屏抗锯齿能力的OpenGL应用程序，如果采用离屏渲染FBO对象进行离屏渲染，会出现锯齿现象。而在非沉浸态地图的状态下，是开启全屏抗锯齿能力的，所以我们必须使用具备抗锯齿能力的离屏渲染技术来进行地图渲染技术优化。 抗锯齿离屏渲染技术简述本节以iOS系统为例，对抗锯齿能力的离屏渲染技术进行简述。iOS系统对OpenGL进行了深度定制，其抗锯齿能力就是建立在FBO基础上的。如下图所示，IOS基于对抗锯齿的帧缓存（FBO）对象进行操作，从而达到全屏抗锯齿的目的： 接下来具体介绍抗锯齿FBO的创建步骤： 创建FBO并绑定：GLuint sampleFramebuffer;glGenFramebuffers(1, &sampleFramebuffer);glBindFramebuffer(GL_FRAMEBUFFER, sampleFramebuffer);创建一个颜色帧缓冲区，在显存中开辟一个具有抗锯齿能力的对象，并将颜色缓冲区挂载到开辟的对象上。创建一个深度模版渲染缓冲区，开辟具有抗锯齿能力的显存空间，并和帧缓冲区进行绑定：GLuint sampleColorRenderbuffer, sampleDepthRenderbuffer;glGenRenderbuffers(1, &sampleColorRenderbuffer);glBindRenderbuffer(GL_RENDERBUFFER, sampleColorRenderbuffer);glRenderbufferStorageMultisampleAPPLE(GL_RENDERBUFFER, 4, GL_RGBA8_OES, width, height);glFramebufferRenderbuffer(GL_FRAMEBUFFER, GL_COLOR_ATTACHMENT0, GL_RENDERBUFFER, sampleColorRenderbuffer);glGenRenderbuffers(1, &sampleDepthRenderbuffer);glBindRenderbuffer(GL_RENDERBUFFER, sampleDepthRenderbuffer);glRenderbufferStorageMultisampleAPPLE(GL_RENDERBUFFER, 4, GL_DEPTH_COMPONENT16, width, height);glFramebufferRenderbuffer(GL_FRAMEBUFFER, GL_DEPTH_ATTACHMENT, GL_RENDERBUFFER, sampleDepthRenderbuffer);测试创建的环境是否正确，避免如显存空间不足等造成创建失败的可能：GLenum status = glCheckFramebufferStatus(GL_FRAMEBUFFER) ;if(status != GL_FRAMEBUFFER_COMPLETE) { return false;}至此，一个具备抗锯齿能力的离屏FBO已创建好，下面将应用这个FBO，步骤如下： 先清除抗锯齿帧缓存空间重的内容：glBindFramebuffer(GL_FRAMEBUFFER, sampleFramebuffer);glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);glViewport(0, 0, framebufferWidth, framebufferHeight);开始进行一系列的渲染函数操作，比如准备顶点数据，纹理数据，VBO，IBO，矩阵，状态等，并执行一系列的渲染指令，选择指定的shader，及其传输数据状态；FBO不是一个具备直接渲染能力的帧缓存空间，在执行完2的操作之后，需要将抗锯齿的FBO内渲染的内容通过合并每个像素，转换到屏幕渲染所在的帧缓存空间去。原理如下图所示：代码如下： glBindFramebuffer(GL_DRAW_FRAMEBUFFER_APPLE, resolveFrameBuffer);glResolveMultisampleFramebufferAPPLE();glBindFramebuffer(GL_READ_FRAMEBUFFER_APPLE, sampleFramebuffer);以上操作完成后，需要进行一些Discard步骤, 将一些原先在当前帧缓存中的内容忽略掉：glBindRenderbuffer(GL_RENDERBUFFER, colorRenderbuffer);[context presentRenderbuffer:GL_RENDERBUFFER];Android系统基本思路一致，需要采用gles3.0接口提供的抗锯齿能力来进行渲染，在此不做展开。 ...