The lectures state the job in one line:
The job of the controller is to provide a brain to the robot, so it can be autonomous and achieve its goals.
And immediately after, a scoping statement that is easy to read too fast:
Feedback control — from control theory and cybernetics — is a good way to write controllers to enable the robot to perform a single simple task.
The qualifier "single simple task" is the entire motivation for the rest of the course. Feedback control is excellent, and it is not enough: a self-sufficient robot must perform multiple tasks (Chapter 1, section 6), and the moment there is more than one task, you need something that decides which loop is in charge. That something is a control architecture.
Three further statements frame what a controller is:
Feedback plays a crucial role in self-organising phenomena, and in complex system dynamics in general. The course adopts the definition from F. Capra & P. L. Luisi, The Systems View of Life, Cambridge University Press, 2014:
"A feedback loop is a circular arrangement of causally connected elements, in which an initial cause propagates around the links of the loop, so that each element has an effect on the next, until the last feeds back the effect into the first element of the cycle."
Note how exactly this matches Plate 1.3. The sensory-motor loop is a feedback loop in this sense, with the environment as one of the causally connected elements. That is why the same vocabulary — gain, saturation, amplification, stability — will keep reappearing, including in the swarm chapter where it is applied to whole colonies rather than single robots.
| Negative feedback | Positive feedback | |
|---|---|---|
| Character | Self-regulating | Self-reinforcing |
| Mechanisms | Saturation · Competition · Resource exhaustion | Amplification of random fluctuations and structure formation · Reinforcement of the most common behaviour patterns |
| Example from the lectures | The centrifugal governor | Pheromone-based dynamics in ants |
And the sentence that matters most:
Complex systems are usually characterised by the presence of both kinds of feedback. Not one or the other. Positive feedback creates structure by amplifying a fluctuation; negative feedback stops that structure from consuming the system. Ant foraging (Chapter 9) is the canonical demonstration: pheromone deposition is the positive loop, pheromone evaporation is the negative one, and removing either destroys the behaviour.
One variable, one loop. Move the gain from negative to positive and watch the same equation produce regulation, then runaway, then oscillation. Nothing changes except the sign and size of one number.
The justification given is short and deliberately unglamorous:
An architecture is therefore not a runtime component — it is a discipline imposed on the designer. It says what a module may be, how modules may be composed, and what is forbidden. Everything you will be asked to do in lab activities 3 and 4 is an exercise in obeying an architecture even when a quicker hack is available: lab 3 explicitly requires you to avoid a centralised dispatcher, because a centralised dispatcher is not the subsumption architecture even if the robot behaves the same.
The course names exactly four. Learn the list in this order, because it is the order of increasing commitment to the world model — and the order in which the field historically discovered them.
| # | Architecture | Basis | Representation of the world |
|---|---|---|---|
| 1 | Deliberative control | Mainly symbolic AI techniques: search problem solving techniques, planning, automated reasoning | Makes use of a symbolic representation of the world |
| 2 | Reactive control | Reflex-like rules | Minimal internal representation — and rather not symbolic |
| 3 | Behaviour-based control | Focused on the concept of behaviour (e.g. "avoid wall", "search light"), achieved by combining basic and more advanced behaviours | Distributed across behaviours; can store state (Chapter 6) |
| 4 | Hybrid control | Integration of deliberative and behaviour-based control | Both, at different layers and time scales |
Reactive and behaviour-based are not synonyms. Reactive control is reflex-like rules with minimal state and no learning. Behaviour-based control is built out of behaviours, which are time-extended, can take inputs from other behaviours, and — as Chapter 6 spells out — can store state and even be used to construct a model of the world. Behaviour-based control contains reactive control as a special case; it is not identical to it.
The lectures do not answer "which architecture is best". They give a questionnaire, split over two slides. These nine questions are the practical core of the chapter.
Questions 1–6 test whether the assumptions of deliberation hold. A planner assumes the world model is accurate and up to date (Chapter 13); noise, change and partial observability are precisely the conditions that break that assumption. Questions 7–9 test whether the limits of reaction bite: reactive control has minimal state (so no memory), no internal models (so no prediction) and no learning. Answering "yes" to 7 or 8 pushes you up the stack; answering "yes" to 9 sends you to Chapters 10–12.
Answer for the robot you are designing. The recommendation is assembled from the course criteria, not from taste — and, as section 7 insists, it is a recommendation, not a theorem.
The deck closes with two observations that should be quoted almost verbatim at the exam:
In general, there is no best controller.
There exist different ways to implement a controller. For example, reactive control can be achieved by a set of rules or by a neural network; deliberative control is typically based on symbolic AI techniques.
The second observation deserves emphasis because it separates two things students routinely conflate: the architecture (what the modules are and how they compose) from the implementation technique (rules, automata, neural networks, trees). The same architecture admits many implementations:
| Architecture | Possible implementations seen in this course |
|---|---|
| Reactive | IF-THEN rules; a Braitenberg wiring (Ch. 5); a feed-forward neural network (EvoStick, Ch. 11) |
| Behaviour-based, arbitration | Fixed or dynamic priorities; IF condition THEN behaviour X; finite state automata, also probabilistic; behaviour trees (Ch. 6, 8) |
| Behaviour-based, fusion | Summation of output signals; mathematical combination functions; fuzzy logic; motor schemas and potential fields (Ch. 7) |
| Deliberative | A*, RRT (Ch. 13); STRIPS, planning graphs, conditional planning (Ch. 14) |
"No best controller" is not a shrug. It is the reason Chapter 15 exists: if there were a best controller, you could argue for it; since there is not, you must measure, on a stated environment distribution, with a stated merit factor, and with a statistical test. The absence of a universal answer is what makes the experimental method compulsory rather than optional.
The job of the controller is to provide a brain to the robot so it can be autonomous and achieve its goals. Feedback control, from control theory and cybernetics, is a good way to write controllers to enable the robot to perform a single simple task. The restriction to a single simple task is what forces the introduction of control architectures.
From Capra & Luisi, The Systems View of Life (CUP, 2014): "a feedback loop is a circular arrangement of causally connected elements, in which an initial cause propagates around the links of the loop, so that each element has an effect on the next, until the last feeds back the effect into the first element of the cycle."
Negative feedback is self-regulating; its mechanisms are saturation, competition and resource exhaustion; the example is the centrifugal governor. Positive feedback is self-reinforcing; its mechanisms are the amplification of random fluctuations and structure formation, and the reinforcement of the most common behaviour patterns; the example is pheromone-based dynamics in ants. Complex systems are usually characterised by the presence of both.
Because to find correct and efficient programs to control a robot one needs guiding principles, so as to avoid bad, inefficient and incorrect programs. The lectures note that similar principles apply to software systems engineering: an architecture constrains what a module may be and how modules may be composed.
Deliberative: mainly symbolic AI techniques — search problem solving, planning, automated reasoning — using a symbolic representation of the world. Reactive: reflex-like rules, with minimal internal representation of the world and rather not symbolic. Behaviour-based: focused on the concept of behaviour (e.g. "avoid wall", "search light"), achieved by combining basic and more advanced behaviours. Hybrid: integration of deliberative and behaviour-based control.
No. Reactive control is reflex-like rules with minimal (if any) state, no learning and no internal models. Behaviour-based control is built out of behaviours, which are time-extended, may take inputs from other behaviours and may store state — a network of behaviours can even be used to construct a model of the world and to look ahead. Behaviour-based control subsumes reactive control as a special case.
Is there a lot of sensor noise? Does the environment change or stay static? Can the robot sense all the information it needs — and if not, how much? How quickly can the robot sense? How quickly can the robot act? Is there a lot of actuator noise?
Does the robot need to remember the past? — pushes beyond purely reactive control, which has minimal state. Does it need to think into the future and predict? — pushes towards deliberative or hybrid control. Does it need to improve its behaviour over time and learn new things? — pushes towards the adaptive-behaviour methods of Chapters 10–12.
(1) In general, there is no best controller. (2) There exist different ways to implement a controller — for example reactive control can be achieved by a set of rules or by a neural network, whereas deliberative control is typically based on symbolic AI techniques. The architecture and the implementation technique are separate choices.
If no architecture is universally best, a design claim cannot be settled by argument. It must be settled empirically: run several control software instances on samples of a stated environment distribution, measure a stated merit factor, and apply a statistical test to decide whether the observed difference is significant. Chapter 15 does exactly this, comparing subsumption, motor-schema and random-walk controllers with the Wilcoxon test.