# initial undershoot

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
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
On Mon, 04 Jun 2012 07:04:50 -0700, Tao Wang wrote:

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.
--
Tim Wescott
Control system and signal processing consulting
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
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'.
On Monday, June 4, 2012 11:36:12 AM UTC-4, Tim Wescott wrote:

<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
On Mon, 04 Jun 2012 09:44:36 -0700, Tao Wang wrote:

Beware of trying to appear learned before you've had your morning caffeine...

--
Tim Wescott
Control system and signal processing consulting
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
On Mon, 04 Jun 2012 12:28:33 -0500, Tim Wescott wrote:

(And it's a good thing you caught my error -- I'm glad what I said made sense in spite of it).
--
Tim Wescott
Control system and signal processing consulting
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
On Mon, 04 Jun 2012 07:04:50 -0700, Tao Wang wrote:

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...
--
Tim Wescott
Control system and signal processing consulting