MCT = PCT ?

[HANS_BLOM2]

------------------- ASCII.ASC follows --------------------
[Hans Blom, 970219]

(Bill Powers (970215.1911 PST))

Rick Marken and I decided to try to write a Pascal model of Hans' MCT
system to demonstrate the drift that would occur because of a small
error in the model. Imagine our surprise: it didn't happen. In fact, the
system behaved exactly as it should, the plant output x following
changes in the reference signal r. Maybe a little offset occurred
because of the assumed computational error, but nothing important.
Egads!

Good to hear. Now we can maybe start to discuss the important things ;-).

Rick said, when he first looked at Hans' equations, "Why, this is just a
closed-loop system!" But I didn't see it right away. We talked it over
for a hour while my brain twisted slowly in the wind. And then I, too,
saw it.

Great. Rick wasn't too far off the mark when he said that he recognized a
"simple proportional control system". It is that, too, but it is
different from a standard proportional controller in that it is "tuned"
or "adapted": its gain is exactly right.

Nice to see what a vacation can do. Let's discuss some remaining
misunderstandings.

u(k) = [r(k+1)-x(k)] / (a*dt)

Look at the argument in brackets: r(k+1)-x(k). Where did that x(k) come
from? The variable x(k) is the state of the output of the plant, the
controlled variable. This value is being used by the control system. So
how does the control system know the value of x? There's only one
possible answer: x is being SENSED by the control system.

Not too hasty! We're not finished yet! We've only started! You are right
in so far as this is the situation I described in my post: I assumed that
x is sensed at all times. But must that necessarily be so? No. Warning:
I'm adding a new twist; we're entering the terrain of "walking in the
dark". Let me explain.

Remember that we have a model, and that we can use it. In our example it
was

  x(k+1) = x(k) + a*dt*u(k)

and, as I said in my earlier post, it has the character of a prediction.
At time instant k and given x(k) and u(k), we already "know" the value of
x(k+1); that makes it prediction. Now assume that we are at time instant
k, but somehow the observation x(k) is missing, e.g. because we weren't
looking. What can we do? Well, we can use the above formula to "recreate"
(an estimate of) x(k) given our knowledge of x(k-1) and u(k-1):

  x(k) = x(k-1) + a*dt*u(k-1)

If the model is good, i.e. the modeling error is small, this
reconstruction will be good as well. We can similarly reconstruct even
_sequences_ of missing observations, but in this case errors due to what
you call "error integration" will start to play a role.

So I need to amend your statement to: There are two possible answers: (1)
x is being SENSED by the control system, and (2) x is being GENERATED by
the internal model. But even that is still far too black-and-white. In
psychological reality -- and in standard MCT control schemes -- there is
probably always a mix of the two: some perceptions are actively sensed by
the controller, whereas others are provided/generated/predicted by the
internal model.

Try such reconstructions out: discard, say, every second "perception" and
replace it by a reconstruction using the above formula. Such a scheme
will continue to work well. To see how rapidly the reconstruction method
degenerates, discard a sequence of N perceptions and then process some
perceptions again. As N increases, you will discover ever greater errors
(in the example the error increases indefinitely, but this often isn't
the case -- perhaps surprisingly: often the "prediction error" reaches an
upper bound). This is, essentially, "walking in the dark".

The lack of drift due to computational errors is thus explained: this is
the closed-loop PCT model!

In its "optimal" form: the controlled variable goes to the specified
reference value (1) in one step and (2) without error and (3) even if the
reference value changes over time in whichever way (assuming no
limitations on u).

In looking for a simple plant, I ended up with an unrealistic model.

No, the model was fine. You just forgot how little can be done (in terms
of achieving one's goal) in a very short time given limited means.

Now the big question comes to mind: has this use of x been present in
ALL the "MCT" models we've talked about?

No. Remember that we discussed an EXAMPLE. In that example I presupposed
a perfect, i.e. noise-free model. In the more general case where the
perception is contaminated by "observation" noise, x will not be equal to
the perception itself but to an internally model-generated, filtered
version of it, in order to cancel the noise.

I'm not in a position to search through past posts just now, but my
memory says yes: in every case, the current perceived value of x has
entered into the computation of u.

You incorrectly equate x with the current perceived value. It is not, in
general, and I've also discussed such a more general case. The equality
between x and p holds only if the perception is not noisy; also, it does
not hold when a perception is missing, of course. In every case, x refers
to a variable that is "simulated" by the internal model, NOT to a
perception of the "world out there". It is only when we also and
independently know that we can perceive the "world out there" without
error (observation noise), that we know that the prediction by the
internal model must necessarily coincide with the perception -- in the
sense that if it is not, the model must be further adjusted.

Basically, the MCT system uses closed-loop feedback control _of the
simulated plant_.

That's a good way of thinking of it. Remember that in real-life control
the "true" characteristics of the plant are unavailable and that we
necessarily have to work with a modeled or "simulated" plant.

I emphasize that this will not give us a _practical_ control system,
because this solution results in correcting an error in a single
instantaneous jump, which is not possible in any physical system.

Have you checked what happens if you specify an unrealistic goal? In the
theodolite example, specify r(k+1) to be equal to the final desired
position for all k. Even if the output is limited, control will be fine
(in this case, not necessarily in _all_ cases!) -- in the sense that the
goal will be realized as rapidly as is physically possible. It is fine to
specify unrealistic goals, but only if one has patience ;-).

If the magnitude of u is given realistic limits, and if the internal
simulation duplicates the physical dynamics of the plant, however, it
would be possible to arrive at SOME calculation of u that would result
in good control without violating physics.

In many cases of saturation of u, u will just be given the maximum or
minimum physically realizable value. Rather intuitive, not?

At long last, the MCT model is beginning to make sense in terms of the
PCT model. The basic control loop is exactly the same in both models,
and the problem of converting an error signal into an appropriate output
is also exactly the same.

Beware of hasty generalizations! Remember that my example treated a
special case. In particular, things get a bit more complicated if there
are modeling errors ("system noise") or perceptual errors ("observation
noise").

There are two primary differences. One is that the MCT model actually
controls a simulated perception generated by a simulation of the plant
function, rather than the plant's actual output.

Such a "filtered" perception is very useful if the plant's perception is
noise-corrupted.

The other is that any unmodeled disturbances acting on the real plant
can't be opposed by the MCT control system because it can't oppose
disturbances that aren't included in the simulation.

That is right. Informally said: the quality of control depends on how
accurately we can predict the future -- as a function of our actions. But
also note that what PCT considers "disturbances" can often themselves be
modeled successfully, as I have demonstrated in the past. That is
possible because the disturbances that you normally consider are not
fully random ("white noise").

Under what circumstances would the MCT model work better than the PCT
model?

I have answered that question as follows, in the context of the example:
The MCT model works better because the controlled variable goes to the
specified reference value (1) in one step and (2) without error and (3)
even if the reference value changes over time in whichever way (assuming
no limitations on u). Neither (1) and (3) are true for PCT models, and
(2) generally takes more time in PCT controllers.

The MCT system controls a simplified and noise-free simulation of the
environment, so its control of the simulation can be very good.

Beware: When is a PCT "environmental function" NOT "a simplified and
noise-free simulation of the environment"? Does a PCT controller have
access to the "true" characteristics of the environment? It is only in
_simulations_ that the "real" thing is available; this point gets easily
lost when all one does are simulations.

The key (philosophical) distinction between MCT and PCT seems to be that
MCT explicitly recognizes that the characteristics of the environment
itself are inaccessible and that they have to be somehow "constructed",
i.e. modeled, by or for the controller or organism.

However, when there is a lot of random variation in the real
environment, and when the real environment is being perceived only
intermittently, the environment is going to deviate from the simulation,
and nothing can be done about those deviations. They are simply ignored.

Now you suddenly talk psychology ;-).

A final question. You said:

Rick said, when he first looked at Hans' equations, "Why, this is just a
closed-loop system!" But I didn't see it right away. We talked it over
for a hour while my brain twisted slowly in the wind. And then I, too,
saw it.

Do you have a -- retrospective -- explanation why it is sometimes so
utterly difficult to understand the "meaning" of a few extremely simple
formulas?

Greetings,

Hans

[Bill_Powers1]

[From Bill Power 970219.0600 MST)]

Hans Blom, 970219 --

Great. Rick wasn't too far off the mark when he said that he recognized a
"simple proportional control system". It is that, too, but it is
different from a standard proportional controller in that it is "tuned"
or "adapted": its gain is exactly right.

There is nothing to prevent the designer of a "standard proportional
controller" from adjusting the gain to the same value. When we study
fully-adapted human control systems (as in the tracking experiments), that
is essentially what we are doing. The human being, after sufficient
practice, controls in a way that can be represented by a simple control
system with fixed parameters. We don't need to address the problem of how
those parameters arrived at those values; in fact, we are establishing by
such studies just what any adaptive model would have to accomplish; it would
have to generate the same parameters, as the end-point of whatever adaptive
process is involved in learning to control.

The difference in the adaptive system is not that the gain can be adjusted
to an "optimum" value, but that the system can do this adjusting by itself
for whatever environment happens to be present. That is an important
feature, and I don't want to minimize it. However, we need to keep this
question separate from the present discussion of the form of the control
system itself. We can do this by putting aside for the moment the relation
between the model's simulation and the properties of the real plant, and
talking about the optimum way of controlling the _simulated_ plant. This
does not involve switching back and forth between the real x and the
simulated x', nor does it involve discussions of uncertainties and noise.
I understand what you are saying about controlling the stimulation as a way
of getting around noise and intermittent observation of the real plant. But
let's just focus on how the MCT model controls a simulation of the plant,
given that the simulation accurately represents the properties of the real
plant.

To make the stimulation realistic, we must include a representation of a
typical independent disturbance of arbitrary waveform. I'm not arguing now
whether such a simulation of a disturbance can actually be accomplished;
let's just suppose that it can. This means that our diagram of the control
system is

                                 ref
                                  >
                      --x'----->[comp] --error -->-
                     > >
                     > [Output Function]
                     > >
                     > u
                     > + (simulated plant) |
                      <---------f(u) <-------------
                     ^ |
                     >+ (to real plant)
           Simulated d

This is the block diagram of the part of the MCT model that controls a
simulation of the plant (now showing what I omitted before, the feedback
connection from x'). It is identical to the PCT diagram. In MCT diagrams the
real d is taken to be a high-frequency noise with a certain variance, but
here we are talking about a low-frequency disturbance which the system can
cancel by varying u in the proper way. In fact d can even be an additive
constant, or contain a constant term. It has to be part of the simulation
since it varies within the control bandwidth of the system.

In your approach, you compute what u must be in order for the error to be
zero. From the diagram we can read off the required condition: f(u) + d = r.
If we can solve this equation for u, we have the answer.

An interesting question arises when we look at the diagram above. This is
exactly the sort of diagram that old-fashioned control system engineers
would have used. Why didn't they think of simply solving the system
equations for the necessary value of u? Is it conceivable that this simple
approach was overlooked? I don't think so. If it was considered, it was
rejected. Why?

I have some ideas about this, but will leave them for a later time.

Do you have a -- retrospective -- explanation why it is sometimes so
utterly difficult to understand the "meaning" of a few extremely simple
formulas?

Yes. The formulas alone don't reveal the structure of the system. I was
perfectly willing to accept that the output computation used the value of x
(or x'), because mathematically that made sense. But it wasn't self-evident
that in order for this computation to be done, the computer had to receive
information continuously about the state of x. When you draw a block
diagram, you have to account for the source and destination of all
information used in the system. If I had actually done that, I would have
seen that x was unaccounted for.

Best,

Bill P.

[HANS_BLOM2]

[Hans Blom, 970220]

(Bill Power 970219.0600 MST))

I do not understand your diagram:

                                 ref
                                  >
                      --x'----->[comp] --error -->-
                     > >
                     > [Output Function]
                     > >
                     > u
                     > + (simulated plant) |
                      <---------f(u) <-------------
                     ^ |
                     >+ (to real plant)
           Simulated d

This is the block diagram of the part of the MCT model that controls
a simulation of the plant (now showing what I omitted before, the
feedback connection from x'). It is identical to the PCT diagram.

What you "feed back" to the system in this diagram are two things,
both simulated, i.e. internally generated. There is no feedback/
perception from the environment. So this diagram applies to "walking
in the dark". But we were definitely NOT discussing that. Why do you
present this diagram? I discussed the case where a perception of what
goes on in the environment is available at all times. That perception
does not show up. Why is that? How would you modify the diagram to
include it?

Greetings,

Hans

[Bill_Powers1]

[From Bill Powers (970220.0710 MST)]

Hans Blom, 970220 --

I do not understand your diagram:

                                ref
                                 >
                     --x'----->[comp] --error -->-
                    > >
                    > [Output Function]
                    > >
                    > u
                    > + (simulated plant) |
                     <---------f(u) <-------------
                    ^ |
                    >+ (to real plant)
          Simulated d

This is the block diagram of the part of the MCT model that controls
a simulation of the plant (now showing what I omitted before, the
feedback connection from x'). It is identical to the PCT diagram.

What you "feed back" to the system in this diagram are two things,
both simulated, i.e. internally generated. There is no feedback/
perception from the environment. So this diagram applies to "walking
in the dark". But we were definitely NOT discussing that. Why do you
present this diagram? I discussed the case where a perception of what
goes on in the environment is available at all times. That perception
does not show up. Why is that? How would you modify the diagram to
include it?

Sorry, my mental leap wasn't adequately explained. The above diagram would
apply to the situation you're talking about if the f(u) were the actual
plant function and there were no internal simulation going on. Then x' would
be the actual perception of x. I decided that the same problem could be
addressed if we dealt with the simulation instead of the real environment,
without getting into details such as noise and intermittent observation. The
difference between our approaches to analyzing the control loop is more
easily seen when we deal with a well-behaved environment, so we don't get
into issues like adaptation and so on. If you wish, you can simply relabel
the above diagram so it refers to control of the real environmental
variable, with the real disturbance acting.

What you're doing is solving the equations for u, to obtain the value of u
that will make x exactly match r. In doing this you are treating the whole
system as a mathematical problem instead of as a problem of assembling
physical components that interact with each other to produce control. You
will notice that in the above diagram, if x = r, then the error signal input
to the output function is exactly zero. This means that the output function
must convert a zero input into a nonzero value of u, in order to maintain x
at the same value as r (after the initial move that corrects the error). If
you were thinking of the output function as a physically distinct process,
this would clearly be impossible: the system would oscillate back and forth
between error and no error. First the output u would come to the value that
makes x = r, exactly opposing the disturbance. Then, because the error is
zero, the output would become zero, and the disturbance (still present)
would cause an error again, and so forth.

However, your way of computing u, being purely mathematical, doesn't produce
this oscillating result. You go through the manipulations of solving for u
once, and that's the end of it. These manipulations are not shown in the
system diagram; there is no provision there for a computer that can do them.
They are done by you, not by your model. This is why you don't recognize the
extreme complexity of your model: most of the complexity exists in the
operations that you perform behind the scenes, and that the model itself
doesn't have to perform.

This is why the output function you derive MUST include a model of the
disturbance. When the input to the output function, the error, is zero, the
output u must, after transformation through f(u), produce an effect equal
and opposite to the disturbance. The only way to do this is to include a
signal generator in the output function that creates a counter-disturbance.
Without this special signal-generator, your model would have no way to avoid
oscillations.

In the PCT model, ALL the computations that are done are represented in the
model; there are no other computations being done behind the scenes. The
model, not the modeler, performs these computations.

···

-------------------------------
I have had a look at two of the papers you recommended, the ones dealing
with the application of MCT to control of a hydraulic crane. About the only
relation to MCT (as you have described it) that I can see is that the effect
of force disturbances on the position of the tip of the crane is derived by
using a simplified model of the crane arm. It is explicitly said that this
is done because the actual position of the tip can't be measured directly.
Disturbances show up as variations in hydraulic piston pressure, and from
these and the elastic properties of the crane arm the effect of the
disturbance on tip position is calculated. This calculated deflection is
then added to the reference signal to compensate for the disturbance.

Aside from the mathematical treatment, which as usual I can follow in
outline but not in detail, this approach looks straightforward and even
old-fashioned; an engineer is simply solving a problem within the
constraints offered by the existing system. Most of the complexity could
have been avoided if the position of the tip of the crane could have been
sensed; if I were given this problem, my first step would be to devise some
mechanical or optical method of monitoring tip position. This would probably
work better, since it wouldn't involve all the approximations needed to make
the equations tractable. But I'm sure the authors' approach worked
adequately for the practical application.

I notice that the authors ended up using a simple hierarchy of control: to
keep the required piston movement from running away, they used real-time
feedback control of piston pressure (without any simulation intervening).

As in many other encounters with theoretical control engineering, I was
struck by the haste with which the authors passed over the basic discussion
of the physical system. The aim seems to be to get into the mathematics as
quickly as possible. Since I am not facile with the mathematics, I tend to
spend a great deal more time thinking about the physical system, trying to
identify the actual control problem so I can, with luck, find a relatively
simple way to carry it out. So while I am awed by demonstrations of
mathematical expertise, and often have wished that I had mastered such
things, I also feel the the approach I have been forced to use sometimes
results in a better basic design.

Best,

Bill P.

[HANS_BLOM2]

[Hans Blom, 970220c]

(Bill Powers (970220.0710 MST))

If you wish, you can simply relabel the above diagram so it refers
to control of the real environmental variable, with the real
disturbance acting.

Show me how. I can't do it if I am to leave the meaning of my
formulas intact.

What you're doing is solving the equations for u, to obtain the
value of u that will make x exactly match r. In doing this you are
treating the whole system as a mathematical problem instead of as a
problem of assembling physical components that interact with each
other to produce control.

Bill, I've shown you IMPLEMENTATIONS! Admittedly in a computer, but a
transformation in terms of any (general enough) set of basic
components would of course also be possible. I'm not just presenting
the solution to a MATHEMATICAL problem, the solution has to be
physically realizable as well. That is a constraint that is automatic
when designing a controller.

You will notice that in the above diagram, if x = r, then the error
signal input to the output function is exactly zero. This means that
the output function must convert a zero input into a nonzero value
of u, in order to maintain x at the same value as r (after the
initial move that corrects the error). If you were thinking of the
output function as a physically distinct process, this would clearly
be impossible: the system would oscillate back and forth between
error and no error. First the output u would come to the value that
makes x = r, exactly opposing the disturbance. Then, because the
error is zero, the output would become zero, and the disturbance
(still present) would cause an error again, and so forth.

I do not understand this argument. It does not apply, for instance,
to the case when the output function is a simple integrator.

However, your way of computing u, being purely mathematical, doesn't
produce this oscillating result.

PCT models routinely have an integrator as the output function. They
don't produce "this oscillating result", either.

This is why the output function you derive MUST include a model of
the disturbance.

Let's leave the subject of disturbances alone for now, shall we?
We'll come to that in due time, and it will open a completely fresh
can of worms. Let's first get the basics straight: control in case of
a perfect model and no disturbances.

I have had a look at two of the papers you recommended, the ones
dealing with the application of MCT to control of a hydraulic crane.
About the only relation to MCT (as you have described it) that I can
see is that the effect of force disturbances on the position of the
tip of the crane is derived by using a simplified model of the crane
arm.

I mentioned the article because it shows the MCT design process and
all the assumptions that underly it. And also to show that MCT leads
to practical results. And that in an attempt to show that it is not
all foolishness and thought experiments only...

Most of the complexity could have been avoided if the position of
the tip of the crane could have been sensed; if I were given this
problem, my first step would be to devise some mechanical or optical
method of monitoring tip position.

Adding another sensor, huh? This method shows that some quantities
can be "measured" using the existing sensors. Such "measurements" are
called _indirect_ measurements. Examples of indirect measurements can
be found in all layers of an HPCT hierarchy except the lowest. So why
object to them here? Their usefulness in this example demonstrates
what HPCT attempts to demonstrate more generally.

Since I am not facile with the mathematics, I tend to spend a great
deal more time thinking about the physical system, trying to
identify the actual control problem so I can, with luck, find a
relatively simple way to carry it out.

Your "thinking about the physical system" goes by the name of (semi-)
physical modeling. There are some articles about that as well where
you found the crane article. This type of modeling is in terms of
already-existing (physical) knowledge. It is like designing a PCT
controller given the fact that lower layers are available already.
Fine, if possible. It is impossible, however, if no prior knowledge
is available. In that case, we can find "black box" models which
describe input-output relationships without needing prior knowledge.
In a standard control context, not much attention is paid to systems
that have the type of "physical knowledge", that you refer to, built
in. That is still considered AI.

So while I am awed by demonstrations of mathematical expertise, and
often have wished that I had mastered such things, I also feel the
the approach I have been forced to use sometimes results in a better
basic design.

Fine. But for the time being, it seems pretty hard to implement this
type of "design knowledge" into (adaptive) controllers themselves.
You are clever, all right, and you can come up with good controllers
by "thinking" and trial-and-error. I'm trying to design systems that
are clever in their own right. That's a wholly different thing...

Greetings,

Hans

[Bill_Powers1]

[From Bill Powers (970220.1445 MST)]

Hans Blom, 970220c--

If you wish, you can simply relabel the above diagram so it refers
to control of the real environmental variable, with the real
disturbance acting.

Show me how. I can't do it if I am to leave the meaning of my
formulas intact.

The f(u) in the diagram is the plant described by my equation

dx/dt = A*u(t)*dt

and that you wrote as a difference equation,

x(k+1) - x(k) = A*dt*u(k).

The "Output Function" in my diagram is the equation you derived:

u(k) = [r(k+1) - x(k)]/(A*dt).

The comparator in my diagram computes an error signal, e[k+1], which is

e[k+1] = r(k+1) - x(k), so that

u(k+1) = e(k+1)/(A*dt)

(I think your equation should have referred to u(k+1)).

For comparison, the PCT model would be formally identical, except that we
would use the integral equation

x[t+dt] = x(t) + A*u(t)*dt

with t + dt as the index, and in computing u we would use a gain factor G
instead of 1/(A*dt):

u(t+dt) = [r(t+dt) - x(t)]*G

In doing iterations, we would advance the time t by dt on every iteration.
Thus shrinking the size of dt would simply put the data points closer
together in time, without changing the behavior of the variables.

Let's switch to using the cruise control as the example. Suppose the car has
a mass M, and that the output is measured in terms of an accelerating force
F(t) applied to the car (Rupert, this is for you). The variable v is the
velocity of the car, and r is the reference velocity. Thus

dv/dt = F(t)/M, or

v(t+dt) = v(t) + F(t)*dt/M.

In the PCT model, the force would be

F(t+dt) = G*[r(t+dt) - v(t)],

and in your model,

F(k+1) = [r(k+1) - v(k)]*M/dt.

Here is a pascal program that exercises the PCT model:

···

===========================================================================
program cruise;

uses dos, crt;

var u,v,f,m,g,r,t,dt: real;
    i,oldtime: integer;
    ch: char;
    datafile: text;
begin
v := 0;
r := 30; { meters per second}
m:= 2000; {Kilograms}
g := 1000.0; {Newtons per m/sec error}
dt := 0.1; {sec}
t := 0.0;
clrscr;
assign(datafile,'\datafile');
rewrite(datafile);
for i := 0 to round(24.0/dt) do
  begin
  v := v + f/m*dt;
  f := g*(r - v);
  if f > 4000.0 then f := 4000.0;
  if abs((t - int(t+dt/10))) < 0.00001 then
   begin
    writeln('t = ',t:5:1,' sec v = ',v:4:1,' m/sec f = ',f:6:1,' newton');
    writeln(datafile,'t = ',t:5:1,' sec v = ',v:4:1,' m/sec f =
',f:6:1,' newton');
   end;
   t := t + dt;
  end;
  ch := readkey;
  close(datafile);
end.

To make this realistic, the force output is limited to 4000 newtons (an
acceleration of about 0.2 g maximum).

The results are as follows, for dt set to 0.1, 0.01, and 0.001 sec:

======================================================
DT = 0.1 sec:

t = 0.0 sec v = 0.0 m/sec f = 4000.0 newton
t = 1.0 sec v = 2.0 m/sec f = 4000.0 newton
t = 2.0 sec v = 4.0 m/sec f = 4000.0 newton
t = 3.0 sec v = 6.0 m/sec f = 4000.0 newton
t = 4.0 sec v = 8.0 m/sec f = 4000.0 newton
t = 5.0 sec v = 10.0 m/sec f = 4000.0 newton
t = 6.0 sec v = 12.0 m/sec f = 4000.0 newton
t = 7.0 sec v = 14.0 m/sec f = 4000.0 newton
t = 8.0 sec v = 16.0 m/sec f = 4000.0 newton
t = 9.0 sec v = 18.0 m/sec f = 4000.0 newton
t = 10.0 sec v = 20.0 m/sec f = 4000.0 newton
t = 11.0 sec v = 22.0 m/sec f = 4000.0 newton
t = 12.0 sec v = 24.0 m/sec f = 4000.0 newton
t = 13.0 sec v = 26.0 m/sec f = 4000.0 newton
t = 14.0 sec v = 27.6 m/sec f = 2394.9 newton
t = 15.0 sec v = 28.6 m/sec f = 1433.9 newton
t = 16.0 sec v = 29.1 m/sec f = 858.6 newton
t = 17.0 sec v = 29.5 m/sec f = 514.0 newton
t = 18.0 sec v = 29.7 m/sec f = 307.8 newton
t = 19.0 sec v = 29.8 m/sec f = 184.3 newton
t = 20.0 sec v = 29.9 m/sec f = 110.3 newton
t = 21.0 sec v = 29.9 m/sec f = 66.1 newton
t = 22.0 sec v = 30.0 m/sec f = 39.6 newton
t = 23.0 sec v = 30.0 m/sec f = 23.7 newton

DT = 0.01 Sec.

t = 0.0 sec v = 0.0 m/sec f = 4000.0 newton
t = 1.0 sec v = 2.0 m/sec f = 4000.0 newton
t = 2.0 sec v = 4.0 m/sec f = 4000.0 newton
t = 3.0 sec v = 6.0 m/sec f = 4000.0 newton
t = 4.0 sec v = 8.0 m/sec f = 4000.0 newton
t = 5.0 sec v = 10.0 m/sec f = 4000.0 newton
t = 6.0 sec v = 12.0 m/sec f = 4000.0 newton
t = 7.0 sec v = 14.0 m/sec f = 4000.0 newton
t = 8.0 sec v = 16.0 m/sec f = 4000.0 newton
t = 9.0 sec v = 18.0 m/sec f = 4000.0 newton
t = 10.0 sec v = 20.0 m/sec f = 4000.0 newton
t = 11.0 sec v = 22.0 m/sec f = 4000.0 newton
t = 12.0 sec v = 24.0 m/sec f = 4000.0 newton
t = 13.0 sec v = 26.0 m/sec f = 4000.0 newton
t = 14.0 sec v = 27.6 m/sec f = 2423.1 newton
t = 15.0 sec v = 28.5 m/sec f = 1467.8 newton
t = 16.0 sec v = 29.1 m/sec f = 889.2 newton
t = 17.0 sec v = 29.5 m/sec f = 538.6 newton
t = 18.0 sec v = 29.7 m/sec f = 326.3 newton
t = 19.0 sec v = 29.8 m/sec f = 197.7 newton
t = 20.0 sec v = 29.9 m/sec f = 119.7 newton
t = 21.0 sec v = 29.9 m/sec f = 72.5 newton
t = 22.0 sec v = 30.0 m/sec f = 43.9 newton
t = 23.0 sec v = 30.0 m/sec f = 26.6 newton

DT = 0.001 sec.

t = 0.0 sec v = 0.0 m/sec f = 4000.0 newton
t = 1.0 sec v = 2.0 m/sec f = 4000.0 newton
t = 2.0 sec v = 4.0 m/sec f = 4000.0 newton
t = 3.0 sec v = 6.0 m/sec f = 4000.0 newton
t = 4.0 sec v = 8.0 m/sec f = 4000.0 newton
t = 5.0 sec v = 10.0 m/sec f = 4000.0 newton
t = 6.0 sec v = 12.0 m/sec f = 4000.0 newton
t = 7.0 sec v = 14.0 m/sec f = 4000.0 newton
t = 8.0 sec v = 16.0 m/sec f = 4000.0 newton
t = 9.0 sec v = 18.0 m/sec f = 4000.0 newton
t = 10.0 sec v = 20.0 m/sec f = 4000.0 newton
t = 11.0 sec v = 22.0 m/sec f = 4000.0 newton
t = 12.0 sec v = 24.0 m/sec f = 4000.0 newton
t = 13.0 sec v = 26.0 m/sec f = 4000.0 newton
t = 14.0 sec v = 27.6 m/sec f = 2425.8 newton
t = 15.0 sec v = 28.5 m/sec f = 1471.1 newton
t = 16.0 sec v = 29.1 m/sec f = 892.2 newton
t = 17.0 sec v = 29.5 m/sec f = 541.1 newton
t = 18.0 sec v = 29.7 m/sec f = 328.1 newton
t = 19.0 sec v = 29.8 m/sec f = 199.0 newton
t = 20.0 sec v = 29.9 m/sec f = 120.7 newton
t = 21.0 sec v = 29.9 m/sec f = 73.2 newton
t = 22.0 sec v = 30.0 m/sec f = 44.4 newton
t = 23.0 sec v = 30.0 m/sec f = 26.9 newton

Note that changing dt makes only a small difference in the computed behavior
of the car, although the results appear to be converging to some limit as dt
gets smaller. The 24th line didn't print out completely, so I chopped the
results off at 23 sec. Not worth the time to find the bug.

Hans, I leave it to you to try a similar test of your model. I think you
will find some difficulties when you change dt. You might want to revise
your equations somewhat.

Best,

Bill P.

[Martin_Taylor3]

[Martin Taylor 970220 14:10]

Bill Powers (970220.0710 MST)] to Hans Blom

You
will notice that in the above diagram, if x = r, then the error signal input
to the output function is exactly zero. This means that the output function
must convert a zero input into a nonzero value of u, in order to maintain x
at the same value as r (after the initial move that corrects the error). If
you were thinking of the output function as a physically distinct process,
this would clearly be impossible: the system would oscillate back and forth
between error and no error. First the output u would come to the value that
makes x = r, exactly opposing the disturbance. Then, because the error is
zero, the output would become zero, and the disturbance (still present)
would cause an error again, and so forth.

I presume you want to retract that, since when I said essentially the
same thing on some past occasion you came down hard on me for saying so.

For the uninitiated, it is not true that for all functions f(.), f(0) = 0.

Martin

[Bill_Powers1]

[From Bill Powers (970221.0810 MST)]

Martin Taylor 970220 14:10]--

makes x = r, exactly opposing the disturbance. Then, because the error
is zero, the output would become zero, and the disturbance (still
present) would cause an error again, and so forth.

I presume you want to retract that, since when I said essentially the
same thing on some past occasion you came down hard on me for saying so.

We were discussing a discrete control system in which both the environment
and the control system are treated as changing instantly from one state to
the next. To apply the discrete analysis it is necessary, at some place in
the loop, to deal correctly with physical time as it appears in the behavior
of continuous systems.

The point I was developing was that the presence of a continuous disturbance
will cause a completely discrete system (of the type described) to
oscillate, unless a counter-disturbance is made part of the system's output
function. That, of course, is the case to which you refer in pointing out
that f(0) is not in general 0. When the error signal is zero, the output of
the output function will be zero, unless there is a term in the function
that is independent of the error and can supply exactly the output needed to
cancel the disturbance. So to deal with disturbances, this kind of discrete
system requires a way to generate an output in the absence of error, with
the output somehow being exactly right at all times to cancel the effects of
the disturbance. This is why "modeling the disturbance" is essential in this
kind of model, however implausible it might be that such modeling could be
done successfully for the _general_ case.

Best,

Bill P.

[HANS_BLOM2]

[Hans Blom, 970221d]

(Bill Powers (970220.1445 MST))

A misunderstanding which deserves correction:

The comparator in my diagram computes an error signal, e[k+1], which
is

e[k+1] = r(k+1) - x(k), so that

u(k+1) = e(k+1)/(A*dt)

(I think your equation should have referred to u(k+1)).

No, Bill, my equations were correct. Let me explain where your
confusion comes from.

It is important to distinguish between what is observed at time k and
what at time k+1 (or k+dt). Your static diagram does not capture
that. It is also standard procedure to call the reference for x(k) by
the name of r(k), and to call the reference for x(k+1) by the name of
r(k+1). Seeing you write down the difference r(k+1) - x(k) hurts my
eyes ;-). Also, at time instant k you cannot compute e(k+1), which
would be the difference of r(k+1) and x(k+1); the latter is not known
yet!

So let's get the indexes right. At time instant k, you perceive x(k)
and have to compute u(k). It is only at time instant k+1 (or k+dt, if
you prefer) that you can discover the result x(k+1) and the control
error e(k+1) = r(k+1) - x(k+1).

The problem with diagrams is that they do not capture the incremental
nature of time of a model expressed as a difference equation. They
are nice for differential equation-type models such as implemented in
electronics or in an analog computer, but become confusing (or rather
insufficiently informative) for discrete-time models.

Actually, MCT models are even more fine-grained. They distinguish
between the two different "times" t where (1) x(t) has been observed
but u(t) not computed yet; and (2) where x(t) has been computed and
u(t) computed and output.

For comparison, the PCT model would be formally identical, except
that we would use the integral equation

x[t+dt] = x(t) + A*u(t)*dt

Where is the integral? This is a _difference equation_ as well, and
it is indeed exactly the formula I used, be it with a substitution of
variables.

... in computing u we would use a gain factor G instead of 1/(A*dt):

u(t+dt) = [r(t+dt) - x(t)]*G

The correct expression (remember that we are at time t!) would be:

u(t) := [r(?) - x(t)]*G

which says that the output u that we compute at time t depends on the
difference between our _current_ perception and some reference level.
This constitutes the basic difference with the MCT control law.

In MCT, your formula would be nonsense: x(t) has been observed
already and cannot be influenced anymore; we need to compute a u(t)
such that a _future_ x, namely x(k+1), will have some specified
value. Thence the MCT expression would be

u(t) := [r(t+dt) - x(t+dt)]*G

with a suitably chosen (model-derived) G.

Let's switch to using the cruise control as the example.

No, let's not change horses in mid-stream. Exactly the same
differences would show up again.

Greetings,

Hans

[Bill_Powers1]

[From Bill Powers (970221.1230 MST)]

Hans Blom, 970221d --

A misunderstanding which deserves correction:

The comparator in my diagram computes an error signal, e[k+1], which
is

e[k+1] = r(k+1) - x(k), so that

u(k+1) = e(k+1)/(A*dt)

(I think your equation should have referred to u(k+1)).

No, Bill, my equations were correct. Let me explain where your
confusion comes from.

OK, I see what you mean. In a way, the indexing depends on where in the loop
you start your iteration. If you use t to designate the current state of
each variable, you use the same t until you get back to the starting point
in the loop, at which time you switch to t+1 (or t+dt).

The problem with diagrams is that they do not capture the incremental
nature of time of a model expressed as a difference equation. They
are nice for differential equation-type models such as implemented in
electronics or in an analog computer, but become confusing (or rather
insufficiently informative) for discrete-time models.

Actually, diagrams can be interpreted however you want. The best approach,
however, requires considering all processes in the diagram to be carried out
simultaneously, as they are in any physical system. Wolfgang Zocher's
"Simcon" program works this way. Each component computes an output on the
basis of its inputs at time t. When all the new outputs have been computed,
they become, simultaneously, the inputs for the computations at time t+dt.
So the input processes are going on literally at the same time as the output
processes, although perturbations still propagate sequentially around a loop.

We accomplish the same thing mathematically by evaluating all the equations
around the loop in a single iteration, and make the change to t+dt only at
the moment we begin the next round of computations.

Actually, MCT models are even more fine-grained. They distinguish
between the two different "times" t where (1) x(t) has been observed
but u(t) not computed yet; and (2) where x(t) has been computed and
u(t) computed and output.

Yes, this is how Simcon does it, if I interpret you correctly. Of course as
dt becomes smaller, the difference between doing the computations correctly
and doing them in the easier sequential way becomes smaller.

For comparison, the PCT model would be formally identical, except
that we would use the integral equation

x[t+dt] = x(t) + A*u(t)*dt

Where is the integral?

The integral is the cumulation of the value of x in steps. Each time this
step is executed, x increases by the amount A*u(t)*dt. In the limit as dt
approaches zero, this program step computes the true integral of A*u(t)*dt.

This is a _difference equation_ as well, and
it is indeed exactly the formula I used, be it with a substitution of
variables.

Yes, that is what I said in my post. Just transpose x(t) to the left side,
and you have the differential form.

... in computing u we would use a gain factor G instead of 1/(A*dt):

u(t+dt) = [r(t+dt) - x(t)]*G

The correct expression (remember that we are at time t!) would be:

u(t) := [r(?) - x(t)]*G

OK, I'll go along with that. The values of r,x, and u are all computed in
the same iteration and so refer to the same time-period.

which says that the output u that we compute at time t depends on the
difference between our _current_ perception and some reference level.
This constitutes the basic difference with the MCT control law.

There is no difference. If you look at the program I posted, you will see
that no time-indices are used, because the operations are simply performed
in sequence. You always have the correct value of the variable for the time
in question. The time t gets incremented by dt only at the end of the iteration.

In MCT, your formula would be nonsense: x(t) has been observed
already and cannot be influenced anymore; we need to compute a u(t)
such that a _future_ x, namely x(k+1), will have some specified
value. Thence the MCT expression would be

u(t) := [r(t+dt) - x(t+dt)]*G

with a suitably chosen (model-derived) G.

Now it seems to me that you're violating your own rules. u(t) refers to the
value at time t; how can it be derived from the _next_ values of r and x,
which have not occurred yet? You are using the variables on the right side
to compute the value of the variable on the left side.

I don't think this problem is very important; when you program the
equations, you naturally write them in the right sequence, and the indices
take care of themselves.

Let's switch to using the cruise control as the example.

No, let's not change horses in mid-stream. Exactly the same
differences would show up again.

The reason I want to switch is that the cruise-control example doesn't
involve a lot of awkward assumptions. Remember that I had to postulate that
the angular velocity of the theodolite was proportional to the applied
torque (physically wierd), and then to explain that in this example, if the
torque fell to zero the theodolite would stop swinging instantly. I picked
an example where a second-order differential equation is really needed, and
then tried to kludge it up so it could be handled by a first-order system. I
just didn't take the trouble to start over when I found these difficulties.
If we switch to the cruise control, where velocity instead of position is
being controlled, we have a valid first-order case without the need for
ad-hoc assumptions to make it work. I apologize for starting us off with a
bad example, but let's not go on using it just because we started that way.
I hate bad examples, and it's my own laziness that let me propose it, but
please let me take it back. You're quite right that the equations would all
be the same, but the conclusions would at least mean something.

Best,

Bill P.