LITTLE BABY

CSGnet Archive CSG1992
1

[From: C. Love (920514.1000)]
[To: CSG-L LIST]
Hello again,
  I have a few questions for the PCT folks. My "little baby" is growing up
more and I need a little advice. There are seven ECMs in my current system,
three are used to drive the arm (2 at shoulder and 1 at elbow) and four for
the eyes (one for left eye vertical, one for left eye horizontal - same for
the right eye). Now since all this is happening on a Macintosh things must
be done *one at a time*.

  Essentially, these are the steps taken in a *time slice*:
1) Retina percepts are made available to all interested ECMs.
2) Angle Percepts are made available to all interested ECMs.
3) All ECMS calculate the weighted perceptual input and store this in its
internal cell called "Percept Sum".
4) Task Reference signals are made available to highest level ECMs.
5) Eye Reference Signals are made available to angle ECMs.
6) Angle ECMs provide their reference signals to (deltas) to external world,
which adds these to existing angles, i.e. modifies angles.
7) Each ECM now has all its signals necessary to do the internal calculations
so internal ECM calculations occur.
This involves determining the percept and reference output for each ECM.
8) Learning Phase. This involves adjusting the weights. Well, I'm working
on it....

The question is whether or not this sequence of events is a good choice or
not. I want to know whether it may be better to, say, propagate the reference
signals from the upper ECMs down to the lower ones before evaluating the lower
ones. This is something similar to what happens in BP. Here, everything
happens *simultaneously*, although still procedural. Intuitively, I think
things should happen this way. What I'm getting at is that signals at all
levels are unaware of whether or not they're receiving new or old signals;
they just take them in, process, and crank out a reference and percept. In
this manner I think this *simultaneous operation is correct.

  Any opinions?

Thanks,
Chris Love.
P.S. Here is a rough graph of the architecture...
           ------ ------ ------ ------
          -LExECM- -LEyECM- -RExECM- -REyECM-
          - - - - - - - -
           ------ ------ ------ ------

                ------- ------ ------
                -PhiECM- -ThetaECM- -AlphaECM-
                - - - - - -
                -------- ---------- ----------

Internal Environment

···

------------------------------------------------------------
External Environment

                       -------------------------------------------------
                       -LETx LETy LEFx LEFy RETx RETy REFx REFy -
                       -------------------------------------------------
-------------------
-Phi Theta Alpha -
------------------

Ok These three (external angles) receive the deltas from the three angle ECMs
(interanal) and the Percepts (external), eg. LETx=Left Eye Target x-coord,
LEFx= Left Eye Finger tip x-coord, are fed to all ECMs. Finally the reference
(task) signal for the top four ECMs are zero input, i.e., match finger to target

That's all.

2

[From Rick Marken (920515 08:30)]

C. Love (920514.1000) says:

I have a few questions for the PCT folks. My "little baby" is growing up
more and I need a little advice. There are seven ECMs in my current system,

Is an ECM a control system? Ectoplasmic Control Module?

three are used to drive the arm (2 at shoulder and 1 at elbow) and four for
the eyes (one for left eye vertical, one for left eye horizontal - same for
the right eye).

Just a verbal nit -- but if ECMs are control systems then its probably better
to say that they are "used to drive perceptual variables that are influenced
by movements of the arm and eyes". That just keeps the conventional roboticists
on their toes (or drives them away -- where's Randall Beer, by the way?).

Now since all this is happening on a Macintosh things must
be done *one at a time*.

Essentially, these are the steps taken in a *time slice*:

... the steps

The question is whether or not this sequence of events is a good choice or
not. I want to know whether it may be better to, say, propagate the reference
signals from the upper ECMs down to the lower ones before evaluating the lower
ones.

It looks like you are, indeed, buiding a hierarchy of control systems. The
order of calculation problem is interesting -- in fact, I think it's causing
me problems in my Excel spreadsheet (which you might look at because Martin
Taylor has a working copy). I think the order of recalculation in excel
does cause problems sometimes (I've never had such problems with lotus;
maybe i'll go back to ibm?).

For any individual control loop, the way to compute the variables is
in the intuitive sequence:

In the following

i = input variable
o = output variable
d = disturbance variable
p = perceptual signal
r = reference signal
e = error signal

1. compute the current input (environmental) variable value (i = o + d)
2. compute current perception (p = f(i))
3 compute error (e = r-p)
4. compute output ( o = g(e)) where g() includes the gain and integrations
that handle the dynamics of the loop

At this point you could repeat (if there is just one control loop) or start
the same calclulations for another loop AT THE SAME LEVEL IN THE HIERARCHY.
Actually, if the calculations are for the lowest level loops in a hierarchy,
I would carry out step 1 for ALL inputs before doing steps 2-4 for each
loop. That is, determine the current state of the environmental input to
the entire system; then use 2-4 for each system.

Once you have completed a 2-4 cycle for all the lowest level loops you have
the values of p for all these loops; these (as well as some i values)
are the inputs to the next level of loops; so do the 2-4 step for
each system at level 2 in the hierarchy. Once all the level 2 systems
are complete, do the level 3 -- etc.

Thanks for asking this question -- it makes me realize how lucky I am
that the spreadsheet model works at all; I'll have to go check the
recalculation order in excel to see what the problem might be; and also
see why it works so well in lotus.

Hasta Luego

Rick

···

**************************************************************

Richard S. Marken USMail: 10459 Holman Ave
The Aerospace Corporation Los Angeles, CA 90024
E-mail: marken@aero.org
(310) 336-6214 (day)
(310) 474-0313 (evening)

3

[From Joe Lubin (920515 12:00)]

C. Love (920514.1000); Rick Marken (920515 08:30) --

One suggestion. To (i) model the hypothesis that lower-level control systems
operate faster than the higher-levels, and (ii) to give each level a chance to
settle down a bit before its reference signals prod it again, iterate each
levela few (4?) times for each iteration of the level above it.

So if you have a two level system, one external clock cycle will encompass four
lower-loop updates and 1 higher-loop updates. Since nobody has the hardware to
build really deep (hierarchically) systems yet, it is not clear whether this
strategy would be necessary/useful among the higher-levels, although it
couldn't hurt.

···

-----------------------------------------------------------------------
Joseph Lubin jmlubin@phoenix.princeton.edu
Civil Eng. Dept. 609-683-5301
Princeton University 609-258-4598
Princeton NJ 08544
-----------------------------------------------------------------------

4

[From Rick Marken (920515 10:00)]

Joe Lubin (920515 12:00) says:

One suggestion. To (i) model the hypothesis that lower-level control systems
operate faster than the higher-levels, and (ii) to give each level a chance to
settle down a bit before its reference signals prod it again, iterate each
levela few (4?) times for each iteration of the level above it.

This technique was used by Powers in his two level force control model
described in his Byte magazine series (I think it was in the July, August
or September issue, 1979) -- it was the third article in the series. It's
an excellent article; it is not reprinted in Living Control Systems I or II.
But it's worth a look, Chris.

In that article, Bill describes a two level model that controls the x and y
component of force exerted by a muscle group anchored at a center point.
In the BASIC program version of that system, the lower level system went
though several iterations of calculation before the high level system started
its calculation.

My experience has been that this extra lower level calculation is unnecessary
for the stability of a multi level hierarchy (I don't do it in the spreadsheet
model and I didn't use it in other programs using Pascal and Basic). I've
found that all you need is the appropriate slowing factors on the outputs
going to lower level references; the output (and, thus, the speed of the
loop) should be slower for higher level than for lower level systems.
The extra lower level loop is a good way to imitate a "transport lag" delay
for the higher level system (those systems must wait for a period equal to
the number of iterations to get their inputs). While such a lag actually exists
in the human nervous system (and it is obviously longer for the higher than for
the lower level systems) it does not seem to be a stability requirement.
In fact, it is probably something that must be smoothed out by other aspects
of loop dynamics. But, since lags exist, it's probably a good idea to
put them into the models -- just for the sake of realism.

Hasta luego

Rick

···

**************************************************************

Richard S. Marken USMail: 10459 Holman Ave
The Aerospace Corporation Los Angeles, CA 90024
E-mail: marken@aero.org
(310) 336-6214 (day)
(310) 474-0313 (evening)