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: stationary initialization followed by lifting is an intended scanning workflow.
• ROS REP-105: separate continuous local odometry, global map correction and robot base frame.
• ROS REP-103: 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.