The Control Theory is the branch of engineering and mathematics that studies how to manipulate a dynamic system so that it behaves the way we want.
As I always say, it wouldn’t be right to start a complete course on something without first laying a solid foundation. We’re going to delve into a fascinating world, sometimes feared for its mathematics, but which is the true engine that makes robotics and automation work.
In computer science and software-level programming, we are very accustomed to immediacy. If we change the value of a variable in memory, it changes instantly. If we send a command over a network, we expect an almost immediate response. Pure logic is discrete and predictable.
What happens when our code has to interact with the physical world?
The real world does not understand immediacy. Things have mass, inertia, friction, thermal capacity, and inductance. If we tell a 1000 W motor to go to its maximum RPM, it won’t do it in zero milliseconds; it will take time. And if we tell it to stop, it will keep spinning due to inertia.
That’s why we use Automatic Control.
Why programmers need control
Let’s imagine we are programming the firmware for a 3D printer and we want to heat the hotend to 200°C.
The “naive” approach of a programmer who doesn’t know control theory would be to write something like this:
float target_temperature = 200.0;
void update_heater() {
float current_temp = read_temperature_sensor();
if (current_temp < target_temperature) {
turn_on_heater(); // Full power!
} else {
turn_off_heater(); // Turn off, we're overshooting!
}
}At first glance, the logic is impeccable. However, in the real world, this is a disaster.
The aluminum block of the hotend has thermal inertia. When you reach 200°C and turn off the heater, the residual heat will continue to flow towards the sensor, and the temperature will rise to 210°C or 215°C (what we know as overshoot). Then it will slowly drop, fall to 190°C before the heater takes effect again, and it will spend its life oscillating violently.
We need a way to observe how the system reacts and adjust our actions. Instead of just turning it on and off, we can modulate the control signal to correct the error without causing unnecessary oscillations. We need control theory.
How we see the world: the concept of the plant
In control theory, the thing we want to control (be it a motor, a drone, the water level in a tank, or a chemical reactor) is called the plant or system.
From now on, the plant will be a dynamic black box for us.
To interact with this black box mathematically and programmatically, we define three fundamental concepts:
- Input u(t): This is the control signal. It is what we can manipulate. In the world of microcontrollers (Arduino, ESP32), it is often a PWM duty cycle (voltage) that we send to a motor driver or a MOSFET transistor.
- Output y(t): This is the variable we want to control. It is the reality we measure through our sensors. It could be the position from an encoder, the degrees per second from a gyroscope, or the temperature from a thermistor.
- State x(t): These are the internal variables of the system at a given moment that determine its future behavior. (We will delve deeper into this when we get to State-Space representation).
Notice that we use the (t) notation. This constantly reminds us that we are working with systems that vary over time. Everything in control is about temporal dynamics.
The goal of the game
When we design a controller, our main goal is to ensure three critical things, in this order of importance:
This is rule number one. If we ask a drone to tilt 10 degrees and, due to poor control, it starts oscillating faster and faster until it flips over and crashes into the ground, the system is unstable.
An unstable system is dangerous and completely useless.
The real world is full of surprises. A gust of wind hits our drone, or someone opens the door of the oven we are controlling.
Our control system must be able to detect that “deviation” and correct it quickly without us having to intervene.
We want the system to reach the target quickly, but without overshooting.
We want to minimize the steady-state error (if I ask for 200°C, it should settle at 200.0°C and not at 198°C forever).
What we will see in this course
Throughout this series, we will get to know the tools used to control physical systems.
We will stop seeing systems as simple lines of sequential code and will instead begin to understand them through block diagrams. We will study how to make a system measure itself and correct its own errors autonomously.
And, most importantly, we will see how to translate all that continuous mathematics (integrals and derivatives) into real, discrete C++ code that we can fit into a simple loop of a 2-euro microcontroller.
Get your coffee ready, because in the next article we’ll start getting our hands dirty to see the fundamental difference between blindly commanding and governing with intelligence.
