What's the point of this blog?
There are several reasons why I’m writing this blog (#0: A Blog, Really?), but I think this is the reason that matters the most for the readers of this post:
Throughout my schooling, I learned a lot of algorithms that were, in some way, related to solving a control engineering problem. I was pretty good at systematically working through the mathematics and I always felt I had a pretty good grasp of things like what a Kalman filter was, or a transfer function, or how to model a system, or what feedforward meant.
It wasn’t until I graduated and started working that I realized that I didn’t truly get how all of these concepts and algorithms worked together for the greater good of ‘controlling a system’.
That’s what I want to cover in this blog. This is going to be a collection of posts that attempt to tie together many of the things that fall under the field of control engineering.
I'm sold! Where do we begin?
I think it makes sense that we all have a similar concept of what control engineering is, so let’s kick this off with a definition. That’s fun, right? If you look up “control engineering” in Wikipedia (as of January 2020), it states:
“Control engineering is an engineering discipline that applies automatic control theory to design systems with desired behaviors in control environments.”
That’s a perfectly reasonable definition but if you’re new to the subject it still might be hard to wrap your head around what that means exactly. Therefore, let me try to simplify it by splitting it up into three separate points:
Control is having the power to influence or direct the course of events of a system.
We want to use this influence to get the system to behave a certain way; i.e. when we have control, we get to decide what to do and ensure that it happens.
Control engineering can be thought of as the collection of tools, techniques, guidelines, and processes by which we accomplish that.
What is a control engineering problem?
The main components in a control engineering problem are having something to control (the system), having a way in which its behavior can be modified (influence over the system), and then figuring out how to use that influence to accomplish what you want (the goal).
For example,
If you have control of your car (system), you get to decide the direction and speed of travel (goal) using the steering wheel and pedals (influence).
If you have control in a video game, you get to decide how the character (system) moves (goal) using the aptly-named controller (influence).
If your child (system) is misbehaving, you try to correct their behavior (goal) through words or actions (influence).
These are all examples of manual control where a human is actively involved in influencing the system. However, most of what we talk about in control engineering - and most of what the theory is dedicated to solving - is automatic control.
Automatic control is when we design a process (control system) that can figure out how to influence the system without the need for human intervention.
An autonomous car determines on its own how to turn the steering wheel and adjust the pedals.
A Non-Player Character (NPC) in a video game determines on its own where to move in the game world.
A robonanny would determine on its own which words and actions are necessary to raise your child.
That last example seems a bit dystopian, but right now I just want to highlight in general what a control problem is and hold off on passing judgement on what is a good and reasonable use of the technology!
The takeaway from this section is that an engineer trying to develop an automatic system to control a car in many ways is similar to a parent trying to control their child. The former is actively trying to change the behavior of an inanimate object while the later is actively trying to change the behavior of another person, however, in a general sense they are both control problems.
Wait, am I learning how to raise children?
Not directly, but I do think that some of the knowledge in how we approach an engineering problem can get us thinking about non-engineering problems as well. To understand why, let’s look more closely at different types of systems and see what their similarities and differences are.
Engineers are typically trying to control machines or chemical processes. These are things like autonomous cars, drones, automatic vacuums, and crude oil distillation columns (just to name a very, very few).
A classic example of electromechanical control is getting an inverted pendulum to balance on top of a cart.
For this system, the behavior we’re trying to control is to overcome the natural tendency for the pendulum to fall over and we can affect this behavior by accelerating the cart left and right. If the acceleration comes from an electric motor that drives the cart’s wheels then ultimately the entire problem comes down to this single question: how much voltage should we supply to the motor in order to keep the pendulum from falling down?
To make the above gif I solved this problem with model-based design. I built a mathematical model of the cart/pendulum dynamics and then used the tools that control theory provides to develop a control system that automatically determines the proper voltage. Solving this is pretty straightforward (once you learn how to do it) since this system has relatively simple dynamics.
Generally speaking, the simpler the system dynamics the more tools we have available and the easier the problem is to solve. Reality is complex and messy, but luckily a lot of real-world systems can be modeled with simple dynamics which is why we spend so much time learning them!
Simple dynamics, however, is not a requirement for control engineering. The idea of control can be applied to any system even if the governing dynamics are extremely complex.
Solving complex problems are tougher but if it’s a well-studied problem, control theory might still provide the tools that will allow you to solve it systematically. Other times we have to solve them using heuristics, or rules of thumb, or experience and intuition. And, yet, other times we’re just taking a guess and gaining experience as we go. Even the problems that fall outside of what we can solve with control theory are still control engineering problems as I defined it above.
Do you have an example of this?
Sure, take the economy as an example. Like controlling an inverted pendulum, controlling the economy can be summed up with a single question: what actions do we need to take in order to have the economy grow at a desired rate? This is a control problem even if it’s not obvious how to solve it.
It differs from the inverted pendulum problem in that the economy is an extremely complex dynamic system. I’m not an economist but I can imagine the number of variables that affect economic performance are unimaginable! I mean, how many different things can you think of that affect the value of the stock market? Storms, particularly charismatic CEO’s, unemployment (which itself can be driven by how the stock market is doing so there is some feedback here), unexpected reported earnings, and so on.
It is theoretically possible to build a model of the economy and use control theory to determine the best control actions, but realistically, this would be impossible. This doesn’t mean, however, that we can’t still use the tools in control engineering to help us influence larger, more easily modeled, economic trends.
For example, economists have developed economic models that they use to help understand and control inflation. Granted they are simpler than the true dynamics but they can be used to determine things like how economic inflation (governed by the system dynamics) can be controlled (to some goal) by raising and lowering interest rates (influence). Economists might not use the exact same mathematical theory as someone who is trying to control an inverted pendulum, but I’d argue that it all falls within control engineering. Ultimately, it’s still the same problem; find a way to get the system to behave the way you want.
You mentioned people, are they control problems?
This might sound a bit nefarious, but we can absolutely think of interacting with people as a contol problem. We try to use our influence to alter the behavior of other people. Here the question might be: What actions should I take or what words should I say to cheer up my friend?
Like the economy, people are complex and dynamic systems and developing a perfect model of a person is not realistic either. We don’t even typically build simple models of people in our day-to-day life. It just doesn’t make sense to describe your friend as a mathematical equation (I’m guessing here but I don’t know you or your friend).
However, in our heads, we do learn simplified models of people. We come to expect how someone will respond to a particular action and that expectation comes from the fact that we’ve built a crude mental model of them. And if they don’t respond the way we expect, then we subconsciously update our model for the future.
Over time we use this mental model to learn what we can say (influence) to our friends (complex dynamic systems) to make them happy (goal). Their mood is the behavior that we’re trying to control and our words and actions are what we use to change that behavior. Again, there’s not a mathematical solution or algorithm that will come up with the correct actions (hence why controlling an inverted pendulum is easier) but this is still a control problem at its core.
So "being controlling" per this broader understanding isn’t as nefarious as it sounds. It just means having the ability to influence and then using that influence to change behavior to something you want. And like I stated at the beginning of this post, control engineering is the collection of tools, techniques, guidelines, and processes by which this is accomplished.
So, where is this blog going?
As we’ll see throughout this blog, the specifics of how we approach a control engineering problem (e.g. inverted pendulum, economy, people) depends on the nature of the problem itself. Therefore, I can’t just tell you which algorithms you need to learn or how to model your system or what you should use to influence your system because there are too many variables that are unique to each problem.
Instead, in this blog we’ll walk through an overview of everything that you might be exposed to, in one way or another, as a control systems engineer. And the way we’re going to cover everything is to fill out and dive into each of the sections in my Map of Control Theory. The goal is that with this overview, you’ll be in a better position to know how to approach any control problem you encounter. I hope you stick around for it.
Continue reading: Coming soon (maybe) but in the meantime why not read about The Kalman Filter?
Previous post: #0: A blog, really?
-- Brian Douglas
References:
Control Engineering, “https://en.wikipedia.org/wiki/Control_engineering”, wikipedia.com
Friedman, M. (1953). "The Methodology of Positive Economics". Essays in Positive Economics. Chicago: University of Chicago Press.
Thank you to Elizabeth Frank for reviewing this post.