基于ARM/Linux的嵌入式衛星定位平臺設計及實現

陳建華，潘樹國，才宇彤，任立冰

(1.南京郵電大學自動化學院，江蘇 南京 210046;2.東南大學儀器科學與工程學院，江蘇 南京 210096;3.中國移動通信集團福建有限公司福州分公司，福建 福州 350000;4.中國聯合網絡通信有限公司樺甸分公司，吉林 樺甸 132416)

0 引言

隨著電子技術的發展及高性能嵌入式芯片的出現，使傳統的基于硬件的GPS接收機導航解算軟件化成為可能［1］。而嵌入式設備的廣泛采用，也促使嵌入式導航軟件的產生。本文GPS導航解算對跟蹤環路輸出的導航數據進行電文解碼和數據處理，對大于等于4顆衛星的情況使用接收機位置信息，并在ARM嵌入式Linux平臺上實現。

1 導航解算算法設計

GPS接收機對GPS信號的基帶信號處理后，后續的工作即對導航數據的解碼，以得到用戶的準確位置信息。導航數據處理包括導航電文解碼和定位解算。導航解算對跟蹤環路輸出的導航數據進行解調和數據處理，得到星歷等信息。在跟蹤環路提供準確的碼起始點基礎上，配合星歷，求得衛星的位置坐標和偽距值，最后計算得到最終的接收機位置等信息。

1.1 前同步位的檢測

導航數據位的檢測是導航解算定位的前提，獲得正確的導航數據的傳輸開始時間是正確解碼的首要工作。導航數據的比特率為50 bit/s，即20 ms傳輸1個導航數據位。理論上只要找到任意一個導航數據的起始位置，每隔20 ms即可確定所有導航數據的傳輸結果。

導航解碼中的首要問題是找到導航電文中子幀的起始位置。該位置由格式為10001011的8 bit長的前同步位校驗位。由于跟蹤環路使用的是對相位不敏感的Costas環，導航數據中的前同步位會以01110100反轉的形式出現。相位反轉的前同步位會出現在接收數據的任何位置，因此必須執行前同步位的額外檢查。對子幀起始位置的前同步位的檢測時間間隔以1個子幀的時間長度6 s為單位檢測。

導航電文子幀起始位置的檢測是由前同步位與導航電文相關完成的。相關函數的第1個輸入參數是接收到的跟蹤環路得到的導航數據位通過過零檢測二值化為±1表示的比特序列，第2個參數即為以－1替代矩形序列的0值的8位前同步校驗位，相關函數的結果為8，前同步位反轉時，相關的輸出為－8。因此可以通過找到相關絕對值為8的位置，找到子幀的起始位置。

GPS導航數據1個主幀包含5個子幀，理論上，30 s的導航數據相關絕對值為8的結果有5個，相關最大值時間延遲為6 s，只要滿足奇偶校驗，即可確定子幀的起始位置。

由于多普勒效應的影響，導航數據位的長度可能偏離20 ms。即使小小的偏移經過長時間的積累，也會造成較大的誤差。因此通常采用基帶跟蹤環路輸出的原始的1000 bit/s的導航數據，與每位離散擴展為20位的校驗位相關，相關最大值也由8變為160。使用該方法，會增加前同步位校驗的計算開銷，但可以更加準確地確定比特轉換和導航數據電文中子幀起始位置。

1.2 接收機位置解算

我們知道，空間兩點確定一條直線，不在一直線上的三點確定一個平面，而要確定一個三維空間至少需要不在同一平面上的四點。因此，要確定一個空間位置的準確坐標，至少需要4顆衛星。在偽距和導航衛星位置坐標都知道的前提下，即可計算出接收機的位置坐標［2］。

理論上輸入衛星的位置和偽距，由式(1)可以求解出位置坐標，

式中:ρi為偽距;(xi，yi，zi)為衛星坐標，i=1，2，3，4;(xu，yu，zu)為接收機坐標;but為用戶時鐘誤差;c為光速。

式(1)為非線性聯立方程組，實際計算很難求解。通常解決的辦法是將各方程線性化。令距離表示的時鐘偏差bu=cbut，則方程微分為

式中:i=1 ～4;?xu，?yu，?zu和 ?bu為未知數，方程轉變為線性方程。矩陣表示為

變換為式(3)后，為了求得位置解，需要進行迭代。為得到我們需要的(xu，yu，zu)和bu，首先設置一組初值，得到新的?xu，?yu，?zu和?bu值后對(xu，yu，zu)和bu進行修正。重復操作，通過迭代直到 ?v=值小于預設的值，結束迭代。

1.3 多于4顆衛星的接收機位置求解

實際接收機捕獲到的衛星數量常常大于4顆。當多于4顆時，需要決定如何優選衛星的算法，一個行之有效的算法是使用最小二乘法［3］。

最小二乘法問題的數學描述為給出了一個無解的系統Ax=b，其中A有m行n列，m ＞n。觀測值b的維數大于變量x的維數。設x^為該系統的最優解，使誤差向量e^=b－A x^的模最小，則誤差向量的求解為‖e‖2=(b－Ax)T(b－Ax)，將求解的二次方程最小化得到常規方程

位置坐標求解方程數m ＞4顆衛星表示為

令 ?ρ= ［?ρ1?ρ2… ?ρm］T，?ρ= ［?xu?yu?zu?bu］T，A即為m行4列的α矩陣，則使用最小二乘法的最小化公式有

從方程(6)中即可求出?x的值，由于最小二乘法采用了更多的衛星數據，比僅使用4顆衛星的位置解更好。按照前面介紹的迭代方法，即可得到更為準確的接收機位置解。

2 實驗平臺組成及搭建

GPS導航解算軟件硬件平臺采用核心工作頻率為203 MHz的ARM9作為開發平臺，包含64M Nand Flash，64M SDRAM，12 MHz外部系統時鐘源，32.768 kHz的RTC時鐘源，以及URAT、USB、以太網等接口資源。嵌入式操作系統采用2.6.15版本的Linux Kernel，并通過自編譯移植。

2.1 嵌入式Linux系統平臺

嵌入式Linux開發平臺，宿主機交叉編譯環境采用3.4.3版本的GNU GCC，修改/etc/.bashrc文件，在文件末尾添加:

export PATH=$PATH:/編譯器目錄/3.4.3/bin

export PATH。

內核編譯配置，執行“make menuconfig”，選擇所需的系統組件和驅動進行，經編譯得到Linux內核壓縮映像文件。

采用支持ARM和MIPS體系架構的u-Boot作為BootLoader，完成操作系統內核運行之前硬件初始化、建立內存空間的映射圖等工作。

串口設置如圖1所示，采用了USB轉串口工具，串口設備類型為/dev/ttyUSB0，波特率設為115200，數據位8 bit，停止位1，無奇偶校驗。

圖1 minicom串口參數設置Fig.1 Serial port parameter settings

配置ARM9的u-Boot的開發板自身IP，Tftp服務器IP，內核啟動參數，Bootcmd啟動命令。在u-Boot的命令提示符下，使用setenv設置參數，saveenv保存參數。設置如下:

這里的ipaddr為開發板的IP地址，serverip為主機的IP，實際設置的IP地址只須保證在同一網段即可。Linux_ arg是 Linux內核的啟動參數，bootcmd是引導命令。

下載固化內核映像文件，連接開發板的串口、網口，在u-Boot提示符下輸入tftp 30008000 zImage，下載內核映像文件，執行固化內核命令nandw c 14000030008000。內存的起始塊號是c，8～b塊是存放環境變量的空間，然后使用boot命令啟動內核，內核移植完畢。

宿主機采用的Ubuntu需安裝NFS(網絡文件系統)服務程序。修改/etc/exports文件，在文件末尾添加:

/armsys2410/root*(rw，sync，no_root_squash)。

最后更新配置文件，重啟NFS服務即可開啟網絡文件服務。對開發板進行復位，重啟后開發板將執行硬件初始化最后直接連接到宿主機上建立的網絡文件系統。采用NFS方式操作過程都通過宿主機進行，可方便地對應用程序快速調試和測試。

2.2 嵌入式導航軟件設計

嵌入式Linux系統的搭建為嵌入式導航解算軟件提供系統平臺，完成嵌入式系統的搭建后，即為對嵌入式導航解算軟件的開發了。

嵌入式導航解算軟件開發使用了交叉編譯工具鏈，以及與之相關的開發工具。GPS導航解算軟件采用C/C++ANSI標準庫函數作為主開發庫，使用支持多平臺的功能函數庫輔助開發，保證跨平臺特性和軟件兼容性。

嵌入式導航解算軟件開發采用漸進設計方案，從算法仿真開始，PC平臺導航解算軟件的開發，至最后的嵌入式Linux平臺軟件的修改和移植的開發流程。并采用模塊化設計，方便軟件的修改和維護。根據GPS導航解算的各主要部分的功能劃分，軟件主要分為以下幾個功能模塊［4］:導航數據前同步位和奇偶校驗模塊;星歷解算模塊;衛星位置計算模塊;偽距計算模塊;用戶位置定位模塊;坐標經緯度轉換模塊。以上模塊共同組成了嵌入式導航解算軟件。嵌入式GPS導航解算程序的完整軟件流程圖如圖2所示。

圖2 衛星導航解算軟件流程Fig.2 Satellite navigation software flowchart

3 實驗結果分析

針對GPS接收機導航解算原理［5－6］，對導航解算進行算法仿真和結果測試。仿真測試使用采樣頻率為16.367667 MHz，信號帶寬為3 MHz，數字中頻為 4.123968 MHz，2 bit采樣的東方聯星NewStar210A中頻信號采樣器，對GPS真實信號采集。使用Matlab 2008a仿真平臺，PC平臺為1.73 GHz的酷睿T2250，1G內存。GPS中頻數據于空曠場地靜態采集，經基帶信號處理捕獲、跟蹤得到的導航數據如圖3所示。

圖3 衛星導航解算數據圖Fig.3 Satellite navigation data

衛星信號在30 s的時間內信號未失鎖，被準確跟蹤?？梢宰鳛閷Ш浇馑愕某跏紝Ш綌祿?，供衛星子幀的前同步位查找使用。

圖4以2號衛星為例，衛星可以找到至少5個相關峰，間隔6000個序列值 (即6 s的時間)出現的相關峰作為子幀起始位置，通過奇偶校驗即可確定每顆衛星子幀的起始位置。

圖4 衛星子幀前同步位查找圖Fig.4 Front synchronization bit searching of a satellite sub-frame

圖5以500 ms的時間間隔輸出一UTM經緯度坐標，在圖中以*表示，將經緯度坐標映射到平面上的點坐標分布，其中五角星表示33 s數據得到的經緯度的平均值。

GPS嵌入式導航解算程序首先在宿主機Linux平臺下使用GNU編譯工具，編譯測試，讀取跟蹤環路輸出的導航數據成功解算出用戶位置等相關信息。結果如圖6所示。

導航解算程序的嵌入式平臺移植，需針對嵌入式Linux平臺進行修改。嵌入式平臺資源有限，而導航解算要占用較多的內存資源，因此，需要優化內存占用。對程序進一步優化，提高其在嵌入式平臺下的處理速度。經過反復的測試，ARM9嵌入式Linux平臺最后的軟件運行結果如圖7所示。

圖7 ARM9/Linux平臺導航解算軟件運行結果Fig.7 Result of navigation software on ARM9/Linux

測試基于ARM的GPS軟件接收機的定位精度，將其與東南大學伽利略中心定位精度達毫米級的測量型接收機S6532A作比較。

在2008年7月21日下午4點至4點30分之間，將東方聯星NewStar210A中頻信號采樣器與S6532A接收機一起靜置于東南大學四牌樓東區足球場北角的地方，同時采集GPS衛星信號。東方聯星采集的數據解算得到的經緯度坐標為北緯32°3'14.9575″和東經 118°47'38.8164″;S6532A 接收機得到的接收機經緯度坐標為北緯32°3'14.9721″和東經118°47'38.7764″。

將得到的解算結果輸入Google Earth，兩點的平面位置坐標相差在5 m左右。導航解算仿真得到的單點定位結果，在無其他方式數據補償和未使用導航解算精度補償方法的情況下，與厘米級精度的雙頻S6532A接收機相比定位誤差在5 m左右，定位精度達到預期要求。

4 結語

本文通過理論分析和嵌入式平臺實現給出了嵌入式導航解算軟件的工程實現。首先從理論角度介紹了從基帶處理輸出信號中通過數據同步和查找導航數據起始位置，對多于4顆衛星使用最小二乘法求解接收機位置方法，經理論仿真算法符合設計要求。移植到ARM9嵌入式Linux平臺，實現了GPS導航解算軟件的嵌入式實現。

［1］羅顯志，楊滕，魏海濤，等.基于MATLAB的衛星導航信號仿真和驗證平臺［J］.系統仿真學報，2009，21(18):5692－5703.LUO Xian-zhi，YANG Teng，WEI Hai-tao，et al.Satellite navigation signal simulation and validation platform based on MATLAB software［J］.Journal of System Simulation，2009，21(18):5692 －5703.

［2］黃丁發，熊永良，袁林果.全球定位系統(GPS)—理論與應用［M］.成都:西南交通大學出版社，2006.207－208.HUANG Ding-fa， XIONG Yong-liang，YUAN Lin-guo.Global positioning system(GPS)—theory and practice［M］.Chengdu:Southwest Jiaotong University Press，2006.207－208.

［3］LEDVINA B M，PSIAKI M L，POWELL S P.A real time software receiver for the GPS and Galileo L1 signals［C］.ION GNSS 2006.Fort Worth:2006.2321 －2333.

［4］ENGEL F，HEISER G，MUMFORD P，et al.An open GNSS receiver platform architecture［C］.The 2004 International Symposium on GNSS/GPS.Sydney，Australia:2004.

［5］ZENG Qing-xi，WANG Qing，WANG Hao-wei，et al.Research and realization of key technology for software GPS receiver base on DSP［J］.Chinese Journal of Scientific Instrument，2009，30(6):1251 －1255.

［6］PSIAKI M L.Realtime-time generation of bit-wise parallel representations of over-sampled PRN codes［J］.IEEE Transactions on Wireless Communications，2006，5(3):487－491.