企业官网建设流程全解析

RTKLIB这套开源的GNSS定位软件库，我前前后后翻源码翻了不下一整年，每次感觉自己懂了，转头又被某个短变量名打回原形。rtk.x到底存了什么，rtk.P为什么是一维数组，relpos()里那一长串udstate、udmeas、filter、fix_amb调用顺序到底在做什么——要是没把双差观测方程、卡尔曼滤波、整周模糊度固定这些理论和代码逐行对上，读RTKLIB源码基本等于猜谜。这篇笔记三里，我不打算罗列函数清单，而是沿着一条真实的数据流，把RTK定位从观测值进来、到固定解出去这条主线拆开讲清楚，顺手把我调试时踩过的坑也写出来。适合正在读RTKLIB源码、或者拿RTKLIB做二次开发的同行，尤其是卡在RTK解算流程和模糊度固定这部分的人。

1. 源码目录和数据结构：先把“仓库”认全

1.1 src下每个文件到底是干什么的

以2.4.3版本为例，打开RTKLIB的src目录会看到一堆.c和.h文件，初次看的人很容易懵。我建议不要从头到尾读，而是先建立一个“文件—功能”的映射表，知道要查什么的时候去哪个文件里找。

• rtklib.h：整个库的头文件，所有结构体、宏定义、函数声明都在这里。我把这个文件当“数据字典”用。
• rtkpos.c：RTK相对定位的核心，relpos()、udstate()、udmeas()、filter()、fix_amb()都在这里。读RTK流程，主要就是读这个文件。
• pntpos.c：单点定位（SPP）实现，RTK解算前拿它算初始位置。
• postpos.c：后处理主循环，负责逐历元读数据、调SPP和RTK、写结果文件。
• lambda.c：LAMBDA整周模糊度搜索算法的实现，代码量不大但数学味道很重。
• ephemeris.c：广播星历计算卫星位置、钟差。
• tropo.c、ionex.c：对流层、电离层模型。
• rtcm.c、rcv*.c、stream.c：RTCM协议、接收机格式、串口/TCP数据流。搞实时处理才需要细看。

1.2 先弄懂四个核心结构体

RTKLIB的注释风格偏“极简”，很多字段不追到具体业务场景根本不知道干嘛的。我读下来觉得最小必要集是这四个结构体。

• obsd_t：一条观测记录，里面的L[NFREQ]是载波相位（单位是周，不是米），P[NFREQ]是伪距（米），D[NFREQ]是多普勒。这个单位差异是很多人踩坑的起点。
• obs_t：一个历元的观测集合，里面是一个obsd_t数组和卫星/接收机数量。
• nav_t：导航电文和改正参数的总装，广播星历、精密星历、电离层参数、UTC参数都挂在它下面。
• rtk_t：RTK解算的“工作台”，流动站和基准站观测值、状态向量x、协方差阵P、解算结果sol、配置参数opt全都装在里面。

记得一个关键点：RTKLIB里大量函数不通过返回值传结果，而是直接修改rtk_t内部状态。所以读代码时盯住一个rtk变量怎么被一层层传进去、改掉，就基本抓住了主线的骨架。

2. 一条数据从文件到定位解的完整旅程

2.1 后处理主循环是怎么把历元喂给RTK的

后处理模式下，入口是rnx2rtkp程序，核心逻辑在postpos.c里。postpos()大致做这样几件事：打开观测文件、星历文件，逐历元调用readobs()读取双频观测值，调用sbserr()做卫星位置误差检查，然后先用pntpos()算一个单点定位结果，作为RTK解算的初始坐标。

很多人会忽略pntpos()这一步，但它很重要。RTK的扩展卡尔曼滤波需要初始状态和初始协方差，直接用(0,0,0)当初始坐标会让滤波收敛很慢，甚至发散。RTKLIB的做法就是先拿伪距做一遍最小二乘，把位置粗略定到米级，再喂给后面的RTK滤波。这一步对应到rnx2rtkp的输出，就是每行解的Q列偶尔会先出现一个5（单点解），然后才变成1（固定解）或2（浮点解）。

2.2 rtkpos：RTK解算总入口

rtkpos()是相对定位的总入口，它的骨架逻辑大概是：先检查观测数据和星历是否有效，然后根据配置选择不同定位模式。我们最关心的relpos()就是在rtkpos()里被调用的。

relpos()的核心步骤如下：

1. 对流动站和基准站的观测数据做共视卫星匹配，按高度角排序。
2. 调用udstate()，完成状态转移（时间更新）：预测当前历元的位置、钟差、模糊度。
3. 调用udmeas()，基于双差观测值构建量测方程，得到设计矩阵H、残差向量v、观测噪声阵R。
4. 调用filter()，执行卡尔曼滤波的量测更新，得到浮点解。
5. 调用fix_amb()，尝试固定整周模糊度。如果固定成功，将整数约束回代得到固定解。

代码里各个阶段都有trace()调用，打开RTKLIB的debug trace后，这些中间矩阵都会输出到日志文件，是排查问题的利器。

2.3 从双差理论到源码函数的映射

RTK能实现厘米级定位，核心思想是利用双差观测值把绝大部分误差消掉。我画了一条从理论到代码的对应关系：

我读relpos()读了三遍才彻底看明白，原因是它的数据流是“状态向量驱动”的：所有观测方程都是围绕着rtk->x和rtk->P在转，而不是围绕一个显式的“观测模型”对象在转。所以读代码时一定要时刻问自己：当前这步操作，是在更新状态向量的哪一段？设计矩阵H的哪一列对应模糊度？

3. 卡尔曼滤波在源码里到底怎么写

3.1 状态向量里装了什么

RTKLIB的rtk->x是一个double数组，长度是rtk->nx。它里面大致包含三块：位置/速度（3到9个状态，看动态模型）、接收机钟差（每个系统一个）、单差/双差模糊度参数（数量随共视卫星数变化）。

模糊度参数是最容易绕晕的部分。RTKLIB在内部用一套“单差模糊度”的排列方式管理，但观测方程构建的是双差组合。这个映射通过ddidx()完成，它做的事情就是把“第i颗卫星和第j颗卫星之间的双差模糊度”换算成状态向量的下标。你可以把它理解成一个查表函数：给它两颗卫星，它告诉你模糊度参数存在rtk->x的第几个位置。

3.2 filter函数和教科书公式怎么对上

filter()函数在rtkpos.c里，虽然只有几十行，但它是整个RTK解算的引擎。它的输入是状态向量x、协方差阵P、设计矩阵H、残差v、观测噪声阵R，输出是更新后的x和P。内部实现的就是教科书上的标准卡尔曼量测更新：

增益矩阵K = P·H^T·(H·P·H^T + R)^(-1)，然后状态更新x = x + K·v，协方差更新P = (I - K·H)·P。

这里有个特别实用的细节：P是一维数组，按列优先存储。取第k个状态的方差就是P[k + k*nx]。很多人在源码里看到一个P[i + j*nx]就懵，其实是列优先矩阵的经典写法。

有次我为了看某个模糊度参数有没有收敛，直接在filter()后面加了一行打印，把rtk->P[0 + 0*nx]、rtk->P[1 + 1*nx]等几个对角线元素打出来。位置方差降下来，说明滤波在收敛；如果伴随模糊度方差一直不降，就要怀疑是不是观测几何太差。

3.3 过程噪声和初始方差：参数背后的物理意义

卡尔曼滤波一半靠模型，一半靠调参。RTKLIB里过程噪声和初始协方差并不是随手拍的，它们对应着你对载体运动的假设。

• 静态模式：位置状态转移是常值，过程噪声取得非常小，模糊度参数在连续历元间基本按常数走。
• 运动学模式：位置状态转移加入了速度甚至加速度，过程噪声给得大，允许位置快速变化。

有段时间我在跑车载动态数据，固定率一直上不去，最后发现是opt里的动态模型选错了。RTKLIB的默认配置偏保守，如果载体运动速度变化大，位置过程噪声给太小，滤波会“跟不上”真实轨迹，模糊度自然固定不住。改大过程噪声后，浮点解收敛明显加快。

4. 整周模糊度固定：源码比公式更亲切

4.1 浮点解为什么会带小数

卡尔曼滤波解出来的模糊度是小数，因为观测噪声、大气残差、多路径都会污染它。浮点解的定位精度大概在分米级，要拿到厘米级必须把模糊度约束成整数。固定模糊度本质上是给滤波加了一个“整数约束”，一旦约束正确，位置解就从一个宽解空间被压到一个窄解空间。

4.2 LAMBDA在lambda.c里做了什么

lambda.c里的lambda()函数是RTKLIB模糊度固定的数学内核，它做三件事：对模糊度协方差阵做LDL分解，通过Z变换降相关，然后在降相关空间里搜索整数候选。降相关这一步是LAMBDA的精髓，它能把原本椭圆形的搜索空间掰成接近球形，搜索速度快到工程可用。

我不建议一上来就死磕lambda.c里的矩阵运算，可以先跑通整个流程，再回头配着论文读。真正影响固定效果的不只是搜索算法本身，而是喂给LAMBDA的浮点模糊度协方差阵Q是不是合理。浮点解质量差时，LAMBDA再快也搜不出正确整数。

4.3 固定解怎么“回代”到滤波器里

fix_amb()做的事情很有意思：它先从浮点解的rtk->x和rtk->P里把模糊度对应的子矩阵抠出来，送给lambda()搜出整数解，然后做ratio检验判断是否接受固定解。如果接受了，它不会直接把浮点解里的模糊度替换成整数，而是把整数模糊度当成一组虚拟观测值，重新做一次滤波更新，得到最终的固定解。这样处理比较严谨，相当于让位置解在“模糊度已知”的条件下重新估计一遍。

RTKLIB还区分两种固定策略：普通AR和“fix-and-hold”。后者会把固定结果作为先验约束保持到后续历元，避免每一历元都重新搜索，适合静态或慢速场景。实时监测这类场景用fix-and-hold效果立竿见影，但如果载体动态太强，硬保持反而可能锁错模糊度。

4.4 怎么判断这次解算到底固没固定

RTKLIB里判断解类型不能只看定位坐标，要看你关注的那个状态量。输出文件里的Q列，1是固定解，2是浮点解，5是单点解。实时程序里可以检查rtk->sol.stat，SOLQ_FIX就是固定状态。

有次我发现某条基线固定率特别低，一开始怀疑是LAMBDA参数问题，后来把浮点解和固定解轨迹放在一起画，发现浮点解本身就在一条平滑轨迹上，只是模糊度的小数部分始终不收敛。最后定位到问题是基准站坐标给了个大概值，导致双差残差里始终挂着一个系统性偏差。把基准站坐标换成精确值后，固定率立刻从20%跳到了90%。所以排查固定率问题时，先怀疑浮点解质量，再怀疑LAMBDA。

5. 把源码跑起来：调试技巧与避坑指南

5.1 用自带demo数据验证整条链路

RTKLIB安装包里自带demo观测文件和星历文件，我用它们把全流程跑通后，心里才真正有了底。编译完rnx2rtkp后，最简单的用法是在RTKPOST图形界面里加载demo数据，设好后处理配置点执行；命令行方式可以直接看usage()输出，不同版本参数略有差异，建议先看帮助再跑。

第一次跑通后，我习惯把输出文件里的Q列统计一下，看看固定解占比。如果demo数据都跑不出高固定率，说明环境或配置有问题，这时候先别急着改源码，优先检查星历文件、观测文件路径和定位模式是不是选对了。

5.2 在relpos里加打印看内部状态

我强烈建议在relpos()的filter()调用之后加一段临时打印，把位置状态和方差打出来，这是理解整条链路的捷径：

/* 临时调试代码：打印前三维位置和方差 */ if (rtk->sol.stat == SOLQ_FIX || rtk->sol.stat == SOLQ_FLOAT) { fprintf(stderr, "x=%.6f %.6f %.6f\n", rtk->x[0], rtk->x[1], rtk->x[2]); fprintf(stderr, "Pvar=%.6f %.6f %.6f\n", rtk->P[0 + 0*rtk->nx], rtk->P[1 + 1*rtk->nx], rtk->P[2 + 2*rtk->nx]); }

注意rtk->nx是当前状态维数，模糊度数量变化时它也在变。P的索引方式前面说过，是列优先一维数组。这个打印在实时程序里会严重影响性能，调试完一定要删掉或放到trace日志里。

5.3 常见问题速查表：我踩过的坑

5.4 给正在啃RTKLIB源码的人几句掏心窝的话

读RTKLIB源码最忌讳按文件顺序从头读到尾，那样大概率在lambdamat和smoother那儿就被劝退了。我用下来的方法是：先跑通demo、拿到一个固定解结果，再在relpos()里加打印、改参数，最后才去对着论文抠lambda.c的数学细节。源码里那些短变量名，读多了会发现其实很有规律，i、j是卫星索引，m是当前历元观测数，nx是状态维数，opt是配置结构体。真正难的不是语法，而是每个矩阵的“物理含义”。

我调模糊度固定卡得最久的一次，问题不在算法也不在参数，而是我拿错了星历文件版本。自那以后我每次做后处理都会先检查星历时间范围和观测文件是否匹配，再谈其他。RTKLIB这块代码很值得啃，啃完它对整个GNSS精密定位的理解都会上一个台阶。