MCT and PCT Theodolite models

[From Bill Powers (970301.1450 MST)]

Hans Blom sent me his preliminary MCT model for the theodolite example,
asking me to add the graphics and return it, which I did. The MCT model
oscillated because of the limits put on the output, so I sent it back to
Hans to allow him to find the problem and fix it. However, this discussion
is of interest to CSGnet, so I think that from here on we should conduct the
exchanges in public.

To recap, I will reconstruct Hans' development of his model, mostly to make
it clearer in my own mind. This is a long derivation for which I apologize,
but if there are any conceptual errors they are very subtle and the only way
to show that they do or do not exist is to slog through the details.

Let r(t) = reference signal at time t
    x(t) = angle at time t
    a(t) = acceleration at time t
    v(t) = velocity at time t
    u(t) = torque at time t
    D(t) = estimated disturbing torque ("disturbance") at time t
            (using a cap D to avoid confusing D(t) with dt)
    J = moment of inertia of theodolite
    dt = time increment

The basic differential equation is

(1) J*d2x/dt^2 = u(t) + D(t)

To compute the second derivative on the basis of observed angles to date, we
take the difference between two velocities (first derivatives). Note that
the following is a little different from what Hans posted, although the
result is the same:

                      x*t) - x(t - dt)
(2) v(t - 0.5*dt) = -----------------
                            dt

                      x(t-dt) - x(t - 2*dt)
(3) v(t - 1.5*dt) = ----------------------
                              dt

The acceleration at time t-dt is the change in velocity divided by dt:

              v(t-0.5*dt) - v(t - 1.5*dt)
a(t - dt) = -----------------------------, or
                         dt

              [x(t) - x(t-dt)] - [x(t-dt) - x(t - 2*dt)]
a(t - dt) = ----------------------------------------------, or
                               dt

                   x(t) - 2*x(t - dt) + x(t - 2*dt)
(4) a(t - dt) = ------------------------------------
                               dt*dt

This acceleration at time t - dt, times the moment of inertia J, is equal to
the total applied torque at time t - dt:

     x(t) - 2*x(t - dt) + x(t - 2*dt)
J* ------------------------------------ = u(t - dt) + D(t - dt)
                  dt*dt

NOTE: at the time this equation holds true, we have observed the present
value of x(t), because t always denotes present time. However, we cannot
write the equation for the acceleration at time t, because it requires
calculations involving previous and future values of x. The acceleration we
calculate is always what existed on the _previous_ iteration, and thus the
equation always refers to the _previous_ values of u and D.

This equation can be used to estimate the value of x(t+dt) given u(t) and
D(t). Hans did this by first adding dt to indices on both sides of the equation:

     x(t+dt) - 2*x(t) + x(t-dt)
J* ------------------------------------ = u(t) + D(t).
               dt*dt

Solving for x(t+dt) given u(t) and D(t), we obtain the _prediction_

(5) x(t+dt) = [u(t) + D(t)]*dt*dt/J + 2*x(t) - x(t-dt).

The strategy of the MCT model is then to say that x(t+dt) is to be equal to
the reference signal r(t+dt), and to compute the value of u(t) that will
give this result. If x(t+dt) = r(t+dt), we then have

r(t+dt) = [u(t) + D(t)]*dt*dt/J + 2*x(t) - x(t-dt),

which we can solve for u(t). This is the _present_ value of u(t) which will
yield x(t+dt) = r(t+dt).

(6) u(t)= [r(t+dt) - 2*x(t) + x(t-dt)] * dt^2/J - D(t);

NOTE that x(t) is the result from the _previous_ iteration and the
_previous_ value of output, u(t-dt). The value of u(t) remains to be
estimated, and D(t) has not yet been established; when they are established,
they will determine the _next_ value of x, x(t+dt).

The initial value of D(t) is set to zero, and from then on it is found by
looking at the difference between x(t+dt) as predicted, and the value of
x(t+dt) obtained by observing the plant. The key to understanding the method
is that the "observation" of x uses an equation exactly the same as equation
(5), except that the true disturbance is used instead of the estimated
disturbance D(t). Any discrepancy between the predicted and actually
observed values of x must be due to an incorrect value of the
estimated D(t). Thus the assumed value of D(t) can be changed in the right
direction and by the right amount, at most one iteration late, on the basis
of the difference between the observed and predicted values of x(t+dt).

Obviously, if the method of predicting x(t+dt) does not exactly reflect the
input-output function of the plant, the estimated disturbance will be
adjusted automatically to make up for the difference. In the present case
the equations for the plant are identical to those used for the prediction,
so this problem does not arise.

···

-----------------------------------------
However (and I am afraid I must impose on your patience even more, here):

Just to see what would happen, I substituted equation (5) for the method of
integration used to convert torque into angular velocity and position in my
model. It didn't work! The model ran, but when I changed the value of dt,
the basic time increment, the model became slower or faster to respond,
instead of showing exactly the same response plotted with a different
density (as it should). This also happens in Hans' program -- the
oscillations it currently suffers change in frequency when dt changes, and
the time taken to reach the final state changes.

Just as a cross-check, I substituted MY method of computing the theodolite
response to torque for Hans' method, in his program. Now Hans' program
didn't work. In addition to the oscillations caused by limiting the output,
there was a persistent oscillation of output that didn't ever go away.

Perhaps Hans will find some simple mistake that will cure these problems. I
can't see what it would be, since equation (5) is derived in a
straightforward way. But I hope to hear from Hans soon (on CSGnet).

I don't want to post Hans' program until he has had an opportunity to fix
any errors in it, particularly those that cause oscillations when the output
is limited. When there is no limit to the output, the model works perfectly,
correcting the error due to a sudden change of reference signal in one
iteration. However, the torque required to do this, with dt set to 0.001
sec., is 250,000 newton-meters. Considering that the limit of 750
newton-meters is equivalent to the maximum torque of a large truck engine,
the output produced by Hans' model is somewhat ridiculous.

There is much more to say, but I will wait until Hans releases his model for
posting on CSGnet.

Best,

Bill P.

[From Bill Powers (9703020600 MST)]

Well, I've found one major problem with Han's theodolite model: it's
controlling theodolite angular velocity, not position. I couldn't understand
why his model of the environment shouldn't work in my simulation, so I
extracted it and put it into a test program. Applying a square wave of force
to its input, I expected to see a parabola of output, showing the angle
accelerating. Instead, I got a linear rise.

Hans, back to the drawing board!

Best,

Bill P.

···

===================================================================
program testint;

uses dos, crt, graph, grutils;

var x,y,dt,j,ylast,t: real;
    i,maxx,maxy: integer;
    ch: char;

begin
initgraphics;
maxx := getmaxx; maxy := getmaxy;
y := 0.0;
j := 1.0;
dt := 0.01;
t := 0.0;
repeat
   if (t< 3) or (t > 6) then x := 0 else x := 100.0;
   y := x*dt*dt/j + 2*y - ylast; {x is input force, y is position(?)}
   ylast := y;
   i := round(450*t/9.0);
   putpixel(i,maxy - round(x),white);
   putpixel(i,maxy - round(100*y),yellow);{output should be parabola{
   putpixel(i,maxy,white);
   t := t + dt;
  until t > 9.0;
  ch := readkey;
  closegraph;
end.

[Hans Blom, 970303c]

(Bill Powers (9703020600 MST))

Well, I've found one major problem with Han's theodolite model: it's
controlling theodolite angular velocity, not position. I couldn't
understand why his model of the environment shouldn't work in my
simulation, so I extracted it and put it into a test program.
Applying a square wave of force to its input, I expected to see a
parabola of output, showing the angle accelerating. Instead, I got a
linear rise.

Hans, back to the drawing board!

Bill, I don't understand this assumption (deduction?) of yours, and
it cannot be correct. Let's check the difference equation formula and
its time behavior. Simplified (all constants set to 1) it reads:

x(k+1) = 2*x(k) - x(k-1) + 1

where the 1 is the input that causes (or ought to cause?) constant
acceleration. Your assumption is that x(.) should be a parabola. It
is. Plug in

x(k) = t^2/2

then you find

x(k+1) = (t+1)^2/2 and x(k-1) = (t-1)^2/2

Plug in into the first formula and you get

(t+1)^2/2 = 2*t^2/2 - (t-1)^2/2 + 1

or

(t+1)^2 = 2*t^2 - (t-1)^2 + 2

or

t^2 + 2*t + 1 = 2*t^2 -[t^2 - 2*t + 1] + 2

or

t^2 + 2*t + 1 = t^2 + 2*t + 1

Mathematical identity. So formula (1) ought to be correct and
according to physics and your intuition as well...

Another way to show the same result is by constructing a table

x(k-1) x(k) x(k+1)=2*x(k) - x(k-1) + 1
------ ---- ------
  0 0 1
  0 1 3
  1 3 6
  3 6 10
  6 10 15
10 15 21
15 21 28

where the difference between entries in a row represents velocity.
Check that velocity increases linearly. If so, how does position
increase?

Greetings,

Hans

[Hans Blom, 970303d]

(Bill Powers (970301.1450 MST))

Hans Blom sent me his preliminary MCT model for the theodolite
example, asking me to add the graphics and return it, which I did.
The MCT model oscillated because of the limits put on the output, so
I sent it back to Hans to allow him to find the problem and fix it.

The problem is a problem because the model does not include self-
knowledge -- about the saturation. In other words, the controller
does not anticipate that the output will be limited and that this
will have severe effects. It controls for taking x to the reference
value as rapidly as possible. The result is overshooting and
oscillatory behavior. This nonlinear behavior is a real phenomenon,
not just a computational artifact. It could be eliminated by choosing
a more complex model and/or control law.

To recap, I will reconstruct Hans' development of his model, mostly
to make it clearer in my own mind.

Good work, except that some formulas got garbled. Bad mail reader?
The result is correct:

    x(t) - 2*x(t - dt) + x(t - 2*dt)
J* ------------------------------------ = u(t - dt) + D(t - dt)
                 dt*dt

as well as the conclusion:

The strategy of the MCT model is then to say that x(t+dt) is to be
equal to the reference signal r(t+dt), and to compute the value of
u(t) that will give this result.

Just to see what would happen, I substituted equation (5) for the
method of integration used to convert torque into angular velocity
and position in my model. It didn't work!

This requires closer investigation.

The model ran, but when I changed the value of dt, the basic time
increment, the model became slower or faster to respond, instead of
showing exactly the same response plotted with a different density
(as it should). This also happens in Hans' program -- the
oscillations it currently suffers change in frequency when dt
changes, and the time taken to reach the final state changes.

I expect that these changes are not due to the choice of dt, but to
the saturation of the controller. Its effect is much more severe than
I initially expected, and its effect is different in the PCT and in
the MCT controller. In this respect, we chose a bad example that
complicates our basic comparison far too much.

Perhaps Hans will find some simple mistake that will cure these
problems. I can't see what it would be, since equation (5) is
derived in a straightforward way. But I hope to hear from Hans soon
(on CSGnet).

I propose a different example where the output does not saturate. Or
we could remain at this example but remove the output limitation,
even though this would make the example physically very unrealistic,
as Bill notes. If we look beyond that, we have a fine example.

The effect of output limitations is, to me, something that ought to
be considered independently. Bill, please check and remove the output
limitation from the PCT controller as well. In that case I expect the
effect of changes in dt in your now-nonlinear PCT controller to go
pretty much away in the closed loop case...

Greetings,

Hans

[From Bill Powers (970303.1151 MST)]

Hans Blom, 970303d --

The problem is a problem because the model does not include self-
knowledge -- about the saturation. In other words, the controller
does not anticipate that the output will be limited and that this
will have severe effects. It controls for taking x to the reference
value as rapidly as possible. The result is overshooting and
oscillatory behavior. This nonlinear behavior is a real phenomenon,
not just a computational artifact. It could be eliminated by choosing
a more complex model and/or control law.

...

I propose a different example where the output does not saturate. Or
we could remain at this example but remove the output limitation,
even though this would make the example physically very unrealistic,
as Bill notes. If we look beyond that, we have a fine example.

I would MUCH prefer to stick to a realistic example. One of my (still-valid)
criticisms of the MCT model is that it is allowed to generate extremely
large output forces; I have maintained that the one-iteration error
correction claimed for an MCT model is possible only with unrealistic levels
of output. I think we have settled that question: one-jump error correction
is not possible in a physical system.

If you want to put the required "self-knowledge" into your MCT model,
that's OK with me. However, we can restrict the required output in a
different way.

One method is to change the reference signal in a more reasonable way
instead of having it jump instantly from one value to another. I suggest using

r := r + 20.0*(r0 - r)*dt,

where r0 is the switched reference signal and r is the reference signal
actually used. With dt set to 0.01 sec, this calls for a change of pointing
angle of 1 radian with a time constant of 0.05 seconds (I think we can
standardize on dt = 0.01 sec; the point I wanted to make about reducing dt
has been made (the peak torque required goes as 1/dt)).

The initial velocity required will be much smaller, with the initial
acceleration also much smaller. This means that the theodolite will execute
95% of the swing in 0.15 seconds, a very fast movement. With a moment of
inertia of 1.0 n-m^2, this still calls for a peak torque of around 400 n-m,
a pretty hefty torque (over 125 foot-pounds).

However, if we increase the moment of inertia J to 10 n-m^2, the effect of
the limit will return. So all things considered, I think it would be best
for you to include the limit in the simulation of the environment.

Note that one of the things I want to try next is looking at the effect of
errors of computation. But first we have to see both models running correctly.

I have come across another interesting effect. The theodolite is, of course,
a physical system; when a torque is applied, it accelerates smoothly. In our
models we represent this acceleration with a discrete equation, and our
control systems change the output u, and sample the angle, only at
intervals. What I tried was to run the physical equations with a much
smaller and constant dt of about 1e-4 sec, so computational errors of
integration would become negligible in the part of the model representing
the physical theodolite. This turned out to make a significant difference in
the operation of the model, when dt was as large as 0.01 sec. We want the
physical model of the theodolite to respond to torques as realistically as
possible, and not for its behavior to depend on the sampling rate with which
the control system works.

There's no need to make this change right now, but when we start estimating
the effects of computational errors, one effect we have to consider is
sampling rate, which is like taking delays into account.

Best,

Bill P.

···

The effect of output limitations is, to me, something that ought to
be considered independently. Bill, please check and remove the output
limitation from the PCT controller as well. In that case I expect the
effect of changes in dt in your now-nonlinear PCT controller to go
pretty much away in the closed loop case...

Greetings,

Hans