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

Text File | 1993-01-25 | 14.3 KB | 340 lines

Comments: Gated by [e-mail]
Path: sparky!uunet!paladin.american.edu!auvm!MEVAX.PSU.EDU!JFG
Return-Path: <@VMD.CSO.UIUC.EDU:[e-mail]>
X-Envelope-to: [e-mail]
X-VMS-To: IN%"[e-mail]"
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Message-ID: <[e-mail]>
Newsgroups: bit.listserv.csg-l
Date:         Mon, 25 Jan 1993 02:20:35 -0500
Sender:       "Control Systems Group Network (CSGnet)" <[e-mail]>
From:         "JOHN F. GARDNER" <[e-mail]>
Subject:      Robots, Control and stuff
Lines: 323

[From John Gardner (930125:0030)]

Bill Powers, Chris Malcom, Rick Marken, et al.

I've been digesting the recent posts on degrees of freedom,
robotics and control and I think we're (almost)
communicating on the 'same plane'.  Let me make a few
observations.

First, I think we've been 'bogged down' in the discussion on
the number of degrees of freedom.  Whether it's 6 or 3 isn't
really the issue, it's the complexity of the geometry that's
at the center of the argument.  Also, there are a number of
ways to approach the problem of robot control and I haven't
been making myself very clear on that.  I think I can shed
some light on both of these issues, if you'll bear with me.
By the way, if I'm getting too pedantic, please let me know.
I know I'm not speaking to engineers here, but it's rather
clear to me that there are some pretty sharp minds and fast
learners out there.  I just wanted to say that I wouldn't be
investing my time here if I didn't think that I'd learn
something in the process as well.

First, robot control.  In my last posting (930121.0000) I
tried to describe ONE approach to robot control.  I think
there were some subtleties which I glossed over but, in
retrospect, probably lie at the very core of the issue.  I
will restrict discussion to the so-called "local control
schemes".  These are schemes which use local control loops
of either position or velocity control at each joint
separately.  These are used in conjunction with some higher
level trajectory planner which compute desired 'set points'
to the local control loops.  As Bill pointed out, this has a
nice ring to it when compared to the H-PCT stuff.  What
seems to be lost is the significant difference between
implementing local position control vs. local velocity
control.

Most industrial robots (alas) implement local position
control loops at each joint.  Then, to get the robot end
effector (finger tip) from point A to point B (assuming that
point B is specified in x-y-z coords) involves the following
tasks:

1)  Finding the x-y-z coords of point A.  This involves
taking a measurement of the robot joint angles (or motor
shafts) and using the geometry of the robot to find the
location (and orientation) of the tip.  This is called the
"Forward Kinematics Problem" (FKP).  The FKP is generally
highly nonlinear put fairly straight-forward to derive and
solve.

2)  Finding the joint angles which correspond to point B.
This is a much more challenging task.  It involves solving
the FKP 'in reverse'.  Hence this is called the "Inverse
Kinematics Problem", or "Reverse Kinematics Problem" (IKP).
This involves nasties like Arccos, multiple solutions,
portions of the space with no solutions (singularities),
etc.  In general, it can be quite time consuming to compute,
but not impossible.

3)  Once the desired joint angles are know, we can take the
simple approach and just use the desired joint angles as the
set-points to the local position control loops and let the
robot run.  You can also work to coordinate the various
joints along the way with lots of games like interpolation,
etc., but I don't think that they have any bearing here.

There is an important implication of this approach which
Bill has pointed out.  The final accuracy of your position
is dependent upon the accuracy of your inverse kinematic
computation in addition to your sensor accuracy and the
ability of you control loops to achieve the set point.  He
points out (rather convincingly) that there appears to be
insufficient computational power and dynamic range to bring
about the level of performance we observe in biological
systems.  The point is well taken.

On the other hand, if we implement local velocity control
loops on our robot, the control problem changes
significantly.  Then we can go with an error-vector approach
which I outlined before.  I'll re-cap it here.  Again,
assume that we are at point A and want to get to point B:

1) Again, use the FKP to find the x-y-z coords of point A.

2) Find the error vector between the desired point (B) and
present point (A).  This vector has both magnitude and
direction (I know, this is the definition of the vector, but
it's an important point).

3)  Scale this position error vector by some gain constant
(we need to tune for this, but it's generally not 'high
gain'). and arrive at a 'Desired Velocity Vector' (DVV).
This vector tells us the velocity we would like the end
effector to move.

4)  Transform the DVV into desired joint rates.  We can then
use these joint rates as commands to our local velocity
loops.  In robotics, we use the transformation known as the
Jacobian matrix.  Actual to go from xyz to joints, we use
the inverse of the Jacobian.  This is a critical step and
one which needs to be examined in light of PCT, which I will
below.

5)  Continue updating the control loops by performing tasks
1-4 at 1 to 10 ms intervals until the your present position,
point A, becomes coincident with your desired, B.

There are some important things to note about this technique

I)  The error will become, in theory, arbitrarily small.  As
Bill has pointed out wrt PCT, if there is an integrator in
the loop, the error can be made to vanish.  And, like PCT,
the error here is not a function of the accuracy of the
inverse of the Jacobian matrix.

II) We are unfortunately tied to using the FKP.  That is
because we have to rely on joint sensors to tell us where we
are.  The 'holy grail' of the robotics field is 'end point
feedback'- i.e. an  independent and accurate measurement of
the endpoint of the robot.  As Bill pointed out, this would
get around problems of large payloads and other
disturbances.

Now, about PCT.  I still don't see what you're proposing
that is significantly different than what I describe.  Let
me quote a few of the recent posts and discuss them in this
light.

Bill Powers (930120.1130) said:

>The (visua) feedback signals representing x,y, and z error
>would be compared with reference signals, and the error
>signals would be distributed among the reference signals
>operating the 7 degrees of freedom of the arm. The
>requirement for the distribution is that a small
>perturbation in x should contribute (through each possible
>path) to an opposing net effect on the finger in the x
>direction, and the same for y and z. The actual effects
>don't have to be exactly opposed to the perturbation, as
>long as they have a component that is opposed to it. In
>this way the three errors would be corrected. The remaining
>degrees of freedom being unspecified, the arm would end up
>in some arbitary configuration, but the fingertip would be
>in the specified position.

The 'distribution among the reference signals' which you
describe above is *exactly* what the Jacobian matrix
accomplishes.  In fact, it is a reasonably good definition
of a Jacobian matrix.

Also, Rick Marken (930120.1400) says:

>That's why you don't need all those inverse kinematics and
>dynamics computations; all the system cares about is the
>controlled degrees of freedom (as perceived) -- the system
>must also be set up so that it can have (relatively)
>independent influences on these df; but after that (and
>some proper stabilization -- EASY) you're ready to boogy
>(er...robot).

Here is the heart of our argument.  Implicit in the above
statement (and, I assume, in the approach) is that it is
somehow easy to 'set up the system so that it can have
relatively independent influences on the degrees of
freedom'.  This is where we differ and this is also the
heart of the more degrees of freedom argument.

As I understand it, the 3 DOF little man demo used a crude
transformation to assign the relationship between the
perceived error and the muscle force/joint torque.  As I
pointed out in my last post, this transformation is simply
an approximation of the Jacobian (or its inverse).  The fact
that it was not arrived at using analytical geometry does
not change it's function.   Now, what I would argue is that
for *more complex* systems (for instance, more degrees of
freedom) it becomes more difficult, and eventually
impossible, to arrive at that approximation without
sophisticated, systematic approaches.  And any way you cut
it, those systematic approaches will give you the Jacobian,
or an approximation thereof.  More importantly, the
approximation, even of a simple model, is valid for only a
small range of motion

To sharpen the point at bit, Bill says (930121.0830);

>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.

I would argue that, at least for robots, you don't have
behavior that's that nice.  Then you could argue that we
would divide the trajectory space into regions and re-define
our relationship in each region.  In essence, have a
transformation which is a function of the position.  This is
what the Jacobian is.

I agree with the essence of the approach.  For instance,
Bill is correct in saying that the actual weighting is not
important.  This is borne out by my description where the
scaling factor between position error and desired velocity
is somewhat arbitrary.

I'm not saying it won't work, I'm just saying that by the
time you make it work, you won't have anything new.  You
might call it something different, but the robot controls
folks will recognize the Jacobian when they see it (Like the
old adage:  if it walks like a duck and quacks like a
duck...)

Just to sum up.  I agree with the essence of the approach
but disagree with the (implicit) statement that it
represents something that is revolutionary.  It's possible
that you might be on to something in that you can assess to
what degree our approximation of the Jacobian can be
degraded and still work, but I maintain that you ARE using a
transformation which approximates the geometrically-based
Jacobian transformation.

Whew, I hope you've stuck with me through this.  I think one
of the pre-requisites for becoming a professor is the
ability to yammer on without getting tired of hearing
yourself.   Let me respond to a few more specific comments
then I'll kick back and wait for the response.

First, Bill P.  (930121.0830)

>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.

For one thing, don't confuse me with a 'control theorists'.
Those are the guys that will tell you that it can't work
because the math says so, even if you have it running along
quite smoothly in the lab.  I'm an engineer and am happy to
look at new approaches even if they didn't start on the
firmest theoretical footing.  I think it's more fun this way
anyway.

>I spell analogue with the -ue in the same way some people
>still build bathtubs with claw feet.

I just figured you were from the 'empire' somewhere.
Probably talked about things like colour, behaviour and
carried a spare tyre in your boot.

>FORTRAN single precision is what, 18 bits?

For what its worth, single precision is usually 32 (4 bytes)
which gives you about 6 or 7 significant digits in
computation.  But, like I said above, I think we're running
a little wide of the issues here.

Bill, I've received your request for help with the rotations
and will be happy to comply, but we might want to re-think
the 7 DOF model.  I think the discussion is valid for the 3
DOF case.

I'd like to close this (much too) long post with a brief
response to Rick Marken (930122.0800):

>We now apparently have several "real" roboticts listening
>in on the net. How about asking them to provide a
>"requirements document" for such a robot.  Clearly we (you,
>Bill, others and myself) have a very poor grasp of what
>might impress our target audience (people who are
>presumably interested in understanding the behavior of
>living --and artifactual--systems).


The only way I know to impress an 'expert' in  a given field
that you have an approach that's better than one he (or she)
knows is to put your approach in the expert's framework.
That way the expert won't have to dig through the jargon to
find the truth about the differences (and similarities)
between existing and proposed methods.  This is, in essence,
what I'm trying to help accomplish here.

>If (as I suspect) all they want is impressive surface
>appearances (the Disneyland syndrome?) then we don't need
>to waste our time; ...

Ouch.
Sure, pretty pictures and glitzy demos are important in
getting attention, the bottom line for controls engineers
and "real" roboticists is math, plain and simple.  And in
this case the bottom line is stability.  Can you *prove*
that the approach is stable?  The local control schemes,
both with the Jacobian and with the inverse kinematics can
be proven to be stable using the Lyupanov stability theorem
for non-linear systems.  This is the approach which must be
taken to be taken seriously in the engineering controls
crowd.

(by the way, I think it might be possible to approach it
that way)

>So this is an open solicitation for contributions to a
>"robot requirements document" (RRD). What behavioral
>capabilities would be impressive in a robot? These should
>become requirements in the RRD.


Just to repeat myself once more in an effort to make it
clear:  It's not capability that I'd look for, it's
comparison to existing methods.  So far, I don't see
anything which I consider to be *significantly* different
from well-researched robot control schemes.  And again, let
me repeat, that's not the same thing as saying that the
approach is not significant.  I happen to agree with the
basic premise.  The argument that biological motor
coordination is done this way is compelling, and this is
what has drawn me to this forum.

Well, I've gone on MUCH longer than I intended and it's
getting MUCH too late.  I'll just duck down in my foxhole
and wait to see what gets tossed back.

Adios

John Gardner