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 used to specify
design requirements for closed loop control systems.
So 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's 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 0 to 1
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
that we can answer when we look at the 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're 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 that we just talked about,
we stepped the reference signal from 10 to 20.
And the step response was how the output or the 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.
Then overshoot, which is the maximum percentage
over the final value that it reaches.
And if the maximum value is the final value,
then there is no overshoot.
There is settling time, which is the time it takes
for the response to enter and stay
within some percentage of the final value,
and there's 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 any local flying laws by going too high.
This would be a difficult requirement
to write in the frequency domain.
Now, we're going to 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'm going to generate three different plots
representing a system responds to an unknown input.
The 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.
But this second response that looks like a ramp
is the result that 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 that 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.
And for the third one, this is the step response
for a high-pass filter.
And 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, so 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.
And 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,
and the 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 a 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.
And we can reason through that 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's also going to 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 that we defined it earlier,
doesn't necessarily make sense.
This is why we still have to know something
about our system--
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 step info on each of these three transfer
functions.
Step info 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 the settling time at almost 4 seconds.
And notice that it's returning that there's
no over or undershoot, which is 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 1/2 seconds, it's close enough to 1
to just call it.
All right.
So all of these numbers look great.
Now 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's no rise time or settling time.
There's no such thing as overshoot or undershoot
since the final value is infinite,
and it also happens to be the peak as well-- infinite.
So this doesn't really 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 nonzero value will always
have a percentage that is infinitely high.
So as we've already covered, 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.
But if you haven't, don't worry.
All this is saying is that if your system transfer
function has no S'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,
and there's tons of great resources
that explain these equations.
And I'm going to link to some of them
below if you're interested in learning more.
But for this video, I just want to show
you visually how changing natural frequency in 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 radian per second
and a damping ratio of 0.3.
We'll apply a unit step input at 1 second, which
is the orange line, and then plot the step response,
the blue line.
You can see that there's some rise time and some overshoot
for this system.
And I could have shown the other time domain values as well in
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.
Now, 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 omega n.
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 of 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 that we're
looking for.
And remember, this doesn't work for every system.
Omega n and zeta are derived for a very specific
second-order transfer function.
So 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 that you're not defining something
like damping ratio for a system that
can't be approximated by the standard second-order transfer
function.
So just 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.