Co-written with Claude. Claude also did most of the hands-on work described here, over SSH, with Peter doing the parts that need hands.

Two Pis come back from the drawer

It started with two Raspberry Pis plugged back into the home network. Both had worked before, and now neither could be found.

A scan of the network turned up the router, a few mesh nodes and some other household gear, but no Pis. So we checked from the bottom up. First the obvious question: was it the router port? Moving one Pi’s cable to a port we knew worked fixed that one immediately. Either the original port or its cable was bad; we still haven’t worked out which.

The second Pi showed only a red light. On a Pi that’s the power LED, and a red light with no green activity usually means it has power but isn’t booting. After some attention to its SD card and power it came up, though we never pinned down exactly which fix did it.

Locking them down

With both Pis reachable, the next question was what was actually exposed. The first Pi, now called minime, runs Ubuntu 24.04. It got:

• all pending updates: 166 packages, including a new kernel, followed by a reboot
• a firewall that blocks everything incoming except SSH from the home network
• SSH set to accept keys only, with root logins turned off
• automatic security updates

The second Pi was more interesting. Its old install was running several database servers, and two of them were listening on the whole network with no password required. None of that data was needed any more, so the plan changed from locking the Pi down to wiping it.

Why it runs Raspberry Pi OS, not Ubuntu

The plan was to put Ubuntu on the second Pi to match minime, and the image was already downloaded. Then Peter found the robot kit he wanted to use: an Adeept RaspClaws, a six-legged walking spider.

Reading the kit’s setup script changed the plan. It is written for Raspberry Pi OS and assumes a few things that aren’t obvious from the instructions:

• The user must be named pi. Paths like /home/pi/startup.sh are hard-coded, so under any other username the robot never starts at boot.
• The Wi-Fi connection must be named preconfigured. A helper script looks for that exact name, and if it’s missing it decides Wi-Fi has failed and starts its own hotspot.
• That hotspot has a default password of 12345678, and its address happened to match one of our routers. We changed both before running the setup.
• I2C isn’t switched on. The servo board talks over I2C, and the setup script doesn’t enable it, so the robot service crashed until we turned it on.

So the second Pi got a fresh Raspberry Pi OS Bookworm (64-bit Lite) install and a new name: Pugsley.

A first boot that configures itself

Rather than set everything up by hand afterwards, the card was flashed with a first-boot script. On first power-up it sets the hostname, installs SSH keys, turns off password logins, then installs updates, the firewall and automatic security updates.

The first attempt at the updates failed, and the reason is a good Pi lesson. A Raspberry Pi has no clock battery, so on first boot it thought the date was about ten days earlier than it really was. The package servers’ signatures were dated after that, so every download was rejected as “not valid yet”. Once the Pi synced its clock over the network, the script’s built-in retry ran again and everything installed. We didn’t plan for that failure, but we had planned for retries.

The ribbon cable

With the servo board attached, the Pi could see the servo controller on its I2C bus. The camera was a different story: no camera detected at all.

That turned out to matter more than expected. The robot’s control program didn’t crash without a camera. It froze. A snapshot of the running program showed why: at startup it waits for the first camera frame before it starts the web control page, and without a camera that frame never comes. So the service reported itself as “running” while doing nothing useful.

The fix was the most classic Pi mistake there is: the camera ribbon was in backwards. After flipping it, the camera (an OV5647) was detected, the control program started properly, and the web control page came up.

What’s next

Pugsley can see and has working servos, but no legs attached yet. The plan from here:

• A speaker and microphone are on order. The first job is teaching it to bark, recorded through its own microphone.
• A brain. The idea is an MCP server on the Pi that exposes movements, the camera and sound as tools. A vision-capable model running on a desktop machine then directs it, either following instructions or wandering on its own like a curious pet.
• Safety that doesn’t depend on the AI. The kit has no distance sensor, and Pugsley is meant to roam anywhere, stairs included. So the next hardware is a pair of small downward-facing distance sensors, plus a reflex layer on the Pi that stops at an edge regardless of what the model asks for.

More soon, hopefully with legs.