基于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.