Files
NODEDC_MISSION_CORE/docs/audits/2026-09-20-physical-midroute-017-018-results.md
T
DCCONSTRUCTIONS e515ab1b8c feat(planning): consolidate recorded-route localization and spatial scene
Preserve the completed teach-and-repeat laboratory stage: reference preparation, cascaded acquisition, local tracking and recovery, recording lifecycle, replay qualification, and persistent Rerun scene controls. Document the open grid-picking regression and Rerun upgrade contract. No autonomous driving or loop-closure optimization is claimed.
2026-09-21 08:47:19 +03:00

168 lines
9.1 KiB
Markdown

# Physical mid-route starts 017/018 — result review
## Scope and verdict
Read-only review of the two latest physical experiments requested by the owner.
No registration, threshold, UI or device-control code was changed. No scanner
commands, replay session, service restart or Ops mutation was performed.
Both cold mid-route starts and subsequent geometric tracking succeeded while
the scanner supplied spatial data. Run 017 moved forward; independently started
run 018 travelled back towards the reference origin. There were no rejected
fresh fits or inconsistent-transform decisions during either traversal.
Two qualifications matter: the reported distances differ from the operator's
rough walking estimates, and both reports contain a terminal `stale` transition
**after commanded scanner stop**, not an in-motion recognition failure.
Absolute localisation accuracy is not established by these recordings.
## Evidence and integrity
Canonical private data root: `../NODEDC_MISSION_CORE/.runtime/mission-core`.
| Item | 017 | 018 |
|---|---|---|
| Name | `ja-sun-017-30m-offset` | `ja-sun-018-80m-offset-back` |
| Live-test ID | `2de294bb-a18e-4dfd-a9c4-51cae38fa54d` | `f61c7041-c1bb-4434-97e5-413bbc3e0695` |
| Raw session | `20260920T182601Z_viewer_live` | `20260920T183041Z_viewer_live` |
| Selected reference length | 112.248 m | 120.073 m |
| Frozen result artifacts verified | 84/84 | 114/114 |
| Raw pose payload hashes verified | 1126/1126 | 1439/1439 |
Both use reference session `20260911T085226Z_viewer_live`, generation
`8527e0de1995c93c835ee7223488ff851442792551e217d4ab43457974f798a1`,
route-relocalisation v6 and stationary fresh bootstrap v3. Current source hashes
match the previously qualified implementation for route retrieval, bootstrap
and live orchestration. Reviewed each step's `source.json`, numerical result
and `decision.json`, the raw receipt indexes, STOP timing diagnostics, temporal
gate and metric definitions in the actual code.
All fresh windows were disjoint in source sequence, and every admitted receipt
was newer than its fresh fence and no later than calculation submission. Both
starts rejected the dense origin hypothesis and searched the selected route;
018 did not inherit the final transform of 017 as an accepted localisation.
## Recognition and tracking
| Metric | 017 forward | 018 backward |
|---|---:|---:|
| Computed reference progress at start | 38.37 m | 84.87 m |
| Computed progress at last accepted fit | 84.89 m | 0.22 m |
| Recorded travelled distance | 47.442 m | 85.023 m |
| Cold confirmation from first usable prefix | 51.614 s | 49.065 s |
| Dense-start fits | 108, rejected | 108, rejected |
| Whole-route regions / precise fits | 24 / 72 | 26 / 78 |
| Search completed / remaining regions | yes / 0 | yes / 0 |
| Selected coarse anchor | 40 m | 85 m |
| Initial overlap / inlier RMSE | 99.538% / 0.1509 m | 99.259% / 0.1553 m |
| Runner-up distinct overlap | 79.994% | 81.514% |
| Fresh accepted fits, including first three | 15/15 | 21/21 |
| Fresh overlap min / median / max | 98.961 / 99.325 / 99.577% | 95.482 / 98.163 / 99.516% |
| Inlier RMSE min / median / max | 0.1460 / 0.1488 / 0.1518 m | 0.1486 / 0.1567 / 0.1755 m |
| Largest inter-update position correction | 0.0401 m | 0.0441 m |
| Largest inter-update rotation correction | 0.2563° | 0.5650° |
| Maximum accepted input age at completion | 0.954 s | 1.499 s |
| Worker wall time median / max | 0.314 / 0.395 s | 0.304 / 0.407 s |
Progress was obtained by projecting transformed scanner positions onto the
selected reference polyline. It is an estimate produced by the registration,
not surveyed ground truth. Its forward/backward progression matches the stated
experiments: 017 from about 38 to 85 m; 018 from about 85 m to the origin.
The travelled distance is the existing live-buffer accumulated SLAM distance,
not straight-line endpoint separation or an independently measured tape length.
The complete route searches took 28.333 s (017) and 25.325 s (018) across the
dense and route stages. Confirmation durations include the stationary prefix
and three new-data checks, but exclude device preparation before usable clouds.
All numerical fits converged. Shape and information metrics remained above
their admission thresholds; no failed fit was disguised as an accepted one.
Using the last raw pose and last accepted transform of 017, then the first raw
pose and third fresh (confirmed) transform of 018, their shared physical-place
coordinates differ by approximately **0.0173 m**. This is an encouraging
cross-session repeatability observation, conditional on the owner's statement
that the scanner restarted at the same physical location. It is not an
absolute 1.7 cm accuracy certificate: both estimates use the same reference,
and exact physical endpoint placement was not independently measured.
At the current scanner location, the maximum difference between the initial
transform and later accepted transforms was 0.119 m in 017 and 0.124 m in 018.
These are registration corrections relative to the initial hypothesis, not
position errors against ground truth. Total orientation-transform changes were
0.357° and 1.135° respectively; the largest single update is listed separately.
## End-of-run `stale`: lifecycle finding
UTC chronology from raw receipt indexes and `scanner-diagnostics.jsonl`:
| Event | 017 | 018 |
|---|---|---|
| STOP handling began | 18:28:20.335 | 18:33:28.029 |
| Last spatial cloud received | 18:28:20.710 | 18:33:30.337 |
| Last accepted fit completed | 18:28:21.033 | 18:33:27.795 |
| Temporal gate became stale | 18:28:28.698 | 18:33:35.441 |
| Capture/planning input finished | 18:29:12.068 | 18:34:22.051 |
STOP was confirmed by the device. Heartbeats and device-status receipts
continued after spatial output ceased. The capture remained active for roughly
another 51 s while shutdown completed. The numerical gate correctly refused
to retain live localisation after its eight-second sample-age fence; the live
orchestrator consequently began recovery (`recovery_attempt=1`) despite the
scanner already being deliberately stopped. No new recovery fit followed.
This is a real lifecycle/reporting defect: commanded stopping should not be
reported as unexpected loss requiring relocalisation. The correct follow-up is
to distinguish capture finalisation from active spatial acquisition, while
still clearing live authority. It is **not** a reason to weaken the freshness
fence or mark stale transforms as live. The present review does not implement
that follow-up.
Code anchors: `causal_tracking.py:32` expires accepted evidence;
`stationary_live.py:349` ticks the gate and starts recovery before the source
has ended. The source's active state remains true during the prolonged stop
finalisation, so simply reordering the end-of-input check is insufficient.
## Input delivery finding
Raw spatial receipts averaged approximately 10 Hz in both experiments, with
maximum receipt gaps of about 1.11 s and 1.01 s. Recorded planning continuity
segments contained no gap beyond the two-second boundary and no detected pose
discontinuity. Burst delivery means that speed calculated from consecutive
host receipt intervals is not a valid physical velocity estimate.
The private derived-data queue did discard some packets on overflow:
- 017: 9/1125 lidar frames (0.80%), no pose frames.
- 018: 34/1439 lidar frames (2.36%), 1/1439 pose frames (0.07%).
These are deltas of cumulative ingress counters, not raw-recorder losses.
Corresponding packets remain in the raw recordings. The discarded derived
packets did not produce a failed geometric/temporal check in these runs, but
delivery cannot honestly be described as lossless. Queue/scheduling headroom
remains a follow-up concern before greater speed, load or route length.
## Accuracy interpretation and conclusion
In `registration.py:140`, overlap is the fraction of sampled query points whose
nearest reference point lies within 0.5 m. RMSE is computed only over that
inlier set, after the existing 0.25 m voxel preparation. Thus 99% is not a
99% probability of correct localisation, and 0.15 m RMSE is neither a measured
scanner position error nor its guaranteed bound. Small corrections between
updates indicate consistency, not independently measured absolute accuracy.
**Passed for this recorded location:** cold starts away from the route origin,
distinct-region selection, three fresh confirmation checks, forward tracking,
independent cold restart near 85 m, and backward tracking to the origin.
These are physical v6 results, not only archive simulations.
**Not established:** centimetre-level absolute accuracy, reliability across
many independent starts, arbitrary off-route starts, kilometre-scale maps,
different locations/conditions, or safe autonomous driving margins. A physical
accuracy claim requires independently measured checkpoints and comparison of
reported scanner positions with those checkpoints.
Recommended decision: retain the geometric cascade and thresholds. Address
commanded-stop semantics and inspect derived-queue headroom separately; use
measured checkpoints for the next accuracy assessment. Do not interpret a
larger walking distance alone as a measurement of absolute accuracy.