RTK float drift: PPC Nagoya run3 late-window long-tail around tow 554746.x

[rsasaki0109]

結論

• PPC Nagoya run3 late-window の all-epoch p95_h を押し上げている主因は false-fix だけではなく、float drift / long-tail でもある。
• まずは tow 554746.x と tow 554605-609.x を代表区間として、float arbitration と fallback 条件を切り分ける。

確認済み事実

• 再現条件は /media/sasaki/aiueo/ai_coding_ws/rtklib_v2_rtk_ws/gnssplusplus-library/output/ppc_nagoya_run3_lowcost_late2k_holdcfgfix.pos。
• tow 554746.8 では libgnss++ FLOAT が horiz=18.878 m, up=-7.265 m、同 epoch の RTKLIB FLOAT は horiz=7.486 m, up=17.638 m、SPP は horiz=14.287 m, up=16.342 m。
• tow 554746.x の drift は default / low-cost / no-hold でほぼ同一で、hold 固着では説明できない。
• apps/gnss_solve.cpp の app-level FLOAT/SPP arbitration は float_vs_spp > 30 m と last output からの jump guard に依存しており、tow 554746.x では発火していない。
• 現行の nonfixed drift guard は last_fixed_output から <=5 s のみを見るため、長い tail を拾い切れていない。
• ratio threshold を上げるだけでは all-epoch p95_h はほぼ改善しない。主因が float 側に残っているため。

未確認/要確認項目

• processor 側で SPP fallback すべきか、app 側で output arbitration すべきか
• last output, last fixed, SPP seed のどれを基準にすると Tokyo side effect が最小か
• long-tail を NONE に落とす方がよいか、SPP に戻す方がよいか

次アクション

• /media/sasaki/aiueo/ai_coding_ws/rtklib_v2_rtk_ws/gnssplusplus-library/apps/gnss_solve.cpp の FLOAT/SPP arbitration と nonfixed drift guard を切り分ける。
• Nagoya/Tokyo late-window で offline replay し、candidate rule の matched/p95 tradeoff を比較する。
• 改善候補が見えたら Odaiba でも coverage regression を確認する。

再現コマンド

python3 apps/gnss.py ppc-demo \
  --dataset-root /media/sasaki/aiueo/ai_coding_ws/datasets/PPC-Dataset-data \
  --city nagoya --run run3 --solver rtk \
  --skip-epochs 3201 --max-epochs 2000 \
  --preset low-cost \
  --summary-json output/ppc_nagoya_run3_lowcost_late2k_holdcfgfix_summary.json \
  --out output/ppc_nagoya_run3_lowcost_late2k_holdcfgfix.pos \
  --rtklib-pos output/ppc_nagoya_run3_late2k_rtklib.pos \
  --use-existing-rtklib-solution

[rsasaki0109]

結論

• /media/sasaki/aiueo/ai_coding_ws/rtklib_v2_rtk_ws/gnssplusplus-library/apps/gnss_solve.cpp の nonfixed arbitration に last_trusted_output を入れる実験は 2026-04-10 時点では採用しない。
• trusted anchor + strong SPP update 案は Nagoya run3 late-window の coverage と all-epoch 精度を悪化させた。
• trusted anchor を FIX のみに限定 + jump guard を last_output cadence 基準へ戻す 案でも、問題区間 tow 554746.x の FLOAT tail は残り、さらに matched epoch を大きく落とした。

確認済み事実

• 実験前の基準は /media/sasaki/aiueo/ai_coding_ws/rtklib_v2_rtk_ws/gnssplusplus-library/output/ppc_nagoya_run3_lowcost_late2k_holdcfgfix_summary.json で、1819 matched, 296 fixed, 16.272677% fix, median_h=7.817195 m, p95_h=18.312437 m, p95_abs_up=55.943279 m だった。
• 1 本目の実験結果は /media/sasaki/aiueo/ai_coding_ws/rtklib_v2_rtk_ws/gnssplusplus-library/output/ppc_nagoya_run3_lowcost_late2k_trustedanchor_summary.json で、1701 matched, 271 fixed, 15.931805% fix, median_h=10.732190 m, p95_h=18.588034 m, p95_abs_up=80.428201 m だった。
• 上記 1 本目の debug CSV /media/sasaki/aiueo/ai_coding_ws/rtklib_v2_rtk_ws/gnssplusplus-library/output/ppc_nagoya_run3_lowcost_late2k_trustedanchor.csv では、tow 554745.6-554748.4 の jump_guard_m が 630-700 m まで膨らみ、action=kept_raw のまま FLOAT tail を通していた。
• これは trusted anchor を strong SPP にも更新した結果、anchor 自体が tail に追従しつつ、guard の時刻差だけが大きくなっていたことを示す。
• 2 本目の実験結果は /media/sasaki/aiueo/ai_coding_ws/rtklib_v2_rtk_ws/gnssplusplus-library/output/ppc_nagoya_run3_lowcost_late2k_trustedanchor_v2_summary.json で、1045 matched, 271 fixed, 25.933014% fix, median_h=16.342565 m, p95_h=18.554252 m, p95_abs_up=56.189414 m だった。
• 上記 2 本目の debug CSV /media/sasaki/aiueo/ai_coding_ws/rtklib_v2_rtk_ws/gnssplusplus-library/output/ppc_nagoya_run3_lowcost_late2k_trustedanchor_v2.csv では、action 集計が kept_raw=1043, drop_nonfixed_jump=930, drop_nonfixed_drift_from_fixed=24, adopt_spp=3 で、coverage を落とし過ぎている。
• 2 本目でも tow 554745.6-554748.4 の candidate_jump_m は 6.154-6.248 m, jump_guard_m=8.000 m で、依然として action=kept_raw のままだった。つまり 554746.x の tail は「trusted anchor をどう持つか」だけでは止まらない。
• Tokyo run3 late-window では /media/sasaki/aiueo/ai_coding_ws/rtklib_v2_rtk_ws/gnssplusplus-library/output/ppc_tokyo_run3_lowcost_arfilter_late2k_trustedanchor_summary.json が 1957 matched, 79.867144% fix, p95_h=1.524507 m、/media/sasaki/aiueo/ai_coding_ws/rtklib_v2_rtk_ws/gnssplusplus-library/output/ppc_tokyo_run3_lowcost_arfilter_late2k_trustedanchor_v2_summary.json が 1884 matched, 82.961783% fix, p95_h=1.248645 m だった。Tokyo だけを見ると改善余地は見えるが、Nagoya 側の coverage 破壊が大き過ぎる。
• skip=4020,max_epochs=50 と skip=4730,max_epochs=50 の単発 debug window は /media/sasaki/aiueo/ai_coding_ws/rtklib_v2_rtk_ws/gnssplusplus-library/output/ppc_nagoya_run3_debug_554605c.csv と /media/sasaki/aiueo/ai_coding_ws/rtklib_v2_rtk_ws/gnssplusplus-library/output/ppc_nagoya_run3_debug_554746c.csv で取得したが、問題 window の直前から十分な anchor history を育てないと挙動差が出なかった。
• 2026-04-10 の作業末尾では、trusted anchor 実験コードは /media/sasaki/aiueo/ai_coding_ws/rtklib_v2_rtk_ws/gnssplusplus-library/apps/gnss_solve.cpp から切り戻し、hold-threshold 修正までの安定状態に戻している。

未確認/要確認項目

• tow 554746.x で float_vs_spp_m が 23.8-24.8 m 程度でも悪い FLOAT が残る理由は未特定。現状の kDefaultFloatVsSppGuardMeters=30.0 を超えないため、SPP 比較ロジックに入っていない可能性が高い。
• 554746.x を止めるには、float_vs_spp の絶対 threshold ではなく「trusted reference に対して FLOAT と SPP のどちらが近いか」を常時見る必要がある可能性がある。ただし、今ある debug CSV では threshold 未満時の spp_jump_m が出ておらず、判断材料が足りない。
• Tokyo run3 でだけ改善する条件を、Nagoya run3 に安全に持ち込める形へ一般化できるかは未確認。

次アクション

• /media/sasaki/aiueo/ai_coding_ws/rtklib_v2_rtk_ws/gnssplusplus-library/apps/gnss_solve.cpp の debug CSV を拡張し、float_vs_spp <= 30 の epoch でも spp_jump_m と比較基準を記録する。
• /media/sasaki/aiueo/ai_coding_ws/rtklib_v2_rtk_ws/gnssplusplus-library/output/ppc_nagoya_run3_lowcost_late2k_holdcfgfix.pos を基準に、tow 554746.x 近傍の FLOAT と SPP を「trusted ref への近さ」で比較し、threshold 依存ではない adopt/drop 条件を設計する。
• #11 では app-level arbitration の追加実験を先に続け、src/algorithms/rtk.cpp 側の processor-level 変更は切り分けが済むまで後ろに置く。