Insights / Embedded & Firmware
Robot Architecture: From Sense-Plan-Act to Modern Robot Systems
How robot architecture moved from sense-plan-act to layered designs, why modern robots separate planning from motion control, and how their parts communicate.
The short answer
Robot architecture is the way a robot's sensing, decision-making and actuation are organised in hardware and software. Early robots such as Shakey used a sequential sense-plan-act loop that reacted too slowly. Behaviour-based designs such as subsumption reacted fast but could not pursue long-term goals. Layered architectures, typically three tiers of reactive control, an executive and a planner, combined the two. Modern robots follow the same idea in hardware: a main computer for perception and planning, and a separate real-time controller for motion.
Why robot architecture is hard
A robot has to watch its surroundings continuously, filter out sensor noise and errors, react to change, and still carry out tasks and respond to commands. Because these concerns cut across hardware and software, the layer that organises them is often called middleware. For a long time designing it was closer to an art than to engineering.
How robot architecture evolved
Shakey and sense-plan-act
Shakey, developed at the Stanford Research Institute (now SRI International) from the late 1960s, is often called the first mobile robot that reasoned about its own actions. Its "brain" was an SDS-940 computer, later a PDP-10, linked to a camera, a range finder and bump sensors. Its software followed three stages: sense the environment, plan a sequence of actions, execute them.
That pattern became the sense-plan-act (SPA) paradigm: read the sensors, build an internal model of the world, plan, then act. Its weakness was the sequence itself. While the robot planned, the world kept changing, and it could not react until the plan was finished. The problem was the architecture, not only the computers of the time.
Behaviour-based robots and subsumption
In the 1980s researchers looked for faster alternatives. The most influential was Rodney Brooks's subsumption architecture: the robot is built from layers of simple behaviours, finite state machines that connect sensors directly to actuators, with higher layers able to override lower ones. These robots responded quickly to a changing world, but long-term goals and overall behaviour were hard to plan.
Layered and three-tier architectures
Layered architectures combined both. The most common is the three-tier (3T) model, used in research robots including at NASA. In some versions the middle tier almost disappears and its work moves to the planner, giving a two-tier design. The Syndicate model extends 3T to teams: each layer talks to the layers above and below it and to the same layer on other robots.
| Paradigm | How it works | Strength | Weakness |
|---|---|---|---|
| Sense-plan-act | Sense, model the world, plan, then act, in sequence | Deliberate, goal-directed behaviour | Slow to react; stalls while planning |
| Subsumption (behaviour-based) | Layers of simple behaviours wired from sensors to actuators | Fast, robust reactions | Hard to plan long-term goals or complex tasks |
| Three-tier (3T) | Reactive control, an executive that sequences tasks, and a planner | Fast reactions and long-term planning together | More components and interfaces to design and test |
| Syndicate | 3T layers that also coordinate with the same layer on other robots | Multi-robot coordination | Coordination traffic and failure handling across robots |
- Behavioural control (lower tier): works with the outside world through cameras, sensors and motor controllers.
- Executive (middle tier): supervises the tasks the lower tier performs, mediating between planning and control.
- Planning (upper tier): localisation, mapping and deciding what to do next.
The standard architecture of a modern robot
Modern robots map the layered model onto hardware. A main computer, x86 or Arm depending on the task, takes the planning role. Cameras, microphones, sonar, radar, LiDAR and positioning modules feed it, and specialised modules such as NVIDIA Jetson accelerate image processing. Its software builds a map of the world as the robot sees it and plans actions.
The main computer does not drive the motors directly. A separate controller, usually a microcontroller running firmware in a tight loop, interprets commands, drives the actuators, detects collisions and processes feedback from moving parts. This is the behavioural-control tier in hardware, and a robot may have several such boards.
Because the software on the main computer coordinates processes like an operating system, robotics frameworks are often named as one, the best-known being ROS, the Robot Operating System.
How robot components communicate
| Approach | How it works | Good for |
|---|---|---|
| Client-server (point-to-point) | One component calls functions on another and waits for the result | Commands and queries: configure a camera, ask a manipulator for its position, coordinate robots in one system |
| Publish-subscribe | Components publish data to named channels; any component can subscribe | Continuous streams: video, sensor readings, robot state shared with many consumers |
A camera, for example, publishes its video stream for object-recognition components to subscribe to, while a control process changes its settings or switches it on and off through request-response calls. Most modern robot middleware uses both approaches at once, which makes it easier to add new software and hardware modules. Messages are usually serialised in compact binary formats inside the robot, with JSON over HTTP or MQTT where the robot connects to web applications and cloud services.
When the body changes the architecture
Some robots depart from the standard design because of what they are made of or where they work.
- Soft robots are built from flexible materials that stretch and fold. Some have few or no electronics and move by pneumatics, which suits hazardous environments; their compliance makes them safer around people, for example in rehabilitation exoskeletons or grippers for fragile objects.
- Micro- and nanorobots are designed for tasks such as targeted drug delivery. Their architecture depends almost entirely on the task, and development relies heavily on simulation of their behaviour.
- Snake robots chain several identical modules in series to move over complex surfaces, climb and reach confined spaces.
The engineering implication for a robot or drone product
The lesson from half a century of robot architecture is to separate time scales. Fast reactions belong close to the sensors and actuators, on dedicated controllers with predictable timing. Planning, perception and coordination belong on more capable computers that can be busy without putting the machine at risk. Drones follow the same pattern: a flight controller for stabilisation and a companion computer for perception and missions.
Practical recommendations
- Put safety-relevant reactions on a dedicated real-time controller, not the main computer.
- Define the interface between planning and motion control before choosing boards.
- Use publish-subscribe for sensor streams and request-response for commands and configuration.
- Decide what the robot does when the main computer or network fails.
- Use an established framework such as ROS 2 for the upper tiers instead of building middleware from scratch.
Questions engineers ask
What are the disadvantages of subsumption architecture?
Behaviour-based subsumption robots react quickly, but it is hard to give them long-term goals, plan complex tasks or predict overall behaviour as layers are added. Layered architectures add a planner above the reactive layer to address this.
What makes a robot a robot?
A robot senses its environment, decides what to do and acts on the physical world through actuators, in a loop. How those three functions are organised is its architecture.
Was this useful?
Where this shows up in our work
SolutionAutonomous & Intelligent Physical Systems EngineeringDividing a robot or drone between real-time controllers and higher-level computers, and making that architecture dependable in the field, is the autonomous physical systems work we do across firmware, hardware and AI.For the same architecture applied to flight controllers and companion computers on drones, see UAV and drone systems engineering.
Apply this to your product