# Physical repeat: 35.30 m and slow planning cloud Date: 2026-09-19. Read-only diagnosis requested after the operator reported a successful approximately 35 m walk, stable video, and an unusually slow new cloud. No product code, device configuration, runtime, or Ops card was changed. The registration-stabilization changes remain loaded in the canonical 8000 service. ## Identity and integrity The new project is also named `ja-sun-006`; it must not be confused with the earlier failed run under that same name. - Run: `27a20878-9697-4735-a86e-763de28e4b67`. - Query: `20260919T185447Z_viewer_live`, generation 1. - Reference: `20260911T085226Z_viewer_live`; route 0–577, map 0–785, `route-context-map/v1`, 70,870 points. - All 83 run artifacts matched their stored hashes. Raw MQTT and metadata hashes also matched the capture summary. Raw SHA-256: `0723c51b7555740e802db669597e42e3f21f4438ef909e1d6ee4e89284119a88`. - Browser diagnostics identify the deployed build `app-D2qqIbEW.js`. ## Registration result The complete 108-hypothesis stationary search finished at 18:55:38.734 UTC. After three independent fresh checks, tracking began at 18:55:51.852 UTC, approximately 38.47 s after the first pose. The first six calculation windows were stationary or nearly stationary; the operator moved after tracking began. All 15 fresh-validation results were accepted. There was no registration rejection or receipt-gap transition during the walk. The final distance was 35.300 m (scanner's own reported distance 35.215 m). During moving windows, overlap was 96.14–98.14%; final stationary checks were 99.37% and 99.16%. Final inlier RMSE was 0.14384 m. This is surface agreement, not independent position accuracy. Accepted transform yaw ranged approximately −3.028° to −2.831°, a span of 0.197°. These are map-frame alignment angles, not an absolute heading error. The large apparent rotation/fallback observed in the earlier run is not present in these saved transforms. Fresh fit worker wall times were 0.246–0.517 s; the latest input age at result admission was 0.311–1.845 s. Fits remain scheduled approximately every five seconds, not at native pose rate. ## End-of-run chronology | Event | UTC | | --- | --- | | Last substantial pose increment (>3 cm between adjacent receipts) | 18:56:43.810 | | Last accepted fit, distance 35.300 m | 18:56:53.617 | | Correlated physical STOP response | 18:56:54.625 | | Last raw point cloud | 18:56:54.747 | | Registration freshness expired | 18:57:00.643 | | Camera archive sealed | 18:57:15.245 | | Input/session closed | 18:57:44.599 | The final `lost/stale` is after confirmed STOP and cessation of raw cloud input, not a loss while walking. The final report ends `input-ended`. Cleanup took longer than physical STOP; those are separate events and must not be conflated. Current acquisition is completed, receiver stopped, device STOP protocol-confirmed, source/control idle, physical command inactive. No STOP command was sent by this diagnostic work. ## Why the cloud remains slow The implementation still has separate ordinary-live and planning display paths. The previous change improved snapshot/poll cadence and alignment ownership, but did not turn the planning preview into a native-rate streaming view. | Layer | Evidence | | --- | --- | | Raw K1 receipts | 1,013 poses and 1,013 point-cloud frames; both approximately 9.984 Hz | | Raw cloud spacing | median 87.58 ms; p95 194.01 ms; maximum 1.001 s | | Existing planning buffer applied offline to this raw recording | 169 cloud frames, 1.663 Hz; median spacing 0.560 s, p95 0.935 s, maximum 1.207 s | | Fresh map-fit/evidence layer | roughly one update per five seconds | | Browser planning requests | next request starts 500 ms after the previous fetch/send finishes; this is not guaranteed 2 FPS | The offline buffer count is deterministic sampling analysis, not a measurement of the physical browser's rendering rate. The actual planning ingress consumed 1,000/1,013 cloud events (13 overflow), all 1,013 poses (zero overflow), and 941/942 camera frames (one overflow). These derived-queue counts do not indicate loss of the raw recording. Source trace: - `missions/live_buffer.py:43–64`: accepts cloud no more often than every 500 ms; 0.25 m voxel, up to 4,000 points/frame, 40 accumulated frames, 40,000 points in a snapshot. At the end, these 40 selected frames cover 23.61 s of history. This is historical accumulation, not a 23.61 s delay before adding a frame. - `missions/stationary_live.py:233–244`: snapshots that same buffer on a separate 500 ms gate. Changing the poll interval does not remove the upstream sampling. - `missions/live_scene.py:25–43`: clears/replaces the entire query/path and validation entities for each response. Green points belong to the previous accepted fit window; they intentionally do not follow every new cloud. - `PlanningLiveScene.tsx:25–42`: sequential HTTP download, RRD handoff, then a 500 ms wait. No recorded per-frame fetch/decode/present acknowledgement exists for this physical pass, so exact browser delay and its dominant cost are unknown. - Ordinary `viewer/rerun_bridge.py:218–249,358–381` publishes each admitted point-cloud envelope to its live Rerun stream. That is not the planning accumulated-snapshot transport. The ordinary receiver recorded zero decode errors and receipt-to-publish p95 85.212 ms. That metric belongs to the ordinary bridge, not planning's browser. The raw stream contains approximately one-second receipt stalls, so it should not be described as perfectly uniform. Nonetheless it supplies much more frequent data than the planning preview admits. Conclusion: the complaint has a concrete implementation basis. There is no evidence that K1 SLAM itself needs multiple seconds per new cloud in this pass. The planning display remains deliberately downsampled and snapshot-driven. Exact user-visible latency is not reconstructible from the retained evidence. ## Camera Complete archive: 942 segments, 75,970,859 bytes. Init, index, all segment hashes, and stream digest verified. Browser diagnostics for the recording interval show successful playback without a decode-error/restart event. Single-threaded offline FFmpeg decoding completed with exit 0 and no corrupt-frame/macroblock diagnostic. It emitted 51 non-monotonic DTS lines plus two repeat notices at the null-output muxer. Therefore decoded pictures are not showing the earlier 005 corruption pattern, but timestamp cleanliness is not fully accepted. Exit 0 alone is not treated as proof of a flawless video path. ## Decision and next step Accept this as a successful short physical registration repeat, not as autonomous navigation acceptance. The slow view should not be dismissed as irrelevant: operators need a current view, and a future controller needs explicitly bounded pose freshness rather than the age of a five-second fit or a painted cloud. Recommended implementation next: feed a bounded fresh cloud/pose display from the existing ingress independently of the numerical accumulation buffer; reuse the admitted live transport where compatible; apply the last accepted alignment to fresh data, keeping fit evidence separate. Preserve identity, segment, freshness, loss and no-authority fences. Do not simply increase ICP frequency or expand its buffer. Instrument receive → sample → export → browser-present and frame sequence so a physical display delay can actually be measured. Qualify this on the current saved recording before requesting another field walk. No such change was made in this diagnostic turn. Runtime remained `snapshot-runtime-564d78ca9bd1eb86e13bdce9b4b5be27`, PID 99603, healthy on 8000. Temporary offline analyses and FFmpeg completed; no service, camera, replay publisher, or device-control job was started. Ops was read only.