home *** CD-ROM | disk | FTP | other *** search
- Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
- Path: sparky!uunet!paladin.american.edu!auvm!MEVAX.PSU.EDU!JFG
- Return-Path: <@VMD.CSO.UIUC.EDU:JFG@MEVAX.PSU.EDU>
- X-Envelope-to: csg-l@uiucvmd.bitnet
- X-VMS-To: IN%"csg-l%uiucvmd.bitnet@ecl.psu.edu"
- MIME-version: 1.0
- Content-type: TEXT/PLAIN; CHARSET=US-ASCII
- Content-transfer-encoding: 7BIT
- Message-ID: <01GTX3WG97FM9BVDJR@MEVAX.PSU.EDU>
- Newsgroups: bit.listserv.csg-l
- Date: Mon, 25 Jan 1993 02:20:35 -0500
- Sender: "Control Systems Group Network (CSGnet)" <CSG-L@UIUCVMD.BITNET>
- From: "JOHN F. GARDNER" <JFG@MEVAX.PSU.EDU>
- 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
-