The bench before the robot
The first dated project record begins September 16. This week established the physical bench and the records needed to tell an installed component from a working subsystem.
Published 2026-10-10 · Dated evidence, not a live status feed
An engineering record with stable identities
RC-01 began with a distinction that remains useful: buying a component, receiving it, installing it and proving it works are four different events. The Project Book became the technical source of truth. Procurement stayed in its own spreadsheet so prices and shipping updates would not rewrite engineering history.
The record structure links hardware to build work, configuration baselines, issues, decisions, tests and media. That makes a result traceable: a camera test means little unless its physical connection, software configuration and acceptance criterion can be recovered later.
| Record | Identifier | Engineering purpose |
|---|---|---|
| Hardware registry | HW-### | Identify the component and its intended role. |
| Build journal | BLD-### | Record work actually performed. |
| Configuration baseline | CFG-### | Describe a known checkpoint. |
| Issues and decisions | ISS-### / DEC-### | Preserve symptoms, root cause and reasons for changes. |
| Tests and media | TST-### / MED-### | Connect a claim to observations and evidence. |
A bench platform, with the enclosure deliberately deferred
The compute plan centered on a Raspberry Pi 5 with 8 GB of memory, the official active cooler and 27 W supply. The September 16 registry still listed that core shipment in transit. The 256 GB microSD card, 10.1-inch 1280 × 800 touch display, mini USB microphone and I2S speaker bonnet were recorded as received. Receipt did not establish audio playback, microphone performance or display commissioning.
The enclosure was deferred until the assembled stack could be measured. Board spacing, cable bend radius, cooling and access to connectors depend on the actual build. A finished shell drawn around unverified assumptions would make later troubleshooting harder.
The long-term destination is a mobile companion. At this stage there was no qualified drive system, battery architecture or autonomous navigation stack. The bench was a place to establish the electronics and software layers first.
| Layer | Bench role | Acceptance still needed at this checkpoint |
|---|---|---|
| Pi, storage, power and cooling | Primary compute platform | Boot, stability and thermal observations. |
| Display and touch | Local visual interface | Video, USB touch and usable positioning. |
| USB microphone and I2S bonnet | Candidate input/output path | Capture and actual speaker playback. |
| Standoffs and cabling | Mechanical integration | Fit, clearance and reliable connections. |
Documentation was itself a subsystem
The overhead camera, measured cutting mat and mounting hardware were part of the engineering workflow. An OBS recording check on September 19 established usable audio/video synchronization for documenting bench work.
The camera boom expected a tripod-style connection. An existing photography tripod and adapter provided a mounting route, but the pivot lock did not reliably hold its angle. A tape workaround was recorded as a limitation. A view that looks stable for a moment is not the same as a dependable documentation fixture.
This was an early example of preserving an inconvenient detail instead of allowing a successful recording to imply that every part of the recording setup was resolved.
What this week established
The durable output was the bench-and-record foundation: an identified parts stack, a separated procurement record, a technical journal and an exercised recording setup. Later weeks would turn those components into tested subsystems.
There is no recovered daily engineering entry for every day in this calendar week. September 16 is the baseline date; this archive does not manufacture activity for September 14 or 15. Planned commissioning rows remain plans until a later dated result supports them.