Not expecting a solution worked out for me... I'm stuck and need a hint. My prof is on vacation this week and is unreachable and the
homework is due the day he returns...
given:
Servo-tracking control problem.
roots of error dynamics equation are:
-4, -2+2j, -2-2j
our physical model is for that of rocket control:
y" - k1 y = k2 B + k3 w,
where w = wind disturbance--an unknown and unmeasurable constant the only measurable physical things are y, ycmd and y'. k1 and k2 >0 and known (but not given--ie we are free to choose a value I assume)
We are to design B so that y approaches ycmd for all t.
ycmd is of the form
ycmd = c1 + c2t
now I know the error equation should look like:
e''' + a3 e" + a2 e' + a1 e = 0;
So....
I plug the roots given into matlab poly() and get a characteristic equation:
e''' + 8e'' + 24e' + 32e = 0;
which meets the hurwitz constraints:
all coeffs >0 and a3 * a2 > a1, 8*24 >32 check.
So now my confusion is:
How do I draw a math flow diagram for the physical model, when all I have is an equation in terms of 3rd order error, e?
He wants us to sim this in simulink and then vary/tweak the given roots to see how the servo-tracking changes.
In class he developed B as a PID algorithm, which I understand accounts for the unknown constant wind.
Can anyone give me some direction?
Thanks,
Bo
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
bo wrote:

He has confidence in you...

I assume that this is rocket attitude control, since it has that inverted-pendulum look about it.

Actually if you're looking for the real error your wind disturbances will show up on the right hand side -- think about it.

Now think. If you're plugging three stable roots into a polynomial generator, wouldn't you _expect_ the result to be stable?

You know an awful lot just from what you have stated already.
* You know the order of your plant. * You know the order of your final system. * So you should be able to deduce something about your controller. * You know that it's a SISO feedback control problem.
So draw a generic system that meets these constraints, fer cryin out loud!

I hope this helps. You said "homework" so I'm being intentionally vague, but there should be a trail of breadcrumbs in here someplace.
Check back in after you've digested this.
--

Tim Wescott
Wescott Design Services
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Tim,
Much thanks for the reply. Perhaps I failed to mention a thing or two....
In class he basically worked thru that the controller is/ needs to be a PID--which takes care of the disturbance on the right hand side. Yes, you are right--it is a rocket attitude control problem. (You must have seen this before!) :)
See further interspersed comments/questions below. I'm going to snip some to hopefully keep this readable.
wrote:

Not his 1st mistake :). Actually I think he's doing a great job so far--but on more than one occassion his homeworks have left the entire class bewildered.

Yep.
They show up in the original eq: y'' - k1 y = k2 B + k3 w ( w is the wind disturbance). However, after the PID controller B is applied, the wind disturbance is nulled. I guess a large part of my confusion is how/why the roots were given as a function of error instead of position--and how to transform the error equation to position WITHOUT using/generating the need for y'' term feedback.

Yes, of course.

= 2

= 3

-- quasi-given--a PID

Not familiar with your SISO acronym--I'm assuming 'single input, single output'?
Not so simple--at least for a old beginner. Recall that the problem states that only y, ycmd and y' are measurable/observable...
If I substitute from e = ycmd -y =( c1 + c2 t - y) e' = ycmd' -y' = (C2 - y'), e'' = ycmd''-y'' = 0 - y'' = (-y'') , e''' = ycmd'''- y''' = 0 - y''' = -y'''
into the error dynamics equation:
e''' + 8e'' + 24e' + 32= 0
I get:
y''' + 8y'' + 24y' + 32y = -32 c1 - 8 c2 t
Given the problem measurability constraints I don't see how I can generate a block diagram for this equation without violating the measurability statements-- ie I need a feedback term for y''--namely the constant 8 at the first 1/s integrator output.
I don't want to impose on you-- but if you are OK with it I can email you a bitmap of my blk diagram. Attempting to draw one here in ascii is futile.
Hopefully this follow-up has given you some insight into my approach and how/why I am 'stuck'. How do I eliminate the need for a y'' term feedback?
Thanks again for your time and help. I'm not looking for the answeer on a platter--I want and NEED to understand this-- our mid-term is week after this :)
Bo

<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
bo wrote:

And using a nekkid differentiator, too. I was thinking "he must be implying a PD or PI -- I wasn't thinking that he was letting you use a bare 's' term. Oh well -- it's a classroom problem, right?

Yup.
Ahh. I think you're stuck in a rut. Here:
| |W | .------. .------. | U + E | | | | V Y ------>O---->| H(s) |---->| G(s) |---O---o---> A | | | | | -| '------' '------' | | | '---------------------------------' (created by AACircuit v1.28.6 beta 04/19/05 www.tech-chat.de)
It should be easy to see that
Y(s) H(s)G(s) ---- = ------------ U(s) 1 + H(s)G(s)
You can use the same block-diagram manipulations to find that
E(s) 1 E(s) ---- = ------------ = - ---- U(s) 1 + H(s)G(s) W(s)
Note that this does _not_ imply an error that goes to zero for all wind disturbances -- only for completely steady ones, and then only if you have that integral term in your controller.
But that's beside the point. The other thing to notice is that the denominator of all three of the transfer functions here (Y/U, E/U and E/W) will be the same -- which implies that all three transfer functions will have exactly the same poles. This is, in fact, a property of closed-loop control systems: assuming no pole-zero cancellations the poles are a characteristic of the _system_, not any one transfer function that pertains to it.
I suggest that you take the block diagram above, and consider how it may work in your case. I also suggest that you try stuffing a PID controller in there, and playing with various values of your P, I and D gains to see if you get the poles where they belong -- you should find that if you get them in the right spot for the error transfer function, they'll be in the same place for all.

--

Tim Wescott
Wescott Design Services
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Tim,
Just a quick note to let you know I'm "digesting" your follow up. Will play with it and follow-up with you hopefully tomorrow....
Sure wish you were available as a local tutor :)
Thanks,
Bo
wrote:

<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Tim,
Just letting you know I finally got _an_ answer. I used simulink and the thing worked pretty good--my only reservation was that I had to have/use a d/dt block to get the derivative of the input ycmd signal. I'm not 100% sure if this was OK per the problem statement. In general I understand the need to avoid a pure 's' term---but in the real world--is it, or is it not practical to assume that you know or can calculate the derivative of your commanded input in a servo-tracking situation? If not, I'm curious how one implements the 'D' term in a PID controller?
Bo

<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Bo wrote: (top posting fixed)

-- snip --

> Tim, > > Just letting you know I finally got _an_ answer. I used simulink and > the thing worked pretty good--my only reservation was that I had to > have/use a d/dt block to get the derivative of the input ycmd signal. > > I'm not 100% sure if this was OK per the problem statement. In general > I understand the need to avoid a pure 's' term---but in the real > world--is it, or is it not practical to assume that you know or can > calculate the derivative of your commanded input in a servo-tracking > situation? If not, I'm curious how one implements the 'D' term in a > PID controller? > > Thanks for your insights... > > Bo > Normally you calculate the 'derivative' of the error signal (command - output), or just the derivative of the output. You generally don't calculate the derivative of the command alone.
I put derivative in quotes because normally you don't try to implement a naked differentiator (practically you can't). Instead you implement a high-pass filter: T(s) = s / (a*s + 1). At low frequencies this 'looks' like a differentiator, but at high frequencies where a differentiator would amplify noise and every hink and kink in the plant output the gain levels off to some maximum.
This is why your three-pole system with a two-pole plant didn't say "PID" to me -- a practical PID controller would add _two_ poles (one for integration, one for differentiation), and a careful control system tuner would locate that differentiator pole as low as he could get away with, as part of the control system design.
--

Tim Wescott
Wescott Design Services