Reality vs. Virtuality

Reality vs. Virtuality

This week’s Theme Week at Engineer Blogs is dealing with cross functional engineering material. Like most mechanical engineers, I’ve had to do my fair share of other engineering disciplines, mainly civil/structural (on the small scale) and electrical (basic circuits, signal processing). Because ME, EE, and Civil are all what I would consider core engineering disciplines, I think most engineers in one of those three fields should understand the basic concepts of the other two fields. Typically, the fundamental concepts in Civil are easier to understand for a ME. (I mean, you have to know your target to make the right bomb 😀 ). Basic concepts on the EE side are a little harder to grasp because they tend to be more abstract. But if you’ve had to do any programming, you understand Paul Clarke’s underlying argument, even if you don’t get the complete package.

As we divert from the core engineering disciplines (FYI, I consider ChemE to be a core discipline but separate from the other three), we tend to get a mix of different fields. You could argue that Material Science is a mix of ME, ChemE, and Physics. Similarly, Environmental Engineering is not only Civil, but also Public Policy and Management, Geology, and so on. And I think the farther down these sub-fields we go, there is a greater chance for discrepancy in terms of terminology and conventional wisdom.

One of these sub-fields is Controls Engineering, combining mechanical systems, electronics, signal processing, and software/programming. With all of those different fields involved, you’re bound to have a disconnect between engineers of two different disciplines. Now, minor disconnects are to be expected but overall, we should still be able to grasp similar concepts. However, nothing could be further from the truth between MEs and Controls engineers when analyzing the same system.

It seems as though mechanical engineers and controls engineers are living in a parallel universe. Everything looks basically the same, and you can easily follow the path of one (the mechanical) but you just scratch your head when trying to figure out the other (the controls). The main reason for this is mechanical engineers live on a plane called Reality. In this plane, a force is exerted on a mass attached to a spring causing a deflection of said spring. If the force is removed, the spring will oscillate until internal and external damping cause it to slow and finally stop.

In the control engineer’s plane, Virtuality, that same spring, mass, and force, are represented by a magical graph called a Bode plot, which tells you the input to output ratio as a function of the frequency of the applied force. Along with the Bode plot, you can use something called the root locus diagram and it tells you everything you need to know about the characteristics of your system. And because this is a parallel universe, two things actually mean the same thing, if you can find someone to explain it properly.

However, I’ve never really found this to be the case. For the controls lectures that I’ve seen, they always start with “If we have this model and we assume we have a bode plot that looks like this…”. Yet their model is way too simplified for most practical systems and they give no indication of how hard it is to get to the point where you can actually make that Bode plot. You tend to get many more resonances and vibrations because it’s impossible to know every characteristic of your system before it’s built.

This story should sum up my thoughts nicely. A colleague of mine was in a large meeting with several other PhD students and advisors for biannual planning for the overall project. My colleague was supposed to build the system and his colleague in the controls dept was supposed to design and implement the MIMO control system. My colleague calmly tried to explain to his fellow controls engineer that he needed to take into account the actual setup parameters and initial conditions otherwise the system he was modeling the controls for could never exist in reality. And the controls engineer’s response was, “I don’t care if it is physically possible. I can model it. And if I can model it, I can model a controller.”


If the controller is built properly, then initial conditions shouldn’t affect it at all. I would assume that a MIMO control system built by a graduate-level student in a controls department would take this into account.

But what you say is very true. At an undergraduate level from the EE side, most “real system” stuff is waved away. At the same time, when designing a controller, a good engineer should take into account sensitivity and robustness which can help mitigate the differences between the model and the physical system.

At the end of the day, how accurate does the model have to be? Does it have to be an atom-for-atom simulation of all of the forces and dynamics that are happening in the system? Probably not, and this is why we are engineers and not physicists. We are smart enough to make the cost-benefit analysis when it comes to accuracy of the model versus meeting the actual design requirements.

Anyway, great job, would love to see more Controls posts!

The sad point is the Controls PhD student did not, but the ME PhD student did.

That hand waving done by most EE departments is the crux of the problem on the ME problem. And generally you think you have a good idea about the model, but it usually turns out to be at least 10% off (at least in research).

I would always contend that having a well designed, properly constrained system with a simple PID controller is better than a poorly designed system with some super H-infinity controller to correct all of the bad design mistakes. It will be cheaper, and more user friendly in the long run

I do enjoy that my grad level controls classes have some grounding in reality.

By grounding, we get to the end of a 2-3 hour derivation and go: “See how this is marginally better than PID? Woohoo!”

Once again, I guess that’s why we are engineers. Don’t build something complicated if that tried and true PID controller will do the job.

Comments are closed.