与WLAN技术紧密结合 MEMS模组增强室内定位精准度
时间：2013-06-03 05:25:00
手机看文章
扫描二维码
随时随地手机看文章
[导读]智慧型手机的室内导航应用体验可望升级。微机电系统(MEMS)感测器所组成的惯性导航系统(INS)，可提供行人航位推算(PDR)资讯，让智慧型手机进入室内时，不会完全丧失位置资讯，并能顺利结合WLAN讯号，持续提供精准定位
智慧型手机的室内导航应用体验可望升级。微机电系统(MEMS)感测器所组成的惯性导航系统(INS)，可提供行人航位推算(PDR)资讯，让智慧型手机进入室内时，不会完全丧失位置资讯，并能顺利结合WLAN讯号，持续提供精准定位服务。
在最新的安全用户层定位技术2.0版(Secured User Plane Location 2.0, SUPL 2.0)中，已将全球导航卫星系统(GNSS)接收机所提供的位置资讯当作选项之一，换言之，SUPL 2.0亦开放其他的定位技术，如利用微机电系统(MEMS)的航位推算(Dead Reckoning, DR)、行动网路的定位、无线区域网路的定位(Wi-Fi Positioning System, WPS)及结合社群网站(Crowd Sourcing)的定位技术。其中，结合社群网站的技术，如同时定位和地图创建(Simultaneous Localization and Map Building, SLAM)和延展性位置知觉的点对点系统(Scalable Location Aware Peer-to-Peer System, SLAP)技术，皆是支撑未来室内定位和导航服务的关键技术。
在室内的环境中，MEMS主要系利用整合惯性导航系统(INS)所提供的行人航位推算(Pedestrian Dead Reckoning, PDR)做为衔接户外和室内模式的桥梁，以确保不中断的位置输出。
要在智慧型手机中实现紧密结合的GNSS/INS，须掌握INS感测器的规格。在所有的规格项目中，最值得注意的一项就是感测器的偏压。感测器的偏压系根据在固定的条件和没有输入激励的情况之下，在特定的时间周期内所量测到感测器的平均输出值。
偏压一般是由两个部分所组成，其一是先天决定的部分(Deterministic Part)，又称为偏压位移(Bias Offset)或开机偏压(Turn-on Bias)；其二是随机的部分(Stochastic Part)，又称为偏压飘移(Bias Drift)或跑偏(In-run Bias)。图1所示为INS感测器的开机偏压和偏压飘移的定义。
图1 INS感测器的开机偏压和偏压飘移的定义
开机偏压本质上是一个常数值，因此可以在校正的程序中被决定，而偏压飘移基本上是一个变数，它会随着时间和外在环境而改变。偏压飘移具有随机的特色，因此只能藉由随机过程来预测。比例因子的误差就是感测器输出讯号的变化量，以及实际量测到的变化量的比值，其具有先天决定(Deterministic)的特色，但一般也都是采用随机程序(Random Process)来估测。
惯性感测器的误差可以用角度的随机游走(Angular Random Walk, ARW)和速度的随机游走(Velocity Random Walk, VRW)(图2)。ARW是用来描述当累积陀螺仪输出讯号的杂讯时，将会产生的误差或平均差(Average Deviation)。反之，VRW是用来描述累积加速器的杂讯时所产生的误差或平均差。
图2 ARW和VRW的图解说明
实现与INS紧密结合 GNSS接收机面临软体考验
GNSS接收机支援GNSS/INS的紧密结合最大的挑战来自于软体，特别是GNSS接收机的卡尔曼滤波器和接收机自体完好性监控(RAIM)必须能将GNSS的量测资料和INS的资料融合，其须利用RAIM来移除量测品质欠佳的卫星。GNSS周边通讯接口(Peripheral Communication Port)，通常是利用序列通讯埠(Serial Communicable Port)，如通用非同步接收/传送器(UART)或内部整合电路(I2C)。
GNSS业者必须和感测器供应商紧密合作，提供工厂校正的程序给智慧型手机的制造商。绝大多数的制造商都希望所有感测器的校正皆能在工厂产线利用一次性的校正，以取得感测器的偏压和比例因子的误差。在校正完成之后，这些值将会被写到感测器的配置文件(Configuration File)且不会再更改。存放在配置文件内的值，将会被加到感测器的原始资料上面。
一般我们并不希望配置文件内的值经常被更改，因为有可能造成感测器输出到处理器资料的不连续，资料串流的不连续性会导致系统性能的大幅降低，如在陀螺仪的输出资料产生0.1dps的跳跃。若连续性的感测器校正可以提供缓慢的输出资料变化率，则连续性的校正是有益的；反之，则不建议使用连续性的校正。
另一项感测器的校正系属于非必要性，但若能在实验室的阶段校正陀螺仪的ARW，则会改善整体系统的性能。如果没有在实验室阶段校正ARW，则系统通常都会填入一个预设值，并利用此预设值来校正陀螺仪。ARW的校正须要用到比较复杂的软体来收集资料、绘图(Plot)和内插(Interpolation)，因此并不适合在工厂产线上面执行，一般都是在实验室的环境中，利用严谨的静态环境来校正ARW。
ARW的值跟元件和元件之间的变异性关联不大，因此每一种陀螺仪只须做一次实验室的校正即可，但在下列的条件满足时，ARW就必须重新校正：更换陀螺仪(MEMS的制程或参数更改时)、更改硬体抽像层(Hardware Abstraction Layer, HAL)的元件(如取样频率和时间)。
实验室阶段的ARW校正主要是利用长时间于严格的静态环境观察陀螺仪的输出，将八组资料(陀螺仪的x、y、z和x/y/z；加速传感器的x、y、z和x/y/z)做成Allan偏差图(Allan Deviation)。利用内差的方式，在Allan偏差的V型曲线上面，分别找出陀螺仪三个轴的ARW值。
支援INS感测器 Android2.3/4.0系统架构大不同
跑在智慧型手机的高阶作业系统，包含Google的Android(如Android 2.3/4.0)、苹果的iOS(iOS 6.0)和微软的WP 7/8，感测器硬体和GNSS接收机的整合，可透过两种方式来实现：利用HLOS所提供Sensor NDK(Native Development Kit)，或利用一个专属的微控制器(MCU)来前置处理(Pre-process)感测器的原始资料。
从Android 2.3 API Level 9之后的版本，皆支援INS感测器(包含三轴线性加速器、三轴陀螺仪、三轴电子罗盘和一轴压力计)。Android系统将感测器分类为：运动感测器(Motion Sensor)、位置感测器(Position Sensor)及环境感测器(Environment Sensor)。依照感测器的实体又可以将感测器分类为：硬体感测器和软体的感测器。
所谓硬体的感测器，即为实际的感测器；而软体感测器基本上是一种虚拟的硬体感测器。软体感测器一般是藉由一种或一种以上的硬体感测器输出资料，融合产生另外一组感测器输出资料，因此软体感测器又可以称为合成感测器(Synthetic Sensor)。 [!--empirenews.page--]
图3所示的旋转向量(Rotation Vector)就是软体感测器的一种，旋转向量是利用提供三个元素的旋转向量来描述元件的方位(Orientation)。Android所支援的软体感测器还包含：重力感测器(Gravity Sensor)、线性加速(Linear Acceleration)感测器、方位(Orientation)感测器。
图3 Android 2.3感测器的系统架构
我们可以藉由Android的感测器框架(Sensor Framework)来读取所有感测器原始的量测资料。Android感测器框架提供数个等级和介面，可我们执行各种不同的任务，如可利用Android感测器框架来执行定义平台上面有哪些感测器、定义个别感测器的能力(如范围、解析度和制造商)、定义取样率(Sampling Rate)并利用该取样率来撷取感测器的原始资料，以及注册和不注册到SensorEventListener，SensorEventListener会随时监视感测器变化项目。
图3所示为Android 2.3姜饼(Gingerbread)作业系统感测器的系统架构。第一层为Linux的核心(Kernel)和Android所有的硬体驱动，从图3中可以发现G-sensor、陀螺仪和电子罗盘的驱动程序皆是由此层来执行。介于Android系统和感测器硬体之间的实体介面(Physical Interface)大部分都是I2C介面。第二层为Android的HAL层，HAL层主要是通过由驱动程序预先定义好的函数(如read()、open()、write()等)和底层的驱动程序进行通讯。
第三方所提供的感测器应用程式(例如Calibration Library和Fusion Library)可以建构在HAL层。STM所提供的iNEMO感测器套装软体就可以建构在Android的HAL层。实际上iNEMO软体只是一组适应性的卡尔曼滤波器(Adaptive KF, AKF)它可以将STM所推出的各种不同的INS感测器在Android HAL层融合成合成感测器。
第三层为Java框架层(Framework)。JNI层(Java Native Interface)是Java框架层内的一个子层(Sublayer)，JNI子层在整个Android感测器的系统架构中，可以被视为配角，因为JNI子层只须要负责将C++语言转换为Java语言。JNI子层为Java框架层提供一系列的接口，JNI子层利用这些接口函数，协助Java框架层和HAL层沟通。
Java框架层内最重要的功能就是SensorManage和SensorService，感测器的状态控制是由SensorService来负责，而感测器的数据控制是由SensorManager来处理。在Android的Java框架层是透过SensorService.java和SensorManager.java来和JNI子层沟通；在JNI子层则是利用SensorService.cpp和SensorManager.cpp透过hardware.c和HAL层内的Sensors.so沟通。HAL层的Sensors.so透过ioctrl控制Sensor Driver，通过打开Sensor Driver对应，以取得感测器的数据。
第四层则是应用框架(Application Framework)，最上层的感测器应用程式透过Sensor Application Framework来取得感测器的数据。Sensor Application Framework内的SensorManager，利用Java语言和Java层内的SensorManager沟通。
一般的GNSS业者比较希望能够利用一颗专属的MCU，来前置处理(Pre-processing)感测器的原始资料，最主要的原因，其一为感测器的Timestamp是由HLOS来控制，未必能够满足GNSS接收机针对感测器Timestamp的要求。
再者，大部分的GNSS业者都希望能够直接读取原始的感测器资料来进行处理，若原始的感测器资料是先经过平坦化处理(Smoothing)，原始设备制造商(OEM)必须确保所有感测器都是受到相同的程序来执行平坦化。
其三，GNSS业者比较希望利用一个专属的外部MCU来执行感测器的校正，而不是利用OEM所内建的校正程序。最后，资料延迟(Latency)方面，必须确保原始的感测器资料经过HLOS处理之后，不会产生太大的时间延迟。
图4为Android 4.0感测器的软体系统架构，从中可发现，从底层的Kernel到上层的感测应用程式介面(Sensor API)皆是由Sensor NDK来处理。利用Android 4.0的Sensor NDK，可以省略外部MCU的需求。另外，Android 4.0和Andriod 2.3在感测器软体的系统架构上面有一个很明显的差异，就是较新的4.0版支援Google九轴的融合演算法。所谓的融合就是将不同种类感测器的原始资料结合并转换成新的感测器(软体感测器)。
图4 Android 4.0感测器软体的系统架构
应用程式的开发者可藉由API来读取经过融合处理过的资料，而不用去读取原始的感测器资料，如Google的融合演算法可利用四元数(Quaternion)来代表元件的方位。图5所示为硬体和软体感测器所定义的运动参数，有些参数由硬体感测器直接输出；另外一些参数则是经过融合之后的资料。
图5 硬体和软体感测器所输出的运动参数
惯性感测器室内导航应用介绍
惯性感测器在室内导航的应用(INS Application in Indoor Navigation)中，MEMS可以提供下列的功能，做为室内导航的辅助系统：
INS感测器助力 PDR扮演辅助定位角色
到目前为止利用消费性MEMS所实现的DR不管是在汽车或是行人模式其精确度和可靠度一直都是令人存疑。但是PDR却是一项很重要的应用特别是在户外(Outdoor)和室内(Indoor)的无缝接轨(Seamless Handover)，在户外的环境主要是以GNSS为主要的位置资讯来源而在室内的环境主要是由Wi-Fi或行动网路做为主要的位置资讯来源。
在户外和室内的边缘地带，GNSS可能已经无法输出位置资讯同时Wi-Fi或行动网路的位置误差太高经常使得智慧型手机在此环境之下会失去位置资讯。利用INS感测器所提供的PDR不失为一个桥梁来连接户外和室内，PDR可以让智慧型手机维持连续的位置更新直到Wi-Fi的准确度达到可以接受的范围。目前努力的方向是确保PDR可以在行人模式持续运作5分钟，且累积的误差不会超过10%。
PDR的原理主要是在一个已知位置(此位置可以是最后一笔GNSS的位置或是PDR演算法所估测的位置)上，利用INS感测器计算速度和航位角来推算下一笔的位置，或是利用G-sensor来计步并利用步伐(Stride Length)来推算行走的距离。 [!--empirenews.page--]
人类步行状态的复杂度和移动的自由度都远高于汽车模式，因此在行人模式利用PDR演算法所推算出来的速度其精确度并不高。航位角可以利用陀螺仪或是电子罗盘来取得，电子罗盘可以提供绝对的方位角资讯给PDR的演算法来计算下一笔的位置，但是电子罗盘和环境干扰(主要是磁场的扰动)的相关性太高也使得它的实用性大打折扣。
因此PDR不能成为室内导航的主角只能扮演辅助定位的脚色。PDR主要是由三个参数所组成：距离(Distance)、方位角(Azimuth)和高度(Altitude)。利用G-sensor可以计算出距离，陀螺仪可以提供相对方位角的偏移，高度计可以提供相对的高度差。另外，电子罗盘也可以提供绝对的方位角。表1所示为INS模组每个的元件在PDR所扮演的脚色以及相对的优缺点。
结合电子罗盘与陀螺仪 PE方位角精确性跃进
电子罗盘在正常的情况之下可以提供绝对的方位角资讯给位置引擎(PE)，但是电子罗盘很容易遭受到环境磁场改变的影响特别是在室内的环境，因此单纯的依赖电子罗盘所提供的方位角资讯并不是一件可靠的导航工具。
另一方面，陀螺仪不会受到室内磁场改变的影响，可以提供较为可靠的相对方位角位移资讯给PE。但是陀螺仪只能在短时间之内提供可靠的相对方位角资讯，如果没有任何可靠的航位角来校正陀螺仪，则陀螺仪本身的ARW会快速的累积，使得陀螺仪所输出的相对方位角成为不可靠的资讯。
一般的做法都是将陀螺仪所输出的相对方位角和电子罗盘的绝对方位角混合(Blending)在一起，当电子罗盘遭受到磁场变动的影响时，可以利用陀螺仪来校正电子罗盘，当电子罗盘是正常工作时又可以利用电子罗盘来校正陀螺仪。
结合电子罗盘和陀螺仪所提供的方位角资讯在室内导航应用中会扮演很重要的角色，因为不管是基于Wi-Fi或行动网路的定位技术都只能够提供位置的资讯并无法提供行人移动的航位角资讯。
借重G-sensor PDR推算累积距离
利用G-sensor可以提供累积距离(Odometer)的资讯给PDR的软体，有两种方式可以利用G-sensor来推算累积距离：直接利用二次积分的方式将加速度的资料转换为距离量；利用G-sensor来当作计步器并利用预先定义的步伐来推算累积距离。数学上将加速度积分可以得到速度，在将速度积分就可以得到距离。
图6所示为加速度、速度和距离之间的关系。利用加速度来估算距离必须使用到双重积分，而每一次的积分会把杂讯累加，因此错误量的累积会非常的快速；所以，利用加速度的双重积分来获得距离的方式对PDR而言并不是一件可靠的方法。另一种方法是利用G-sensor做为计步器(Step Count)，因此并不须要利用到对G-sensor的资料进行积分的使用模式。
图6 在等加速度的模式之下加速度、速度和距离的关系
图7所示为在步行模式之下，G-sensor在三轴的G值总输出。从图7中可以发现，每一个步伐都会在G-sensor的总输出上面造成显著的短期峰值，利用峰值检测，即可计算步数。
图7 利用G-sensor的总输出来侦测步数
峰值的检测主要系利用G-sensor的输出，在一个短周期内快速的增加和降低至原来的值。为了避免错误的侦测，我们可以在峰值检测加上一个临界值，每个被认定的峰值必须要超过预先定义的临界值，才能够被判定为一个真正的峰值。
另外，每一个步伐可能会产生多个峰值造成步数的误判，我们可以在时域上面加上一个时间周期的缓冲来确保每一个峰值的时间间距必须超过预先定义的时间。峰值的临界值和时间的缓冲周期，皆可以利用大量的测试来定义一个合理值。
距离的推算就是将步数乘上预先定义的步伐大小，因此预先定义的步伐参数必须是一个合理值，否则整个距离的推算误差会相当的大。步伐的长度也可以利用G-sensor在较短的区间内的双重积分所得到的距离，除上步数即可求得步伐的长度。
简单来说，利用G-sensor输出的双重积分所得到的距离来动态的校正步伐的长度，并结合G-sensor的计步功能就可以实现较为准确的累积距离，提供给PDR使用。
此外，步数的峰值检测还可以用来做为运动的侦测，当侦测的步数为零时，就表示用户是在静止的状态，因此PE就可以将位置持续的锁住在前一笔有效的位置上面，直到运动侦测状态变回非静态。
改善覆盖率和精准度 WLAN/INS紧密结合有谱
GNSS/INS的紧密结合在汽车导航上的贡献，即是提供比传统全球卫星定位系统(GPS)接收机更佳的精确度和可靠度，特别是在航位角的改善，可以大幅度的降低后级的地图匹配的错误率，较低的地图匹配错误率意味着较低的误导航错误预警(False Alarm)频率。
GNSS/INS在室内导航的应用最主要的贡献即为PDR，PDR串起室外GNSS为主的定位和室内无线区域网路(WLAN)为主的定位技术。PDR可以提供无缝接轨的室内和户外导航。此外，若把GNSS接收机当成一个位置感测器，则GNSS的角色其实是可以被其他的位置感测器所取代，如WLAN、行动网路和社群网站。
非GNSS位置感测器的最大挑战在于覆盖率、准确度、可重复性及可靠度。若这些问题皆能改善并提升至10公尺内的准确度，实际上GNSS/INS的紧密结合亦可以延伸到WLAN/INS或SLAP/SLAM/INS的紧密结合。图6所示为结合WLAN和INS感测器，以实现紧密结合的WLAN/INS室内定位。
图6 利用WLAN和INS感测器的紧密结合来实现室内定位
在最新的安全用户层定位技术2.0版(Secured User Plane Location 2.0, SUPL 2.0)中，已将全球导航卫星系统(GNSS)接收机所提供的位置资讯当作选项之一，换言之，SUPL 2.0亦开放其他的定位技术，如利用微机电系统(MEMS)的航位推算(Dead Reckoning, DR)、行动网路的定位、无线区域网路的定位(Wi-Fi Positioning System, WPS)及结合社群网站(Crowd Sourcing)的定位技术。其中，结合社群网站的技术，如同时定位和地图创建(Simultaneous Localization and Map Building, SLAM)和延展性位置知觉的点对点系统(Scalable Location Aware Peer-to-Peer System, SLAP)技术，皆是支撑未来室内定位和导航服务的关键技术。
在室内的环境中，MEMS主要系利用整合惯性导航系统(INS)所提供的行人航位推算(Pedestrian Dead Reckoning, PDR)做为衔接户外和室内模式的桥梁，以确保不中断的位置输出。
要在智慧型手机中实现紧密结合的GNSS/INS，须掌握INS感测器的规格。在所有的规格项目中，最值得注意的一项就是感测器的偏压。感测器的偏压系根据在固定的条件和没有输入激励的情况之下，在特定的时间周期内所量测到感测器的平均输出值。
偏压一般是由两个部分所组成，其一是先天决定的部分(Deterministic Part)，又称为偏压位移(Bias Offset)或开机偏压(Turn-on Bias)；其二是随机的部分(Stochastic Part)，又称为偏压飘移(Bias Drift)或跑偏(In-run Bias)。图1所示为INS感测器的开机偏压和偏压飘移的定义。
图1 INS感测器的开机偏压和偏压飘移的定义
开机偏压本质上是一个常数值，因此可以在校正的程序中被决定，而偏压飘移基本上是一个变数，它会随着时间和外在环境而改变。偏压飘移具有随机的特色，因此只能藉由随机过程来预测。比例因子的误差就是感测器输出讯号的变化量，以及实际量测到的变化量的比值，其具有先天决定(Deterministic)的特色，但一般也都是采用随机程序(Random Process)来估测。
惯性感测器的误差可以用角度的随机游走(Angular Random Walk, ARW)和速度的随机游走(Velocity Random Walk, VRW)(图2)。ARW是用来描述当累积陀螺仪输出讯号的杂讯时，将会产生的误差或平均差(Average Deviation)。反之，VRW是用来描述累积加速器的杂讯时所产生的误差或平均差。
图2 ARW和VRW的图解说明
实现与INS紧密结合 GNSS接收机面临软体考验
GNSS接收机支援GNSS/INS的紧密结合最大的挑战来自于软体，特别是GNSS接收机的卡尔曼滤波器和接收机自体完好性监控(RAIM)必须能将GNSS的量测资料和INS的资料融合，其须利用RAIM来移除量测品质欠佳的卫星。GNSS周边通讯接口(Peripheral Communication Port)，通常是利用序列通讯埠(Serial Communicable Port)，如通用非同步接收/传送器(UART)或内部整合电路(I2C)。
GNSS业者必须和感测器供应商紧密合作，提供工厂校正的程序给智慧型手机的制造商。绝大多数的制造商都希望所有感测器的校正皆能在工厂产线利用一次性的校正，以取得感测器的偏压和比例因子的误差。在校正完成之后，这些值将会被写到感测器的配置文件(Configuration File)且不会再更改。存放在配置文件内的值，将会被加到感测器的原始资料上面。
一般我们并不希望配置文件内的值经常被更改，因为有可能造成感测器输出到处理器资料的不连续，资料串流的不连续性会导致系统性能的大幅降低，如在陀螺仪的输出资料产生0.1dps的跳跃。若连续性的感测器校正可以提供缓慢的输出资料变化率，则连续性的校正是有益的；反之，则不建议使用连续性的校正。
另一项感测器的校正系属于非必要性，但若能在实验室的阶段校正陀螺仪的ARW，则会改善整体系统的性能。如果没有在实验室阶段校正ARW，则系统通常都会填入一个预设值，并利用此预设值来校正陀螺仪。ARW的校正须要用到比较复杂的软体来收集资料、绘图(Plot)和内插(Interpolation)，因此并不适合在工厂产线上面执行，一般都是在实验室的环境中，利用严谨的静态环境来校正ARW。
ARW的值跟元件和元件之间的变异性关联不大，因此每一种陀螺仪只须做一次实验室的校正即可，但在下列的条件满足时，ARW就必须重新校正：更换陀螺仪(MEMS的制程或参数更改时)、更改硬体抽像层(Hardware Abstraction Layer, HAL)的元件(如取样频率和时间)。
实验室阶段的ARW校正主要是利用长时间于严格的静态环境观察陀螺仪的输出，将八组资料(陀螺仪的x、y、z和x/y/z；加速传感器的x、y、z和x/y/z)做成Allan偏差图(Allan Deviation)。利用内差的方式，在Allan偏差的V型曲线上面，分别找出陀螺仪三个轴的ARW值。
支援INS感测器 Android2.3/4.0系统架构大不同
跑在智慧型手机的高阶作业系统，包含Google的Android(如Android 2.3/4.0)、苹果的iOS(iOS 6.0)和微软的WP 7/8，感测器硬体和GNSS接收机的整合，可透过两种方式来实现：利用HLOS所提供Sensor NDK(Native Development Kit)，或利用一个专属的微控制器(MCU)来前置处理(Pre-process)感测器的原始资料。
从Android 2.3 API Level 9之后的版本，皆支援INS感测器(包含三轴线性加速器、三轴陀螺仪、三轴电子罗盘和一轴压力计)。Android系统将感测器分类为：运动感测器(Motion Sensor)、位置感测器(Position Sensor)及环境感测器(Environment Sensor)。依照感测器的实体又可以将感测器分类为：硬体感测器和软体的感测器。
所谓硬体的感测器，即为实际的感测器；而软体感测器基本上是一种虚拟的硬体感测器。软体感测器一般是藉由一种或一种以上的硬体感测器输出资料，融合产生另外一组感测器输出资料，因此软体感测器又可以称为合成感测器(Synthetic Sensor)。 [!--empirenews.page--]
图3所示的旋转向量(Rotation Vector)就是软体感测器的一种，旋转向量是利用提供三个元素的旋转向量来描述元件的方位(Orientation)。Android所支援的软体感测器还包含：重力感测器(Gravity Sensor)、线性加速(Linear Acceleration)感测器、方位(Orientation)感测器。
图3 Android 2.3感测器的系统架构
我们可以藉由Android的感测器框架(Sensor Framework)来读取所有感测器原始的量测资料。Android感测器框架提供数个等级和介面，可我们执行各种不同的任务，如可利用Android感测器框架来执行定义平台上面有哪些感测器、定义个别感测器的能力(如范围、解析度和制造商)、定义取样率(Sampling Rate)并利用该取样率来撷取感测器的原始资料，以及注册和不注册到SensorEventListener，SensorEventListener会随时监视感测器变化项目。
图3所示为Android 2.3姜饼(Gingerbread)作业系统感测器的系统架构。第一层为Linux的核心(Kernel)和Android所有的硬体驱动，从图3中可以发现G-sensor、陀螺仪和电子罗盘的驱动程序皆是由此层来执行。介于Android系统和感测器硬体之间的实体介面(Physical Interface)大部分都是I2C介面。第二层为Android的HAL层，HAL层主要是通过由驱动程序预先定义好的函数(如read()、open()、write()等)和底层的驱动程序进行通讯。
第三方所提供的感测器应用程式(例如Calibration Library和Fusion Library)可以建构在HAL层。STM所提供的iNEMO感测器套装软体就可以建构在Android的HAL层。实际上iNEMO软体只是一组适应性的卡尔曼滤波器(Adaptive KF, AKF)它可以将STM所推出的各种不同的INS感测器在Android HAL层融合成合成感测器。
第三层为Java框架层(Framework)。JNI层(Java Native Interface)是Java框架层内的一个子层(Sublayer)，JNI子层在整个Android感测器的系统架构中，可以被视为配角，因为JNI子层只须要负责将C++语言转换为Java语言。JNI子层为Java框架层提供一系列的接口，JNI子层利用这些接口函数，协助Java框架层和HAL层沟通。
Java框架层内最重要的功能就是SensorManage和SensorService，感测器的状态控制是由SensorService来负责，而感测器的数据控制是由SensorManager来处理。在Android的Java框架层是透过SensorService.java和SensorManager.java来和JNI子层沟通；在JNI子层则是利用SensorService.cpp和SensorManager.cpp透过hardware.c和HAL层内的Sensors.so沟通。HAL层的Sensors.so透过ioctrl控制Sensor Driver，通过打开Sensor Driver对应，以取得感测器的数据。
第四层则是应用框架(Application Framework)，最上层的感测器应用程式透过Sensor Application Framework来取得感测器的数据。Sensor Application Framework内的SensorManager，利用Java语言和Java层内的SensorManager沟通。
一般的GNSS业者比较希望能够利用一颗专属的MCU，来前置处理(Pre-processing)感测器的原始资料，最主要的原因，其一为感测器的Timestamp是由HLOS来控制，未必能够满足GNSS接收机针对感测器Timestamp的要求。
再者，大部分的GNSS业者都希望能够直接读取原始的感测器资料来进行处理，若原始的感测器资料是先经过平坦化处理(Smoothing)，原始设备制造商(OEM)必须确保所有感测器都是受到相同的程序来执行平坦化。
其三，GNSS业者比较希望利用一个专属的外部MCU来执行感测器的校正，而不是利用OEM所内建的校正程序。最后，资料延迟(Latency)方面，必须确保原始的感测器资料经过HLOS处理之后，不会产生太大的时间延迟。
图4为Android 4.0感测器的软体系统架构，从中可发现，从底层的Kernel到上层的感测应用程式介面(Sensor API)皆是由Sensor NDK来处理。利用Android 4.0的Sensor NDK，可以省略外部MCU的需求。另外，Android 4.0和Andriod 2.3在感测器软体的系统架构上面有一个很明显的差异，就是较新的4.0版支援Google九轴的融合演算法。所谓的融合就是将不同种类感测器的原始资料结合并转换成新的感测器(软体感测器)。
图4 Android 4.0感测器软体的系统架构
应用程式的开发者可藉由API来读取经过融合处理过的资料，而不用去读取原始的感测器资料，如Google的融合演算法可利用四元数(Quaternion)来代表元件的方位。图5所示为硬体和软体感测器所定义的运动参数，有些参数由硬体感测器直接输出；另外一些参数则是经过融合之后的资料。
图5 硬体和软体感测器所输出的运动参数
惯性感测器室内导航应用介绍
惯性感测器在室内导航的应用(INS Application in Indoor Navigation)中，MEMS可以提供下列的功能，做为室内导航的辅助系统：
INS感测器助力 PDR扮演辅助定位角色
到目前为止利用消费性MEMS所实现的DR不管是在汽车或是行人模式其精确度和可靠度一直都是令人存疑。但是PDR却是一项很重要的应用特别是在户外(Outdoor)和室内(Indoor)的无缝接轨(Seamless Handover)，在户外的环境主要是以GNSS为主要的位置资讯来源而在室内的环境主要是由Wi-Fi或行动网路做为主要的位置资讯来源。
在户外和室内的边缘地带，GNSS可能已经无法输出位置资讯同时Wi-Fi或行动网路的位置误差太高经常使得智慧型手机在此环境之下会失去位置资讯。利用INS感测器所提供的PDR不失为一个桥梁来连接户外和室内，PDR可以让智慧型手机维持连续的位置更新直到Wi-Fi的准确度达到可以接受的范围。目前努力的方向是确保PDR可以在行人模式持续运作5分钟，且累积的误差不会超过10%。
PDR的原理主要是在一个已知位置(此位置可以是最后一笔GNSS的位置或是PDR演算法所估测的位置)上，利用INS感测器计算速度和航位角来推算下一笔的位置，或是利用G-sensor来计步并利用步伐(Stride Length)来推算行走的距离。 [!--empirenews.page--]
人类步行状态的复杂度和移动的自由度都远高于汽车模式，因此在行人模式利用PDR演算法所推算出来的速度其精确度并不高。航位角可以利用陀螺仪或是电子罗盘来取得，电子罗盘可以提供绝对的方位角资讯给PDR的演算法来计算下一笔的位置，但是电子罗盘和环境干扰(主要是磁场的扰动)的相关性太高也使得它的实用性大打折扣。
因此PDR不能成为室内导航的主角只能扮演辅助定位的脚色。PDR主要是由三个参数所组成：距离(Distance)、方位角(Azimuth)和高度(Altitude)。利用G-sensor可以计算出距离，陀螺仪可以提供相对方位角的偏移，高度计可以提供相对的高度差。另外，电子罗盘也可以提供绝对的方位角。表1所示为INS模组每个的元件在PDR所扮演的脚色以及相对的优缺点。
结合电子罗盘与陀螺仪 PE方位角精确性跃进
电子罗盘在正常的情况之下可以提供绝对的方位角资讯给位置引擎(PE)，但是电子罗盘很容易遭受到环境磁场改变的影响特别是在室内的环境，因此单纯的依赖电子罗盘所提供的方位角资讯并不是一件可靠的导航工具。
另一方面，陀螺仪不会受到室内磁场改变的影响，可以提供较为可靠的相对方位角位移资讯给PE。但是陀螺仪只能在短时间之内提供可靠的相对方位角资讯，如果没有任何可靠的航位角来校正陀螺仪，则陀螺仪本身的ARW会快速的累积，使得陀螺仪所输出的相对方位角成为不可靠的资讯。
一般的做法都是将陀螺仪所输出的相对方位角和电子罗盘的绝对方位角混合(Blending)在一起，当电子罗盘遭受到磁场变动的影响时，可以利用陀螺仪来校正电子罗盘，当电子罗盘是正常工作时又可以利用电子罗盘来校正陀螺仪。
结合电子罗盘和陀螺仪所提供的方位角资讯在室内导航应用中会扮演很重要的角色，因为不管是基于Wi-Fi或行动网路的定位技术都只能够提供位置的资讯并无法提供行人移动的航位角资讯。
借重G-sensor PDR推算累积距离
利用G-sensor可以提供累积距离(Odometer)的资讯给PDR的软体，有两种方式可以利用G-sensor来推算累积距离：直接利用二次积分的方式将加速度的资料转换为距离量；利用G-sensor来当作计步器并利用预先定义的步伐来推算累积距离。数学上将加速度积分可以得到速度，在将速度积分就可以得到距离。
图6所示为加速度、速度和距离之间的关系。利用加速度来估算距离必须使用到双重积分，而每一次的积分会把杂讯累加，因此错误量的累积会非常的快速；所以，利用加速度的双重积分来获得距离的方式对PDR而言并不是一件可靠的方法。另一种方法是利用G-sensor做为计步器(Step Count)，因此并不须要利用到对G-sensor的资料进行积分的使用模式。
图6 在等加速度的模式之下加速度、速度和距离的关系
图7所示为在步行模式之下，G-sensor在三轴的G值总输出。从图7中可以发现，每一个步伐都会在G-sensor的总输出上面造成显著的短期峰值，利用峰值检测，即可计算步数。
图7 利用G-sensor的总输出来侦测步数
峰值的检测主要系利用G-sensor的输出，在一个短周期内快速的增加和降低至原来的值。为了避免错误的侦测，我们可以在峰值检测加上一个临界值，每个被认定的峰值必须要超过预先定义的临界值，才能够被判定为一个真正的峰值。
另外，每一个步伐可能会产生多个峰值造成步数的误判，我们可以在时域上面加上一个时间周期的缓冲来确保每一个峰值的时间间距必须超过预先定义的时间。峰值的临界值和时间的缓冲周期，皆可以利用大量的测试来定义一个合理值。
距离的推算就是将步数乘上预先定义的步伐大小，因此预先定义的步伐参数必须是一个合理值，否则整个距离的推算误差会相当的大。步伐的长度也可以利用G-sensor在较短的区间内的双重积分所得到的距离，除上步数即可求得步伐的长度。
简单来说，利用G-sensor输出的双重积分所得到的距离来动态的校正步伐的长度，并结合G-sensor的计步功能就可以实现较为准确的累积距离，提供给PDR使用。
此外，步数的峰值检测还可以用来做为运动的侦测，当侦测的步数为零时，就表示用户是在静止的状态，因此PE就可以将位置持续的锁住在前一笔有效的位置上面，直到运动侦测状态变回非静态。
改善覆盖率和精准度 WLAN/INS紧密结合有谱
GNSS/INS的紧密结合在汽车导航上的贡献，即是提供比传统全球卫星定位系统(GPS)接收机更佳的精确度和可靠度，特别是在航位角的改善，可以大幅度的降低后级的地图匹配的错误率，较低的地图匹配错误率意味着较低的误导航错误预警(False Alarm)频率。
GNSS/INS在室内导航的应用最主要的贡献即为PDR，PDR串起室外GNSS为主的定位和室内无线区域网路(WLAN)为主的定位技术。PDR可以提供无缝接轨的室内和户外导航。此外，若把GNSS接收机当成一个位置感测器，则GNSS的角色其实是可以被其他的位置感测器所取代，如WLAN、行动网路和社群网站。
非GNSS位置感测器的最大挑战在于覆盖率、准确度、可重复性及可靠度。若这些问题皆能改善并提升至10公尺内的准确度，实际上GNSS/INS的紧密结合亦可以延伸到WLAN/INS或SLAP/SLAM/INS的紧密结合。图6所示为结合WLAN和INS感测器，以实现紧密结合的WLAN/INS室内定位。
图6 利用WLAN和INS感测器的紧密结合来实现室内定位
[!--empirenews.page--]
下载文档
