Why
I bought the ProtoBot and it's awesome. The long game is building a small quadruped for my niece, and this seemed like a good starting point to get situated with robotics, remote control, custom firmware, and ML for robots. All of it was new to me.
How I went about it
The robot sat on my desk, with a browser dashboard for eyes and an AI coding agent in a terminal on the same machine. I release the robot, every run auto-saves its full telemetry, the AI reads the traces and changes the firmware, and I flash and release again. Dozens of cycles a day. Training ran on the same machine, PPO in a simulator, CPU only, about 30 minutes per policy generation. On method, full disclosure: I set the goals, ran every experiment, judged behavior on the desk, and did the physical measurements. The AI wrote most of the code, did the math, and briefed me on the theory as we went.
Eyes first
First lesson of the weekend: you can't debug a robot you can't see. We built 50 Hz telemetry over Bluetooth into a browser dashboard, with live charts, a pose view, tunable parameters, and every run archived with its exact settings. My favorite accidental lesson is that my desktop's Bluetooth dongle shipped with the antenna unscrewed. The link was weak and dropping for a day. Now I know what the antenna is for.
The classical ceiling
I now know what kp even is, and the key intuition of this robot: it reacts 20-25 ms late, measured. Pushing harder means overshooting harder, and past kp of about 8 the loop rings at 5 Hz no matter what. Careful tuning still got us far. Pulse-density modulation let us command torque below the motors' dead zone, and a modeled wheel speed stood in for the encoder the robot does not have. That model was the load-bearing trick. My favorite experiment found the true balance point, which sits about half a degree off vertical from mass asymmetry. We ran two setpoints and interpolated the zero-drift point between them.
The robot measures itself
Every constant we guessed was wrong, so we made the robot do the guessing. The firmware grew a 25-second self-test bench that measures its own dead zone, lag, torque curve, battery sag, and fall speed. Surprising findings: warm motors lose 20-25% of their torque, and a warm robot falls slower than theory says because the tire contact patch acts as a soft spring.
A 1.2 KB brain
A tiny network trained in simulation balances the real robot for 60+ seconds, drives over a cable and recovers, and works upside-down, a pose it saw in only 20% of training. Inference takes 2.7 ms on a chip with no floating-point unit. The simulator had to be honest first. One generation trained on motors 3x too weak and learned bang-bang violence. Another trained on rigid tires and wobbled itself to death. The fix that stuck was a calibration gate. Training refuses to start unless the sim reproduces the measured torque curve and fall speed. A sim transfers exactly what you calibrated, nothing more.
What the network taught me
My favorite result. A plain linear regression over the policy's own good runs explains almost everything it does near upright, and the readout doubles as a review of my hand tuning. It rediscovered my error gain, doubled my damping, invented a command-memory term to fight its own delay, and used wheel speed with the opposite sign to mine. Refitted without extra sensors, that law fits in about 20 stock-shaped lines of firmware, which I hope to suggest upstream. This was the most fun I've had with anything on wheels.