與WLAN技術(shù)緊密結(jié)合 MEMS模組增強(qiáng)室內(nèi)定位精準(zhǔn)度
[導(dǎo)讀]智慧型手機(jī)的室內(nèi)導(dǎo)航應(yīng)用體驗(yàn)可望升級(jí)。微機(jī)電系統(tǒng)(MEMS)感測(cè)器所組成的慣性導(dǎo)航系統(tǒng)(INS)，可提供行人航位推算(PDR)資訊，讓智慧型手機(jī)進(jìn)入室內(nèi)時(shí)，不會(huì)完全喪失位置資訊，并能順利結(jié)合WLAN訊號(hào)，持續(xù)提供精準(zhǔn)定位
智慧型手機(jī)的室內(nèi)導(dǎo)航應(yīng)用體驗(yàn)可望升級(jí)。微機(jī)電系統(tǒng)(MEMS)感測(cè)器所組成的慣性導(dǎo)航系統(tǒng)(INS)，可提供行人航位推算(PDR)資訊，讓智慧型手機(jī)進(jìn)入室內(nèi)時(shí)，不會(huì)完全喪失位置資訊，并能順利結(jié)合WLAN訊號(hào)，持續(xù)提供精準(zhǔn)定位服務(wù)。
在最新的安全用戶層定位技術(shù)2.0版(Secured User Plane Location 2.0, SUPL 2.0)中，已將全球?qū)Ш叫l(wèi)星系統(tǒng)(GNSS)接收機(jī)所提供的位置資訊當(dāng)作選項(xiàng)之一，換言之，SUPL 2.0亦開放其他的定位技術(shù)，如利用微機(jī)電系統(tǒng)(MEMS)的航位推算(Dead Reckoning, DR)、行動(dòng)網(wǎng)路的定位、無線區(qū)域網(wǎng)路的定位(Wi-Fi Positioning System, WPS)及結(jié)合社群網(wǎng)站(Crowd Sourcing)的定位技術(shù)。其中，結(jié)合社群網(wǎng)站的技術(shù)，如同時(shí)定位和地圖創(chuàng)建(Simultaneous Localization and Map Building, SLAM)和延展性位置知覺的點(diǎn)對(duì)點(diǎn)系統(tǒng)(Scalable Location Aware Peer-to-Peer System, SLAP)技術(shù)，皆是支撐未來室內(nèi)定位和導(dǎo)航服務(wù)的關(guān)鍵技術(shù)。
在室內(nèi)的環(huán)境中，MEMS主要系利用整合慣性導(dǎo)航系統(tǒng)(INS)所提供的行人航位推算(Pedestrian Dead Reckoning, PDR)做為銜接戶外和室內(nèi)模式的橋梁，以確保不中斷的位置輸出。
要在智慧型手機(jī)中實(shí)現(xiàn)緊密結(jié)合的GNSS/INS，須掌握INS感測(cè)器的規(guī)格。在所有的規(guī)格項(xiàng)目中，最值得注意的一項(xiàng)就是感測(cè)器的偏壓。感測(cè)器的偏壓系根據(jù)在固定的條件和沒有輸入激勵(lì)的情況之下，在特定的時(shí)間周期內(nèi)所量測(cè)到感測(cè)器的平均輸出值。
偏壓一般是由兩個(gè)部分所組成，其一是先天決定的部分(Deterministic Part)，又稱為偏壓位移(Bias Offset)或開機(jī)偏壓(Turn-on Bias)；其二是隨機(jī)的部分(Stochastic Part)，又稱為偏壓飄移(Bias Drift)或跑偏(In-run Bias)。圖1所示為INS感測(cè)器的開機(jī)偏壓和偏壓飄移的定義。
圖1 INS感測(cè)器的開機(jī)偏壓和偏壓飄移的定義
開機(jī)偏壓本質(zhì)上是一個(gè)常數(shù)值，因此可以在校正的程序中被決定，而偏壓飄移基本上是一個(gè)變數(shù)，它會(huì)隨著時(shí)間和外在環(huán)境而改變。偏壓飄移具有隨機(jī)的特色，因此只能藉由隨機(jī)過程來預(yù)測(cè)。比例因子的誤差就是感測(cè)器輸出訊號(hào)的變化量，以及實(shí)際量測(cè)到的變化量的比值，其具有先天決定(Deterministic)的特色，但一般也都是采用隨機(jī)程序(Random Process)來估測(cè)。
慣性感測(cè)器的誤差可以用角度的隨機(jī)游走(Angular Random Walk, ARW)和速度的隨機(jī)游走(Velocity Random Walk, VRW)(圖2)。ARW是用來描述當(dāng)累積陀螺儀輸出訊號(hào)的雜訊時(shí)，將會(huì)產(chǎn)生的誤差或平均差(Average Deviation)。反之，VRW是用來描述累積加速器的雜訊時(shí)所產(chǎn)生的誤差或平均差。
圖2 ARW和VRW的圖解說明
實(shí)現(xiàn)與INS緊密結(jié)合 GNSS接收機(jī)面臨軟體考驗(yàn)
GNSS接收機(jī)支援GNSS/INS的緊密結(jié)合最大的挑戰(zhàn)來自于軟體，特別是GNSS接收機(jī)的卡爾曼濾波器和接收機(jī)自體完好性監(jiān)控(RAIM)必須能將GNSS的量測(cè)資料和INS的資料融合，其須利用RAIM來移除量測(cè)品質(zhì)欠佳的衛(wèi)星。GNSS周邊通訊接口(Peripheral Communication Port)，通常是利用序列通訊埠(Serial Communicable Port)，如通用非同步接收/傳送器(UART)或內(nèi)部整合電路(I2C)。
GNSS業(yè)者必須和感測(cè)器供應(yīng)商緊密合作，提供工廠校正的程序給智慧型手機(jī)的制造商。絕大多數(shù)的制造商都希望所有感測(cè)器的校正皆能在工廠產(chǎn)線利用一次性的校正，以取得感測(cè)器的偏壓和比例因子的誤差。在校正完成之后，這些值將會(huì)被寫到感測(cè)器的配置文件(Configuration File)且不會(huì)再更改。存放在配置文件內(nèi)的值，將會(huì)被加到感測(cè)器的原始資料上面。
一般我們并不希望配置文件內(nèi)的值經(jīng)常被更改，因?yàn)橛锌赡茉斐筛袦y(cè)器輸出到處理器資料的不連續(xù)，資料串流的不連續(xù)性會(huì)導(dǎo)致系統(tǒng)性能的大幅降低，如在陀螺儀的輸出資料產(chǎn)生0.1dps的跳躍。若連續(xù)性的感測(cè)器校正可以提供緩慢的輸出資料變化率，則連續(xù)性的校正是有益的；反之，則不建議使用連續(xù)性的校正。
另一項(xiàng)感測(cè)器的校正系屬于非必要性，但若能在實(shí)驗(yàn)室的階段校正陀螺儀的ARW，則會(huì)改善整體系統(tǒng)的性能。如果沒有在實(shí)驗(yàn)室階段校正ARW，則系統(tǒng)通常都會(huì)填入一個(gè)預(yù)設(shè)值，并利用此預(yù)設(shè)值來校正陀螺儀。ARW的校正須要用到比較復(fù)雜的軟體來收集資料、繪圖(Plot)和內(nèi)插(Interpolation)，因此并不適合在工廠產(chǎn)線上面執(zhí)行，一般都是在實(shí)驗(yàn)室的環(huán)境中，利用嚴(yán)謹(jǐn)?shù)撵o態(tài)環(huán)境來校正ARW。
ARW的值跟元件和元件之間的變異性關(guān)聯(lián)不大，因此每一種陀螺儀只須做一次實(shí)驗(yàn)室的校正即可，但在下列的條件滿足時(shí)，ARW就必須重新校正：更換陀螺儀(MEMS的制程或參數(shù)更改時(shí))、更改硬體抽像層(Hardware Abstraction Layer, HAL)的元件(如取樣頻率和時(shí)間)。
實(shí)驗(yàn)室階段的ARW校正主要是利用長(zhǎng)時(shí)間于嚴(yán)格的靜態(tài)環(huán)境觀察陀螺儀的輸出，將八組資料(陀螺儀的x、y、z和x/y/z；加速傳感器的x、y、z和x/y/z)做成Allan偏差圖(Allan Deviation)。利用內(nèi)差的方式，在Allan偏差的V型曲線上面，分別找出陀螺儀三個(gè)軸的ARW值。
支援INS感測(cè)器 Android2.3/4.0系統(tǒng)架構(gòu)大不同
跑在智慧型手機(jī)的高階作業(yè)系統(tǒng)，包含Google的Android(如Android 2.3/4.0)、蘋果的iOS(iOS 6.0)和微軟的WP 7/8，感測(cè)器硬體和GNSS接收機(jī)的整合，可透過兩種方式來實(shí)現(xiàn)：利用HLOS所提供Sensor NDK(Native Development Kit)，或利用一個(gè)專屬的微控制器(MCU)來前置處理(Pre-process)感測(cè)器的原始資料。
從Android 2.3 API Level 9之后的版本，皆支援INS感測(cè)器(包含三軸線性加速器、三軸陀螺儀、三軸電子羅盤和一軸壓力計(jì))。Android系統(tǒng)將感測(cè)器分類為：運(yùn)動(dòng)感測(cè)器(Motion Sensor)、位置感測(cè)器(Position Sensor)及環(huán)境感測(cè)器(Environment Sensor)。依照感測(cè)器的實(shí)體又可以將感測(cè)器分類為：硬體感測(cè)器和軟體的感測(cè)器。
所謂硬體的感測(cè)器，即為實(shí)際的感測(cè)器；而軟體感測(cè)器基本上是一種虛擬的硬體感測(cè)器。軟體感測(cè)器一般是藉由一種或一種以上的硬體感測(cè)器輸出資料，融合產(chǎn)生另外一組感測(cè)器輸出資料，因此軟體感測(cè)器又可以稱為合成感測(cè)器(Synthetic Sensor)。 [!--empirenews.page--]
圖3所示的旋轉(zhuǎn)向量(Rotation Vector)就是軟體感測(cè)器的一種，旋轉(zhuǎn)向量是利用提供三個(gè)元素的旋轉(zhuǎn)向量來描述元件的方位(Orientation)。Android所支援的軟體感測(cè)器還包含：重力感測(cè)器(Gravity Sensor)、線性加速(Linear Acceleration)感測(cè)器、方位(Orientation)感測(cè)器。
圖3 Android 2.3感測(cè)器的系統(tǒng)架構(gòu)
我們可以藉由Android的感測(cè)器框架(Sensor Framework)來讀取所有感測(cè)器原始的量測(cè)資料。Android感測(cè)器框架提供數(shù)個(gè)等級(jí)和介面，可我們執(zhí)行各種不同的任務(wù)，如可利用Android感測(cè)器框架來執(zhí)行定義平臺(tái)上面有哪些感測(cè)器、定義個(gè)別感測(cè)器的能力(如范圍、解析度和制造商)、定義取樣率(Sampling Rate)并利用該取樣率來擷取感測(cè)器的原始資料，以及注冊(cè)和不注冊(cè)到SensorEventListener，SensorEventListener會(huì)隨時(shí)監(jiān)視感測(cè)器變化項(xiàng)目。
圖3所示為Android 2.3姜餅(Gingerbread)作業(yè)系統(tǒng)感測(cè)器的系統(tǒng)架構(gòu)。第一層為L(zhǎng)inux的核心(Kernel)和Android所有的硬體驅(qū)動(dòng)，從圖3中可以發(fā)現(xiàn)G-sensor、陀螺儀和電子羅盤的驅(qū)動(dòng)程序皆是由此層來執(zhí)行。介于Android系統(tǒng)和感測(cè)器硬體之間的實(shí)體介面(Physical Interface)大部分都是I2C介面。第二層為Android的HAL層，HAL層主要是通過由驅(qū)動(dòng)程序預(yù)先定義好的函數(shù)(如read()、open()、write()等)和底層的驅(qū)動(dòng)程序進(jìn)行通訊。
第三方所提供的感測(cè)器應(yīng)用程式(例如Calibration Library和Fusion Library)可以建構(gòu)在HAL層。STM所提供的iNEMO感測(cè)器套裝軟體就可以建構(gòu)在Android的HAL層。實(shí)際上iNEMO軟體只是一組適應(yīng)性的卡爾曼濾波器(Adaptive KF, AKF)它可以將STM所推出的各種不同的INS感測(cè)器在Android HAL層融合成合成感測(cè)器。
第三層為Java框架層(Framework)。JNI層(Java Native Interface)是Java框架層內(nèi)的一個(gè)子層(Sublayer)，JNI子層在整個(gè)Android感測(cè)器的系統(tǒng)架構(gòu)中，可以被視為配角，因?yàn)镴NI子層只須要負(fù)責(zé)將C++語言轉(zhuǎn)換為Java語言。JNI子層為Java框架層提供一系列的接口，JNI子層利用這些接口函數(shù)，協(xié)助Java框架層和HAL層溝通。
Java框架層內(nèi)最重要的功能就是SensorManage和SensorService，感測(cè)器的狀態(tài)控制是由SensorService來負(fù)責(zé)，而感測(cè)器的數(shù)據(jù)控制是由SensorManager來處理。在Android的Java框架層是透過SensorService.java和SensorManager.java來和JNI子層溝通；在JNI子層則是利用SensorService.cpp和SensorManager.cpp透過hardware.c和HAL層內(nèi)的Sensors.so溝通。HAL層的Sensors.so透過ioctrl控制Sensor Driver，通過打開Sensor Driver對(duì)應(yīng)，以取得感測(cè)器的數(shù)據(jù)。
第四層則是應(yīng)用框架(Application Framework)，最上層的感測(cè)器應(yīng)用程式透過Sensor Application Framework來取得感測(cè)器的數(shù)據(jù)。Sensor Application Framework內(nèi)的SensorManager，利用Java語言和Java層內(nèi)的SensorManager溝通。
一般的GNSS業(yè)者比較希望能夠利用一顆專屬的MCU，來前置處理(Pre-processing)感測(cè)器的原始資料，最主要的原因，其一為感測(cè)器的Timestamp是由HLOS來控制，未必能夠滿足GNSS接收機(jī)針對(duì)感測(cè)器Timestamp的要求。
再者，大部分的GNSS業(yè)者都希望能夠直接讀取原始的感測(cè)器資料來進(jìn)行處理，若原始的感測(cè)器資料是先經(jīng)過平坦化處理(Smoothing)，原始設(shè)備制造商(OEM)必須確保所有感測(cè)器都是受到相同的程序來執(zhí)行平坦化。
其三，GNSS業(yè)者比較希望利用一個(gè)專屬的外部MCU來執(zhí)行感測(cè)器的校正，而不是利用OEM所內(nèi)建的校正程序。最后，資料延遲(Latency)方面，必須確保原始的感測(cè)器資料經(jīng)過HLOS處理之后，不會(huì)產(chǎn)生太大的時(shí)間延遲。
圖4為Android 4.0感測(cè)器的軟體系統(tǒng)架構(gòu)，從中可發(fā)現(xiàn)，從底層的Kernel到上層的感測(cè)應(yīng)用程式介面(Sensor API)皆是由Sensor NDK來處理。利用Android 4.0的Sensor NDK，可以省略外部MCU的需求。另外，Android 4.0和Andriod 2.3在感測(cè)器軟體的系統(tǒng)架構(gòu)上面有一個(gè)很明顯的差異，就是較新的4.0版支援Google九軸的融合演算法。所謂的融合就是將不同種類感測(cè)器的原始資料結(jié)合并轉(zhuǎn)換成新的感測(cè)器(軟體感測(cè)器)。
圖4 Android 4.0感測(cè)器軟體的系統(tǒng)架構(gòu)
應(yīng)用程式的開發(fā)者可藉由API來讀取經(jīng)過融合處理過的資料，而不用去讀取原始的感測(cè)器資料，如Google的融合演算法可利用四元數(shù)(Quaternion)來代表元件的方位。圖5所示為硬體和軟體感測(cè)器所定義的運(yùn)動(dòng)參數(shù)，有些參數(shù)由硬體感測(cè)器直接輸出；另外一些參數(shù)則是經(jīng)過融合之后的資料。
圖5 硬體和軟體感測(cè)器所輸出的運(yùn)動(dòng)參數(shù)
慣性感測(cè)器室內(nèi)導(dǎo)航應(yīng)用介紹
慣性感測(cè)器在室內(nèi)導(dǎo)航的應(yīng)用(INS Application in Indoor Navigation)中，MEMS可以提供下列的功能，做為室內(nèi)導(dǎo)航的輔助系統(tǒng)：
INS感測(cè)器助力 PDR扮演輔助定位角色
到目前為止利用消費(fèi)性MEMS所實(shí)現(xiàn)的DR不管是在汽車或是行人模式其精確度和可靠度一直都是令人存疑。但是PDR卻是一項(xiàng)很重要的應(yīng)用特別是在戶外(Outdoor)和室內(nèi)(Indoor)的無縫接軌(Seamless Handover)，在戶外的環(huán)境主要是以GNSS為主要的位置資訊來源而在室內(nèi)的環(huán)境主要是由Wi-Fi或行動(dòng)網(wǎng)路做為主要的位置資訊來源。
在戶外和室內(nèi)的邊緣地帶，GNSS可能已經(jīng)無法輸出位置資訊同時(shí)Wi-Fi或行動(dòng)網(wǎng)路的位置誤差太高經(jīng)常使得智慧型手機(jī)在此環(huán)境之下會(huì)失去位置資訊。利用INS感測(cè)器所提供的PDR不失為一個(gè)橋梁來連接戶外和室內(nèi)，PDR可以讓智慧型手機(jī)維持連續(xù)的位置更新直到Wi-Fi的準(zhǔn)確度達(dá)到可以接受的范圍。目前努力的方向是確保PDR可以在行人模式持續(xù)運(yùn)作5分鐘，且累積的誤差不會(huì)超過10%。
PDR的原理主要是在一個(gè)已知位置(此位置可以是最后一筆GNSS的位置或是PDR演算法所估測(cè)的位置)上，利用INS感測(cè)器計(jì)算速度和航位角來推算下一筆的位置，或是利用G-sensor來計(jì)步并利用步伐(Stride Length)來推算行走的距離。 [!--empirenews.page--]
人類步行狀態(tài)的復(fù)雜度和移動(dòng)的自由度都遠(yuǎn)高于汽車模式，因此在行人模式利用PDR演算法所推算出來的速度其精確度并不高。航位角可以利用陀螺儀或是電子羅盤來取得，電子羅盤可以提供絕對(duì)的方位角資訊給PDR的演算法來計(jì)算下一筆的位置，但是電子羅盤和環(huán)境干擾(主要是磁場(chǎng)的擾動(dòng))的相關(guān)性太高也使得它的實(shí)用性大打折扣。
因此PDR不能成為室內(nèi)導(dǎo)航的主角只能扮演輔助定位的腳色。PDR主要是由三個(gè)參數(shù)所組成：距離(Distance)、方位角(Azimuth)和高度(Altitude)。利用G-sensor可以計(jì)算出距離，陀螺儀可以提供相對(duì)方位角的偏移，高度計(jì)可以提供相對(duì)的高度差。另外，電子羅盤也可以提供絕對(duì)的方位角。表1所示為INS模組每個(gè)的元件在PDR所扮演的腳色以及相對(duì)的優(yōu)缺點(diǎn)。
結(jié)合電子羅盤與陀螺儀 PE方位角精確性躍進(jìn)
電子羅盤在正常的情況之下可以提供絕對(duì)的方位角資訊給位置引擎(PE)，但是電子羅盤很容易遭受到環(huán)境磁場(chǎng)改變的影響特別是在室內(nèi)的環(huán)境，因此單純的依賴電子羅盤所提供的方位角資訊并不是一件可靠的導(dǎo)航工具。
另一方面，陀螺儀不會(huì)受到室內(nèi)磁場(chǎng)改變的影響，可以提供較為可靠的相對(duì)方位角位移資訊給PE。但是陀螺儀只能在短時(shí)間之內(nèi)提供可靠的相對(duì)方位角資訊，如果沒有任何可靠的航位角來校正陀螺儀，則陀螺儀本身的ARW會(huì)快速的累積，使得陀螺儀所輸出的相對(duì)方位角成為不可靠的資訊。
一般的做法都是將陀螺儀所輸出的相對(duì)方位角和電子羅盤的絕對(duì)方位角混合(Blending)在一起，當(dāng)電子羅盤遭受到磁場(chǎng)變動(dòng)的影響時(shí)，可以利用陀螺儀來校正電子羅盤，當(dāng)電子羅盤是正常工作時(shí)又可以利用電子羅盤來校正陀螺儀。
結(jié)合電子羅盤和陀螺儀所提供的方位角資訊在室內(nèi)導(dǎo)航應(yīng)用中會(huì)扮演很重要的角色，因?yàn)椴还苁腔赪i-Fi或行動(dòng)網(wǎng)路的定位技術(shù)都只能夠提供位置的資訊并無法提供行人移動(dòng)的航位角資訊。
借重G-sensor PDR推算累積距離
利用G-sensor可以提供累積距離(Odometer)的資訊給PDR的軟體，有兩種方式可以利用G-sensor來推算累積距離：直接利用二次積分的方式將加速度的資料轉(zhuǎn)換為距離量；利用G-sensor來當(dāng)作計(jì)步器并利用預(yù)先定義的步伐來推算累積距離。數(shù)學(xué)上將加速度積分可以得到速度，在將速度積分就可以得到距離。
圖6所示為加速度、速度和距離之間的關(guān)系。利用加速度來估算距離必須使用到雙重積分，而每一次的積分會(huì)把雜訊累加，因此錯(cuò)誤量的累積會(huì)非常的快速；所以，利用加速度的雙重積分來獲得距離的方式對(duì)PDR而言并不是一件可靠的方法。另一種方法是利用G-sensor做為計(jì)步器(Step Count)，因此并不須要利用到對(duì)G-sensor的資料進(jìn)行積分的使用模式。
圖6 在等加速度的模式之下加速度、速度和距離的關(guān)系
圖7所示為在步行模式之下，G-sensor在三軸的G值總輸出。從圖7中可以發(fā)現(xiàn)，每一個(gè)步伐都會(huì)在G-sensor的總輸出上面造成顯著的短期峰值，利用峰值檢測(cè)，即可計(jì)算步數(shù)。
圖7 利用G-sensor的總輸出來偵測(cè)步數(shù)
峰值的檢測(cè)主要系利用G-sensor的輸出，在一個(gè)短周期內(nèi)快速的增加和降低至原來的值。為了避免錯(cuò)誤的偵測(cè)，我們可以在峰值檢測(cè)加上一個(gè)臨界值，每個(gè)被認(rèn)定的峰值必須要超過預(yù)先定義的臨界值，才能夠被判定為一個(gè)真正的峰值。
另外，每一個(gè)步伐可能會(huì)產(chǎn)生多個(gè)峰值造成步數(shù)的誤判，我們可以在時(shí)域上面加上一個(gè)時(shí)間周期的緩沖來確保每一個(gè)峰值的時(shí)間間距必須超過預(yù)先定義的時(shí)間。峰值的臨界值和時(shí)間的緩沖周期，皆可以利用大量的測(cè)試來定義一個(gè)合理值。
距離的推算就是將步數(shù)乘上預(yù)先定義的步伐大小，因此預(yù)先定義的步伐參數(shù)必須是一個(gè)合理值，否則整個(gè)距離的推算誤差會(huì)相當(dāng)?shù)拇蟆２椒サ拈L(zhǎng)度也可以利用G-sensor在較短的區(qū)間內(nèi)的雙重積分所得到的距離，除上步數(shù)即可求得步伐的長(zhǎng)度。
簡(jiǎn)單來說，利用G-sensor輸出的雙重積分所得到的距離來動(dòng)態(tài)的校正步伐的長(zhǎng)度，并結(jié)合G-sensor的計(jì)步功能就可以實(shí)現(xiàn)較為準(zhǔn)確的累積距離，提供給PDR使用。
此外，步數(shù)的峰值檢測(cè)還可以用來做為運(yùn)動(dòng)的偵測(cè)，當(dāng)偵測(cè)的步數(shù)為零時(shí)，就表示用戶是在靜止的狀態(tài)，因此PE就可以將位置持續(xù)的鎖住在前一筆有效的位置上面，直到運(yùn)動(dòng)偵測(cè)狀態(tài)變回非靜態(tài)。
改善覆蓋率和精準(zhǔn)度 WLAN/INS緊密結(jié)合有譜
GNSS/INS的緊密結(jié)合在汽車導(dǎo)航上的貢獻(xiàn)，即是提供比傳統(tǒng)全球衛(wèi)星定位系統(tǒng)(GPS)接收機(jī)更佳的精確度和可靠度，特別是在航位角的改善，可以大幅度的降低后級(jí)的地圖匹配的錯(cuò)誤率，較低的地圖匹配錯(cuò)誤率意味著較低的誤導(dǎo)航錯(cuò)誤預(yù)警(False Alarm)頻率。
GNSS/INS在室內(nèi)導(dǎo)航的應(yīng)用最主要的貢獻(xiàn)即為PDR，PDR串起室外GNSS為主的定位和室內(nèi)無線區(qū)域網(wǎng)路(WLAN)為主的定位技術(shù)。PDR可以提供無縫接軌的室內(nèi)和戶外導(dǎo)航。此外，若把GNSS接收機(jī)當(dāng)成一個(gè)位置感測(cè)器，則GNSS的角色其實(shí)是可以被其他的位置感測(cè)器所取代，如WLAN、行動(dòng)網(wǎng)路和社群網(wǎng)站。
非GNSS位置感測(cè)器的最大挑戰(zhàn)在于覆蓋率、準(zhǔn)確度、可重復(fù)性及可靠度。若這些問題皆能改善并提升至10公尺內(nèi)的準(zhǔn)確度，實(shí)際上GNSS/INS的緊密結(jié)合亦可以延伸到WLAN/INS或SLAP/SLAM/INS的緊密結(jié)合。圖6所示為結(jié)合WLAN和INS感測(cè)器，以實(shí)現(xiàn)緊密結(jié)合的WLAN/INS室內(nèi)定位。
圖6 利用WLAN和INS感測(cè)器的緊密結(jié)合來實(shí)現(xiàn)室內(nèi)定位
在最新的安全用戶層定位技術(shù)2.0版(Secured User Plane Location 2.0, SUPL 2.0)中，已將全球?qū)Ш叫l(wèi)星系統(tǒng)(GNSS)接收機(jī)所提供的位置資訊當(dāng)作選項(xiàng)之一，換言之，SUPL 2.0亦開放其他的定位技術(shù)，如利用微機(jī)電系統(tǒng)(MEMS)的航位推算(Dead Reckoning, DR)、行動(dòng)網(wǎng)路的定位、無線區(qū)域網(wǎng)路的定位(Wi-Fi Positioning System, WPS)及結(jié)合社群網(wǎng)站(Crowd Sourcing)的定位技術(shù)。其中，結(jié)合社群網(wǎng)站的技術(shù)，如同時(shí)定位和地圖創(chuàng)建(Simultaneous Localization and Map Building, SLAM)和延展性位置知覺的點(diǎn)對(duì)點(diǎn)系統(tǒng)(Scalable Location Aware Peer-to-Peer System, SLAP)技術(shù)，皆是支撐未來室內(nèi)定位和導(dǎo)航服務(wù)的關(guān)鍵技術(shù)。
在室內(nèi)的環(huán)境中，MEMS主要系利用整合慣性導(dǎo)航系統(tǒng)(INS)所提供的行人航位推算(Pedestrian Dead Reckoning, PDR)做為銜接戶外和室內(nèi)模式的橋梁，以確保不中斷的位置輸出。
要在智慧型手機(jī)中實(shí)現(xiàn)緊密結(jié)合的GNSS/INS，須掌握INS感測(cè)器的規(guī)格。在所有的規(guī)格項(xiàng)目中，最值得注意的一項(xiàng)就是感測(cè)器的偏壓。感測(cè)器的偏壓系根據(jù)在固定的條件和沒有輸入激勵(lì)的情況之下，在特定的時(shí)間周期內(nèi)所量測(cè)到感測(cè)器的平均輸出值。
偏壓一般是由兩個(gè)部分所組成，其一是先天決定的部分(Deterministic Part)，又稱為偏壓位移(Bias Offset)或開機(jī)偏壓(Turn-on Bias)；其二是隨機(jī)的部分(Stochastic Part)，又稱為偏壓飄移(Bias Drift)或跑偏(In-run Bias)。圖1所示為INS感測(cè)器的開機(jī)偏壓和偏壓飄移的定義。
圖1 INS感測(cè)器的開機(jī)偏壓和偏壓飄移的定義
開機(jī)偏壓本質(zhì)上是一個(gè)常數(shù)值，因此可以在校正的程序中被決定，而偏壓飄移基本上是一個(gè)變數(shù)，它會(huì)隨著時(shí)間和外在環(huán)境而改變。偏壓飄移具有隨機(jī)的特色，因此只能藉由隨機(jī)過程來預(yù)測(cè)。比例因子的誤差就是感測(cè)器輸出訊號(hào)的變化量，以及實(shí)際量測(cè)到的變化量的比值，其具有先天決定(Deterministic)的特色，但一般也都是采用隨機(jī)程序(Random Process)來估測(cè)。
慣性感測(cè)器的誤差可以用角度的隨機(jī)游走(Angular Random Walk, ARW)和速度的隨機(jī)游走(Velocity Random Walk, VRW)(圖2)。ARW是用來描述當(dāng)累積陀螺儀輸出訊號(hào)的雜訊時(shí)，將會(huì)產(chǎn)生的誤差或平均差(Average Deviation)。反之，VRW是用來描述累積加速器的雜訊時(shí)所產(chǎn)生的誤差或平均差。
圖2 ARW和VRW的圖解說明
實(shí)現(xiàn)與INS緊密結(jié)合 GNSS接收機(jī)面臨軟體考驗(yàn)
GNSS接收機(jī)支援GNSS/INS的緊密結(jié)合最大的挑戰(zhàn)來自于軟體，特別是GNSS接收機(jī)的卡爾曼濾波器和接收機(jī)自體完好性監(jiān)控(RAIM)必須能將GNSS的量測(cè)資料和INS的資料融合，其須利用RAIM來移除量測(cè)品質(zhì)欠佳的衛(wèi)星。GNSS周邊通訊接口(Peripheral Communication Port)，通常是利用序列通訊埠(Serial Communicable Port)，如通用非同步接收/傳送器(UART)或內(nèi)部整合電路(I2C)。
GNSS業(yè)者必須和感測(cè)器供應(yīng)商緊密合作，提供工廠校正的程序給智慧型手機(jī)的制造商。絕大多數(shù)的制造商都希望所有感測(cè)器的校正皆能在工廠產(chǎn)線利用一次性的校正，以取得感測(cè)器的偏壓和比例因子的誤差。在校正完成之后，這些值將會(huì)被寫到感測(cè)器的配置文件(Configuration File)且不會(huì)再更改。存放在配置文件內(nèi)的值，將會(huì)被加到感測(cè)器的原始資料上面。
一般我們并不希望配置文件內(nèi)的值經(jīng)常被更改，因?yàn)橛锌赡茉斐筛袦y(cè)器輸出到處理器資料的不連續(xù)，資料串流的不連續(xù)性會(huì)導(dǎo)致系統(tǒng)性能的大幅降低，如在陀螺儀的輸出資料產(chǎn)生0.1dps的跳躍。若連續(xù)性的感測(cè)器校正可以提供緩慢的輸出資料變化率，則連續(xù)性的校正是有益的；反之，則不建議使用連續(xù)性的校正。
另一項(xiàng)感測(cè)器的校正系屬于非必要性，但若能在實(shí)驗(yàn)室的階段校正陀螺儀的ARW，則會(huì)改善整體系統(tǒng)的性能。如果沒有在實(shí)驗(yàn)室階段校正ARW，則系統(tǒng)通常都會(huì)填入一個(gè)預(yù)設(shè)值，并利用此預(yù)設(shè)值來校正陀螺儀。ARW的校正須要用到比較復(fù)雜的軟體來收集資料、繪圖(Plot)和內(nèi)插(Interpolation)，因此并不適合在工廠產(chǎn)線上面執(zhí)行，一般都是在實(shí)驗(yàn)室的環(huán)境中，利用嚴(yán)謹(jǐn)?shù)撵o態(tài)環(huán)境來校正ARW。
ARW的值跟元件和元件之間的變異性關(guān)聯(lián)不大，因此每一種陀螺儀只須做一次實(shí)驗(yàn)室的校正即可，但在下列的條件滿足時(shí)，ARW就必須重新校正：更換陀螺儀(MEMS的制程或參數(shù)更改時(shí))、更改硬體抽像層(Hardware Abstraction Layer, HAL)的元件(如取樣頻率和時(shí)間)。
實(shí)驗(yàn)室階段的ARW校正主要是利用長(zhǎng)時(shí)間于嚴(yán)格的靜態(tài)環(huán)境觀察陀螺儀的輸出，將八組資料(陀螺儀的x、y、z和x/y/z；加速傳感器的x、y、z和x/y/z)做成Allan偏差圖(Allan Deviation)。利用內(nèi)差的方式，在Allan偏差的V型曲線上面，分別找出陀螺儀三個(gè)軸的ARW值。
支援INS感測(cè)器 Android2.3/4.0系統(tǒng)架構(gòu)大不同
跑在智慧型手機(jī)的高階作業(yè)系統(tǒng)，包含Google的Android(如Android 2.3/4.0)、蘋果的iOS(iOS 6.0)和微軟的WP 7/8，感測(cè)器硬體和GNSS接收機(jī)的整合，可透過兩種方式來實(shí)現(xiàn)：利用HLOS所提供Sensor NDK(Native Development Kit)，或利用一個(gè)專屬的微控制器(MCU)來前置處理(Pre-process)感測(cè)器的原始資料。
從Android 2.3 API Level 9之后的版本，皆支援INS感測(cè)器(包含三軸線性加速器、三軸陀螺儀、三軸電子羅盤和一軸壓力計(jì))。Android系統(tǒng)將感測(cè)器分類為：運(yùn)動(dòng)感測(cè)器(Motion Sensor)、位置感測(cè)器(Position Sensor)及環(huán)境感測(cè)器(Environment Sensor)。依照感測(cè)器的實(shí)體又可以將感測(cè)器分類為：硬體感測(cè)器和軟體的感測(cè)器。
所謂硬體的感測(cè)器，即為實(shí)際的感測(cè)器；而軟體感測(cè)器基本上是一種虛擬的硬體感測(cè)器。軟體感測(cè)器一般是藉由一種或一種以上的硬體感測(cè)器輸出資料，融合產(chǎn)生另外一組感測(cè)器輸出資料，因此軟體感測(cè)器又可以稱為合成感測(cè)器(Synthetic Sensor)。 [!--empirenews.page--]
圖3所示的旋轉(zhuǎn)向量(Rotation Vector)就是軟體感測(cè)器的一種，旋轉(zhuǎn)向量是利用提供三個(gè)元素的旋轉(zhuǎn)向量來描述元件的方位(Orientation)。Android所支援的軟體感測(cè)器還包含：重力感測(cè)器(Gravity Sensor)、線性加速(Linear Acceleration)感測(cè)器、方位(Orientation)感測(cè)器。
圖3 Android 2.3感測(cè)器的系統(tǒng)架構(gòu)
我們可以藉由Android的感測(cè)器框架(Sensor Framework)來讀取所有感測(cè)器原始的量測(cè)資料。Android感測(cè)器框架提供數(shù)個(gè)等級(jí)和介面，可我們執(zhí)行各種不同的任務(wù)，如可利用Android感測(cè)器框架來執(zhí)行定義平臺(tái)上面有哪些感測(cè)器、定義個(gè)別感測(cè)器的能力(如范圍、解析度和制造商)、定義取樣率(Sampling Rate)并利用該取樣率來擷取感測(cè)器的原始資料，以及注冊(cè)和不注冊(cè)到SensorEventListener，SensorEventListener會(huì)隨時(shí)監(jiān)視感測(cè)器變化項(xiàng)目。
圖3所示為Android 2.3姜餅(Gingerbread)作業(yè)系統(tǒng)感測(cè)器的系統(tǒng)架構(gòu)。第一層為L(zhǎng)inux的核心(Kernel)和Android所有的硬體驅(qū)動(dòng)，從圖3中可以發(fā)現(xiàn)G-sensor、陀螺儀和電子羅盤的驅(qū)動(dòng)程序皆是由此層來執(zhí)行。介于Android系統(tǒng)和感測(cè)器硬體之間的實(shí)體介面(Physical Interface)大部分都是I2C介面。第二層為Android的HAL層，HAL層主要是通過由驅(qū)動(dòng)程序預(yù)先定義好的函數(shù)(如read()、open()、write()等)和底層的驅(qū)動(dòng)程序進(jìn)行通訊。
第三方所提供的感測(cè)器應(yīng)用程式(例如Calibration Library和Fusion Library)可以建構(gòu)在HAL層。STM所提供的iNEMO感測(cè)器套裝軟體就可以建構(gòu)在Android的HAL層。實(shí)際上iNEMO軟體只是一組適應(yīng)性的卡爾曼濾波器(Adaptive KF, AKF)它可以將STM所推出的各種不同的INS感測(cè)器在Android HAL層融合成合成感測(cè)器。
第三層為Java框架層(Framework)。JNI層(Java Native Interface)是Java框架層內(nèi)的一個(gè)子層(Sublayer)，JNI子層在整個(gè)Android感測(cè)器的系統(tǒng)架構(gòu)中，可以被視為配角，因?yàn)镴NI子層只須要負(fù)責(zé)將C++語言轉(zhuǎn)換為Java語言。JNI子層為Java框架層提供一系列的接口，JNI子層利用這些接口函數(shù)，協(xié)助Java框架層和HAL層溝通。
Java框架層內(nèi)最重要的功能就是SensorManage和SensorService，感測(cè)器的狀態(tài)控制是由SensorService來負(fù)責(zé)，而感測(cè)器的數(shù)據(jù)控制是由SensorManager來處理。在Android的Java框架層是透過SensorService.java和SensorManager.java來和JNI子層溝通；在JNI子層則是利用SensorService.cpp和SensorManager.cpp透過hardware.c和HAL層內(nèi)的Sensors.so溝通。HAL層的Sensors.so透過ioctrl控制Sensor Driver，通過打開Sensor Driver對(duì)應(yīng)，以取得感測(cè)器的數(shù)據(jù)。
第四層則是應(yīng)用框架(Application Framework)，最上層的感測(cè)器應(yīng)用程式透過Sensor Application Framework來取得感測(cè)器的數(shù)據(jù)。Sensor Application Framework內(nèi)的SensorManager，利用Java語言和Java層內(nèi)的SensorManager溝通。
一般的GNSS業(yè)者比較希望能夠利用一顆專屬的MCU，來前置處理(Pre-processing)感測(cè)器的原始資料，最主要的原因，其一為感測(cè)器的Timestamp是由HLOS來控制，未必能夠滿足GNSS接收機(jī)針對(duì)感測(cè)器Timestamp的要求。
再者，大部分的GNSS業(yè)者都希望能夠直接讀取原始的感測(cè)器資料來進(jìn)行處理，若原始的感測(cè)器資料是先經(jīng)過平坦化處理(Smoothing)，原始設(shè)備制造商(OEM)必須確保所有感測(cè)器都是受到相同的程序來執(zhí)行平坦化。
其三，GNSS業(yè)者比較希望利用一個(gè)專屬的外部MCU來執(zhí)行感測(cè)器的校正，而不是利用OEM所內(nèi)建的校正程序。最后，資料延遲(Latency)方面，必須確保原始的感測(cè)器資料經(jīng)過HLOS處理之后，不會(huì)產(chǎn)生太大的時(shí)間延遲。
圖4為Android 4.0感測(cè)器的軟體系統(tǒng)架構(gòu)，從中可發(fā)現(xiàn)，從底層的Kernel到上層的感測(cè)應(yīng)用程式介面(Sensor API)皆是由Sensor NDK來處理。利用Android 4.0的Sensor NDK，可以省略外部MCU的需求。另外，Android 4.0和Andriod 2.3在感測(cè)器軟體的系統(tǒng)架構(gòu)上面有一個(gè)很明顯的差異，就是較新的4.0版支援Google九軸的融合演算法。所謂的融合就是將不同種類感測(cè)器的原始資料結(jié)合并轉(zhuǎn)換成新的感測(cè)器(軟體感測(cè)器)。
圖4 Android 4.0感測(cè)器軟體的系統(tǒng)架構(gòu)
應(yīng)用程式的開發(fā)者可藉由API來讀取經(jīng)過融合處理過的資料，而不用去讀取原始的感測(cè)器資料，如Google的融合演算法可利用四元數(shù)(Quaternion)來代表元件的方位。圖5所示為硬體和軟體感測(cè)器所定義的運(yùn)動(dòng)參數(shù)，有些參數(shù)由硬體感測(cè)器直接輸出；另外一些參數(shù)則是經(jīng)過融合之后的資料。
圖5 硬體和軟體感測(cè)器所輸出的運(yùn)動(dòng)參數(shù)
慣性感測(cè)器室內(nèi)導(dǎo)航應(yīng)用介紹
慣性感測(cè)器在室內(nèi)導(dǎo)航的應(yīng)用(INS Application in Indoor Navigation)中，MEMS可以提供下列的功能，做為室內(nèi)導(dǎo)航的輔助系統(tǒng)：
INS感測(cè)器助力 PDR扮演輔助定位角色
到目前為止利用消費(fèi)性MEMS所實(shí)現(xiàn)的DR不管是在汽車或是行人模式其精確度和可靠度一直都是令人存疑。但是PDR卻是一項(xiàng)很重要的應(yīng)用特別是在戶外(Outdoor)和室內(nèi)(Indoor)的無縫接軌(Seamless Handover)，在戶外的環(huán)境主要是以GNSS為主要的位置資訊來源而在室內(nèi)的環(huán)境主要是由Wi-Fi或行動(dòng)網(wǎng)路做為主要的位置資訊來源。
在戶外和室內(nèi)的邊緣地帶，GNSS可能已經(jīng)無法輸出位置資訊同時(shí)Wi-Fi或行動(dòng)網(wǎng)路的位置誤差太高經(jīng)常使得智慧型手機(jī)在此環(huán)境之下會(huì)失去位置資訊。利用INS感測(cè)器所提供的PDR不失為一個(gè)橋梁來連接戶外和室內(nèi)，PDR可以讓智慧型手機(jī)維持連續(xù)的位置更新直到Wi-Fi的準(zhǔn)確度達(dá)到可以接受的范圍。目前努力的方向是確保PDR可以在行人模式持續(xù)運(yùn)作5分鐘，且累積的誤差不會(huì)超過10%。
PDR的原理主要是在一個(gè)已知位置(此位置可以是最后一筆GNSS的位置或是PDR演算法所估測(cè)的位置)上，利用INS感測(cè)器計(jì)算速度和航位角來推算下一筆的位置，或是利用G-sensor來計(jì)步并利用步伐(Stride Length)來推算行走的距離。 [!--empirenews.page--]
人類步行狀態(tài)的復(fù)雜度和移動(dòng)的自由度都遠(yuǎn)高于汽車模式，因此在行人模式利用PDR演算法所推算出來的速度其精確度并不高。航位角可以利用陀螺儀或是電子羅盤來取得，電子羅盤可以提供絕對(duì)的方位角資訊給PDR的演算法來計(jì)算下一筆的位置，但是電子羅盤和環(huán)境干擾(主要是磁場(chǎng)的擾動(dòng))的相關(guān)性太高也使得它的實(shí)用性大打折扣。
因此PDR不能成為室內(nèi)導(dǎo)航的主角只能扮演輔助定位的腳色。PDR主要是由三個(gè)參數(shù)所組成：距離(Distance)、方位角(Azimuth)和高度(Altitude)。利用G-sensor可以計(jì)算出距離，陀螺儀可以提供相對(duì)方位角的偏移，高度計(jì)可以提供相對(duì)的高度差。另外，電子羅盤也可以提供絕對(duì)的方位角。表1所示為INS模組每個(gè)的元件在PDR所扮演的腳色以及相對(duì)的優(yōu)缺點(diǎn)。
結(jié)合電子羅盤與陀螺儀 PE方位角精確性躍進(jìn)
電子羅盤在正常的情況之下可以提供絕對(duì)的方位角資訊給位置引擎(PE)，但是電子羅盤很容易遭受到環(huán)境磁場(chǎng)改變的影響特別是在室內(nèi)的環(huán)境，因此單純的依賴電子羅盤所提供的方位角資訊并不是一件可靠的導(dǎo)航工具。
另一方面，陀螺儀不會(huì)受到室內(nèi)磁場(chǎng)改變的影響，可以提供較為可靠的相對(duì)方位角位移資訊給PE。但是陀螺儀只能在短時(shí)間之內(nèi)提供可靠的相對(duì)方位角資訊，如果沒有任何可靠的航位角來校正陀螺儀，則陀螺儀本身的ARW會(huì)快速的累積，使得陀螺儀所輸出的相對(duì)方位角成為不可靠的資訊。
一般的做法都是將陀螺儀所輸出的相對(duì)方位角和電子羅盤的絕對(duì)方位角混合(Blending)在一起，當(dāng)電子羅盤遭受到磁場(chǎng)變動(dòng)的影響時(shí)，可以利用陀螺儀來校正電子羅盤，當(dāng)電子羅盤是正常工作時(shí)又可以利用電子羅盤來校正陀螺儀。
結(jié)合電子羅盤和陀螺儀所提供的方位角資訊在室內(nèi)導(dǎo)航應(yīng)用中會(huì)扮演很重要的角色，因?yàn)椴还苁腔赪i-Fi或行動(dòng)網(wǎng)路的定位技術(shù)都只能夠提供位置的資訊并無法提供行人移動(dòng)的航位角資訊。
借重G-sensor PDR推算累積距離
利用G-sensor可以提供累積距離(Odometer)的資訊給PDR的軟體，有兩種方式可以利用G-sensor來推算累積距離：直接利用二次積分的方式將加速度的資料轉(zhuǎn)換為距離量；利用G-sensor來當(dāng)作計(jì)步器并利用預(yù)先定義的步伐來推算累積距離。數(shù)學(xué)上將加速度積分可以得到速度，在將速度積分就可以得到距離。
圖6所示為加速度、速度和距離之間的關(guān)系。利用加速度來估算距離必須使用到雙重積分，而每一次的積分會(huì)把雜訊累加，因此錯(cuò)誤量的累積會(huì)非常的快速；所以，利用加速度的雙重積分來獲得距離的方式對(duì)PDR而言并不是一件可靠的方法。另一種方法是利用G-sensor做為計(jì)步器(Step Count)，因此并不須要利用到對(duì)G-sensor的資料進(jìn)行積分的使用模式。
圖6 在等加速度的模式之下加速度、速度和距離的關(guān)系
圖7所示為在步行模式之下，G-sensor在三軸的G值總輸出。從圖7中可以發(fā)現(xiàn)，每一個(gè)步伐都會(huì)在G-sensor的總輸出上面造成顯著的短期峰值，利用峰值檢測(cè)，即可計(jì)算步數(shù)。
圖7 利用G-sensor的總輸出來偵測(cè)步數(shù)
峰值的檢測(cè)主要系利用G-sensor的輸出，在一個(gè)短周期內(nèi)快速的增加和降低至原來的值。為了避免錯(cuò)誤的偵測(cè)，我們可以在峰值檢測(cè)加上一個(gè)臨界值，每個(gè)被認(rèn)定的峰值必須要超過預(yù)先定義的臨界值，才能夠被判定為一個(gè)真正的峰值。
另外，每一個(gè)步伐可能會(huì)產(chǎn)生多個(gè)峰值造成步數(shù)的誤判，我們可以在時(shí)域上面加上一個(gè)時(shí)間周期的緩沖來確保每一個(gè)峰值的時(shí)間間距必須超過預(yù)先定義的時(shí)間。峰值的臨界值和時(shí)間的緩沖周期，皆可以利用大量的測(cè)試來定義一個(gè)合理值。
距離的推算就是將步數(shù)乘上預(yù)先定義的步伐大小，因此預(yù)先定義的步伐參數(shù)必須是一個(gè)合理值，否則整個(gè)距離的推算誤差會(huì)相當(dāng)?shù)拇蟆２椒サ拈L(zhǎng)度也可以利用G-sensor在較短的區(qū)間內(nèi)的雙重積分所得到的距離，除上步數(shù)即可求得步伐的長(zhǎng)度。
簡(jiǎn)單來說，利用G-sensor輸出的雙重積分所得到的距離來動(dòng)態(tài)的校正步伐的長(zhǎng)度，并結(jié)合G-sensor的計(jì)步功能就可以實(shí)現(xiàn)較為準(zhǔn)確的累積距離，提供給PDR使用。
此外，步數(shù)的峰值檢測(cè)還可以用來做為運(yùn)動(dòng)的偵測(cè)，當(dāng)偵測(cè)的步數(shù)為零時(shí)，就表示用戶是在靜止的狀態(tài)，因此PE就可以將位置持續(xù)的鎖住在前一筆有效的位置上面，直到運(yùn)動(dòng)偵測(cè)狀態(tài)變回非靜態(tài)。
改善覆蓋率和精準(zhǔn)度 WLAN/INS緊密結(jié)合有譜
GNSS/INS的緊密結(jié)合在汽車導(dǎo)航上的貢獻(xiàn)，即是提供比傳統(tǒng)全球衛(wèi)星定位系統(tǒng)(GPS)接收機(jī)更佳的精確度和可靠度，特別是在航位角的改善，可以大幅度的降低后級(jí)的地圖匹配的錯(cuò)誤率，較低的地圖匹配錯(cuò)誤率意味著較低的誤導(dǎo)航錯(cuò)誤預(yù)警(False Alarm)頻率。
GNSS/INS在室內(nèi)導(dǎo)航的應(yīng)用最主要的貢獻(xiàn)即為PDR，PDR串起室外GNSS為主的定位和室內(nèi)無線區(qū)域網(wǎng)路(WLAN)為主的定位技術(shù)。PDR可以提供無縫接軌的室內(nèi)和戶外導(dǎo)航。此外，若把GNSS接收機(jī)當(dāng)成一個(gè)位置感測(cè)器，則GNSS的角色其實(shí)是可以被其他的位置感測(cè)器所取代，如WLAN、行動(dòng)網(wǎng)路和社群網(wǎng)站。
非GNSS位置感測(cè)器的最大挑戰(zhàn)在于覆蓋率、準(zhǔn)確度、可重復(fù)性及可靠度。若這些問題皆能改善并提升至10公尺內(nèi)的準(zhǔn)確度，實(shí)際上GNSS/INS的緊密結(jié)合亦可以延伸到WLAN/INS或SLAP/SLAM/INS的緊密結(jié)合。圖6所示為結(jié)合WLAN和INS感測(cè)器，以實(shí)現(xiàn)緊密結(jié)合的WLAN/INS室內(nèi)定位。
圖6 利用WLAN和INS感測(cè)器的緊密結(jié)合來實(shí)現(xiàn)室內(nèi)定位
[!--empirenews.page--]
下載文檔
