How Ash’s systems fit together

Three runtimes with different evidence

RC-01 currently has three related engineering surfaces: the Raspberry Pi bench stack, the PC-assisted voice development path and the public browser character. Their shared identity is Ash. They are not yet one integrated mobile robot.

The Pi perception/state/behavior pipeline has dated service and live-event evidence. Voice has native capture work plus later bounded conversation experiments. The website has authored animation and ambience. A feature working on one surface must not be presented as automatically working on the others.

Perception is a stateful interpretation of frames

The camera and accelerator produce detections; the per-frame gate turns those detections into presence transitions. The state engine records what those transitions mean for Ash, and the behavior service emits an intent. Each boundary changes the meaning and timing of the data.

A confidence value is not certainty, as the jersey experiment showed. A service being active is not proof of fresh images. A recent processing timestamp is not proof of a recent source observation. These distinctions shape the remaining health-monitoring work.

A separate September 30 spatial observer used frame-level target arbitration and hysteretic horizontal zones. Its tested live role was advisory telemetry only. Offline continuity experiments were not promoted to physical identity tracking or actuator control.

Event contracts carry meaning across restarts

Perception transitions, state synchronization and state changes must remain distinct. Recovering a snapshot establishes context; it does not authorize replaying every side effect. The behavior consumer therefore filters synchronization events.

Native audio V1.6 adds runtime UUID plus sequence identity to AUDIO_TRANSCRIPT_READY. That helps distinguish observed events across restarts, but does not itself guarantee durable writes, acknowledgement, deduplication or exactly-once effects.

Atomic state-file replacement protects readers from a partially replaced snapshot in the implemented state path. It is not a blanket promise of power-loss durability for every file. Log-write checking for the native audio patch remains unrun in the retained evidence.

Voice architecture: recognition, knowledge, then delivery

A calm voice is the final presentation stage. Before it speaks, the system must decide whether the microphone contained speech, whether the transcript is plausible, what information is available and whether the reply belongs in history.

The accepted local output is Kokoro am_michael at 1.15 speed. The user approved its sound. The conversation stack remains under qualification, including source-backed weather/Eagles routing and clarification on ambiguous or non-speech input.

History should be committed only after input validation and the relevant response checks. The observed transcript-contamination failure is the practical reason for that ordering. Broader model judgment remains fallible; a separate reviewer is not proof of truth.

PC compute can shorten development iterations. The intended mobile architecture still centers on the Pi, so dependency on Windows playback, complete latency, speaker hardware and resource contention need explicit exit criteria before calling the robot independent.

Hardware roles and qualification boundaries

The documented bench stack uses the Pi 5 8 GB, active cooling, microSD storage, touch display, Camera Module 3 Wide and AI HAT+ with Hailo-8. The microphone and speaker options need to be judged by the exercised signal path, not their presence in inventory.

The mini USB microphone participated in voice capture. The I2S speaker bonnet and other audio equipment being available does not prove a finished output chain. Monitor-speaker audio remains unresolved in the current record. Future enclosure and mobile power decisions must account for the measured final stack.

The public implementation

The website build produces static routes from curated content. The journal and engineering archive have explicit publication status, escaped text and generated navigation. Drafts are excluded from the deployed pages, and withdrawn pages are removed on rebuild. Source-backed-up content is still restricted to public-ready material.

The Command Center uses a common animation timeline for coupled actions. CODD’s wheel position, tray height, arm pose and cup ownership must agree at pickup and return. Audio ownership follows the active scene and visitor sound preference.

DDS-01 will need a different kind of state: a weekly delivery slot, daily reply decisions, the latest unmentioned visit and recorded delivery outcomes. The design exists; those persistent behaviors are not running on this static website today.

The next integration gates

The project follows BUILD → TEST → VERIFY → ACCEPT → LOCK. Acceptance attaches to a specific result: the Michael voice was accepted; unrestricted conversation and autonomous mobility were not. A known-good baseline should be preserved while changing one uncertain behavior at a time.