NODEDC_MISSION_CORE/docs/audits/2026-09-19-physical-start-006-diagnosis.md

# JA-SUN-006: read-only diagnosis of rotation, update cadence and mounting

Date: 2026-09-19. No product source changes, runtime restart, device commands,
Ops writes or capture modifications were performed in this diagnostic pass.
Temporary numeric checks ran sequentially against saved evidence, without
publishing replay into live ingress. Canonical service remains on port 8000.

## Evidence and scope

- Project label: `ja-sun-006`.
- Run: `ebee2e65-5d74-49f2-9489-1b2fecf30a76`.
- Query session: `20260919T174634Z_viewer_live`, generation 1.
- Reference: `JA-SADOVAYA-001`, `20260911T085226Z_viewer_live`.
- Frozen reference generation:
  `8527e0de1995c93c835ee7223488ff851442792551e217d4ab43457974f798a1`.
- Selected reference pose interval: 0–577, route length 30.011684 m.
- All 82 report-bound artifact hashes verified. Original reference raw capture
  SHA-256 verified:
  `61ae4631e6d59b57cd32235871153760976f18706607c7759b8dc28060a56e51`.
- Current and related architecture context: MISSIONCOR-81, with linked
  MISSIONCOR-79/80. The handheld scanner trace is not an accepted chassis route.
- User cannot establish whether the visible rotation happened during tracking
  or after loss/completion; no screen recording is available. Do not present the
  particular screen moment or a physical 10-degree scanner drift as proven.

## Actual progression

All times UTC; add three hours for the operator's Moscow clock.

| Event | Time | Evidence |
|---|---|---|
| Usable cloud / collecting | 17:47:00.338 | Stationary prefix begins |
| Initial search | 17:47:10.350 | 108-seed bounded search |
| Initial candidate ready | 17:47:24.739 | Yaw -1.003°, overlap 98.05%, inlier RMSE 0.144 m |
| Three-window tracking established | 17:47:37.370 | Accepted fresh validation; not just point color |
| Scanner lifted and carried | approximately 17:47:47 onward | Local z rises about 1 m; quaternion changes with body turn |
| Last accepted fit | 17:48:33.310 | Distance 33.959 m, yaw -0.679°, overlap 81.0%, RMSE 0.215 m |
| Fit rejected | 17:48:39.335 | Distance 38.100 m, overlap 49.36%, RMSE 0.266 m, nonconvergence |
| Lab test ends | 17:48:41.069 | Last published distance 39.486 m; loop has a 40 m cap |

Accepted moving fits retain yaw between approximately -1.018° and -0.661°.
After the lift/turn, overlap stays approximately 97–98% for much of the walk.
This evidence does not support blaming the scanner's approximately one-metre
height change or changed carrying orientation for a 10-degree registration turn.
It does not qualify arbitrary mounting heights/orientations either.

`input-ended` in the final report is not proof that scanner input stopped:
`stationary_live.py` uses the same terminal reason after all normal loop exits,
including the distance cap. Raw pose/cloud continue until approximately 17:49:00.
The saved acquisition reports a later protocol-confirmed device stop.

## Confirmed defect: live view falls back to a different transform

`PlanningLiveTests.scene()` uses `accepted_sample` only while the source is
active, the run is running and the accepted sample is sufficiently fresh.
Otherwise it supplies the global buffer sample with no accepted result.
`live_scene.scene_bytes()` then uses `sample['hint']`.

That hint is computed by `registration.path_hint()` from the two trajectories'
first >=3 m horizontal displacement. It assumes their early travel headings
should agree; it is not geometric localization. The stationary bootstrap
explicitly disables this fallback for localization, but the renderer still uses it.

A bounded test called the existing `PlanningLiveTests.scene()` selection logic
on saved 006 inputs, with only clock/source/render sink substituted:

| Display selection | Applied yaw | Path size |
|---|---:|---:|
| Last accepted tracking window | -0.678689° | 50 points |
| After rejected fit | -21.929674° | 530 points |
| After lab completion | -21.929674° | 530 points |

Green is correctly removed in the fallback, but geometry changes by about
21.25° without a new accepted localization. This is a reproducible presentation
defect and a plausible explanation of the operator's observation. Screen-right
and perceived angle depend on camera viewpoint; the exact observed event is unknown.

The archived project viewer uses a separate path: `projects.live_scene()`
selects the committed last calculation, including a rejected result, with its
own input window. It does not apply this preview hint. Live completion and
archive inspection must therefore not be conflated.

## Confirmed submap coverage limitation: counterfactual control

The run uses a single fixed reference submap extracted from the selected 30 m
route interval, while allowing a new walk of about 40 m. Reference cloud points
extend beyond the route endpoint (up to 48.49 m along the route chord), but
sparse distant visibility is not equivalent to mapping the later section.

Control: read the same original reference capture and extract its later
10.003–49.009 m interval, poses 339–775. This respects the existing <=40 m
extraction-window bound; 120 frames yielded 52,159 retained voxel points in
2.172 seconds. No original artifact, route or runtime configuration was changed.
Use exactly the same step-016 query and the same last-accepted transform:

| Reference data | Raw-query overlap within 0.5 m | Inlier RMSE |
|---|---:|---:|
| Original frozen submap | 50.8236% | 0.2581 m |
| Later reference interval | 98.0735% | 0.1572 m |

This comparison changes reference coverage only, not query pose or alignment.
A subsequent single bounded GICP control on the later reference also converged:
97.6789% preprocessed overlap, RMSE 0.157108 m, five iterations, 0.0431 m
centre correction, 0.4348° rotation correction, native calculation 0.0281 s.
Its transform yaw is approximately -0.789°.

Thus loss of overlap at the end of 006 is explained by the selected reference
coverage rather than requiring a failed scanner SLAM or changed mount hypothesis.
This retrospective control is not a new successful live run and does not grant
localization/control authority. A route endpoint and a localization map boundary
need separate handling; thresholds should not simply be relaxed.

## Cadence: sensor arrival, calculation and display are different

Raw capture contains 1,200 consecutive pose sequence numbers and 1,200 cloud
messages over approximately 120 seconds. Average receipt frequency is 10 Hz
for each. During the lab interval:

| Stream | Median interarrival | p95 | Maximum |
|---|---:|---:|---:|
| Pose | 0.0892 s | 0.1735 s | 1.0285 s |
| Cloud | 0.0867 s | 0.1776 s | 1.0577 s |

These are host receipt intervals, not calibrated sensor-to-actuator latency.
No >=2 s pose/cloud receipt gap appears, but the approximately one-second pauses
are real evidence against assuming a hard real-time guarantee. The planning
ingress snapshot also contains 14 lidar overflow drops out of 1,009 publications;
the raw recording and derived-consumer accounting are distinct.

- `LiveCloudBuffer.ingest`: cloud selection limited to at most 2 Hz.
- `StationaryBootstrap.validation`: independent fresh fits approximately every 5 s.
- `PlanningLiveTests.scene`: displays the accepted calculation's frozen window,
  rather than latest pose/cloud under the accepted transform.
- `PlanningLiveScene.tsx`: next fetch starts 2 s after the previous fetch/render
  submission. This is at best 0.5 Hz polling, not a guaranteed display rate.
- Fresh fit worker wall time is approximately 0.198–0.466 s; newest input age at
  completion approximately 0.246–0.850 s. A five-second collection window also
  contains older observations, so newest age is not the age of every point.

Slow drawing is not proof of a 2-second scanner sampling rate. Nevertheless,
the current LAB is not a proven rover perception/control loop. It has no vehicle
authority and admits tracking evidence up to 8 s old. Fast local pose/perception,
slower global map correction, and operator rendering must be separately timed,
bounded and measured; simply refreshing the browser faster is insufficient.

## Mounting and route semantics

Cloud-to-cloud registration aligns the scanner's SLAM session map with the
reference map in six degrees of freedom. A different scanner height/orientation
does not inherently require rebuilding that map or a separate SLAM algorithm.
006 already provides limited positive evidence for lift and turn after startup.

Knowing the scanner pose is different from knowing a rover's chassis/control
point pose. Ground geometry alone does not identify an unknown chassis's forward
direction, wheel axle/control point, scanner lever arm or footprint. The missing
scanner-to-chassis transform must be known or estimated and validated at runtime.
It need not be a manually entered per-rover SLAM profile: a keyed standardized
dock or an independently qualified calibration using chassis motion/odometry
are candidate product approaches. Chassis geometry and kinematics remain real
inputs even when the sensor/computer box is transferable.

Current planning decoding retains position but discards the already decoded K1
orientation. This suffices to draw a scanner trajectory and register map points,
not to expose a complete chassis pose for control. Do not equate a handheld
scanner path, including lift/start manoeuvres, with the ground route to drive.

Primary references checked:

- [XGRIDS K1 FAQ](https://docs.xgrids.com/en-us/02-lingguang-k/01-lingguang-k1/v2.4.0/09-faq.html): stationary initialization followed by lifting is an intended scanning workflow.
- [ROS REP-105](https://github.com/ros-infrastructure/rep/blob/master/rep-0105.rst): separate continuous local odometry, global map correction and robot base frame.
- [ROS REP-103](https://github.com/ros-infrastructure/rep/blob/master/rep-0103.rst): body and optical coordinate conventions.

## Recommended next implementation, not performed

1. Never replace a validated transform with the travel-heading hint when tracking
   expires or the test ends. Preserve clearly stale historical alignment or hide
   unlocalized geometry; do not represent it as current localization. Make live
   completion and archive transform selection explicit and consistent.
2. Decouple reference-map coverage from selected route length. For a short test,
   constrain the evaluation to the covered corridor; later qualify rolling or
   route-ahead submaps with their own evidence and ambiguity guards.
3. Separate latest scanner pose/cloud, accepted map transform and fit evidence.
   Measure arrival/queue/compute/display ages independently, preserve orientation,
   and define loss/stale behavior before enabling any rover consumption.
4. Qualify the scanner localization contract first, then the transferable-box
   mounting/chassis contract and the sensor-path-to-drivable-route conversion.
5. First regress these changes against saved 006, existing independent passes
   and wrong-place controls. Only then request a new short physical walk inside
   the covered reference corridor; do not repeat the same ambiguous field test now.

Numeric diagnostic scripts are retained under
`/private/tmp/mission-core-006.AWd3FO/`; original evidence remains under the
canonical runtime data root, outside normal Git.