Assembling the SunFounder PiDog

The robot hit the floor before I finished building it.

I was routing a wire through the chassis when the whole assembly slid off the table. The PiDog landed hard enough to shear the plastic spacers holding the body together. I sat there for a moment looking at a partially built robot and a pile of small plastic pieces, then ordered M2 screws and nuts online and kept going.

That moment tells you more about hardware builds than any getting-started guide does.

What I am building and why

Nymbra is my personal AI robot dog project, built on the SunFounder PiDog kit and a Raspberry Pi. I am documenting the full build publicly on GitHub and Hashnode. The goal is to learn how to program a physical AI system from the ground up, using Claude to help me understand the code as I write it.

I write documentation for a living. I have spent seven years writing API references, user guides, and governance policies for enterprise SaaS products. Building something with my hands, then writing about it, is a different kind of documentation challenge. I wanted to understand that difference firsthand.

Robot dog vs PC tower

This is my second hardware build. My first was a PC tower, and I went in expecting a similar experience.

Building a PC tower is mostly a matter of following a sequence. The parts are large, the connectors are keyed so you cannot plug them in wrong, and the tolerances are forgiving. You can reseat a RAM stick six times and nothing breaks.

The PiDog is not like that.

The kit has 12 servos, 2 per leg, 1 for tail, and 3 for the head. Each servo connects to the control board with a small wire and a three-pin connector. After the robot fell and I replaced the spacers, I had to reattach every leg wire carefully. Twelve connections, each one requiring you to hold a small connector, align three pins, and seat it without bending anything. The chassis is compact. Your fingers do not fit comfortably in the spaces you need them.

The bigger challenge is precision. A PC tower either boots or it does not. A robot dog can power on and still be completely wrong. If a servo is even slightly off its neutral position during calibration, the leg sits at the wrong angle. The whole gait goes wrong from there. You do not know something is misaligned until the robot tries to move and lists sideways like a boat taking on water. When I turned on the robot and pressed the "Zero" button, one of the legs kicked upwards.

Getting each leg zeroed correctly takes patience. You cannot rush it.

The documentation problem

I am currently working through the calibration step, following the SunFounder module installation guide. Getting to this step required me to read through a document that conflates three distinct user scenarios into one set of instructions.

The guide covers PiDog version 1 owners, PiDog version 2 owners, and a set of module installation steps that apply to both. It presents all of this as a single flow. Some steps apply only to version 1. Some apply only to version 2. The guide does not always tell you which is which before asking you to do something. And if it does, it's posted as a note at the end of the page. By then you have already run the command.

This is a content architecture problem. The information exists. The organization does not serve the reader.

A technical writer looking at this guide would restructure it into three documents. The first document covers module installation for PiDog version 1. The second covers module installation for PiDog version 2. The third covers any shared steps that apply regardless of version. Each document opens with a clear statement of which hardware it applies to, so a reader knows in the first ten seconds whether they are in the right place.

The current guide asks the reader to carry version awareness themselves throughout the entire process. That is unnecessary cognitive load. When instructions say "run this command" without specifying which version it applies to, users run it on hardware it was not designed for and spend time debugging a problem the documentation created.

I have hit this twice. Both times I traced the confusion back to a version-specific step that was not labeled as such. Both times I lost twenty minutes.

I am not frustrated by this. I recognize it because I have written guides that made the same mistake. When you are close to a product, universal instructions feel safe. They seem to reduce duplication. What they actually do is transfer the disambiguation work from the writer to every reader, every time.

Where I am now

I am running the module installation scripts from the SunFounder documentation. The calibration step requires setting each servo to its neutral position before anything moves. The process involves running a script, observing where each leg sits, and adjusting until the angles match the reference position in the guide.

It is slower than I expected. Each leg needs to be checked individually. If a servo is off by more than a few degrees, the gait script will not produce clean movement. I am treating this as a documentation task as much as a technical one: observe the current state, compare it to the spec, adjust, and verify.

Nothing is walking yet. That is fine. Getting the zeroing right now saves significant debugging time later.

What hardware builds teach you

Documentation describes a process. Hardware is the process.

When I write a software guide, I can verify steps by running them in a test environment. If a step is wrong, I catch it before a user does. Hardware does not work that way. The robot fell. The spacers broke. I found M2 screws online, rebuilt the section, and reattached twelve servo wires one at a time.

You cannot document your way out of that. You have to do it.

The SunFounder guide will eventually get me to a walking robot. The gaps in it have already taught me something about where version-specific documentation fails. I am taking notes on both.