information in the perception

CSGnet Archive CSG1997
1

[Hans Blom, 970422]

(Rick Marken (970418.0900 PDT))

So when you say that there is "imperfect information about the
disturbance passed by the perceptual function" I can't help but
think you are saying that there is information about the state of d
in the state of p. But it is easy to show that there is absolutely
no information about d in p; knowing p tells you nothing about the
state of d.

Let me give you a simple counterexample that demonstrates that Martin
is right and you are wrong: there _is_ information about the
disturbance in the perception.

First, what is the meaning of this assertion? I restate it as the
fact that, when a perception is contaminated by a disturbance, it is
(more or less) possible to tease (1) the undisturbed perception and
(2) the disturbance apart. You must not have followed the theodolite
discussion. In the MCT theodolite controller, exactly this is done.

How? Well, let's assume the environment equation takes the form

  p = f(u) + d

where p is the perception, d the disturbance, u the controller's
output and f what I call the "environment function" which relates a
controller's action to the resulting perception in case there are no
disturbances. But there are...

However, a model-based controller knows f more or less perfectly.
Let's first assume that f is known perfectly. In that case the
controller can predict what the undisturbed perception would be,
given u. It is

  p' = f(u)

where p' is called the prediction, a hypothetical disturbance-free
"imagined" perception. The prediction error is defined as p - p' and
its value is

  p - p' = f(u) + d - f(u) = d

Thus, given the actual preception p and the controller's internal
prediction/imagination p', d can be computed/reconstructed. In this
case, therefore, there is even _perfect_ information about the
disturbance in the perception: d can be recreated without error.

What is the model is imperfect? Assume that the controller "knows" f'
rather than the true f. In that case, its prediction will be

  p' = f'(u)

Now the prediction error will be

  p - p' = f(u) + d - f'(u)

Rearranging terms we have

  d = p - p' - [f(u) - f'(u)]

which tells us that the disturbance will be reconstructed imperfectly
and that the reconstruction error will be the larger the more f'
differs from f. If the discrepancy is not too large, however, the
reconstruction of d will not be too bad.

Thus, the perception allows us to reconstruct d more or less well. In
a model-based controller, that is. It seems that a PCT controller
cannot do so -- because it has no model. But that in itself is not
good enough a reason to say that the perception tells us nothing
about the disturbance...

Greetings,

Hans

2

[From Bill Powers (970422.0858 MST)]

Hans Blom, 970422--

I was sort of saving this for later, but it's appropriate as a reply to your
post today:

...let's assume the environment equation takes the form

p = f(u) + d

where p is the perception, d the disturbance, u the controller's
output and f what I call the "environment function" which relates a
controller's action to the resulting perception in case there are no
disturbances. But there are...

However, a model-based controller knows f more or less perfectly.
Let's first assume that f is known perfectly. In that case the
controller can predict what the undisturbed perception would be,
given u. It is

p' = f(u)

where p' is called the prediction, a hypothetical disturbance-free

"imagined" perception. The prediction error is defined as p - p' and
its value is

p - p' = f(u) + d - f(u) = d

Very clear. Now try this with the following equation for p:

p = f(u) + 10*sin(d)
where d = 2*t (for our 9-second run).

The PCT model will have no difficulty with this, as long as the effect of
the disturbance isn't so great that the output has to exceed physically
possible limits. Actually, the MCT model will have no difficulty, either, if
you handle it right -- but your model will not be able to deduce the value
of d. In fact, if you substitute 10*sin(t) for the disturbance calculation
now used in your program "x_v_theodolite_model", the program hangs up at
about t = 2.

Thus, the perception allows us to reconstruct d more or less well. In
a model-based controller, that is. It seems that a PCT controller
cannot do so -- because it has no model. But that in itself is not
good enough a reason to say that the perception tells us nothing
about the disturbance...

You are making unspoken simplifying assumptions about the function that
connects d to the controlled quantity. In fact you're doing the same thing
Martin Taylor did: confusing the _cause_ of a perturbation with the
perturbation itself.

Best,

Bill P.

3

[Hans Blom, 970424b]

(Bill Powers (970422.0858 MST))

Let's first assume that f is known perfectly. In that case the
controller can predict what the undisturbed perception would be,
given u. It is

p' = f(u)

where p' is called the prediction, a hypothetical disturbance-free
"imagined" perception. The prediction error is defined as p - p'
and its value is

p - p' = f(u) + d - f(u) = d

Very clear. Now try this with the following equation for p:

p = f(u) + 10*sin(d)
where d = 2*t (for our 9-second run).

The PCT model will have no difficulty with this, as long as the
effect of the disturbance isn't so great that the output has to
exceed physically possible limits. Actually, the MCT model will have
no difficulty, either, if you handle it right -- but your model will
not be able to deduce the value of d. In fact, if you substitute
10*sin(t) for the disturbance calculation now used in your program
"x_v_theodolite_model", the program hangs up at about t = 2.

That is funny, Bill: my program does _not_ hang with a disturbance
10*sin(t). It runs the full 9 seconds of simulated time. This is part
of its output, around the time where the motion starts:

    time x-ref x v d-est u
    1.900 0.000 0.000 -0.001 9.495 -9.496
    1.910 0.000 0.000 -0.001 9.463 -9.464
    1.920 0.000 0.000 -0.001 9.430 -9.431
    1.930 0.000 0.000 -0.001 9.396 -9.397
    1.940 0.000 0.000 -0.001 9.362 -9.362
    1.950 0.000 0.000 -0.001 9.326 -9.327
    1.960 0.000 0.000 -0.001 9.290 -9.290
    1.970 0.000 0.000 -0.001 9.252 -9.253
    1.980 0.000 0.000 -0.001 9.214 -9.214
    1.990 0.000 0.000 -0.001 9.174 -9.175
    2.000 0.000 0.000 -0.001 9.134 -9.135
    2.010 0.005 0.005 0.999 9.093 90.906
    2.020 0.015 0.015 0.999 9.051 -9.052
    2.030 0.025 0.025 0.999 9.008 -9.009
    2.040 0.035 0.035 0.999 8.964 -8.965
    2.050 0.045 0.045 0.999 8.919 -8.920
    2.060 0.055 0.055 0.999 8.874 -8.874
    2.070 0.065 0.065 0.999 8.827 -8.828
    2.080 0.075 0.075 0.999 8.780 -8.780
    2.090 0.085 0.085 0.999 8.731 -8.732
    2.100 0.095 0.095 0.999 8.682 -8.683

Rather good behavior, I would say. Also, rather good reconstruction
of the sine-wave, I would say. Try again, Bill, using the original
version of the program, maybe?

You are making unspoken simplifying assumptions about the function
that connects d to the controlled quantity. In fact you're doing the
same thing Martin Taylor did: confusing the _cause_ of a
perturbation with the perturbation itself.

I might. But what does a _program_ know about causes, Bill?

Greetings,

Hans

4

[From Bill Powers (970422.0909 MST)]

Hans Blom, 970424b --

That is funny, Bill: my program does _not_ hang with a disturbance
10*sin(t). It runs the full 9 seconds of simulated time. This is part
of its output, around the time where the motion starts:

   time x-ref x v d-est u
   1.900 0.000 0.000 -0.001 9.495 -9.496
   1.910 0.000 0.000 -0.001 9.463 -9.464
   1.920 0.000 0.000 -0.001 9.430 -9.431

Rather good behavior, I would say. Also, rather good reconstruction
of the sine-wave, I would say. Try again, Bill, using the original
version of the program, maybe?

That must be the problem, because mine still hangs up (to the point where I
have to reboot!). I must have hit a key and changed something inadvertently.
Can you send me the code again by direct post?

Best,

Bill P.

5

[Hans Blom, 970428]

(Bill Powers (970422.0909 MST))

Rather good behavior [of the MCT controller], I would say. Also,
rather good reconstruction of the sine-wave, I would say. Try
again, Bill, using the original version of the program, maybe?

That must be the problem, because mine still hangs up (to the point
where I have to reboot!). I must have hit a key and changed
something inadvertently. Can you send me the code again by direct
post?

I'm posting it here so that others can check as well that a sinewave
can be nicely reconstructed, and to make another point.

In recent discussions, it was accepted that the disturbance can be
reconstructed if the environment equation was

  x = f(u) + d

but _not_ if the environment equation was

  x = f(u) + g(e)

where d = g(e) and g some function.

This demo with its sinusoidally varying disturbance shows that this
reasoning must be slightly modified. What is estimated in the program
below is g(d), where _we_ know that g() is a sine-function but the
program does not. That is, however, unimportant _for control
purposes_: control is unhampered by that lack of knowledge. But only
if feedback exists. "Running in the dark", i.e. without measurements
of position and velocity would become inferior. If _that_ is required
as well, the sine-function would have to be discovered as well.

In principle, that is possible: _because_ the system can separate out
the disturbance (as samples) so nicely, it could -- given a number of
"basic building block" functions -- attempt to model d in terms of
these primitives and discover, for instance, that d=10*sin(t). I've
never done such an exercise, however. But I foresee no implementation
problems.

Note that this could be considered an extra "hierarchical level" of
the MCT controller. At the lowest level, control proceeds fine, but
this lowest level also provides a "disturbance signal" which a higher
level could attempt to model (find regularities in). Doing so would
allow the combined system to operate better when feedback information
is missing and/or of inferior quality.

So a "hierarchy" of MCT-levels can be seen as subsequent levels
increasingly "explaining" what for the lower levels are just "random"
or "unexplained" data points. I've never thought of attempting to
subdivide models into such a hierarchical structure, but it seems
possible...

Greetings,

Hans

program x_v_theodolite_model;

const
  J = 1.0; {theodolite characteristic}

var
  k, {k=0: velocity control; k=large: position control}
  x, {perceived position}
  v, {perceived velocity}
  u, {controller's output}
  rx, rv, {TWO reference levels}
  d, {disturbance estimate}
  p, {prediction of next observation}
  dt, {time increment; var so it can be changed}
  t: real; {time; for display/loop control purposes}
  fo: text;

procedure observe;
{this procedure implements the theodolite motion equations; it
generates the NEXT observation(s) x(t+dt) and v(t+dt), given u(t)
and d(t); thus it also shifts the time by dt; note that aa, vv and
xx are LOCAL variables, not visible outside this function; declaring
them as "const" saves their value from run to run; aa, vv and xx are
initially known to be zero}

  function disturbance: real;
  {this function implements the disturbance, which is known only
   to procedure observe, the theodolite's motion simulator}
  begin
{ if (t < 4.0) or (t > 5.0) then
      disturbance := 0.0
    else
      disturbance := 10.0
}
    disturbance := 10.0 * sin (t)
  end;

const
  aa: real = 0.0;
  vv: real = 0.0;
  xx: real = 0.0;
begin
  aa := (u + disturbance) / J;
  xx := xx + vv*dt + 0.5*aa*dt*dt;
  vv := vv + aa*dt;
  t := t + dt;
  x := xx; v := vv {the controller may use these}
end;

procedure reference (t: real);
{this procedure specifies the reference levels for x(t) and v(t);
the initial and final steps of rx are half their normal value}
begin
  if t < 2.0 + 0.25*dt then {no movement}
    begin rx := 0.0; rv := 0.0 end
  else
  if t < 6.0 + 0.25*dt then {constant speed}
    begin rx := t - 0.5*dt - 2.0; rv := 1.0 end
  else {and halted again}
    begin rx := 4.0; rv := 0.0 end;
end;

procedure control;
{this function implements the controller; it knows the motion equa-
tions and J, is allowed to observe x(t) and v(t), and delivers u(t)}
var
begin
  u := J * a - d
end;

begin
  assign (fo, 'theo9.dat'); rewrite (fo);
  dt := 0.01; {or any other value}
  k := 1.0; {SCALED value w.r.t. dt, i.e k*dt}
  t := 0.0; {start at t=0}
  x := 0.0; {initially zero}
  v := 0.0; {initially zero}
  rx := 0.0;
  rv := 0.0;
  d := 0.0; {estimate of disturbance}
  repeat
    writeln (t:9:3, rx:9:3, x:9:3, v:9:3, d:9:3, u:9:3);
    writeln (fo, t:9:3, rx:9:3, x:9:3, v:9:3, d:9:3, u:9:3);
    reference (t+dt); {specify desired x and v}
    control; {controller computes u}
                                  {predict next observation}
    p := x + v*dt + 0.5 * (u + d) * (dt*dt) / J;
                                  {time shifts by dt here}
    observe; {observe x (and v?)}
                                  {update disturbance estimate}
    d := d + 2.0 * J * (x-p) / (dt*dt)
  until t > 9.0;
  close (fo)
end.

ยทยทยท

a: real;
  a := (rv - v + 0.5*k*(rx-x-v*dt)) / (1.0 + 0.25*k*dt)/dt;

6

[From Bill Powers (970428.0732 MST)]

Hans Blom, 970428--

OK, code received and now the program doesn't hang up. I must have changed
something.

You are right, the MCT model does "reconstruct" the effect of the
disturbance, although as you recognize it can't reconstruct the actual
disturbing variable dd, which is simply proportional to time.

The PCT model, of course, produces variations in its output that cancel the
effects of the same disturbance, but without having to construct an explicit
model of an equivalent disturbance.

You mention the possibility of building a hierarchical MCT model. That would
be interesting.

Best,

Bill P.