NetNews Usenet Archive 1993 #3/NN_1993_3.iso/spool/bit/listserv/csgl/2240

Internet Message Format | 1993-01-21 | 12.0 KB

Path: sparky!uunet!noc.near.net!hri.com!spool.mu.edu!howland.reston.ans.net!paladin.american.edu!auvm!VAXF.COLORADO.EDU!POWERS_W
From: [e-mail] (William T. Powers)
Newsgroups: bit.listserv.csg-l
Subject: Multiple directions; arm models
Message-ID: <[e-mail]>
Date: 21 Jan 93 16:58:07 GMT
Sender: "Control Systems Group Network (CSGnet)" <[e-mail]>
Lines: 239
Comments: Gated by [e-mail]
Return-Path: <@VMD.CSO.UIUC.EDU:[e-mail]>
X-Envelope-to: [e-mail]
X-VMS-To: @CSG
MIME-version: 1.0
Content-transfer-encoding: 7BIT

[From Bill Powers (930121.0830)]

Martin Taylor (930120.1545)--

>I think it more likely that the human is not working with
>orthogonal control systems at all.  It seems more likely that
>there are many, rather than two directions of control, and that
>the observed actions of handle (mouse) movement are the result
>of these many outputs in the different directions.

I can see perceptions being made of individual contributions from
many individual direction-detectors aimed in different
directions, but when it comes to output the available directions
are limited to the degrees of freedom of the arm.

Exactly orthogonal control is not necessary; if there is a slight
deviation from a 90-degree angle between the axes, motion in one
axis simply disturbs the other axis a little, and the control
system on the other axis cancels the disturbance by normal means.
The only thing to watch out for is positive feedback in the
interaction. If the angle between axes is 95 degrees (as in your
example), the coupling of one axis to the other is about 0.09.
Multiply that by the error sensitivity of the other system, and
by 0.09 again for the return coupling, and you get the positive
feedback gain (or something, I'm skimming the surface here). My
point is that a certain amount of interaction between high-gain
control systems can be tolerated.

>So, to enhance the model, I would put more ECSs, which look at
>error in different directions, rather than impute to the human
>an ability to rotate the space.

You'd better work out an example; this just looks like a great
opportunity for conflict to me.

>If one does make a model with more ECSs, there are more degrees
>of freedom with which to fit the data, which makes it more
>difficult to determine whether the new model is an improvement
>over the old.

Slow down. First demonstrate that such a model would work at all.
Then worry about degrees of freedom.
---------------------------------------------------------------
John Gardner (930121.0000)--

>Albus suggests an approach in which the arm states (angles and
>velocities) can be used as addresses to a large memory system
>which contains values of muscle torques/forces.  These tables
>are built up, either through evolution or learning and the
>system runs and a funny kind of hybrid open/closed loop system.

The open-loop aspects of Albus' model are what I object to. He
does have some good concepts of hierarchical control, although
his approach is still "task oriented." By that I mean that he
seems to partition the behavior according to externally-defined
objectives instead of internal reference signals. In robotics, of
course, that may be appropriate. In models of organisms it isn't.

The idea of using the memory capacities of the brain looks good
to me. In the Arm model I used something like that just to get
the show on the road, not because I thought I had done it right.
The output of the visual control systems is based on errors
computed from the coordinates of the eyes, while the arm itself
works in a shoulder-centered coordinate system. For slow
movements this causes no difficulties, but it makes fast
movements toward a target start off in the wrong direction,
resulting in unrealistic trajectories. I "solved" this problem by
putting in an adaptive transformation map between the visual
systems and the reference inputs of the arm control systems. I
would rather have put the transformation in the perceptual
systems, but had computational problems in getting the perceptual
map to adapt without ruining control when the map was half-
finished. So I took the easy way out, figuring on doing it right
later.

Paul Churchland has also suggested transformation maps in his
"crab" model, but he failed to notice that the same
transformation would apply to the visual image of the reaching
claw, so he never got to the stage of proposing a control system.
The target position was transformed into a claw movement open
loop.

I'm quite pleased, actually, that you didn't consider my previous
post to be a nut letter. It's been hard to get real control
engineers to listen long enough to see that there is another
point of view possible. When you say "This reminds me of
performing dynamic system simulation using analog
computers" you hit the nail on the head. My earliest experiences,
and the initial modeling I did, was with analogue computers
(Philbrick). That's where I learned about solving simultaneous
differential equations with that magical bootstrap method where
you say "OK, this wire contains the solution for x, so I'll
connect it back to the input where x is needed, and use it to
compute the solution." My whole approach to modeling organismic
control systems is based on insights learned from analogue
computers. I spell analogue with the -ue in the same way some
people still build bathtubs with claw feet.

>The point I'm trying to make is that by manipulating the
>reference signals in that way, you're just performing the exact
>same computations (inverse Jacobian), you're just doing it 'in
>the hardware' instead of software.

Hooray, you understand! The control loop is doing the inverse
computations by BEING the solution. Hearking back to your
previous post, it's perfectly true that you must convert the
positional error into appropriate changes in the joint angles,
but this doesn't mean that you have to actually compute the
inverse matrix. It means getting the sign of feedback to be
correct (negative) for every possible feedback path through every
joint. The amount of feedback (the weighting) is of only minor
importance if the sign is correct. Because integrators are used
in the output functions, the errors will eventually go to zero.
Stabilizing the system is a separate consideration; first you
have to make sure you have the basic organization of a control
system that will work quasi-statically.

>By your own arguments, isn't it even less likely that the
>lower reaches of the brain' are capable of the kind of high-
>level reasoning that was required for you to come up with the
>solution you outlined above?  Or are these relationships 'hard-
>wired by evolution?

Let's just say "by learning" and leave the mechanism to be
discovered.

>Sounds to me like your describing a control based on neural
>networks.

I think that self-adaptive neural nets are a definite
possibility. Using them as parts of control systems is especially
nice because you have a built-in criterion for guiding the
adaptations: the error signals should all be as small as
possible.

RE: accuracy.

FORTRAN single precision is what, 18 bits? The precision of
nervous system analogue computations is something like 8 bits. If
your model tried to invert a 6x6 matrix of variables known to
that precision, by computations of that precision, what would the
final precision look like? Remember that when you do matrix
inversions in hardware, every implicit multiplication, division,
and addition must actually be done by a computing element. I
think you'd be lucky to end up with 4 bits. Yet the behavior we
have to account for is as accurate as perceptual resolution.

>We assume that the links don't bend and it doesn't take a very
>heavy payload to cause significant link bending when the robot
>arm is extended.

This is where the lack of good sensors is a real handicap. If you
could sense where the payload is very accurately, you wouldn't
care if the arm bends a bit. Real control is based on the sensed
outcome, not the generated output. The kludgiest control system I
ever built was also the most precise: it controlled the position
of a carriage under the ruling diamond of a grating-ruling
engine. The position was sensed using a stabilized laser
interferometer, and the fine adjustments of the carriage were
made by a voice coil pushing through a nonlinear compound lever
to bend the inch-thick supports of the central part of the 300-
pound carriage. We had no idea what the minification function of
the compound lever looked like. But the interferometer could
measure the carriage position to 0.01 wavelength of laser light,
and that is the accuracy of groove-spacing that we achieved. The
un-fed-back engine accuracy was about 1 wavelength.

All you really need is reasonable monotonicity of the output part
of the system. You don't even need linearity or precise
repeatability over time. All precision is achieved by the sensor;
the rest of the system can be pretty crude.

>The scheme I described (and similar ones described on the
>CSGNET earlier) are what we call 'local control schemes' based
>on local velocity or position control loops at each motor.
>Since we are using geometry to compute desired set points for
>those loops, things which cause disturbing torques (like
>gravity) are compensated, more or less, by the local loops.

The local loops can do some of the compensation -- but what if
the target moves? What you are calling "local loops" I would call
lower-level control systems. In the arm model, these lower level
loops actually turn out to have modest steady-state loop gain,
only 5 to 10 depending on how you tweak the system. The main
effect is to achieve stability. A higher level of kinesthetic
control is needed to boost the gain for positional errors -- I
used joint=angle sensors and leaky integrators, which makes
steady-state position errors small, while allowing transient
effects from disturbances (as in real human arms).

I'll send you a copy of the arm model version 2 if you want it.
It needs a 286, 386, or 486 DOS computer with Hercules, CGA, EVA,
or VGA graphics (no color is used). Full C source code is
included. If you can get your department to buy it, great;
otherwise just ask.

>No real argument from me here.  I think my discussion up to
>this point deals with this pretty well.  I've never seen that
>number on the dynamic range of the neural signals.  Where can I
>find that in the literature?

Nowhere that I know of. I'm estimating that the maximum possible
frequency of a neural signal is about 2500 pulses per second,
with a noise level equal to the square root of the pulse rate. E.
g., 50:1. What says Martin Taylor?

>I'm enjoying this exchange.  I believe there is some
>substantial common ground here and I look forward to continuing
>the discussion.

Me, too.
--------------------------------------------------------------
Greg Williams (930121) --

>Regarding the ongoing discussion about modeling pointing
>behavior, I think it is clear that PCTers apparently could be
>looked up to by (at least some) roboticists if they
>successfully make a fast PCT model (endpoint control) with six
>or seven degrees of freedom. So, if that's what it takes, why
>not try to do it?

I'm tempted. Unfortunately I seem to be leaving a trail of
projects started but never finished. Everything is so
interesting, and my time and energy are so limited! Well, maybe a
bunch of half-finished projects will some day give other people
ideas about how to finish them. Actually, last night before going
to sleep I saw how to compute the fingertip position by using a
series of rotation matrixes progressing from the fingertip back
to the shoulder. Maybe it would be worth while trying this out in
the same way that the Little Man version 1 ran -- without
dynamics. At least this would show what the kinematic problems
are. If I can get that much to work, maybe the real control
engineers on the net would see some value in trying to get the
dynamics under control. I sure wouldn't know how to do that in 6
or 7 degrees of freedom.
--------------------------------------------------------------
Best to all,

Bill P.