Skip to content

R1-09 urban RTK/IMU field checklist

This is the field hand-off checklist for the frozen Tokyo R1 continuity profile. It is an operational checklist, not an accuracy claim. The R1 profile is currently on hold: run3 is a frozen holdout failure, so no R1 profile should be offered for field deployment until a release authority records a separate decision.

The corresponding evidence and release decision are in the urban RTK/IMU guide. Keep this checklist with every archived bundle.

Frozen recipe

Do not change these values when reproducing the frozen candidate:

Setting Frozen value Contract
IMU-to-antenna lever arm 0.31,0,-0.55 m PPC vehicle coordinates; signed Z is negative
Preset low-cost Tokyo R1 profile
ZUPT/NHC ZUPT on, NHC off NHC is not part of the frozen profile
Position gate NIS 500, FIX patience 30 Position-only recovery; FLOAT resets patience
Doppler velocity gate NIS 25 χ²-style statistical gate for the velocity update
Velocity reject patience 3 consecutive rejects Trusted finite/PSD Doppler only
Velocity re-anchor bound 20 m/s Velocity-only recovery; position/attitude/bias unchanged

The lever arm is the IMU origin to antenna vector. The internal ESKF solution is IMU-origin; the externally scored fused .pos, RTK .pos, KML, and PPC reference are antenna-frame. Never score an internal IMU-origin solution as the antenna trajectory.

One-command bundle and KML hand-off

Run the existing dispatcher from the repository root:

python3 apps/gnss.py urban-continuity-bundle \
  --data-dir data/PPC-Dataset/tokyo/run1 \
  --reference-csv data/PPC-Dataset/tokyo/run1/reference.csv \
  --output-dir output/use_cases/urban_fusion_full/r1_bundle

The command runs fusion, pos2kml, the single-input trajectory plotter, and the bridge scorer. It emits these files in one directory:

rtk.pos  fused.pos  fused.kml  fused_trajectory.png
bundle.log  score.json  segments.csv  manifest.json

fused.kml is generated by the bundle's pos2kml step; no separate KML conversion command is needed. fused_trajectory.png is generated by calling trackplot with fused.pos alone. Do not pass the libgnss++ RTK .pos as trackplot's second positional argument: that argument means an RTKLIB-format input file.

The manifest is the hand-off record. Check its exact argv, input/output SHA-256 and byte counts, binary/version probe, software revision and dirty state, frame/lever contract, score gate, propagation age, and every step exit status. A failed step must leave the manifest and log; a nonzero bundle exit is not a usable artifact.

Preflight and frozen score gates

Before a run, confirm that the data directory contains non-empty rover.obs, base.obs, base.nav, imu.csv, and reference.csv, and record the vehicle calibration, IMU axes, time synchronization, and antenna lever arm. Confirm that the manifest's software revision is the intended binary.

The frozen score gates are:

Gate Requirement
Fused bridge coverage >= 99%
Maximum bridge horizontal error <= 75 m
Maximum reacquisition step <= 15 m
Fixed-epoch P95 regression vs RTK <= 5 m
Fused availability >= RTK availability
Non-finite fused epochs 0

Also inspect segments.csv: the score can pass while a particular bridge is too old for the mission. KML is useful for a visual sanity check, but it is not a substitute for score.json, segments.csv, and the reference-based error gates.

Operational classification

Use the following classification for each bundle, independent of whether the score gate alone says PASS:

Classification Conditions Action
usable Every frozen score gate passes, all artifacts and manifest are complete, nonfinite=0, maximum propagation age is <= 60 s, and release status is approved May proceed under the approved mission limits
degraded Finite evidence and a complete manifest exist, maximum age is <= 60 s, but one or more score gates fail or the result is not yet accuracy-approved Diagnostic/review only; do not claim field readiness
unusable Maximum propagation age is > 60 s, any non-finite/missing artifact occurs, a required step fails, or the profile/release is on hold Do not use for field decisions; stop or fall back to an approved source

The 60 s value is the R1 operational recommendation. It is stricter than the continuity score: a continuous bridge older than 60 s is still unusable until a vehicle-specific integrity analysis approves a different limit.

R1 release decision and holdout rule

The frozen records classify as follows:

  • run1: score PASS, maximum age 87.2 s → unusable under the 60 s rule;
  • run2: score PASS, maximum age 96.6 s → unusable under the 60 s rule;
  • run3: score FAIL because fused availability 99.934645% is below RTK 99.993464%, and maximum age is 63.4 s → unusable.

The immutable evidence directories are output/use_cases/urban_fusion_full/r1_frozen_bundle/, output/use_cases/urban_fusion_full/r1_holdout_run2/, and output/use_cases/urban_fusion_full/r1_holdout_run3/.

Run3 is a frozen holdout result. Do not rerun it, retune against it, or reclassify it as development data. Do not use either holdout to alter the frozen R1 recipe. A new candidate requires new, explicitly authorized development data and a new release review.

Field sign-off

Before sign-off, archive the complete bundle directory and verify:

  • the manifest and log identify the binary, revision, inputs, frame, and lever arm;
  • score.json and segments.csv agree with the intended reference window;
  • the fused and RTK .pos files use the antenna-frame contract;
  • the KML is geographically plausible and the PNG has no obvious time/order discontinuity;
  • every segment stays within the approved bridge-age and mission limits; and
  • the release decision is approved, not merely a scorer PASS.

If any item is uncertain, classify the result as unusable and retain the bundle for review rather than silently promoting it.