In this video, we’re going to walk through a controller design for an active suspension system. Actually, we’re going to design two controllers. For the first, we’ll use H infinity synthesis to design a controller for a nominal plant model that will guarantee performance but not necessarily be robust to variation in the system. Then we’ll build an uncertain model like we did in the last video and design a robust controller using mu synthesis. I think it’ll be pretty interesting, so I hope you stick around for it. I’m Brian, and welcome to a MATLAB Tech Talk.
When a car hits a road bump, the tire absorbs some of that impact and compresses a little bit and then it forces the whole wheel assembly up. This force transfers through the suspension and causes the body of the car to bounce. For a suspension system, we’re usually interested in things like how the vehicle performs and how comfortable the ride is when it hits that bump.
With an active suspension system, alongside the passive springs and damping mechanisms there is a hydraulic actuator that can inject forces into the system to fine tune the performance and comfort we desire.
We can approximate this system with the following model. We treat the flexing of the tire as a spring, the tire assembly as a mass which is connected to the body mass through a spring/damper system that represents the passive suspension components, and a hydraulic actuator that we treat as an input force.
With this simplified model of the plant, we can design a feedback controller, K, that will take in some measurements, which we’ll call v, and produce the controlled variables, u. For our system, we have one controlled variable, which is the hydraulic force that’s being requested, and we’ll use two measurements: vehicle body acceleration, ab, and suspension travel, sd. Suspension travel is how compressed or expanded the suspension is. So, this is our feedback control problem. Now, let’s get into how we design this controller. And like I said, we’ll start with H infinity synthesis.
To understand conceptually what H infinity and eventually mu synthesis is doing for us, we need to expand this block diagram. In addition to the controller input, we also have external inputs into this system that come from sources like disturbances, and noise, and even reference signals. We’ll call these w.
And there are other outputs that we have to look at as well. These are the error signals that give us a sense of how well the system is performing. These outputs can be signals that are measured on the real system, or they can be virtual, in the sense that we just use them temporarily in the model to design the controller but we don’t need them on the real system. We’ll call these error signals z.
Let’s say our plant has a single external input that we care about; the disturbance that comes from when we hit a bump in the road. And there are three error signals that we want to use to define performance: there’s the body acceleration, suspension travel, and the requested actuator force.
So, here’s the whole design problem in a nutshell. We want a controller that minimizes the errors signals when a disturbance enters the system. We can think of it this way: when the car hits a bump, there’s a disturbance, and that disturbance is amplified in some way through the tire and the springs and dampers and moves the car up and down and stretches and compresses the suspension. The controller can modify how this disturbance impacts these signals by driving the actuator. The goal is to drive the actuator such that the amplification of the disturbance is minimized and in the process uses the least amount of actuator force possible.
And that is exactly what H infinity synthesis is doing for us. It’s an optimization process that calculates the controller that minimizes the gain between w and z.
However, as a designer, you might not want each signal to be treated equally in this optimization problem. Therefore, we can manipulate the signals within the model by adding weighting factors to w and z to set the importance of individual signals. For example, we may lower the actuator weighting factor if we’re not as concerned about actuator energy as we are about body acceleration. Or we may increase the weight if we want to drive the actuator less because we’re more concerned about extending its life. And we may develop more than one controller, each with a different set of weights, and then allow the user to switch between different active suspension modes like performance, comfort, or a balance between the two.
All right, now that we have an idea of how we’re going to approach this, to set up and solve this problem you can see we have a few design choices. We need to create a model of the plant, we need to determine which measured signals the controller has access to and which input variables it has control over, we need to choose the external inputs and error signals, and then finally we have to set up the cost function by weighting each signal. And once we have that, then we essentially solve a large optimization problem using H infinity synthesis. Mathematically, it can be a bit tricky, but the point of this video is not to have you do this by hand. It’s to give you a sense of how the controller works, so that you can set the problem up yourself and let the tools solve the math for you.
So, let’s go over to MATLAB and do just that.
For the most part, this script follows along with the MathWorks example, Robust Control of an Active Suspension, but I modified it a bit for this video. I’d recommend checking out the original example yourself if you want to dive into how to set all of this up and practice it yourself. And this is going to look like a lot of confusing code, but I promise that the gist of this script is exactly what we just walked through.
We start by setting up a model of the plant, which is the spring/mass/damper representation of the quarter car suspension. At the moment, we’ll assume that this model is perfect and there is no uncertainty in our dynamics. We’ll come back to this assumption in just a bit.
Another thing to note here is that we're modeling the hydraulic actuator as a first order system. This means that the controller requests a force, u, but the actual force the actuator generates, fs, depends on its dynamics.
To continue the rest of the design setup, we set individual weighting functions for each of the external inputs and error signals. Like, for example, W road is a gain of .07. But here’s what’s really cool. The weighting function can be frequency dependent. So, in this case, we’re putting a high pass filter on the actuator signal. This will penalize high-frequency controller commands more than low frequency, and therefore gives us a way to limit the control bandwidth.
Something else to note here is that we’re setting up three different sets of weights for body acceleration and suspension travel. This is how we can differentiate between performance mode, comfort mode, and balanced mode; and going forward, we’re actually going to solve for three different controllers, one for each of these gain sets.
Now, we connect each of these blocks to create a single open loop model. This model includes the suspension dynamics, the actuator dynamics, and the weighting functions. This open loop function is called qcaric.
All right, with the design problem set up, we can build the controller with the h infinity synthesis command. And it's pretty simple. It's a single command where we pass it the open loop function and tell it which signals the controller has access to. But keep in mind that what’s going on behind the scenes is that it's solving an optimization problem by finding the controller, K, that minimizes the energy transfer from the external inputs to the error signals. And actually, it’s doing that three times, one for each gain set.
So, what we’re left with is a controller that takes in two measured signals, suspension travel and body acceleration, and it outputs the actuator command, u. Let’s take a look at these controllers in action by simulating the response to a 5 cm road bump. I built the closed loop system with the H infinity controllers, and here I’m running a 1-second simulation for four different configurations: the uncontrolled system, and the comfort, balanced, and performance profiles. And check this out.
The green line is the 5 cm road bump and the blue line is the open loop response. This is how the system would behave if all we had were the passive suspension components. But with the closed loop controller, we have the comfort profile where the bump is damped out nicely like you’re floating on a cloud, and we have the performance profile that damps out quickly and you can really feel the road. And the balanced is somewhere between the two.
So this is all well and good, except that these controllers were designed using an imperfect model. We know that the suspension system is more complex than a simple spring/mass/damper system; there’s also four wheels interacting with each other, there’s noise in the sensors, and the actuator dynamics might vary, among other things. So, the question we keep asking ourselves in this series is how does this system handle variation?
Well, let’s just look at the effects of an uncertain actuator. Here, I’m varying the nominal actuator dynamics with some frequency dependent uncertainty. Then, I’ll rebuild the open loop model with this uncertain actuator. So, everything is the same as before, just now our plant is modeled with uncertainty.
Let’s see how well the nominal H infinity controller does by simulating the 5 cm road bump for 100 random actuator variations. For simplicity, we’re looking at just the balanced controller. And check it out. Most of the actuator combinations appear to be stable and produce a reasonable response. However, some variations create an unstable response. So, the H infinity controller is not a great solution if the actuator dynamics can really vary as much as I’ve modeled.
So, how can we improve this? Well, we could go back and tweak the weights on the different signals and try to come up with a controller that is stable across these variations, but if we already have a model of our uncertain system, why don’t we just develop a controller that takes those uncertainties into account from the start? And this is what Mu synthesis does.
Mu synthesis is an extension of H infinity in the sense that it’s still solving the same problem, except that it tries to minimize the worst-case gain across the entire uncertainty space.
The way it does this is with an iterative process called D-K iteration. The mathematical details of this process isn’t important for this video, but essentially what it’s doing in each step is running H infinity synthesis to find a nominal controller and checking its robustness. Then it scales the problem based on the uncertainty in the system and runs another H infinity synthesis, checks its robustness, and scales again. It keeps doing this until the robust performance stops improving.
The robust performance is the Peak Mu value, and in general, the lower this number, the more robust the system is. You can see that Peak Mu is decreasing over each iteration, and it’s the final value that is reported as the best achieved robust performance.
So, in this way, we know that whatever the worst-case combination of uncertainty is, it will still have at least this level of robustness. Just like with H infinity, we can run mu synthesis with a single command where we pass it the open loop function, and tell it which signals the controller has access to. It’s exactly the same, it’s just using a different optimization under the hood. Here, I’m running it for just the balanced gain set, set number 2.
Let’s check out the difference between the balanced H infinity controller and this comparable Mu synthesis controller. This is the same response that I showed earlier, except now we can see how the mu synthesis controller produces a response with less variability due to uncertainty. Both body position and suspension travel are very consistent, and importantly, stable. At first it looks like body acceleration is worse, but if we look closely, the bulk of the variations are more consistent here as well, and these wild acceleration swings are only associated with the variations that deviate the most from the nominal actuator. And so, if you build your suspension with an actuator that is near the variation limit, the system will still be stable, but it comes at the expense of having a slightly rougher ride. Probably a good trade off in the end.
So, hopefully, you can see the value of thinking about where you have uncertainty in your system, modeling that uncertainty, and then using that uncertain model to develop a robust controller. I definitely think it’s worthwhile trying to practice this on your own because it’ll allow you to tweak some values and see how that impacts the final controller design. And one way to do this is to check out the MathWorks example in the description.
And that’s where I’m going to leave this video.
If you don’t want to miss any other future Tech Talk videos, don’t forget to subscribe to this channel. And if you want to check out my channel, control system lectures, I cover more control theory topics there as well. Thanks for watching, and I’ll see you next time.
