The Step Response | Control Systems in Practice

In this video, I want to cover a few interesting things about the step response. We’ll look at what a step response is and some of the ways it can be used to specify design requirements for closed loop control systems. I hope you stick around for it.  I’m Brian, and welcome to a MATLAB Tech Talk.

Let’s start with the question, what is a step response? And the answer probably won’t shock you. It is how a system responds to a step input. So, we can input a unit step function into a system—that’s when the input changes from zero to one in a very short period of time—and we can measure the behavior of the system that results from it. That behavior is the unit step response.

Of course, we don’t have to limit ourselves to just a step from 0 to 1. More generally, a step input could start from any steady state value and jump instantly to any other value.

For example, let’s say we’ve developed an altitude controller for a drone and it’s hovering at a steady state altitude of 10 meters. This is our starting condition. Now, our step input could be asking the controller to raise the altitude to 20 meters. The command instantly steps from 10 to 20, and the step response would be how the drone reacts to that step command. How fast does the drone rise? Does it go above 20 meters before dropping back down? How long does it take to settle back to a steady state value? And is there any steady state error at the end?

So, you can see some of the questions we can answer when we look at a step response plot of our system. But rather than just answering these questions after the design is complete, we can use these values as design requirements. A design requirement is a need that the final system must meet. It’s a way of letting the engineer know when the design is good enough.

Now, when we’re talking about step response requirements for a closed loop control system, we are looking at the step response from an input into the loop, like a reference signal or a disturbance, to the output of the system. For the drone we just talked about, we stepped the reference signal from 10 to 20, and the step response was how the output, or altitude of the drone, changed over time. So, in this way, the design requirements for the altitude controller could be stated in terms of how we want the drone to react to a step input like this. And those requirements would dictate how the entire closed loop system should be designed.

Of course, usually we don’t just draw a picture of a step response and say, make it look like this! We define it by building up the step response as a set of individual features. Let me show you what I mean.

We can define the response in terms of rise time, which is the time required for the signal to rise from some starting point to an ending point. Usually, it’s measured from 10% to 90% of the final value. Overshoot, which is the maximum percentage over the final value that it reaches. If the maximum value is the final value, then there is no overshoot. Settling time, which is the time it takes for the response to enter and stay within some percentage of the final value. And the steady state error, which is how far off the final value is from the commanded value when it’s at steady state.

So, before we start designing that altitude controller, we can state things like our closed loop system shall have a rise time that is less than 10 seconds, or overshoot shall be less than 5% of the final value, and so on. And this gives us something to aim for with our design.

And for some systems, thinking about requirements in the time domain like this can be a lot more intuitive than specifying frequency domain requirements like bandwidth or pole locations in the complex plane, since often the things we care about are how the system performs over time. For example, due to altitude restrictions on hobby drones, we may not want our system to have any overshoot when commanded to step its altitude up to the maximum allowed height so that it doesn’t violate local flying laws by going too high. This would be a difficult requirement to write in the frequency domain.

Now, we're going talk more about step response requirements in just a bit, but first I have a question for you. And it’s something that tripped me up early on and I want to make sure it doesn’t do the same to you. The question is, what does a step response look like?

I’ll generate three different plots representing a system response to an unknown input. This first plot rises asymptotically to 1. The second plot rises forever in a straight line. And the third plot decays exponentially. Which of these do you think are responses to a step input versus some other input signal like an impulse or a ramp?

OK, ready? It’s a trick question. All of these are step responses. Let me explain. This first one is the step response of a first order low pass filter. And it produces something that looks like what we might expect a step response to look like—a step.

This second response that looks like a ramp is the result you get from a system whose dynamics look like an integrator—a so-called type 1 transfer function. Imagine taking the integral of a step and you’ll get a ramp. Think about a car where the input is the gas pedal and the output is the distance the car has traveled. If you apply a step input, or step on the pedal and hold it down, the car will accelerate to max velocity and the distance that the car travels would continue to increase linearly over time. It looks like a ramp, but it is still a step response.

For this third one, this is the step response for a high-pass filter. We can reason through this response like this. When the input steps up, there is a lot of high frequency information in this instant jump and that high frequency information is passed through the high pass filter to the response. The steady state portion of the step is just a DC gain—no frequency information at all—and so it gets blocked by the high pass filter, resulting in a step response that starts high and fades to nothing over time.

So, a step input doesn’t necessarily mean it’s going to create a response that also looks like a step. To complicate things a bit more, each of these plots could be generated by non-step inputs. For example, this first plot could also be the ramp response of a high pass filter. This second plot could also be the ramp response of a low pass filter. And this third plot could also be the impulse response of a low pass filter. So, the thing I want you to take away from this is that we can’t tell just by looking at the output alone whether we’re looking at a step response or something else. We have to know that the input was a step, or we have to know the dynamics of our system to be certain.

So, for closed loop control, why do we often define requirements in terms of a step response that looks like this, like a low pass filter, rather than one that looks like this ramp or this decay? Well, we do define step response requirements differently depending on what behavior you want your closed loop system to have.

If you’re building a system that’s tracking a reference signal, then the resulting system will behave like a low pass filter, and the step response will look like a step. We can reason through it like this. We want the closed loop system to track the reference. If the reference signal steps, then we want the output in some way to follow that reference. Hence, it also will look like a step, and therefore, the whole closed loop system will behave like some kind of a low pass filter. And since reference tracking is a large part of control system design, these types of requirements are popular.

But, on the other hand, if you’re designing a closed loop system to reject disturbances, then a low pass filter is not the desired behavior. When a disturbance steps, that will initially move the system in a direction away from the desired state, and the control system is trying to bring the state back to zero error. So, in this way, a disturbance rejection system will behave more like the high pass filter step response.

And specifying a design requirement for this type of system like overshoot (at least the way we defined it earlier) doesn’t necessarily make sense. This is why we still have to know something about our system, and what we’re trying to accomplish, before we just come up with a list of requirements for it.

Now, just for fun, I want to go over to MATLAB and run the command stepinfo on each of these three transfer functions. Stepinfo will return the step response characteristics, and I want to show you what it returns for our low pass filter, high pass filter, and integrating type 1 transfer function.

Let’s start with the low pass filter, since it produces a step response that fits nicely with how we defined our requirements. It has a rise time of just over 2 seconds and settling time at almost 4 seconds. And notice there’s no over or undershoot as expected for this system and the peak time is just after 10 seconds. Of course, there’s no real peak time for this system since it asymptotically approaches 1 but it never quite reaches it. Although, I’m sure after 10 and half seconds it’s close enough to 1. All right, that all looks great. Let’s move on to the integrating system with its response that looks like a ramp.

The step info for this is not so good. There is no rise time or settling time. There’s no such thing as overshoot or undershoot since the final value is infinite (which also happens to be the peak as well). So, this doesn’t tell us a whole lot about our system.

Now, the high pass filter does return some real values, but we have to interpret them differently. Rise time and settling time represent more like how long it takes to decay and settle. The peak value is still valid and tells us what the maximum value is, which happens to come right at the beginning of the response. But overshoot isn’t really a thing, since the final value is 0 and so any non-zero value will always have a percentage that is infinitely high.

So, as we covered already, not all step response requirements make sense for every type of system. But, if we’re designing a reference tracking system that’s functionally going to behave like a low pass filter, then these classic requirements are just perfect.

In fact, if we narrow the behavior of the tracking system that we’re designing even more to one that is linear and low pass filter-like but is also second order with no finite zeros, then we can simplify the design requirements to just two parameters: natural frequency, and damping ratio. These types of second order systems can be described in a form that you’ve probably seen many times in other videos and textbooks. If you haven’t, don’t worry. All this is saying is that if your system transfer function has no s in the numerator (so no finite zeros), and a second order denominator, then you can write your system as a function of omega n and zeta.

If your closed loop system can be described by this transfer function, then instead of having to specify a bunch of requirements like rise time, settling time, overshoot, and so on, you only need to specify natural frequency and damping ratio. These parameters are related to those other time domain requirements through some equations. There are tons of great resources that explain these equations, and I will link to some below if you’re interested in learning more.

For this video, I just want to show you visually how changing natural frequency and damping ratio for a second order system like this impacts the time domain parameters.

Let’s start with a system that has a natural frequency of 1 rad/s and a damping ratio of .3. We’ll apply a unit step input at 1 second, the orange line, and plot the step response, the blue line. You can see there is some rise time and overshoot for this system. I could have shown the other time domain values as well on this graph, but I wanted to keep it relatively clean so you could see what was happening. The important thing to watch for is how overshoot and rise time change as we adjust natural frequency and damping ratio. Let’s start with the damping ratio.

All of the time domain features of a step response are affected by damping. You can see that as I increase and decrease zeta, the entire shape of the step response changes. And you can see, in particular, how it affects both overshoot and rise time.

Adjusting natural frequency, on the other hand, has the property of maintaining the same step response shape. It just squishes it or expands it along the time axis. You can see that rise time gets shorter as natural frequency increases, but overshoot is the same for any value of wn.

So, rather than state maximum overshoot as a percentage, for example, we can state the maximum overshoot as a damping requirement. And we can specify rise time and settling time in terms the natural frequency and damping ratio.

So, knowing this, if we’re designing a second order system with no finite zeros, then we can specify a damping ratio and natural frequency requirement that produces the desired step response we’re looking for.

Remember that this doesn’t work for every system. Wn and zeta are derived for a very specific second order transfer function. Just like you have to be aware of whether your system will act like a low pass or high pass filter before you set your step response requirements, you also need to make sure you’re not defining something like damping ratio for a system that can’t be approximated by the standard second order transfer function. So, be careful to understand your system before you request a design requirement that just can’t be met.

OK, that’s where I will leave this video. I hope it’s helped you in some small way. 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.