Jordan Reyes

Day in the Life

The lab smells like solder and coffee. Jordan Reyes has a prosthetic forearm clamped to the bench — not a mannequin’s, a real one, built for a client named Marcus who lost his arm in a construction accident two years ago. Today is fitting day three. Something’s still wrong: when Marcus tries to pick up a paper cup, the hand either crushes it or doesn’t grip at all.

Jordan pulls up the live sensor feed: six tiny force sensors in the fingertips, a motor current sensor at each joint, a control loop running a thousand times per second trying to turn “a little bit of muscle signal” into “exactly the right amount of grip force.” Right now the loop is overshooting — senses the cup, slams the grip shut, panics, opens back up, overcorrects again.

A classic feedback oscillation. She’s seen it a hundred times. She’ll fix it in five minutes.

She doesn’t reach for a soldering iron. She reaches for three numbers — gains in the hand’s control software — and starts tuning. Turn down the aggressiveness. Add a touch of “anticipation” so the hand eases off before it overshoots. Test.

Marcus picks up the cup. It wobbles, but it holds. He picks up a second cup, then an egg — a real one, Jordan’s idea of a stress test — and this time the egg survives.

“That’s it,” Jordan says, already typing notes for the next iteration. “Now let’s get you picking up a coffee mug while it’s full.”

Down the hall, a very different robot — a four-legged inspection bot the size of a large dog — is doing laps around an obstacle course, recovering every time Jordan’s intern gives it a shove. By day’s end, Jordan has touched code that’ll help someone hold their kid’s hand again, and code that’ll help a robot climb over rubble after an earthquake. Same toolbox. Same feedback loops. Wildly different stakes — she loves both.

The Science

Feedback control — the heartbeat of every robot

Almost every robot, from a robotic arm to a self-balancing scooter, runs on a feedback loop: measure what’s actually happening (sensors), compare it to what should be happening (the goal), and adjust (actuators) to close the gap — over and over, often hundreds or thousands of times per second.

A very common way to compute that adjustment is a PID controller — Proportional, Integral, Derivative:

• Proportional (P) — push harder the further you are from the goal.
• Integral (I) — if you’ve been consistently a little off for a while, push a bit harder to fix that lingering error.
• Derivative (D) — look at how fast the error is changing, and ease off early if you’re closing in too quickly (this is what fixes the “overshoot and oscillate” problem Jordan saw with Marcus’s hand).

Torque, force, and why “more power” isn’t always the answer

A motor’s torque is its rotational “twisting force” — and the amount of torque needed at a joint depends on the load and the distance from the joint (the lever arm). A prosthetic finger gripping an egg needs to apply just a few newtons of force, precisely controlled — too little and the egg slips, too much and it cracks. Engineers have to choose motors and gearing that can deliver a wide range of force accurately, not just a lot of force.

Kinematics — describing how things move

Kinematics is the branch of mechanics that describes motion — position, velocity, and acceleration — without worrying yet about the forces that cause it. For a robotic arm, forward kinematics answers “if each joint is at this angle, where does my hand end up?” and inverse kinematics answers the harder question robots ask constantly: “I want my hand here — what angles do my joints need?”

These same ideas — position, velocity, and acceleration, and how they relate to each other through calculus — show up again in Problem A, where they describe a spacecraft’s trajectory instead of a robot’s arm. Try Problem A →