Voice, character and a public engineering surface

The website is a separate runtime

The public journal and Command Center became a place to show the project’s character and selected engineering progress. The static site generates its journal pages from curated content, excludes drafts and removes withdrawn generated pages. The source book, raw test evidence and private connection details stay outside the public deployment.

The browser animation is not a remote console for the Raspberry Pi. Its scenes, character poses and visitor controls run in the visitor’s browser. A coffee visit on the website does not mean a physical robot delivered coffee, and the approved voice is not automatically a live web conversation service.

Engineer’s Corner adds a technical reading layer to that website. The narrative Weekly Posts remain their own section; these engineering reports preserve the mechanisms, measurements and unfinished interfaces behind the stories.

Bench work still matters

Soldering practice exposed a practical technique problem: solder was initially slow to melt, followed by too much solder on the work. Snips and wire-to-pad practice were the next direction. This was training, not qualification of a finished electrical joint or production wiring harness.

Display/touch recovery included changing the touch connection and recovering a blank/static display. The user reported the interface working afterward. A system-update session was interrupted and later completed with a reported reboot; the record included 54 upgrades and no package additions or removals. Monitor-speaker output remained unresolved, with absent audio capability information in the observed display path.

The control connection also affected development. Wi-Fi observations included five-to-ten-second terminal delays, about 123 ms average ping and loss. A twenty-sample Ethernet check averaged about 45 ms with no loss, and the user reported the lag gone. That supported using the wired bench connection; it was not a universal network-performance benchmark.

A sequential conversation path

The demonstrated early conversation path captured USB microphone input, transcribed speech locally, generated a local model reply on the Pi, synthesized speech, then played the result on Windows before accepting the next turn. The three-turn launcher carried session context and began a fresh context on a new launch.

This was a bounded, sequential loop. It did not establish always-on listening, interruption while speaking, echo cancellation or durable personal memory. The Hailo vision accelerator did not provide the Pi language model’s CPU inference.

A smaller Qwen 1.7B trial generated around 7.9–8.1 tokens per second versus roughly 3.4–3.7 for the 4B trial in the recorded conditions. Those figures helped investigate responsiveness, but output length, context and setup prevent treating them as a general product ranking.

Fast replies need a boundary around knowledge

The user’s preference was fast replies with honest limits. Conversation examples included daily life, meditation, ideas, weather and the Philadelphia Eagles. Tests found unsupported claims about prior conversations and other invented details. Larger models and reviewer passes did not remove that problem; reviewers could also approve faulty answers.

The safer demonstrated approach was narrower routing for selected facts: a weather path using National Weather Service information, an Eagles path using the official schedule, a small set of science facts and self-description, and explicit handling for absent history. These routes do not make unrestricted model conversation truthful.

A vocabulary hint helped one name but a later expanded hint coincided with repeated unwanted text. The cause was not conclusively established. Once an incorrect transcript entered the history, it could contaminate later turns. The recovery baseline restored the earlier prompt and disabled the expanded hint.

One repetition filter rejected transcripts of at least twelve tokens when a token appeared at least eight times and occupied at least sixty percent of the text. That is a narrow heuristic, not a complete hallucination detector; intentional repetition can also meet it. The important processing rule was to reject suspect input before inference and before committing it to conversation history.

The accepted voice: Michael, a little faster

The user rejected stiff, robotic samples and asked for a calm, smooth, conversational voice with a subtle New Jersey / Philadelphia feeling. An external reference helped establish the desired tone, but the accepted local choice was Kokoro am_michael. It was not a clone of the reference voice.

Listening iterations increased the speed until the user accepted 1.15 and described the voice as perfect. That superseded the earlier 1.10 checkpoint. The chosen voice runs locally without a separate voice-service subscription.

An uncached Pi synthesis check took about 4.95 seconds to generate a 4.66-second reply. That is synthesis time, not a complete listening-to-speaking result. A prompt-order comparison reduced one Pi follow-up from about 40.92 to 15.09 seconds before speech synthesis. Warm PC examples around 2.86, 1.53 and 1.95 seconds used different replies and conditions; they were useful development observations, not a controlled Pi-versus-PC benchmark.

The architectural direction remains a mobile Raspberry Pi unit. PC compute is useful for development and comparison while a fully independent Pi conversation experience still needs qualification. Voice preference acceptance and whole-system readiness are separate milestones.

Live testing found failures that scripted tests missed

A live weather turn returned a supported forecast, with roughly 21.70 seconds from listening start to a ready audio file. In the same testing work, a misrecognized Eagles request missed its intended route, and throat clearing received an inappropriate conversational response.

Repairs made annotation-only/non-speech input request clarification without adding it to history. An ambiguous Eagles phrase asked for clarification, and a clear replay used the official-source path. The live Eagles microphone retest remained pending; a replay pass did not close that item.

The recorded full Pi suite passed 139 checks before later focused non-speech and Eagles checks. Those later groups were not silently added into a new whole-suite total. Tests of deterministic handling do not prove that the open-ended model will always be accurate.

An eight-second human speech comparison was also instructive. Whisper tiny took about 0.936 seconds and preserved the reference wording with punctuation differences; base took about 2.245 seconds and introduced duplicated/joined words. This was one sample in a separate capture harness, including model loading, not the native VAD pipeline or a general accuracy study. It supported keeping the current default while gathering more examples.

CODD: contact, reach and cup ownership

The service droid became CODD: Coffee On Demand Droid. Its browser visit needed more than moving a cup near Ash. The wheels originally appeared to cross Ash’s paw, and the reach created a stretched sleeve and an unnatural wrist pivot.

The revised choreography parks the wheels clear of Ash’s feet, raises and extends the tray toward the nearest paw, then uses controlled upper-arm/forearm angles and a small head lean for the sip. Separate rigid sleeve pieces overlap around a rounded elbow. This avoids treating the whole arm as a stretchable strip or the wrist as a freely spinning hinge.

Cup ownership is explicit: tray-supported before pickup, hand-held during lift and sip, then tray-supported again only after the return reaches its support point. Paw release precedes tray lowering and departure. A shared timeline keeps pause and replay consistent across the droid, tray, arm and cup.

This is authored browser choreography using the accepted character artwork. It is not inverse-kinematics qualification for a physical arm, nor evidence of a constructed mobile coffee droid.

DDS-01 and Bishop: a design with state rules

DDS-01 is a separate autonomous character: a blue mailbox on treads with expressive eyes. Its behavior is patient and non-hostile under the project’s PMA direction. Bishop’s cheerful letters belong to the fictional world and can reference CODD and the Unknown Engineer without claiming real telemetry.

The incoming-letter policy allows one delivery each week: a twenty-five-percent Monday attempt; if none, a twenty-five-percent Wednesday attempt; and Friday delivery if the week still has none. Saturday and Sunday each provide an independent fifty-percent chance for Ash to initiate a reply while DDS is off regular duty.

Visit notices use latest-location-wins semantics. A new location replaces an older unmentioned visit. When a letter consumes a visit notice, it must clear only the matching notice so a newer visit arriving during composition is not accidentally erased. If there is no new visit, Bishop can offer a gentle vacation reminder.

The design calls for event identity, actors, correlation, sampled chances, outcomes and persisted scheduling slots. A missed Friday during an outage must not be logged as a completed delivery. Clock/timezone behavior, restart recovery and duplicate prevention still need implementation and tests. The correspondence system remains design-only.

Appearance update, October 12: the current DDS direction is white-and-orange and wheeled. The blue tracked mailbox above is the earlier dated design, preserved here as history. Production scheduling and integration remain open.

Ambient sound follows scene ownership

Six destinations gained locally hosted ambient recordings: London at dusk, Paris at night, Grand Canyon at sunset, Colorado alpine lake, Niagara Falls on the Canadian side and Malta’s Grand Harbour. The recordings use documented CC0 or attribution licensing. The canyon wind and alpine-lake sound are representative ambience rather than a claim that every recording was made at the exact displayed viewpoint.

The browser audio path accounts for the visitor’s initial sound gesture, volume, scene changes, looping/crossfading, hidden-page pause and preference restoration. Scene changes must release the previous sound so multiple locations do not keep playing together.

The first London choice contained audible speech and the user rejected it. It was replaced with Thames beach ambience. A speech-recognition check found no spoken words in the replacement; that is narrower evidence than a listener’s final acceptance of the entire soundscape.

What remains after this week

The accepted voice and the demonstrated routes are useful building blocks. The next conversation work needs real microphone retests, broader recognition examples, trustworthy handling of uncertain input and measured full-turn latency. The Pi target still needs its final local playback path qualified.

The engineering backlog also retains fresh-frame health, storage failure handling, service endurance, recovery proof and unqualified camera modes. DDS-01 needs implementation. Mobility, electrical/mechanical integration and any physical coffee interaction remain future work. This report closes at October 10; it does not pre-fill the rest of the calendar week.