參考：http://network.chinabyte.com/376/12363876.shtml

1. 引言

位置資訊在人們的日常生活中扮演著重要的作用。在郊外、展覽館、公園等陌生環境中，使用定位導航資訊可為觀眾遊覽提供更便捷的服務；在倉儲物流過程中，對物品進行實時定位跟蹤將大大提高工作效率；在監獄環境中，及時準確地掌握相關人員的位置資訊，有助於提高安全管理水平，簡化監獄管理工作。

目前全球定位系統（ GPS , GlobalPositioning System）是獲取室外環境位置資訊的最常用方式。近年來，隨著無線移動通訊技術的快速發展，GPS 和蜂窩網路相結合的A-GPS（Assisted Global Positioning System）定位方式在緊急救援和各種基於位置服務（LBS,Location-Based Services）中逐漸得到了應用。但由於衛星訊號容易受到各種障礙物遮擋，GPS/APGS 等衛星定位技術並不適用於室內或高樓林立的場合，目前無線室內定位技術迅速發展，已成為GPS 的有力補充。

一般來講，使用無線訊號強度獲取目標位置資訊的過程，就是建立無線訊號強度和位置資訊穩定對映關係的過程。現有室內無線定位系統主要採用紅外、超聲波、藍芽、WiFi（Wireless Fidelity）、RFID（Radio FrequencyIdentification）等短距離無線技術。其中基於WiFi 網路的無線定位技術由於部署廣泛且低成本較低，因此備受關注。其中由微軟開發的RADAR 系統是最早的基於WiFi 網路的定位系統。它採用射頻指紋匹配方法，從指紋庫中查詢最接近的K 個鄰居，取它們座標的平均作為座標估計。而文獻[5]介紹的室內定位系統則基於RSSI 訊號的統計特性，採用貝葉斯公式，通過計算目標位置的後驗概率分佈，來進行定位。

本文同樣基於WiFi 網路，設計和實現了一種無線室內定位系統，但與上述定位方法不同，本文采用了基於權值選擇的定位演算法，在一定程度上減少了RSS.訊號隨機變化引起的定位誤差，實驗結果表明，該系統可獲得較好的定位精度（4 米）。

2. 系統設計

本系統可為移動終端客戶在展館、商場、校園等應用場景提供定位服務。鑑於移動終端受到計算能力、儲存容量和電池電量等諸多限制，所以僅完成簡單的訊號採集工作，定位計算由定位服務端完成。

定位系統的架構體系如圖1 所示。服務端主要負責定位計算和響應終端的定位請求。基於負載均衡考慮，響應位置請求的Web 伺服器和執行定位計算的定位伺服器分離，資料交換方式採用客戶端和Web 伺服器相同的資料交換方式。客戶端依附於具體物件，主要負責採集周邊AP 的無線訊號強度，並向服務端提交訊號特徵，伺服器使用客戶端採集的訊號特徵進行定位計算，獲得移動終端的位置估計。

客戶端和服務端通訊採用標準的HTTP協議，程式設計方便，可擴充套件性好，客戶端程式功能可根據需要進行擴充。

圖1 定位系統網路結構

圖2 為本定位系統的資訊互動流程圖。移動終端向Web 伺服器提交GET 請求，GET 請求中包含了訊號強度特徵向量，Web 伺服器收到請求後，以同樣的方式傳達給定位伺服器，定位伺服器查詢資料庫，並進行相關的定位運算操作，從而得到移動終端的位置估計。

圖2 移動終端與伺服器間的資訊互動3. 系統實現

3.1. 客戶端設計

本系統客戶端採用Android 系統手機。

Android 系統是Google 在2007 年釋出的基於Linux 平臺的開源手機作業系統。近年來，基於此平臺的手機市場佔有率不斷提高，加上其良好的開放性和豐富的API 介面，可以很方便地開發各種應用程式。

3.1.1. Android 系統架構簡介

Android 系統架構見圖3,它建立於Linux核心之上，包含了各種裝置驅動和管理模組，囊括了非常齊全的類庫和框架，包括輕量級資料庫SQLite、瀏覽器Webkit 等。整個系統建立在Dalvik 虛擬機器上，應用程式使用Java 語言編寫。Android 系統提供了豐富的框架（活動管理、位置管理等）來管理系統的軟、硬體資源，整合了常用的應用程式（聯絡人、電話本等），並開放了很全面的API 供使用者使用，整個平臺具有良好的開放性和擴充套件性。

圖3 Android 系統架構圖

3.1.2. Activity 生命週期

Android 系統上執行的應用程式一般包含一個或多個Activity,主要由活動管理器進行管理，Activity 是Android 系統分配和管理資源的基本單位。每個Activity 都有其對應的生命週期（圖4）。

圖4 Activity 生命週期

onCreate（）方法在活動開始時呼叫，並依次呼叫onStart（）方法和onResume（）方法，Activity 處於執行狀態，如有新活動啟動，則呼叫onPause（），活動轉入後臺；如記憶體不足，活動程序則被關閉。退出程式則會依次呼叫onStop（）和onDestroy（）。

活動管理器對Activity 的管理體現在不同生命週期對以上幾個方法的呼叫上，使用者可根據自己的需要過載這幾個方法。一般來講，主程式類繼承Activity 類，使用者的功能程式碼在過載這些方法中實現。

3.1.3. 獲取周邊AP 訊號強度

本文采用基於射頻指紋的定位方法，移動終端需要獲得周圍AP 的RSSI 指紋特徵，Android 系統提供的介面可以很方便地實現這一功能。

參見圖5 示例程式碼片段。首先建立包含響應掃描結果的接收器（reciever） 並重載onReceive（）方法，此方法即為收到WiFi 訊號的回撥函式，使用者自定義功能在此實現；再通過registerReceiver（）方法將receiver 向Android 系統進行註冊，getSystemService（）方法用於獲得操作WiFi 裝置的控制代碼；最後用startScan（）方法啟動掃描，當獲得掃描結果後，系統會觸發註冊的回撥函式，完成使用者程式碼功能。

圖5 掃描示例程式碼

實驗結果表明，從給出掃描指令，至接收到掃描結果，耗時約400-500ms,考慮到後臺伺服器演算法運算及網路通訊開銷，定位過程耗時將超過500ms.  

3.1.4. 程式流程

從程式的功能來看，客戶端需完成3 個功能：定期掃描並獲得周圍AP 的訊號強度指紋特徵，向伺服器提交指紋特徵資訊，得到定位結果後更新介面顯示。程式流程如圖6 所示。

首先程式初始化並建立更新回撥函式，獲得WiFi 服務控制代碼後註冊此回撥函式，最後啟動掃描程序週期掃描，直至系統結束程式。

其中，回撥函式首先獲取掃描結果，並格式化為字串，然後通過GET 請求提交給服務端，獲得定位結果後再更新顯示介面。

圖6 程式流程圖

3.1.5. 獲取周邊AP 訊號強度

本文采用基於射頻指紋的定位方法，移動終端需要獲得周圍AP 的RSSI 指紋特徵，Android 系統提供的介面可以很方便地實現這一功能。

參見圖5 示例程式碼片段。首先建立包含響應掃描結果的接收器（reciever） 並重載onReceive（）方法，此方法即為收到WiFi 訊號的回撥函式，使用者自定義功能在此實現；再通過registerReceiver（）方法將receiver 向Android 系統進行註冊，getSystemService（）方法用於獲得操作WiFi 裝置的控制代碼；最後用startScan（）方法啟動掃描，當獲得掃描結果後，系統會觸發註冊的回撥函式，完成使用者程式碼功能。

圖5 掃描示例程式碼

實驗結果表明，從給出掃描指令，至接收到掃描結果，耗時約400-500ms,考慮到後臺伺服器演算法運算及網路通訊開銷，定位過程耗時將超過500ms.

3.1.6. 程式流程

從程式的功能來看，客戶端需完成3 個功能：定期掃描並獲得周圍AP 的訊號強度指紋特徵，向伺服器提交指紋特徵資訊，得到定位結果後更新介面顯示。程式流程如圖6 所示。

首先程式初始化並建立更新回撥函式，獲得WiFi 服務控制代碼後註冊此回撥函式，最後啟動掃描程序週期掃描，直至系統結束程式。

其中，回撥函式首先獲取掃描結果，並格式化為字串，然後通過GET 請求提交給服務端，獲得定位結果後再更新顯示介面。

圖6 程式流程圖

3.2. 服務端軟體設計

3.2.1. Web 伺服器

Web 伺服器用於對外通訊，接收外界的請求，並返回相應的位置資訊。

Web 伺服器執行Apache Tomcat 6.0.20,響應網路的定位請求，相應的軟體設定引數為：在%TOMCAT_HOME%\webapps 目錄下建立目錄：\ExServlet\WEB-INF,建立web.xml描述檔案和classes 資料夾，web.xml 檔案是描述檔案，classes 存放後臺處理的類檔案。

web.xml 中定義了外部引用此服務的名字和對應的類檔案，內容片段見圖7。

圖7 web 伺服器web.xml 程式碼片段

3.2.2. 定位伺服器

定位伺服器用於執行演算法，硬體配置引數為，CPU:Intel Core2 Duo E7500 2.93GHz,記憶體：2G,網絡卡：Marvell Yukon 88E8057 PCI-EGigabit Ethernet Controller.軟體配置引數為，作業系統：Windows XP Professional SP3,Web伺服器：Apache Tomcat 6.0.20.相應的軟體配置引數與web 伺服器類似，web.xml 中程式碼片段見圖8.

圖8 定位伺服器web.xml 程式碼片段

3.3. 3客戶端與服務端通訊

客戶端與服務端都接入Internet,通過標準的HTTP 協議通訊，簡化設計的同時，也為以後Web 方式的應用留下了設計空間。

服務端Servlet 用於響應客戶端的請求，客戶端只需在GET 請求中提交指紋資訊即可獲得定位結果。圖9 列出了客戶端從定位伺服器中獲取位置資訊的Java 示例程式碼。其中url包含了伺服器的IP 地址和RSSI 指紋資訊，getConnection（）方法是向伺服器發出GET 請求，伺服器將返回位置資訊，獲得輸入流後讀出位置資訊，並更新介面顯示即完成整個通訊過程。由於使用HTTP 協議，實現方法簡單，適用於多種程式語言。

圖9 客戶端獲取位置資訊的通訊示例程式碼

4. 定位演算法

由於室內環境複雜，WiFi 無線訊號具有較強的時變特性圖10.無線訊號傳播衰減模型難以很好的表徵距離與訊號強度間的對映關係，本文采用基於射頻指紋匹配定位方法，它具有較好的定位魯棒性。

圖10 訊號強度的時變特性

指紋匹配方式定位演算法建立在實驗資料基礎上，它主要包括離線訓練和線上定位兩個階段，其中離線訓練階段的任務是建立射頻訊號強度向量和客戶端位置間的一一對應關係，形成一個指紋庫（radio map），定位階段則使用實時採集的訊號強度向量去匹配訓練階段構建的指紋庫，從而獲得目標的位置估計。

現有的基於射頻指紋匹配定位方法主要包括確定型和概率型兩種。其中確定型定位演算法一般在指紋庫中選擇與實時採集的射頻指紋距離最小的幾個點的質心作為目標的位置估計。確定型定位演算法的計算效率較高，但精度較低。概率型定位演算法一般採用貝葉斯估計理論，通過不同的似然函式，如基於核函式的似然函式，計算目標位置的後驗概率，並取後驗概率最大的位置點作為目標的最終位置估計。概率型定位演算法具有較高的定位精度和定位魯棒性，但計算量相對較大。

本文采用快速選擇的定位演算法，訓練階段指紋特徵採用RSSI 均值，定位階段採用逐次累加的RSSI 均值與指紋庫匹配的方法，從而大大降低了運算的複雜度。

4.1. 演算法描述

指紋特徵採用每個AP 的RSSI 均值，即：

也就是，訓練階段對同一位置點採集的每個AP 的多次資料取平均，定位階段也是如此，區別在於訓練階段採集資料多，以便得到儘量多的資訊，定位階段採集的資料少，減少定位延時，一定程度上提高了實時性。

指紋匹配採用快速選擇的方式。偽碼如下：

對每個掃描到的AP 的RSSI 值，設定一個選擇區間[RSSI-Σ，RSSI+Σ],Σ為多次實驗的經驗值，在指紋庫中查詢滿足此區間範圍的位置點，若有n 個位置點落在此區間範圍，則這些位置點分別取權值為1/n,其他的位置點則取權值為0;對所有AP 做如上處理後，選出權值最大的位置點為估計位置。如有多個位置點權值一樣，則比較訊號強度距離，取最小者。

4.2. 演算法分析

本文的演算法是建立在RSSI 統計特性相對穩定的基礎上，從圖11 中可以看出，RSSI 值的直方圖分佈與正態分佈曲線近似，因此均值在一定程度上代表了RSSI 特徵。這也避免了單次掃描的訊號強度中某個AP 的RSSI 不穩定造成的定位結果偏差。

圖11 RSSI 的統計特性

時間複雜度分析：一次掃描有m 個AP,前期訓練階段有n 個位置點，則要進行m 次選擇，每次選擇遍歷n 個位置點，時間複雜度為O（m*n），遇到權值一致的情況，要進行二次選擇，最壞情況再比較n 次，時間複雜度為O（n），所以總的時間複雜度為O（m*n）。

5. 實驗

5.1. 實驗過程

實驗在計算所6 層進行，見圖12,在南北兩側走廊總共採集了24 個位置點，距離約4米，加上在645 房間，總共25 個位置點的資料。掃描週期1s,掃描次數120 次。採集資料耗時約1 小時。

圖12 實驗環境

本實驗主要為驗證定位準確性，所以定位時採用多次掃描的均值作為訊號特徵。共選取了6 個位置點作為實驗的位置點。測試次數約為50 次，掃描週期為2s,執行介面見圖13.

圖13 手機終端顯示

5.2. 實驗結果

各實驗位置點的結果見圖14.各個隨機測試位置點的定位準確率都較高。

圖14 各實驗位置點定位結果

6. 總結

本文基於Android 智慧手機平臺，設計並實現了一種基於WiFi 訊號的移動終端定位系統，並提出了一種基於權值選擇的定位演算法，一定程度上克服RSSI 訊號隨機擾動帶來的定位誤差，經過實際環境的測試，多次定位實驗的精度在4 米左右，適當調整AP 的佈置可以進一步定位精度。本系統可方便地部署到展館、校園等實際場景中。