If you have ever watched a factory line run itself, sat in a car that brakes before you even react, or wondered how a building keeps its temperature without anyone touching the thermostat, you have already seen controls engineering at work. You just probably did not know what to call it.
Controls engineering sits quietly behind some of the most impressive technology we interact with every day, yet it rarely gets the spotlight that software or mechanical engineering does. That gap is exactly why this blog exists.
Welcome to Engineering For Fun. My name is Atsu Bedjean, and I am a controls engineer who believes that technical knowledge should feel accessible, not intimidating. Whether you are already working in a related field or you are simply curious about how automated systems actually think, this blog is built for you.
In this first post, we are going to cover what controls engineering really is, why feedback loops matter more than most people realize, what a real project looks like from the inside, and where this blog is headed. Consider this your starting point for everything that comes next.
What Controls Engineering Actually Is (And Why It Gets Ignored)
Ask most people what a controls engineer does, and you’ll get a blank stare. Meanwhile, controls engineering is quietly running the world around them.
Controls engineering is the discipline of designing systems that automatically regulate behavior. Thermostats, industrial robots, aircraft autopilots, the cruise control holding your car at 65 mph on the highway, the job title is nearly invisible in public-facing tech content, but the systems it produces are impossible to avoid.
At the heart of every one of those systems is the same core idea: the feedback loop.
Here’s how it works. A sensor measures what a system is actually doing. A controller compares that measurement against a desired setpoint. If there’s a gap between the two, an actuator corrects it. That cycle, measure, compare, correct, repeats continuously. According to IEEE, this structure now underlies regulation in systems as diverse as aircraft autopilots, power converters, chemical reactors, and building climate systems. It is the heartbeat of every automated system you depend on.
Controls engineering also sits at an unusual intersection. A single project might involve mechanical sensors, electrical signal processing, and software running a control algorithm on a digital processor. That cross-disciplinary reality is part of why the field is underrepresented in tech media. It doesn’t fit cleanly into any one category, so it tends to fall through the cracks.
You interact with it constantly anyway. Your building’s HVAC holds a set temperature all winter. A drone holds position in a crosswind. Your car’s stability system catches a skid before you feel it.
This blog exists to pull back the curtain on all of that. Controls engineering isn’t just important; it’s genuinely fascinating once someone cuts through the jargon and shows you what is actually happening.
Why ‘Engineering For Fun’ Is a Deliberate Choice
Good controls engineering writing is remarkably rare. Here is why.
Technical engineering content tends to fail in one of two directions. Academic papers bury the insight under notation and assumed prerequisites that take years to build. Pop-science explainers swing the other way, smoothing out every interesting wrinkle until the subject feels trivial. Both approaches lose the reader, just for opposite reasons.
“Engineering For Fun” is not a promise to make controls engineering cute. It is a commitment to treat you like someone capable of handling real information, delivered without the unnecessary friction that makes most technical reading feel like a chore. ABET program outcomes explicitly require engineers to “communicate effectively with a range of audiences”, which confirms that clarity and technical rigor are not opposites; the engineering profession already knows this.
The differentiator here is Atsu’s working experience as a controls engineer. Not textbook examples, but the observations you accumulate on actual projects: what is genuinely confusing in practice, where the standard explanation breaks down, and the context that never makes it into formal documentation.
The intended reader sits somewhere in the middle of the expertise curve. Engineering students trying to connect classroom theory to real systems. Early-career engineers hitting concepts their program glossed over. Professionals from adjacent fields, mechanical, electrical, software, who interact with control systems and want a clearer mental model of what is happening. A technical manual serves none of these people well. A conversation does.
That is what this blog is designed to be. Each post takes one idea, follows it far enough to be genuinely useful, and leaves you with something concrete to think about or apply. No lecture. No prerequisites beyond curiosity.
Feedback Loops: The Idea Behind Almost Every Smart System
Think about the last time you adjusted your shower temperature. Too cold, so you turn the knob. Still cold, so you turn it more. Finally hot, you ease back. That loop, measure, compare to target, correct, is a feedback loop. You are the controller.
A PID controller automates exactly that process. PID stands for Proportional, Integral, Derivative, and it is the foundational algorithm behind most modern control systems. You do not need to memorize the math right now. Just understand what each term does:
- Proportional responds to current error. The further you are from your target, the harder the system pushes.
- Integral accounts for accumulated error over time, correcting stubborn offsets that proportional action alone cannot fix.
- Derivative watches the rate of change and anticipates where the system is heading, applying a brake before things overshoot.
Together, they give a controller memory of the past and a prediction of the future.
A concrete example: a factory conveyor belt must maintain constant speed regardless of load. When a heavy box drops on, speed dips. The PID controller detects the error instantly, ramps motor output proportionally, uses integral action to eliminate any lingering lag, and derivative action prevents overshooting target speed on recovery. This happens in milliseconds, invisibly.
Poor tuning breaks that picture fast. Too much proportional gain and the belt oscillates around target speed, never settling. Too little integral and it runs slightly slow forever. These are not textbook problems; they are real issues engineers debug during commissioning every week.
That same logic scales dramatically, from industrial robots to complex grid regulation, but the shower principle never changes. Only the stakes do.
What You See on an Actual Controls Engineering Project
Knowing how feedback loops work in theory is one thing. Watching them misbehave on a 15-year-old industrial chiller at 2 a.m. is another education entirely.
A real controls project moves through recognizable phases: requirements gathering, system modeling, controller design, simulation, and commissioning. Requirements gathering sounds straightforward until the client changes the target setpoint three weeks into the build. Modeling is genuinely interesting work. Commissioning, which means getting the actual hardware to match what your simulation predicted, is where humility lives.
The gap between school and the job is real. University teaches you clean, well-documented systems with known parameters. Industry hands you a motor drive with a partially legible nameplate, a PLC program last touched by someone who left the company in 2011, and a project deadline that does not care about either of those facts. Legacy systems, undocumented equipment, and scope creep are not edge cases. They are the job.
One scenario I come back to often: a temperature sensor on a packaging line was triggering intermittent faults, but only during the first 20 minutes of a production run. The sensor read correctly at steady state. It read correctly in the lab. The fault was a grounding issue that only manifested when the enclosure thermally expanded enough to loosen a connection. Nothing in the simulation caught it, because the model assumed ideal signal integrity.
That is the core limitation of any simulation environment, whether MATLAB/Simulink or otherwise: it models the physics you know about. Real hardware introduces noise, drift, mechanical wear, and electrical interference that no model anticipates by default. Simulation gets you 80% of the way there. The remaining 20% is fieldwork, patience, and a decent multimeter.
How This Blog Was Built (and Why the Platform Choice Matters)
Talking about project workflows is the easy part. Actually building the infrastructure to publish those conversations is where a lot of technical people quietly give up.
For this blog, the decision came down to one honest question: do I want to spend my weekends managing servers and debugging CSS, or do I want to write about controls engineering? I chose writing. That meant building Engineering For Fun on Lovable.app, an AI-powered app builder that lets you create and ship a production-ready site without touching backend infrastructure or writing boilerplate frontend code.
Engineers are builders by instinct. The appeal of Lovable is that it respects that instinct without taxing it on problems that aren’t the point. Describe what you want, iterate on it, ship it. The feedback loop is short, which is satisfying in exactly the way a well-tuned controller is satisfying.
That framing is not accidental. The same systems-thinking that shapes good controls engineering applies to platform selection: identify the actual output that matters, pick the tool that delivers it most directly, and eliminate unnecessary complexity everywhere else. Spending forty hours configuring a web stack to host a blog is unnecessary complexity. Lovable removes that layer cleanly.
For this use case, a writing-focused technical blog, it handled everything needed without friction. This is not a recommendation or a review; it is just an honest account of how this blog was assembled and why that approach made sense given the constraints.
The goal was always the content. The platform just needed to stay out of the way, and it has.
What Topics This Blog Will Cover Going Forward
Now that the platform is sorted, here is what is actually coming.
The next posts on the schedule cover three areas I think deserve more accessible treatment: model predictive control and why it has become the go-to strategy in modern energy systems, the real differences between controls engineering in robotics versus traditional industrial automation, and how the everyday toolset for controls work is shifting in ways that MATLAB-centric curricula have not fully addressed.
Every post follows the same structure: one concept, built from first principles, tied to a concrete application, written with enough personality that you do not feel like you are reading a standards document.
What level of background does this assume? If you are comfortable with basic engineering concepts, familiar with the idea that math is a language for describing physical behavior, and willing to follow an argument without needing every derivation spelled out in full, you are in the right place. The goal is to make the reasoning clear, not to hide the math entirely.
Where it helps, posts will include practical resources. Simulation files, annotated diagrams, links to tools that let you poke at a concept hands-on rather than just read about it. Controls engineering makes a lot more sense when you can actually run something and watch it respond.
Finally, and genuinely: suggest topics. If there is a concept you keep running into and cannot find a clear explanation for, that is exactly the kind of thing this blog should cover. Drop a question in the comments or reach out directly. Reader curiosity is a legitimate content roadmap, and I would rather write about what is actually confusing people than guess from a content calendar.
The next post is on MPC. See you there.
Start Here, Go Anywhere
So here’s where I leave you, and here’s what I want you to take away.
That gap between how much controls engineering matters and how rarely it gets serious public treatment bothers me, and this blog is my answer to it.
Come back whenever a topic catches your eye. You do not need to have read the previous post. You do not need a graduate degree. You need curiosity and a willingness to look at a system and ask, how is that actually working?
Start practicing that right now. Pick something near you: a thermostat, your car’s cruise control, the elevator down the hall. Ask yourself what the system is trying to hold constant, what is measuring the actual output, and what is making corrections when things drift. That line of thinking, that instinct to trace the feedback loop, is the core of how a controls engineer sees the world. You just did it.
I am genuinely excited about what is coming on this blog. Not in a performative way. In a “I have wanted to write about this stuff for years and now I am” way.
Controls engineering is fascinating, impactful, and criminally underexplained. I intend to fix that, one post at a time. Come along.
Conclusion
Controls engineering shapes the world quietly, and that silence ends here. Here is what this blog stands for: making a powerful discipline accessible, explaining real systems with honesty and depth, and building a community around genuine curiosity rather than credentials.
The gap between “engineers know this” and “everyone can understand this” is exactly what this blog was built to close. Let’s close it together.
Leave a Reply