本文记录rtklib-java（RTKLIB 2.5.0 demo5分支的Java移植与增强项目）在双基线联合RTK开发过程中的一次典型踩坑：两个单基线独立解算FIX率均稳定在91.5%，但合并为共享Kalman滤波的联合解后FIX率直接掉到0%。通过三层递进定位根因完成修复，并配套落地了窗口历元聚合工具SolAggregator，附上真实1小时北斗短基线数据的实测结果。
1 项目背景与测试环境
rtklib-java是基于RTKLIB 2.5.0 demo5分支的全功能Java移植实现，采用多模块Maven工程结构：
-
rtklib-core：核心定位算法（SPP/RTK/PPP），保留原有解算逻辑
-
rtklib-adjust：多基线间接平差（结果空间融合，各基线独立解算后做WLS平差）
-
rtklib-joint：多基线联合RTK（观测空间融合，共享Kalman滤波器全局位置状态）
2 反直觉故障：单基线正常，联合直接FIX=0%
开发联调阶段出现了一个非常反直觉的现象：单独跑任意一条基线，解算FIX率稳定在91.5%；一旦把两条基线接入共享位置的联合Kalman滤波器，所有历元全部停留在FLOAT状态，FIX率为0%。
暂时无法在飞书文档外展示此内容
通过逐历元回算状态、对照原C版本RTKLIB的Java移植逻辑，逐层定位到三个递进的根因：
2.1 P4：Kalman更新阶段跨基线状态污染
问题机制 ：移植版KalmanFilter.update在选择参与更新的状态分量时，只判断了状态方差P[i*i]>0且状态值非零，没有检查观测矩阵H中对应列是否全零。bl=1（第二条基线）执行更新时，bl=0的模糊度列H全零，但仍被错误选中参与状态更新，通过交叉协方差把bl=1的新息直接泄漏到两条基线共享的位置状态上。
实测现象：epoch=0时刻，共享位置分量y从+39.83m直接跳变到-31.48m，位置状态直接发散。
修复方式 ：状态选择逻辑增加H列非零校验，仅当Math.abs(H[j*nx+i]) > 0时才纳入更新集合。
// 旧逻辑：仅检查状态方差非零 for (int i = 0; i < nx; i++) { if (x[i] != 0 && P[i*nx+i] > 0) { /* 纳入更新 */ } } // 新逻辑：增加H列非零校验 for (int i = 0; i < nx; i++) { boolean hNonZero = false; for (int j = 0; j < n; j++) { if (Math.abs(H[j*nx+i]) > 1e-12) { hNonZero = true; break; } } if (x[i] != 0 && P[i*nx+i] > 0 && hNonZero) { /* 纳入更新 */ } }
2.2 P5：holdamb触发的minfix门槛过高
问题机制 ：原移植逻辑中需要连续FIX次数达到minfix=20才触发模糊度holdamb保持。epoch=20时刻首次解算FIX（ratio=51/77远高于阈值），但因为没达到连续20次FIX的门槛，模糊度方差没有被压缩；从epoch=21开始，ratio直接骤降到~1，永远无法达到连续FIX的触发条件，形成死循环。
修复方式：去掉连续FIX次数的门槛，每次LAMBDA模糊度固定成功后立即触发holdamb，压缩对应模糊度分量的方差。
2.3 P6（核心根因）：FIX后模糊度协方差完全未修正
问题机制 ：这是导致FIX率直接归零的核心bug。LAMBDA模糊度固定成功后，原移植逻辑只修正了位置部分的状态和协方差（按Schur补更新xa[0:na]、Pa[0:na,0:na]），模糊度分量xa[na:nx]只是硬写回固定后的整周值，但协方差矩阵P中对应的模糊度行/列完全没有做修正。
这就造成状态值x和协方差P完全不匹配：模糊度值已经被固定为整数，但协方差还是FLOAT阶段的大方差，后续历元更新时模糊度会继续自由漂移，ratio永远无法稳定通过阈值。
修复方式：FIX写回P之前，手动将所有模糊度分量（i≥na）的协方差对角元设为1E-6，模糊度与位置之间的交叉协方差全部清零。
// LAMBDA固定成功后：位置部分按Schur补正常更新 // ... 原有位置协方差更新逻辑 ... // 核心补充：模糊度部分协方差强制压缩 for (int i = na; i < nx; i++) { Pa[i*nx + i] = 1e-6; // 模糊度方差压到极小，代表已固定 for (int j = 0; j < nx; j++) { if (i != j) { Pa[i*nx + j] = 0.0; // 交叉协方差清零 Pa[j*nx + i] = 0.0; } } }
最终修复结果：双基线联合解FIX率恢复到216/236=91.5%，和单基线独立解算结果完全一致。
3 架构权衡：观测层联合 vs 结果层平差
在完成故障修复后，我们对两种多基站融合方案做了系统对比，两者并非替代关系，而是互补使用：
| 对比维度 | rtklib-joint（观测层联合） | rtklib-adjust（结果层平差） |
|---|---|---|
| 融合层级 | 共享Kalman滤波器，位置状态全局共享，模糊度分基线独立 | 各基线独立完成RTK解算，拿到独立FIX结果后做WLS间接平差 |
| 精度表现 | FIX后理论精度≈σ₀/√N；FLOAT阶段收敛更快，整体FIX率更高 | FIX后精度≈σ₀/√N（WLS最优，无信息损失）；收敛速度略慢 |
| 可靠性 | 无故障隔离机制，单条坏基线的误差会直接污染共享位置状态 | 支持基线交叉验证、Baarda数据探测、保护级计算，坏基线可单独剔除 |
| 协方差 建模 | 自然建模跨基线位置相关性 | 默认块对角协方差，使用各基线原始输出的Sol.qr矩阵 |
| 适用场景 | 开阔环境、短基线、观测数据均匀的静态监测场景 | 城市峡谷、遮挡严重、多路径影响大的复杂场景 |
关键洞察：观测层联合滤波的隐含假设是"各基线观测误差为零均值随机噪声"，但在遮挡、多路径场景下误差是系统性的，这个假设直接破产。差环境下joint模式存在5种典型失效模式：共享位置=共享故障、交叉协方差污染扩散、全局参考星脆弱、周跳源难定位、ratio被好基线稀释。
最终结论：joint模式用来提精度，adjust模式用来保可靠性，两者互补而非替代。
4 配套工具：SolAggregator 历元聚合实测
多基线解算跑通后，我们新增了独立的历元聚合工具SolAggregator，输入为窗口内的List<SolData>，不修改原有solstatic选点逻辑，也不侵入RTK滤波器内部，纯外部后处理实现窗口级位置融合。
工具内置两种聚合模式：
-
ROBUST 模式：IGG3抗差降权+加权平均+经验协方差，适合静态场景压噪声、抗假固定
-
KALMAN_SMOOTH模式：常速度Kalman前向滤波+RTS反向平滑，适合跟踪窗口内缓慢位移
在同一份1小时实测数据上（原始FIX序列散布std=(0.636,1.560,0.742)mm），两种模式不同窗口长度的实测结果：
| 窗口长度 | ROBUST模式窗口间std(E,N,U) | KALMAN_SMOOTH模式窗口间std(E,N,U) |
|---|---|---|
| 5min | (0.569, 1.571, 0.730) mm | (0.464, 1.610, 0.768) mm |
| 15min | (0.319, 1.599, 0.729) mm | (0.568, 1.975, 0.854) mm |
两个关键实测发现：
-
ROBUST模式在15min窗口下，E方向散布相比原始序列降低50%，N/U方向基本持平，抗差效果符合预期；
-
KALMAN_SMOOTH模式在15min窗口下，N方向散布反而升高27%------这正好验证了设计阶段标注的"滤波之滤波"风险：把RTK滤波输出当伪观测再做一次Kalman平滑，容易出现过度平滑、把真实微小位移当成噪声抹掉的问题。
抗假固定测试：在序列中注入1个历元1m的位置偏移模拟假固定，ROBUST模式最终融合结果的偏移仅为0.076/0.675/0.292 mm，粗差被IGG3权重直接剔除，没有污染最终结果。
5 代码位置与后续规划
本次修复与新增功能的代码位置：
-
KalmanFilter.java：H列非零校验修复 -
JointCore.java：holdamb去minfix门槛、FIX后模糊度协方差压缩 -
rtklib-core/.../aggregate/：SolAggregator全套实现 -
docs/JOINT_VS_ADJUST_ANALYSIS.md：联合与平差方案对比分析 -
docs/SOL_AGGREGATOR_DESIGN.md：聚合工具设计文档
后续迭代计划：补充FLOAT历元可选参与融合开关、常加速度运动模型、经验单位权方差缩放协方差等能力，所有功能均保持与RTKLIB原逻辑的数学等价性。