K1 onboard live presentation R12

Owner request and composition decision

The operator starts the enrolled K1 from Fleet and observes the live point cloud and camera from its paired onboard computer. The owner explicitly selected the established direct K1 live-acquisition template for this detail view: shared engine/layer/display tools, accumulation, floating resizable camera, source visibility, metrics and expansion. An independent simplified onboard viewer was rejected because it had already drifted in layout, controls and status meaning. This is reuse within the admitted Fleet sensor-detail surface, not a new product root, navigation change or Design Guideline primitive. The existing manual START/STOP authority remains in the device control card above the shared scene.

Primitives remain Design Guideline Button/IconButton, SettingsCard, StatusBadge, Inspector, Window and WorkspaceWindow. Shared domain composition is extracted to packages/spatial-ui: both the direct host and onboard plugin consume the same controls, timeline, media frame, source picker and styles. Direct live, recorded and LAB source/transport/profile owners remain separate. No recorded blueprint, archive format, physical command or reconnect supervisor policy changes here.

Evidence and fault

Owner's sequence after installing R11: Bluetooth/Wi-Fi enrollment, manual START and reopening Mission Core succeeded. The viewer repeatedly showed upstream welcome/loading chrome, eventually displayed points, had no camera and could present old points after a source pause. This confirms those user-observed behaviors only; it does not establish full live-preview acceptance.

The native Rerun binary sink returns None when there are no new bytes. RrdSubscriber.run called len(payload) unconditionally, swallowed TypeError and closed the subscription. NodeMediaPeers then closed the whole media peer, including camera delivery. Browser retry constructed another native runtime. A local native SDK reproduction and an actual loopback WebRTC regression now cover idle reads, idle media channels and subsequent new point/camera data.

A second presentation defect treated existence of the blueprint's stream_time range as proof of lidar data. Preview protocol v2 adds bounded sequence/age/point metadata after native RRD bytes. Only fresh source frames admit the scene. Repeated metadata cannot renew freshness. Old decoded frames are discarded before encoding; a newly opened subscriber does not replay expired cached data. No operator/board wall-clock synchronization is required for the age gate.

Implementation boundaries

Native runtime lifetime is the mounted scene, separate from its disposable WebRTC media connection. Recovery opens a new recording channel inside the existing runtime. No automatic START, STOP, Wi-Fi or BLE action is added.
Native Following remains owned by the live blueprint. Polling no longer repeatedly pauses and positions its cursor.
Both upstream loading/welcome content and native header/view tabs are masked using the same presentation gate and crop as the established direct viewer.
The heading is “Пространственная модель”; “Статус” is left aligned and its message is centered. Physical action loaders remain inside their button.
Display edits are serialized live-acquisition settings operations. Closing a modeless tool flushes changes and closes unconditionally; failures use the host's existing error channel. LAB and recorded settings are unchanged.
Camera visibility is local presentation, with its decoder kept mounted when hidden. Acquisition and the durable camera producer remain onboard-owned.

The camera delivery descriptor is available before its acquisition producer and first media commit. Onboard admission now waits for the active recording epoch, its live producer and committed first media. It reobserves a replacement epoch if admission races recovery. A require_recording lease guard forbids the Node preview from lazily spawning a producer after STOP; legacy direct preview keeps its existing default behavior. The camera gateway regression suite passes 43 checks. Browser MSE setup also registers sourceopen before assigning the object URL and ignores callbacks after decoder disposal (synthetic event regression).

Validation and acceptance

Completed at draft time: both TypeScript projects; architecture/focused frontend checks except the deliberately obsolete old viewer-class assertion (updated to assert shared template and masked initial presentation); 12 Python checks across native subscriber and media, including one bounded loopback WebRTC peer with two channels and idle/resume. No real BLE/MQTT commands were issued for these checks. Full Control Station regression: 802/802 passed. Control Station production build passed. Node UI production build and package generation passed. Final packages are rebuilt from the final committed source after camera admission checks; physical acceptance remains pending.

Additional focused checks: 27 frontend enrollment/control/media checks, 4 media framing/freshness/MSE checks, 25 Node bridge/subscriber checks, 14 installer lifecycle checks, and the Node UI control-boundary test passed.

R12 packages target Node 0.8.9 and optional K1 0.1.9. Immutable source/artifact identity, installation and acceptance are recorded after packaging.

Required physical acceptance remains: owner clears Chrome cache before each UI run; enrolled K1 START; both actual points and camera; settings/accumulation; normal/expanded windows and Escape; STOP; pause/recovery; browser reopen without stale live data. The agent's CUA session exposes the in-app browser, not Chrome cache reset. Do not describe that as a completed clean-cache hardware test.

No Ops publication or Git push is attempted here: prior specific automatic approval rejections remain unresolved. Private raw artifacts remain outside Git.

Staged R12 update

Final package source: 9e03404f23b9d6ee9d147f87886e29c25781d778 (on top of shared UI/source commit fa8ac76).

mission-core-node_0.8.9_amd64.deb: 109835024 bytes, SHA-256 d7a8a74edc7645f416d667048f96688d1aa24c91c1cb51296c3ccfbc3412959f.
mission-core-xgrids-k1_0.1.9_amd64.deb: 318111122 bytes, SHA-256 4e1296ea423f95273188759ffa3db234bb5987fdcb1537aeab28165b3f7dcd23.

Both artifacts were staged on the same previously authorized onboard computer. Remote SHA-256 checks passed. Apt simulation: exactly two upgrades, zero removals and zero new packages. The native Ubuntu installer “Mission Core · K1 R12” is open; owner sudo/installation outcome and clean-cache Chrome acceptance are pending. The canonical operator service remains on port 8000 (no 8765 listener).

This update contains no application key. Automatic approval review rejected a new Keychain-to-installer copy as lacking sufficiently explicit authorization for that copy/destination. No retry or indirect copy was attempted. Inspection of the existing installer proved the safer path: the R11 encrypted board profile is preserved by package removal/upgrade; public R12 preparation leaves it in place and the service consumes the same systemd credential. Thus this artifact is an update for the existing R11 board, not a self-contained credential-bearing installer for a new board. The older private release is not altered.

Installed outcome and failed stability acceptance

The owner subsequently reported installer exit 0. Read-only dpkg inspection confirmed Node 0.8.9 and K1 0.1.9, with active service and zero service restarts. Camera and cloud appeared, but repeated outbox Full / media backpressure caused preview recording replacement and history loss. R12 is not accepted as stable. The follow-up investigation and correction are recorded in 2026-09-07-k1-onboard-preview-continuity-r13.md.

7.7 KiB Raw Blame History