What Is a Robot? Anatomy and the Sense-Plan-Act Loop

People argue about this endlessly, but a working definition covers almost every case: a robot is a machine that senses its environment, processes that information, and acts on the physical world — automatically, without a human guiding each move. A thermostat barely qualifies; a surgical arm definitely does. The word comes from the Czech robota, meaning drudge work, coined in a 1920 play.

Three building blocks appear in every robot, from a $30 Roomba to a$2 million industrial welder:

• Sensors — gather raw data (light, distance, joint angle, force).
• Controller / compute — turns that data into a decision.
• Actuators — execute the decision on the physical world (spin a motor, open a valve).

Remove any one pillar and the machine breaks down into either a dumb tool or an expensive paperweight. The rest of this lesson is about how those three pieces talk to each other.

A sensor converts a physical quantity — light, temperature, distance, angle — into an electrical signal a computer can read. No sensor is perfect: every measurement carries noise (random error), bias (systematic offset), and a range beyond which it saturates or fails.

Sensors split into two families:

A drone uses a proprioceptive IMU to know its tilt and an exteroceptive downward-facing camera to know its height above the ground. Both streams feed the controller simultaneously. This split is a useful debugging tool: if your robot drifts, ask first whether the fault is proprioceptive (it doesn't know where its joints are) or exteroceptive (it can't see the wall it's supposed to avoid).

An actuator converts energy into mechanical work. Electric motors dominate hobby and research robots because they're cheap, precise, and controllable. Hydraulic cylinders appear in heavy machines (excavators, early Boston Dynamics robots) because fluid pressure produces enormous force. Pneumatic grippers inflate rubber bladders for soft, compliant grasps.

The key insight is that actuators are not on/off switches — they have continuous dynamics. A motor's speed depends on applied voltage, shaft load, temperature, and battery state. That variability is exactly why the controller can't send one command and walk away; it must keep checking and adjusting.

The controller is the software (and the hardware it runs on) that bridges sensing and acting. It ranges from a tiny 8-bit microcontroller on an Arduino Uno to a GPU-laden computer running a neural-network policy on a humanoid robot. Size doesn't determine smarts — a grain-sorting machine may need millisecond-precision timing more than it needs floating-point math.

The controller's job description never changes:

1. Read sensor values.
2. Compute a desired action based on a goal and current state.
3. Send commands to actuators.
4. Repeat — fast enough that the world hasn't changed too much between cycles.

That last point is critical. A self-driving car at 30 m/s moves 3 cm every millisecond. A controller running at 10 Hz (one cycle per 100 ms) would let the car drift 3 meters between decisions — dangerously slow. Loop rate is a first-class design constraint, not an afterthought.

Every deliberative robot architecture passes through these four stages in order, then repeats indefinitely.

In 1986, Rodney Brooks formalized what engineers had been doing intuitively: the Sense-Plan-Act (SPA) loop. Sense the environment, build a plan, execute an action. Repeat forever.

SPA separates concerns cleanly — swap the planner without touching sensor drivers. But SPA has a famous weakness: latency. If planning takes 200 ms and something unexpected happens at 50 ms, the robot is acting on stale data.

A Mars rover using SPA might take a stereo image, run path planning for 500 ms, drive 10 cm, then repeat. That's fine where terrain changes slowly. It would be fatal for a warehouse drone flying at 5 m/s.

The fix isn't to abandon SPA — it's to know when a simpler, faster approach works better, and layer the two together.

Reactive (behavior-based) control skips planning and wires sensors almost directly to actuators through a fixed set of rules. Rodney Brooks built autonomous robots this way using a layered architecture he called subsumption.

The Roomba is the canonical example. It doesn't build a map. It runs reactive rules:

• If bump sensor fires → reverse and turn randomly.
• If cliff sensor fires → stop and back away.
• Otherwise → spiral outward to cover the floor.

No planning, no world model — and it works. The tradeoff: reactive systems struggle with tasks requiring memory or foresight. A reactive robot can't return to a dock it hasn't seen recently, or execute a multi-step assembly task.

Modern robots layer both: fast reactive reflexes at the bottom (collision avoidance), slower deliberative planning on top (route optimization). The reflexes can override the plan at any time.

Embodiment is the principle that intelligence is inseparable from having a physical body in a physical world. A robotic arm manipulating objects develops representations shaped by the mass, friction, and compliance of that specific body — representations a pure software agent never acquires.

This has concrete engineering consequences:

• A wheeled robot (Roomba, delivery bot) has nonholonomic constraints — it can't slide sideways. Its planner must respect that geometry.
• A drone lives in 3D but controls only 4–6 thrust axes. Full 6-DOF motion requires careful thrust allocation.
• An industrial arm (KUKA, UR5) has 6 revolute joints. Its workspace is a donut-shaped volume — points at the robot's own base are unreachable.

When you design a robot system, start with the body. What the body can physically do constrains everything the controller can even attempt. The body is not a detail — it's half the design.

The SPA loop looks different depending on scale and task. Here's how the three-pillar anatomy maps across real systems:

Notice the pattern: more complex tasks push toward full SPA with richer sensors and more compute. But reactive layers persist even in self-driving cars — emergency braking fires far faster than the main planner runs. The architecture scales; the three-pillar anatomy never changes.

You now have the skeleton of every robot system:

1. Sensors gather imperfect data about the world and the robot's own state.
2. Controller reads that data, applies logic or learned behavior, and decides what to do.
3. Actuators execute that decision, changing the world — which sensors then re-observe.

Even the simplest robot sketch follows this structure:

# Minimal SPA pseudocode
while robot_is_running():
    distance = ultrasonic_sensor.read()   # Sense
    if distance < 20:                     # Plan
        command = turn_left()
    else:
        command = drive_forward()
    motors.send(command)                  # Act

The loop rate, sensor quality, and actuator precision set the ceiling on what the robot can achieve. A controller at 1 Hz with a noisy rangefinder can't play table tennis. A controller at 1 kHz with high-resolution encoders can perform fine surgery.

In the lessons that follow, we'll zoom into each pillar: sensors next, then actuators, then the feedback control algorithms that tie them together. Every concept connects back to this loop. When something breaks on a real robot, the first question is always: where in the loop did the information go wrong?