Anatomy of a Robot

What a robot actually is, once you strip away the sci-fi: a body that senses, decides, and moves, plus the loop that ties those three together.

Here's the uncomfortable truth that makes robotics hard and beautiful at the same time: a neural network that's wrong just outputs a bad number, but a robot that's wrong knocks a glass off the table. Everything in this guide is downstream of that one fact. Software gets to live in a clean world of tokens; a robot has to live in ours, with gravity, friction, sensor noise, and a clock that never stops.

Before we can talk about the flashy stuff (the vision-language-action models steering humanoids, the reinforcement learning that teaches a quadruped to run) we have to agree on what a robot is. Not philosophically. Mechanically. Because every algorithm later in this guide is really just a way of answering one of three questions a robot is constantly asking: where am I, what should I do, and how do I make my body do it?

I'm assuming you can read a bit of math and you've seen a for-loop. Everything else (joints, frames, actuators, degrees of freedom) we build from zero. Here's the road: we start with the single loop that every robot ever built runs on. Then we open up the body: the joints that let it move, the actuators that drive them, the sensors that tell it what happened. We count degrees of freedom, because that number governs everything. And we end with the one distinction, holonomic vs nonholonomic, that explains why parallel parking is annoying and why a drone isn't.

Let's go.

Strip any robot down (a Roomba, a surgical arm, a Boston Dynamics Atlas) and you find the same three-beat loop running underneath, thousands of times a second:

Sense → Plan → Act. Read the world. Decide what to do. Move. Repeat.

That's it. That's the whole field. A Roomba senses a bump, plans a turn, acts by spinning a wheel. Atlas senses its own tilt, plans a foot placement, acts by firing actuators in its leg. The sophistication lives in how each beat is done, but the skeleton never changes. Everything you'll learn (SLAM, PID, PPO, VLAs) slots into exactly one of these three beats.

Two things make the loop hard, and they're the villains of this entire guide:

Villain #1: the world doesn't hold still. By the time you've finished planning, the world has moved on. So the loop has to run fast (often 100 to 1000 times per second) and each pass can only afford a little computation. This is why robotics obsesses over latency in a way that pure ML doesn't.

Villain #2: every measurement lies a little. No sensor is exact. No motor moves exactly where you told it. These small errors don't stay small. They accumulate. Drive forward "one meter" a hundred times using only your wheel counts, and you'll be meters away from where you think you are. The hero that fights this, feedback, closing the loop by constantly re-measuring, shows up in every chapter from here on.

A robot's body is a chain of rigid pieces called links (the "bones") connected by joints (the "knuckles"). The links don't bend; all the motion happens at the joints. This is a modeling choice as much as a physical one: treating the forearm as a perfectly rigid rod is a lie, but a useful lie that makes the math tractable. We'll keep making useful lies like this throughout the guide, and I'll flag them when they matter.

There are really only two joint types you need, and almost every robot is built from them:

Each joint contributes exactly one number to the robot's state. A six-joint arm is described, completely, by six numbers. Hold onto that: it's the seed of the single most important idea in this chapter.

Count the joints (really, count the independent numbers you need to fully describe a robot's configuration) and you have its degrees of freedom (DoF). It's the single most predictive number about a robot. It tells you how hard the math will be, how many motors you're paying for, and what the robot can and can't reach. Do the count for a quadruped: 3 joints per leg, 4 legs — 12 DoF, so twelve motors to buy and twelve numbers to command, before you've even asked where its body is in space.

A human arm has 7 DoF from shoulder to wrist. That extra one past six is why you can hold your hand perfectly still and still move your elbow around: there's slack in the system. Most industrial arms have 6, the magic number that lets an end-effector reach any pose (position and orientation) in its workspace. We'll prove why 6 is magic in Chapter 3; for now, just internalize that DoF is the currency of a robot body.

Here's where it gets subtle, and where a lot of beginners trip: the DoF of the body and the DoF of the task are different things, and their mismatch defines two failure modes you'll meet everywhere.

A joint that can't move is furniture. Actuators are what convert stored energy into motion: the muscles. Three families cover almost everything:

Electric motors dominate. They're clean, precise, and easy to control, which is why nearly every modern robot from a hobby arm to a humanoid runs on them. The catch is that a raw motor spins fast with little twisting force (torque), so it's almost always paired with a gearbox that trades speed for torque. The arithmetic sells it: a small motor might make $0.1$ N·m of torque at 6,000 rpm — not enough to turn a doorknob. Run it through a 100:1 gearbox and you get $\tau_{\text{out}} \approx 100 \times 0.1 = 10$ N·m at 60 rpm. Now check what a real task needs: holding a 1 kg bottle at the end of a metre-long horizontal arm takes $\tau = mgr = 1 \times 9.8 \times 1 = 9.8$ N·m at the shoulder. The raw motor can't hold it at all; the geared one can, with margin to spare. But the trade has a hidden cost we'll come back to: gears add friction and backlash (a tiny dead zone where the output doesn't move when the input reverses direction), and backlash is a quiet enemy of precision.

Hydraulics push fluid to make enormous forces: this is how the early heavy Boston Dynamics machines threw their weight around. Incredible power density, but leaky, loud, and hard to control finely. The field has largely moved to electric as motors got stronger.

Pneumatics use compressed air. Cheap and springy, great for simple grippers, but that same springiness makes precise position control a nightmare.

There's a design axis hiding here that matters more than the technology: stiff vs compliant. A stiff actuator holds its commanded position hard and resists being pushed: great for precision, dangerous around people, because it'll happily crush what's in its way. A compliant actuator (via a physical spring, or via software that senses force and yields) gives when pushed. Compliance is what makes a robot safe to work next to and gentle enough to hold an egg. Modern robots increasingly use torque-controlled actuators (you command a force, not a position) precisely so they can be soft when they need to be. Keep this stiff/compliant split in mind; it comes roaring back in Chapter 4 when we do force control, and again in Chapter 12 when we talk about robots working around humans.

Actuators are how a robot acts; sensors are how it senses. And there's one split that organizes all of them, worth burning into memory because it structures the entire estimation chapter later:

Proprioceptive sensors measure the robot's own body. Exteroceptive sensors measure the outside world. Your sense of where your limbs are without looking is proprioception; your eyes are exteroception. Robots have both, and they lie in different ways, which is exactly why we fuse them.

The proprioceptive crew:

The exteroceptive crew:

Notice the pattern: no single sensor is complete. Encoders know the joints but not slip. IMUs react fast but drift. Cameras see meaning but not depth. LiDAR sees geometry but not meaning. The art isn't picking the best sensor: it's fusing several so each one's strengths cover another's blindness. That fusion is Chapter 5, and it's one of the most important ideas in the whole field.

The same loop and the same parts assemble into wildly different bodies, and the body shape decides which problems are easy and which are brutal. A quick tour, because you'll meet all of these later:

One last distinction, and it's the one that most surprises newcomers because it feels like it shouldn't matter, but it decides whether motion is easy or a puzzle.

A robot is holonomic if it can move instantaneously in any direction it might want to go. A drone is holonomic-ish: it can slide left, right, up, or forward at will. So is a robot on omni-wheels that can scoot sideways.

A car is nonholonomic. It has 3 degrees of freedom in where it can end up (x, y, and heading) but at any instant it can only do two things: drive forward/back and steer. It cannot slide directly sideways. That gap (free to reach any parking spot eventually, but forbidden from moving straight into it) is the entire reason parallel parking requires that awkward back-and-forth shuffle. The constraint isn't on where you can be; it's on how you're allowed to get there.

This matters enormously for planning. A holonomic robot's planner can draw a straight line to the goal. A nonholonomic one has to plan paths its wheels can actually follow (smooth curves, three-point turns) which makes Chapter 6's planning problem genuinely harder. Whenever a motion problem feels weirdly constrained, this is usually why.

You now have the vocabulary the rest of the guide is built on. A robot is a sense–plan–act loop running on a body of links and joints, where the number of degrees of freedom governs everything, actuators push on the world (stiff or compliant), sensors report back (proprioceptive and exteroceptive, each blind to something), and the body's embodiment and holonomy decide which problems are hard.

From here the guide follows the three beats of the loop. First we master Act and the math under it: Chapter 2 gives us the language of space (frames and transforms), Chapter 3 turns joint angles into hand positions (kinematics), Chapter 4 makes the body actually track a command (control). Then Sense: Chapter 5 fights drift with fusion and mapping (estimation and SLAM). Then Plan: Chapter 6 finds paths through the configuration space you met in Fig 1.3. With the classical stack in hand, we turn to learning: reinforcement learning (7), perception and vision-language models (8), the vision-language-action models running today's robots (9), how they're taught from demonstrations (10), the world models and simulators that train them (11), and finally putting a whole real system together safely (12).

Every one of those is just a smarter way to do one beat of the loop you met in Fig 1.1. Onward.