• Learning PID controllers

    Gabriel • 08/13/2026 at 16:09 • 0 comments

    Small update this week, no printing, no hardware, but a chunk of learning I think is worth writing up because it changes how the control system actually gets built.

    I'd been saying "PID controller" for a couple posts without really understanding it, so I sat down with four different videos to actually learn it properly instead of just copy-pasting the equations.

    • Introduction to PID Control — the most useful one. Derives the control law (u = Kp·e + Ki·∫e dt + Kd·de/dt) and walks through P, I, and D one at a time using error-vs-time sketches. Also does a genuinely great physical demo: a weight hanging from a rubber band (proportional), a pink string being manually pulled to represent the integrator, and then dunking the setup in water and honey to show what increasing derivative damping actually looks like.
    • a shorter overview on terminology — gain vs. proportional band, integral units (repeats per minute etc), and the useful note that most real-world loops are just PI. Full PID and P-only show up sometimes, PD alone is rare. Also: most tuning in practice is trial and error, not some clean formula.
    • one on PID's history in industrial control, contrasting old-school ON/OFF ("bang-bang") control, like a home thermostat or a tank level that just oscillates around setpoint, with PID's ability to throttle continuously instead of just slamming on/off.
    • a terminology-focused one covering setpoint, process variable, control variable, and error, using a thermostat example and a gas-flow-through-a-pipe example.

    To make it stick, I built a tiny live simulation in Desmos using the ticker feature: a point chasing a target using a PID loop. Desmos graph demo

    Motion is smooth, no overshoot, but I'll be upfront: the gains in there are completely arbitrary. I haven't tuned P, I, or D against anything real, this was just to get the shape of the behavior right before I touch actual hardware.

    The control flow got simpler

    The bigger thing this week was redoing Handy's control flow diagram in Figma. The idea hasn't changed from my last post: a shared neural net producing gains, feeding five independent per-motor PID loops. But the old diagram was overcomplicated in a way that made it harder to build, not easier.

    Roughly how it reads: desired trajectory and the hand's current output get compared to produce an error signal. That error, plus some previous-state values, feeds a small neural net with a sigmoid hidden layer, which outputs Kp, Ki, and Kd. Those gains go into a PID controller along with the error, and the PID output is the torque sent to the hand. The hand's new output feeds back into both the error comparison and the previous-state block, closing the loop.

    That loop runs five times, once per finger. (The diagram currently says x9 in a couple spots, that's a labeling mistake, it should say x5.)

    Next step is actually tuning the gains instead of eyeballing them, probably back in the Desmos sandbox before it touches real hardware.

  • Handy: Building a Robotic Hand from Scratch (Part 1)

    Gabriel • 08/10/2026 at 23:11 • 0 comments

    If you're just joining, here's the short version: Handy is a tendon-driven, fully 3D-printed robotic hand I'm building from scratch. This post covers what it is, why it's built the way it is, and where things stand right now.

    What it is

    Handy is loosely based on the InMoov v2/i2 hand. I started from that design as a reference, then reworked the joints and drive mechanism instead of printing it stock. Each finger closes when a length of fishing line, standing in for a tendon, gets wound in by a small winch motor. Slack the line and an elastic band pulls the finger back open. Same basic mechanics as your own hand, just fishing line instead of flexor tendons and a servo instead of a forearm muscle.

    Why it's built this way

    Cost efficiency is the constraint everything else answers to. Tendon-driven over direct-drive, elastic return instead of extension springs, fishing line instead of purpose-built cabling, SG90 servos I already had instead of buying something better suited to the job, all the same reasoning. It's also why the motor and joint setup keeps changing. I'm finding out what the cheap parts can and can't do as I go.

    Two things it needs to do

    1. Roll a coin across the knuckles: four fingers lifting and dropping it in sequence, timed so it doesn't fall off.
    2. Sign in ASL: distinct, recognizable letter shapes, not just open and closed.

    Both need tighter per-finger control than a basic gripper, which is most of why the control system is getting as much attention as the mechanical build. I'm going to mainly focus on point #1, because I think its a good challenge.

    Where it stands

    Two tracks running in parallel right now. On the mechanical side, the hand is rigged in Blender. Nothing's been printed yet for this version. I wanted the joints and drive mechanism right in simulation first. On the control side, the rigged model exports into MuJoCo and runs through Gymnasium, where I'm building out reinforcement learning to actually drive the hand. Each finger gets its own motor and its own control loop, with a neural network on top tuning those loops rather than driving the fingers directly. More on that later.