Almost everything that went wrong on this robot looked like a software bug, and almost none of it was.
A servo mounted mirrored, so "plant both feet" put one leg down and pulled the other up. Two data pins swapped, so an audio chip accepted every command and stayed silent. A buck converter whose own display read 6 volts while it delivered 9.7 into servos rated for less. Every one of those was invisible from the code, and every one of them cost days.
So I stopped trusting what the code said should be happening and started measuring what was. Most of my debugging now begins by building a small tool that answers one question — which direction did that servo actually move, what voltage is actually on that rail, is that chip actually receiving anything — before I change a single line.
The gait took eleven attempts because the first ten were fixing the wrong thing.
They all planted the feet in front of the body, and every one toppled backward. I kept tuning the timings, the speeds, the travel — dozens of parameter sweeps against geometry that could never work. The eleventh version came from moving the frame with my hands until I understood what it needed, then writing that down: the feet never go in front. Five beats. It walked.
I'm self-taught and I build the whole thing — CAD, printing, wiring, power, firmware, the services behind it, the network between them. Nobody hands me a working subsystem, which means when something breaks there's no one else to ask. That turns out to be the fastest way to learn anything.
One robot, built end to end.
Every subsystem measured on hardware.
Two boards, four servos, no IMU and a five-beat cycle — plotted from the same numbers driving the model above.
The actual gait, plotted from the same values driving the model above. Forward travel happens only during CARRY, when the planted legs rake backward — that beat is the entire propulsion mechanism.
A gait designed by hand
Five beats, no IMU, no active balance. Stability comes from where the feet are, not from correcting after the fact.
It sees and it listens
A camera for person detection, a codec driving both a microphone and a speaker, and a listener that keeps a rolling buffer so the first word of a sentence survives.
Everything runs at home
Speech recognition, the language model, routing and home control all run on a desktop in my room. Nothing about how it listens leaves the house.
It talks in my best friend's voice. He recorded it for me before he moved away.
The service behind the robot is named after him. When I told him what I was building he sent forty seconds of himself talking — half of it him laughing about being cloned — and that recording is what it speaks with now.
It greets me the way he does. "Hello sor" — sir, pronounced wrong on purpose, an old joke between us. It says "wallahi why not" when it agrees with something. Getting that right mattered more to me than the gait did.
Forty seconds is not much to work with. Local voice models truncate the reference at twelve seconds while still using the whole transcript, so the clone ends up mapping four times more words than it can actually hear. Finding that out took a night. Which eleven seconds you choose matters more than which model you use.
Frequently
asked questions
What people actually ask, answered without hedging.
Did you design the gait yourself?
Yes, and it took eleven attempts. The first ten came from reasoning about it on paper and all of them toppled backward. The one that works came from moving the chassis by hand until I understood what it actually needed, then writing that down as five beats.
How much of it is off the shelf?
The boards, servos, camera and codec are off the shelf — an ESP32-S3, MG996R servos, an OV5640, an ES8311. Everything else isn't: the chassis is my own CAD, the firmware on both boards is mine, the gait is mine, and the service tying it together is mine.
I use existing models for speech recognition and the language model. I didn't train those and I wouldn't claim to have.
Does it really use your friend's voice?
Yes. He recorded about forty seconds specifically for it after I told him what I was building. The service is named after him.
What was the hardest part?
Not the gait, and not the speech — it was the class of bug where everything reports success and nothing happens. An audio codec that accepted thirty configuration writes and stayed silent for a whole session, because two data pins were reversed. The control bus was fine, so every log line said it worked.
That taught me the most useful thing I know: an acknowledgement proves a chip heard you, not that anything is working.
What's next?
A dock it charges from, so it stops running its battery down. Then having it recognise me and walk over, which needs the gait to be more reliable than it currently is. After that, whatever the next robot turns out to be.
Are you available?
I'm looking for an internship. I'm still studying, so I'm flexible about hours, and I'd rather work on something hard than something comfortable.