Test the hardware
before adding AI

CURRENT SOFTWARE DIRECTION · 3 OCTOBER 2026 PLAN

A private stationary control app is the next software release

This public website is the guide, not a live robot controller. The proposed app runs on the Pi and still needs implementation, a reviewed installer and real acceptance tests.

1. Preserve and inventory first. Identify the actual Pi, boot card, OS, supply, cooling and received audio/camera revisions. Keep a checked rollback copy; do not overwrite a working card to match a guide. Verify packages against the selected 64-bit Raspberry Pi OS image.
2. Qualify the Lite adapter locally. Measure actual device identity, capture/playback formats and channel roles. Validate resampling between device and cloud formats; no automatic fallback to another microphone and no relabeling samples as conversion.
3. Build one deliberate interaction at a time. Talk, Cancel, Take photo and Send this photo need honest device/network status. Show a timestamped local photo preview before sending that one selected image. No background photography, replayed media or motion tools.
4. Make AUDIO OFF complete. Removing the sole USB link cancels capture, playback and the active cloud turn, clears unsent buffers and never switches input. Replugging requires deliberate restart.
5. Keep first controls local. Begin on the Pi's loopback interface. Mac access through an existing approved SSH tunnel, and later phone/private-network access, require their own authentication and access review. Do not expose an unauthenticated control port.
6. Ship a real versioned release. Include pinned dependencies, a checksum manifest, offline tests, bounded media buffers, manual launch instructions and rollback. Check the current cloud model/API contract and account availability at implementation time. Start idle with no automatic capture, paid cloud turn or drive authority.

The older R2 terminal voice prototype remains preserved. Mocked unit tests establish only bounded software logic; they do not establish a Pi installation, Lite compatibility, camera integration or live cloud acceptance.

What software exists, and what needs fixing

The archived prototype already has an Enter-to-talk terminal interface, typed questions, cloud transcription/replies/speech, a local audio test, unique-device selection and no motion tools. Its 11 mocked unit tests were rerun successfully on 2 October 2026. This verifies bounded software logic, not a Pi installation or live service.

1. Enumerate the actual Lite input/output formats on the Pi. Keep unique-device selection and no automatic fallback to another microphone.
2. Adapt channel selection and sample-rate conversion to the measured formats. Convert the prototype’s 24 kHz speech audio to supported output, or explicitly configure and test a converting audio layer. Do not relabel 24 kHz samples as 16 kHz: that changes speed and pitch.
3. Pass local recording/playback and AUDIO OFF tests with the adapted app before configuring cloud access. Keep optional lighting disabled; the later motor Pico is separate.
4. Add a separate deliberate “Take photo” action. Show the local preview and ask before sending that selected image. Camera capture, image submission and shutter-state handling are not implemented in the old voice app.
5. Then qualify one voice turn and one chosen-image question, plus USB removal, cloud failure, network loss and restart. Start stopped; never replay queued audio or pictures automatically.

First controls can use the Pi’s existing keyboard and display. No new button, screen, LED controller, wake-word service or motor hardware is required for this initial software milestone.

Lite formats and official USB test · Full design review

Local audio test

Use the existing working Raspberry Pi OS desktop. Do not overwrite the Pi’s card. If the Pi does not already boot and have a usable desktop, settle that setup first.

1. Finish the power-off inspection in assembly step 5. Connect the correct existing Pi supply when you are ready to test. Leave motors and batteries disconnected.
2. Open the desktop sound controls. Select ReSpeaker Lite for output and microphone input. Start output volume low, around 10%.
3. Use Audacity if already installed. Otherwise install the Debian package from Raspberry Pi OS with sudo apt install audacity. This is a later local installation instruction, not an action performed here.
4. In Audacity, choose the ALSA audio host, ReSpeaker Lite recording device, 2 recording channels and 16000 Hz project sample rate. Choose Lite playback output.
5. Press Record, say “MORLOK audio test” for five seconds, then press Stop. Press Play. You should hear your own voice through the enclosed speaker.
6. Stop playback and recording. Unplug the labeled AUDIO OFF USB-A plug from the Pi. Lite should disappear from the available devices; a new Lite recording/playback must fail. It should not silently switch to a different microphone.

If it fails: check the selected input/output, cable data capability and empty 3.5 mm jack. Reseat the speaker only with power disconnected. Inspect firmware identity before considering a separate firmware update. Do not copy I2S/XIAO instructions into this USB-only setup.

Expected result: clear recorded speech, low-volume playback, and complete audio loss when the sole USB connection is removed. Record the result as pass/fail; it is currently untested.

Source: Seeed USB recording guide. Its screenshots use Windows; ALSA is the Linux host on Raspberry Pi OS.

Local camera test

1. Shut down and unplug Pi power before attaching or reseating the camera ribbon. Finish assembly steps 6–7 and support the camera securely.
2. When ready, power the Pi and open Terminal. Enter rpicam-hello --list-cameras. Expected: one detected Camera Module 3 / IMX708 camera.
3. Point at a non-sensitive object. Enter rpicam-still --timeout 2000 -o morlok-open.jpg. Open the saved file in the current Terminal folder and confirm a clear picture.
4. Place an opaque cover in front of the lens without touching it. Enter rpicam-still --timeout 2000 -o morlok-covered.jpg. Compare both files. The covered image must show no recognizable scene, including under bright light. Keep the cover closed between intentional pictures. These local files remain on the Pi until you remove them.

If it fails: check current Raspberry Pi OS camera tools. A “no cameras available” result requires shutdown and an unpowered ribbon/connector check. Do not enable legacy camera mode or hot-plug the ribbon.

Source: Raspberry Pi camera software documentation

Then make it answer

The recommended next application has one deliberate talk control and one deliberate photo control, obvious recording status, low-volume output, and no motion tools. Test microphone/speaker sample formats on the real device before connecting an AI service.

Cloud AI needs separate account setup, secure credentials and billing. It may transmit selected audio or pictures; the local tests above do not. A ChatGPT subscription, this site and a phone voice call do not automatically install or connect the Pi application.

Read the preserved software architecture, offline behavior and acceptance tests

Four checks finish the local bench

1. A five-second local recording plays clearly at low volume, without clipping or repeated audio dropouts.
2. Unplugging the sole AUDIO OFF connection removes Lite. Recording and playback stop without choosing another input.
3. The camera gives one clear picture and a separate covered-lens picture with no recognizable scene.
4. The Pi remains stable with its current cooling and supply. Log any power warning, USB reset, fan obstruction or thermal throttling and resolve it before enclosing the kit.

Record date, exact part/revision, OS version, selected device/formats and pass/fail. All physical outcomes remain NOT RUN until actually observed. A working local bench does not yet prove AI conversation.