[From Bruce Abbott (2013.11.15 20:00 EST)]
Thanks, Richard, for the fix, and thanks, Rupert, for pointing out the
problem. I had noticed it myself and brought it to Bill's attention at the
time, but he didn't think it was serious enough to worry about discovering
why it was happening, since the point of the demo was to demonstrate a set
of control systems that would keep the inverted pole balanced. Where the
cart stopped when balance was achieved was really irrelevant, except that
one would want it to stay within the limits of the screen.
It wouldn't be much trouble for me to revise the Delphi version, but I
hesitate to do so because then it wouldn't match Bill's diagram of it in
LCSIII. I'd welcome some advice on this from CSGnetters.
Bruce
[From Richard Kennaway (2013.11.15 11:28 GMT)]
[From Rupert Young (2013.11.12 15.00 UT)]
I notice from the inverted pendulum demo (LCSIII) that the red line (bob
ref) is directly above the bob, when the cart and bob are in the middle of
the screen, but when they are over on the left, or right, and at rest, then
the red line is slightly off to one side, indicating that there is a
difference between the bob reference and actual position (this can also be
seen in the graph display).
Anyone know why it was done like this?
There's a steady-state error in Bill's original model, which I think comes
in at the middle level of his five-level controller. This controls bob
acceleration by setting a reference for cart position proportional to the
error in bob acceleration. This results in the steady state error.
Let b and c be the bob and cart positions, measured from some chosen zero
mark, and bdot, bdotdot, etc. be their derivatives. A prefixed e or r
indicates error and reference variables. In the steady state all the
derivatives are zero, and b=c. Let the reference bob position be rb.
I'll take the controllers to be purely proportional. In the steady state let
their be an error in the bob position of eb = rb - b. Then we have:
eb = rb-b
rbdot = k0 eb
ebdot = k0 eb because ebdot = rbdot - bdot, and bdot = 0 rbdotdot = k1
ebdot = k0k1 eb ebdotdot = k0k1 eb rc = k2 ebdotdot = k0k1k2 eb ec = k0k1k2
eb - c = k0k1k2eb - b rcdot = k3 ec = k3(k0k1k2eb - b) ecdot = k3(k0k1k2eb -
b) rcdotdot = k4 ecdot = k3k4(k0k1k2eb - b)
And finally, cdotdot = rcdotdot, because at the bottom level the actuator
delivers rcdotdot directly. For this to be zero we must have
eb = b/k0k1k2
which is the steady-state error. The bob will end up not quite reaching the
target.
In my version I used a different scheme which eliminates the middle
controller. Instead, the controller for bob acceleration has rbdotdot as its
reference and b-c as its perception, because to a first approximation, the
difference between bob and cart position is proportional to the bob
acceleration. The output of this controller is rcdot. For this scheme, the
steady state equations are these:
eb = rb-b
rbdot = k0 eb
ebdot = k0 eb because ebdot = rbdot - bdot, and bdot = 0 rbdotdot = k1
ebdot = k0k1 eb ebdotdot = rbdotdot - (b-c) = rbdotdot, since b=c in the
steady state.
rcdot = k2 ebdotdot = k2 rbdotdot = k0k1k2 eb ecdot = k0k1k2 eb rcdotdot =
k3 ecdot = k0k1k2k3 eb
So in the steady state where rcdotdot is zero, so is eb.
In the original five-level controller, it might also work to replace the
middle-level controller by one that sets the reference cart position to the
current bob position plus a constant times the bob acceleration error. I
made both changes at once -- using c-b instead of c, and also eliminating
the middle controller, because I saw that bob acceleration and c-b are
equivalent to each other. It doesn't take a control system to use the latter
to achieve the former, the latter is the former already.
-- Richard
···
--
Richard Kennaway, R.Kennaway@uea.ac.uk, Richard Kennaway
School of Computing Sciences, University of East Anglia, Norwich NR4 7TJ,
U.K.
-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.3426 / Virus Database: 3629/6838 - Release Date: 11/15/13