Most first-year controls courses are teaching the wrong thing.
At least, I think so but I’d like to hear what other people think.
Most first year control classes are set up to "train control engineers". But the goal really should be to "train engineers about control".
There's a difference between the two. The first needs a good foundation on which a student can build a proper understanding of the field. This is what we already teach; Laplace transforms, state space, stability theory. All that normal important stuff.
But I think the first course should give any engineer an overview of the field. What is a control problem? How can we approach solving these problems? What are the things control engineers are concerned about? How does this fit into the rest of engineering?
The first control class should focus on building engineering intuition rather than the mathematical foundations. If a student walks away and never takes another controls course, they should still understand what controls can do, when to call someone who knows it, and how their job interfaces with or contributes to the overall control problem.
And I think this will help them much more than whatever they manage to remember about Bode plots.
Then if we’ve motivated the student to go deeper into controls and build that foundational knowledge, that's what the second class can do.
So, here's how I'd structure the first class:
1. The Control Problem: What are we even trying to do?
Control is everywhere, but most engineers don't recognize it when they see it. Before any math, students should see the control problem show up in a chemical plant, a spacecraft attitude system, a prosthetic limb, a data center cooling loop. By the end of this section a student should be able to walk into any engineering context and ask: what's being measured, what's being driven, and what are we trying to achieve?
This is also where the instructor should lay out the full control loop as a diagram students will carry through the entire course. This would be the standard plant, sensor, estimator, controller, actuator loop that we’re familiar with. Give students the map on day one and tell them that the rest of the course is just zooming in to different parts.
Project ideas: Have students identify every element of the control loop on a physical system before they've been taught any of the details. On a temperature control platform, can they find the heater, the sensor, what it’s trying to accomplish? On a mobile robot, what's being measured and what's being driven? The goal is to build the habit of asking the right questions about a real system from day one.
2. Sensors, Actuators, and the Hardware Layer
You can't control what you can't measure, and you can't change what you can't drive. Before students touch a block diagram, they should understand that sensor and actuator choices are design decisions with real consequences. Introduce concepts like bandwidth, noise, cost, and failure modes. This is where controls connects to every other engineering discipline. A mechanical engineer who understands that their bearing choice can affect the estimator, or that their actuator saturates before the controller expects it to, is a better collaborator on any control problem.
Project ideas: Have students characterize the sensors and actuators on their platform directly. What is the noise floor on the position sensor? How quickly does the motor respond to a commanded input? What happens at the limits of its range? Students don't need to analyze this formally yet. The point is to handle the hardware and develop physical intuition about the gap between what the datasheet says and what the bench shows.
3. Modeling — Every Model is Wrong, But Some are Useful
The point of this section isn't to teach students to derive transfer functions. It's to show them that a model is a choice, and that choice has consequences for everything downstream. What do you include in the model? What do you leave out? What happens when reality doesn't match your assumptions? Students should leave understanding the different ways we represent systems mathematically, and maybe more importantly, why we pick one over another. The engineer who never builds a model themselves still needs to know what the model their colleague handed them is actually claiming about the world.
Project ideas: Give students a simple model of their platform like a first or second order approximation and have them test its predictions against the real system. Where does it match? Where does it break down? At what input amplitude does the linear model stop being useful? This exercise gives students a concrete example of model mismatch to carry into the analysis and estimation sections later.
4. Analysis — How Do We Know What Our System Can Do?
Now that we have a model, what can we learn about the system before we ever build anything? This section covers the performance, stability, and robustness measures that control engineers actually care about. And we frame it not with mathematical rigor but as questions to be asked and understood. Will it settle? How fast? How much does it push back against disturbances? How wrong can our model be before things fall apart? The goal is for students to internalize these as the right questions, so they know what to demand from a controls engineer even if they can't answer them themselves.
Project ideas: Apply a step input to the physical system and have students measure rise time, overshoot, and settling time directly from the response. Then compare those numbers against what the model predicts. This grounds abstract performance metrics in something students have touched and watched move. It also sets up a natural question for later: if we don't like these numbers, what do we change?
5. Specifying What You Want — Translating Requirements into Objectives
This is often the hardest part of a control problem, and it happens entirely upstream of any math. A customer wants a smoother ride. A regulator requires a process to stay within bounds. A pilot needs an aircraft that feels responsive but not twitchy. Turning those into control objectives, and knowing when the objectives themselves are contradictory, is a skill that belongs to every engineer on the team, not just the controls specialist. Students should also leave this section understanding that "good enough" is a real engineering answer, and that deciding what it means is often a cross-disciplinary negotiation.
Project ideas: Ask students to write a one-page control specification for their platform before any controller is designed. How fast should it respond? How much steady-state error is acceptable? Are there safety constraints on how hard the actuator can be driven? Then have them compare specifications across the class, and maybe have them work through the disagreements. There is rarely one right answer, and this discourse can help students understand the give and take of engineering design.
6. State Estimation — Knowing Where Your System Is
Knowing how to change your system requires you to know where your system is. Your sensors don't tell you the full story. They're noisy, they're slow, they measure proxies rather than the things you actually care about. State estimation is the art of building the best possible picture of your system from imperfect information. Students don't need to implement a Kalman filter, but they do need to understand why estimation is a separate problem from control, and why getting it wrong can destabilize a system that looks perfect on paper. This section also sets up a natural conversation about what happens when your model drifts from reality.
Project ideas: Introduce artificial noise or a sensor dropout into the platform's feedback signal and have students observe what happens to the system's behavior. Then show them a simple filtered estimate alongside the raw measurement and let them see the difference in real time. The goal is to understand how measurements alone can be inadequate and the role of the estimator in the control loop.
7. What Can Go Wrong — Failure Modes and the Fragility of Real Systems
A non-controls engineer needs to be aware of how their work interferes with the operation of the control loop that someone else designed. Integrator windup, actuator saturation, sensor dropouts, model mismatch, for example. Recognizing these patterns is more valuable in practice than being able to derive why they happen. This section builds intuition through failure: show the system working, then show what happens when one assumption breaks. Engineers who understand failure modes ask better questions, write better specifications, and cause fewer incidents.
Project ideas: Deliberately induce failures on the platform and have students diagnose them. Command a setpoint the actuator physically can't reach and observe windup. Disconnect and reconnect the sensor mid-run. Swap in a controller tuned for a different operating point. Students should practice recognizing failure signatures before they're responsible for preventing them.
8. The Landscape of Controllers — Different Problems Need Different Tools
Students should see the full terrain early, even if they only explore a small part of it. PID is one answer to one class of problems. MIMO systems, nonlinear control, robust and adaptive methods, data-driven approaches, MPC for constrained systems, distributed control: these exist because different problems exist, and a good engineer knows enough to ask which regime they're in. This section doesn't need to be rigorous. It needs to be a map. Give students something to point at when they encounter a new problem later and say I think this is one of those.
Project ideas: Have students implement and compare two or three different controllers on the same platform; a simple proportional controller, a PID, and if the platform supports it, something with a constraint like a rate limit handled by MPC or a simple lookup table. The point is that students feel the difference in behavior with their own hands and eyes. A system that a P controller can't quite settle, that a PID handles cleanly, and that an MPC keeps within bounds during a large disturbance reinforces the story of why the landscape exists.
9. The Human in the Loop — You Are Part of the System
For most engineers working in industry, they are part of a control loop whether they know it or not. A process engineer tweaking a setpoint. A pilot with an autopilot engaged. A surgeon guiding a robotic tool. A technician who overrides an alarm. Supervisory control, operator interfaces, and human-in-the-loop dynamics are where controls meets organizational behavior, safety engineering, and human factors. Making this explicit, and showing students that the human element changes the analysis, might be the most effective way to make every person in the room feel like this course is directly about their future job even if they don’t become control engineers.
Project ideas: Have students operate their platform manually, tracking a moving setpoint by hand using a simple interface and then switch to the automated controller and try to do better. Then ask them to operate the automated system supervisorily: set targets, monitor performance, and intervene when something looks wrong. The debrief question is the point: when did your intervention help, and when did it make things worse? Students who have experienced that firsthand understand why human factors is a controls problem.