Improved PCT theodolite program cheats!

CSGnet Archive CSG1997
1

[Hans Blom, 970306d]

(Bill Powers (970305.0501 MST))

Bill, you cheat! I kept wondering how you use velocity in your
controller. It just can't be done the way you said. So I checked the
program code. And it shows that (1) your "environment equation"
generates both a position and a velocity and that (2) your controller
uses both (!!!). Thus your controller has TWO perceptual inputs. That
was not agreed. You are entirely free to use any intermediate
variables for velocity in both the environment equation and in the
controller, but you're not allowed to set them equal. Doing that
gives the controller direct access to the true physical velocity.
That's cheating.

I suggest the following: define local variables v in both the
function do_observation and in the PCT controller. That will
effectively isolate velocity and perceived velocity. But then it
becomes the responsibility of the controller to somehow reconstruct
the velocity out of position measurements only, of course...

Let me know how you do that.

Greetings,

Hans

2

[From Bill Powers (970307.0818 MST)]

Haven't dared to look at what I wrote last night, yet.

Hans Blom, 970306d]

Bill, you cheat! I kept wondering how you use velocity in your
controller. It just can't be done the way you said. So I checked the
program code. And it shows that (1) your "environment equation"
generates both a position and a velocity and that (2) your controller
uses both (!!!). Thus your controller has TWO perceptual inputs. That
was not agreed.

Since when is using tachometer feedback in a control system "cheating?" You
may think of it that way, but if you do, you're deliberately accepting a
handicap in designing control systems.

You are entirely free to use any intermediate
variables for velocity in both the environment equation and in the
controller, but you're not allowed to set them equal. Doing that
gives the controller direct access to the true physical velocity.
That's cheating.

Not to the "true" physical velocity -- just to a sensory representation of
it, sampled at intervals of dt, which can be as small an interval as needed
for accuracy.

I suppose it would be possible to construct an accurate perception of
velocity by putting the position samples through some elaborate
extrapolation computation makiing use of past values of position, but the
samples would have to be much closer together than those of the overall
iteration loop in order to be accurate enough to give good control. But it
seems much simpler to me to use a sensory signal that continuously
represents velocity, such as the signal from a drag-cup tachometer, and then
sample that signal at the basic iteration rate of the control loop.

I suggest the following: define local variables v in both the
function do_observation and in the PCT controller. That will
effectively isolate velocity and perceived velocity. But then it
becomes the responsibility of the controller to somehow reconstruct
the velocity out of position measurements only, of course...

Why "position measurements only, of course"? The PCT model implies no such
self-imposed limitations. In fact, in designing the PCT model for
controlling the theodolite, I consider it legitimate to use any sensor
devices for which I can think of realistic examples.

At the end of the long post of last night, I did point out that the problem
suffered by the MCT model is due to _lack_ of velocity sensing. If you want
to add a velocity sensor to your MCT model, I would have no objection. I
said that this would probably cure the problem. Reducing dt in the MCT
model, by the way, does NOT cure the problem.

I should mention that in my modeling, I don't autmatically conceive of the
control system itself as being of digital nature. My work with human motor
behavior, in fact, always assumes an _analog_ control system. The computer
representation of the model, therefore, can use as small a value of dt as
required to represent the analog processes accurately; there is no
implication that there are computations in the real system that must be done
at the repetition rate of the computer program. There is no correspondence
between the repetition rate of the computer iterations and any "sampling
rate" in the real system. If there are actual time-lags in the real system,
or actual samplings of signals, then in the simulation I would simply
arrange for the repetition rate of the digital model to be fast enough to
represent the lags or the durations of the samples accurately. If a sampling
system used a window of, say, 0.1 second, I might use an iteration interval
of 0.005 second to represent the sample duration with an accuracy of 5% (if
that would be sufficiently accurate). This would in no way imply that the
real system did anything 200 times per second. In PCT models, we use the
digital computer as an _analog_ computer (as in Simcon, or Stella, or other
such prominent simulation programs). In such models we adjust dt for a
compromise between accuracy and the time the user must wait to see the
result. Sometimes, to get an accurate result, you must simply wait. Digital
simulations of analog processes are very slow.

Best,

Bill P.

3

[Hans Blom, 970310d]

(Bill Powers (970307.0818 MST))

Since when is using tachometer feedback in a control system
"cheating?" You may think of it that way, but if you do, you're
deliberately accepting a handicap in designing control systems.

As I remember (accurately, I think), we were to design a POSITION
FEEDBACK controller. I understood and still understand that to mean a
controller which controls the theodolite's position, given perception
of its position ONLY. You were to design the PCT controller.

Now if I remember well, a generic PCT controller has as many outputs
(action channels) as it has inputs (perceptual channels). Suddenly
you deviate from your own paradigm. I find that unacceptable; you're
of course free to design anything at all, but don't call it a PCT
controller if it isn't.

Moreover, I'm _not_ "deliberately accepting a handicap". In any
control system, sensors are costly and vulnerable to both damage and
temporary lack of "vision", and that is a good reason to attempt to
derive as much information out of the existing sensors as possible,
rather than adding another one (even though I recognize full well
that redundancy may make perception more robust). Moreover, in this
simple control problem a second (velocity) sensor is not needed at
all, as my controller demonstrates.

In the final analysis, I object to your design for three reasons:
first, it is not a PCT controller as I have come to understand them;
you use the velocity as a kind of "feedforward" variable which is not
itself controlled -- which conflicts with the "control of perception"
part of what you say behavior is. The second reason is that your
controller has two sensors, whereas mine has only one; that doesn't
make for a good comparison. And the third reason is that the whole
concept of modeling is thrown out of the door if you force me to use
direct perception of velocity: if I need velocity, I _model_ it,
using perceptions of position only. That is the main theme we are
investigating, isn't it? The question is: can one use "internal"
model-based perceptions rather than measurements in order to achieve
adequate control quality. My program shows that this is possible and
that it results in good control quality.

I'm not willing to continue our comparison investigation as long as
you stick to using two sensors, for the reasons given above. Is there
really no way you can think of discarding the velocity sensor?
Remember that my controller is (at least) as good as yours, whereas
it has only one...

I suppose it would be possible to construct an accurate perception
of velocity by putting the position samples through some elaborate
extrapolation computation makiing use of past values of position,
but the samples would have to be much closer together than those of
the overall iteration loop in order to be accurate enough to give
good control.

Great. If you need that, do it. Only position perception is allowed,
but you are allowed to sample the position as often as you want. But
then, if you perceive at that rate, why not control at that rate as
well? That is, use a smaller dt. But, as you note, that doesn't help
much... (hint!)

But it seems much simpler to me to use a sensory signal that
continuously represents velocity, such as the signal from a drag-cup
tachometer, and then sample that signal at the basic iteration rate
of the control loop.

You must mean simplicity in calculation here, _not_ simplicity in
instrumentation. Moreover, simplicity isn't the issue here; adequate
use of perceptual information is.

Why "position measurements only, of course"? The PCT model implies
no such self-imposed limitations. In fact, in designing the PCT
model for controlling the theodolite, I consider it legitimate to
use any sensor devices for which I can think of realistic examples.

I could think of additional sensors that might help; acceleration? a
device that measures J? a device that somehow measures disturbance?
Let's be realistic and stick to the basics of PCT: one input and one
output. Of course you can do it. If I can, you can do it, too!

Greetings,

Hans