# initial undershoot

• posted
If there is right half plane zero, there will be a initial undershoot in the
step response.
I have a second order system as zdotdot=-g+u/m, zdotdot is double derivative of
z, g is the gravity acceleration, m is mass and u is the control. If I choose
different value for m, and using PID controller, there is a initial undershoot.
How can I approximate the system to see the zeros and poles? I think changing
the mass will change the zeros. Do you guys have some clue?
Thanks
• posted
But if there is initial undershoot, that does not necessarily mean that there is a right half plane zero.
This is not a system with right-half plane zeros. This is a system that has more inputs than the control input alone.
You don't have to approximate the given equation at all: you can bring it into the Laplace domain directly with just one assumption.
The assumption is that the system is at rest at time t = 0, with known position and velocity. I'm going to assume the position and velocity are zero, because I'm lazy.
The Laplace transform of the left-hand side is L{d^2/dt^2 z} = Z(s)/s^2.
The Laplace transform of the right-hand side is
L{-g + u/m} = -g/s + U(s)/m
(OK, two more assumptions: I'm taking g and m as being constants). The reason I can do the above is because _for the purposes of the problem_ you can treat the acceleration due to gravity as starting up at time t=0. This is 'incorrect', but is accounted for by the assumption that the system is at rest at time t=0 (and I'll bet that you're simulating this).
Z(s)/s^2 = -g/s + U(s)/m
Your problem is that you have a two-input system. You should be starting to see that your undershoot isn't coming from any zeros (which you don't have), but is rather coming from the naturally-induced acceleration due to gravity, which is (presumably) in the opposite direction of your desired motion.
• posted
Great, Tim
Got your clear explanation again. You are doing the real 'control' thing. I change the desired 'z' to another direction, then I get only overshoot (more) because of the 'second' control input, the gravity.
Thanks Tao Wang
A small note on "L{d^2/dt^2 z} = Z(s)/s^2", you mess it with integration, should be "L{d^2/dt^2 z} = Z(s)s^2'.
• posted
Beware of trying to appear learned before you've had your morning caffeine...
• posted
(And it's a good thing you caught my error -- I'm glad what I said made sense in spite of it).
• posted
Now that the problem is solved, I can go off on a fun tangent:
Your system, as described, is -- strictly speaking, and if you consider it as a SISO system with position as output and force as input -- nonlinear.
(half the readers of this are screaming at me for saying this -- but wait! It's true, and I can prove it!)
The reason it's nonlinear is because you're adding in that constant acceleration term. This makes the system fail the superposition test:
x1 = h(u1): d^2 / dt^2 x1 = u1 / m - g, x2 = h(u2): d^2 / dt^2 x2 = u2 / m - g,
BUT:
x1 + x2 = h(u1 + u2) says that
(u1 + u2)/m - g = (u1 + u2)/m - 2g.
This is, of course, absolutely trivial to linearize -- but the system is still nonlinear, and has various "nonlinear" problems. Including, but not limited to, the fact that it fooled you into thinking there were unstable zeros...

PolyTech Forum website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.