home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / bit / listserv / csgl / 2273 < prev    next >
Encoding:
Text File  |  1993-01-25  |  14.3 KB  |  340 lines

  1. Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
  2. Path: sparky!uunet!paladin.american.edu!auvm!MEVAX.PSU.EDU!JFG
  3. Return-Path: <@VMD.CSO.UIUC.EDU:JFG@MEVAX.PSU.EDU>
  4. X-Envelope-to: csg-l@uiucvmd.bitnet
  5. X-VMS-To: IN%"csg-l%uiucvmd.bitnet@ecl.psu.edu"
  6. MIME-version: 1.0
  7. Content-type: TEXT/PLAIN; CHARSET=US-ASCII
  8. Content-transfer-encoding: 7BIT
  9. Message-ID: <01GTX3WG97FM9BVDJR@MEVAX.PSU.EDU>
  10. Newsgroups: bit.listserv.csg-l
  11. Date:         Mon, 25 Jan 1993 02:20:35 -0500
  12. Sender:       "Control Systems Group Network (CSGnet)" <CSG-L@UIUCVMD.BITNET>
  13. From:         "JOHN F. GARDNER" <JFG@MEVAX.PSU.EDU>
  14. Subject:      Robots, Control and stuff
  15. Lines: 323
  16.  
  17. [From John Gardner (930125:0030)]
  18.  
  19. Bill Powers, Chris Malcom, Rick Marken, et al.
  20.  
  21. I've been digesting the recent posts on degrees of freedom,
  22. robotics and control and I think we're (almost)
  23. communicating on the 'same plane'.  Let me make a few
  24. observations.
  25.  
  26. First, I think we've been 'bogged down' in the discussion on
  27. the number of degrees of freedom.  Whether it's 6 or 3 isn't
  28. really the issue, it's the complexity of the geometry that's
  29. at the center of the argument.  Also, there are a number of
  30. ways to approach the problem of robot control and I haven't
  31. been making myself very clear on that.  I think I can shed
  32. some light on both of these issues, if you'll bear with me.
  33. By the way, if I'm getting too pedantic, please let me know.
  34. I know I'm not speaking to engineers here, but it's rather
  35. clear to me that there are some pretty sharp minds and fast
  36. learners out there.  I just wanted to say that I wouldn't be
  37. investing my time here if I didn't think that I'd learn
  38. something in the process as well.
  39.  
  40. First, robot control.  In my last posting (930121.0000) I
  41. tried to describe ONE approach to robot control.  I think
  42. there were some subtleties which I glossed over but, in
  43. retrospect, probably lie at the very core of the issue.  I
  44. will restrict discussion to the so-called "local control
  45. schemes".  These are schemes which use local control loops
  46. of either position or velocity control at each joint
  47. separately.  These are used in conjunction with some higher
  48. level trajectory planner which compute desired 'set points'
  49. to the local control loops.  As Bill pointed out, this has a
  50. nice ring to it when compared to the H-PCT stuff.  What
  51. seems to be lost is the significant difference between
  52. implementing local position control vs. local velocity
  53. control.
  54.  
  55. Most industrial robots (alas) implement local position
  56. control loops at each joint.  Then, to get the robot end
  57. effector (finger tip) from point A to point B (assuming that
  58. point B is specified in x-y-z coords) involves the following
  59. tasks:
  60.  
  61. 1)  Finding the x-y-z coords of point A.  This involves
  62. taking a measurement of the robot joint angles (or motor
  63. shafts) and using the geometry of the robot to find the
  64. location (and orientation) of the tip.  This is called the
  65. "Forward Kinematics Problem" (FKP).  The FKP is generally
  66. highly nonlinear put fairly straight-forward to derive and
  67. solve.
  68.  
  69. 2)  Finding the joint angles which correspond to point B.
  70. This is a much more challenging task.  It involves solving
  71. the FKP 'in reverse'.  Hence this is called the "Inverse
  72. Kinematics Problem", or "Reverse Kinematics Problem" (IKP).
  73. This involves nasties like Arccos, multiple solutions,
  74. portions of the space with no solutions (singularities),
  75. etc.  In general, it can be quite time consuming to compute,
  76. but not impossible.
  77.  
  78. 3)  Once the desired joint angles are know, we can take the
  79. simple approach and just use the desired joint angles as the
  80. set-points to the local position control loops and let the
  81. robot run.  You can also work to coordinate the various
  82. joints along the way with lots of games like interpolation,
  83. etc., but I don't think that they have any bearing here.
  84.  
  85. There is an important implication of this approach which
  86. Bill has pointed out.  The final accuracy of your position
  87. is dependent upon the accuracy of your inverse kinematic
  88. computation in addition to your sensor accuracy and the
  89. ability of you control loops to achieve the set point.  He
  90. points out (rather convincingly) that there appears to be
  91. insufficient computational power and dynamic range to bring
  92. about the level of performance we observe in biological
  93. systems.  The point is well taken.
  94.  
  95. On the other hand, if we implement local velocity control
  96. loops on our robot, the control problem changes
  97. significantly.  Then we can go with an error-vector approach
  98. which I outlined before.  I'll re-cap it here.  Again,
  99. assume that we are at point A and want to get to point B:
  100.  
  101. 1) Again, use the FKP to find the x-y-z coords of point A.
  102.  
  103. 2) Find the error vector between the desired point (B) and
  104. present point (A).  This vector has both magnitude and
  105. direction (I know, this is the definition of the vector, but
  106. it's an important point).
  107.  
  108. 3)  Scale this position error vector by some gain constant
  109. (we need to tune for this, but it's generally not 'high
  110. gain'). and arrive at a 'Desired Velocity Vector' (DVV).
  111. This vector tells us the velocity we would like the end
  112. effector to move.
  113.  
  114. 4)  Transform the DVV into desired joint rates.  We can then
  115. use these joint rates as commands to our local velocity
  116. loops.  In robotics, we use the transformation known as the
  117. Jacobian matrix.  Actual to go from xyz to joints, we use
  118. the inverse of the Jacobian.  This is a critical step and
  119. one which needs to be examined in light of PCT, which I will
  120. below.
  121.  
  122. 5)  Continue updating the control loops by performing tasks
  123. 1-4 at 1 to 10 ms intervals until the your present position,
  124. point A, becomes coincident with your desired, B.
  125.  
  126. There are some important things to note about this technique
  127.  
  128. I)  The error will become, in theory, arbitrarily small.  As
  129. Bill has pointed out wrt PCT, if there is an integrator in
  130. the loop, the error can be made to vanish.  And, like PCT,
  131. the error here is not a function of the accuracy of the
  132. inverse of the Jacobian matrix.
  133.  
  134. II) We are unfortunately tied to using the FKP.  That is
  135. because we have to rely on joint sensors to tell us where we
  136. are.  The 'holy grail' of the robotics field is 'end point
  137. feedback'- i.e. an  independent and accurate measurement of
  138. the endpoint of the robot.  As Bill pointed out, this would
  139. get around problems of large payloads and other
  140. disturbances.
  141.  
  142. Now, about PCT.  I still don't see what you're proposing
  143. that is significantly different than what I describe.  Let
  144. me quote a few of the recent posts and discuss them in this
  145. light.
  146.  
  147. Bill Powers (930120.1130) said:
  148.  
  149. >The (visua) feedback signals representing x,y, and z error
  150. >would be compared with reference signals, and the error
  151. >signals would be distributed among the reference signals
  152. >operating the 7 degrees of freedom of the arm. The
  153. >requirement for the distribution is that a small
  154. >perturbation in x should contribute (through each possible
  155. >path) to an opposing net effect on the finger in the x
  156. >direction, and the same for y and z. The actual effects
  157. >don't have to be exactly opposed to the perturbation, as
  158. >long as they have a component that is opposed to it. In
  159. >this way the three errors would be corrected. The remaining
  160. >degrees of freedom being unspecified, the arm would end up
  161. >in some arbitary configuration, but the fingertip would be
  162. >in the specified position.
  163.  
  164. The 'distribution among the reference signals' which you
  165. describe above is *exactly* what the Jacobian matrix
  166. accomplishes.  In fact, it is a reasonably good definition
  167. of a Jacobian matrix.
  168.  
  169. Also, Rick Marken (930120.1400) says:
  170.  
  171. >That's why you don't need all those inverse kinematics and
  172. >dynamics computations; all the system cares about is the
  173. >controlled degrees of freedom (as perceived) -- the system
  174. >must also be set up so that it can have (relatively)
  175. >independent influences on these df; but after that (and
  176. >some proper stabilization -- EASY) you're ready to boogy
  177. >(er...robot).
  178.  
  179. Here is the heart of our argument.  Implicit in the above
  180. statement (and, I assume, in the approach) is that it is
  181. somehow easy to 'set up the system so that it can have
  182. relatively independent influences on the degrees of
  183. freedom'.  This is where we differ and this is also the
  184. heart of the more degrees of freedom argument.
  185.  
  186. As I understand it, the 3 DOF little man demo used a crude
  187. transformation to assign the relationship between the
  188. perceived error and the muscle force/joint torque.  As I
  189. pointed out in my last post, this transformation is simply
  190. an approximation of the Jacobian (or its inverse).  The fact
  191. that it was not arrived at using analytical geometry does
  192. not change it's function.   Now, what I would argue is that
  193. for *more complex* systems (for instance, more degrees of
  194. freedom) it becomes more difficult, and eventually
  195. impossible, to arrive at that approximation without
  196. sophisticated, systematic approaches.  And any way you cut
  197. it, those systematic approaches will give you the Jacobian,
  198. or an approximation thereof.  More importantly, the
  199. approximation, even of a simple model, is valid for only a
  200. small range of motion
  201.  
  202. To sharpen the point at bit, Bill says (930121.0830);
  203.  
  204. >All you really need is reasonable monotonicity of the
  205. >output part of the system. You don't even need linearity or
  206. >precise repeatability over time.
  207.  
  208. I would argue that, at least for robots, you don't have
  209. behavior that's that nice.  Then you could argue that we
  210. would divide the trajectory space into regions and re-define
  211. our relationship in each region.  In essence, have a
  212. transformation which is a function of the position.  This is
  213. what the Jacobian is.
  214.  
  215. I agree with the essence of the approach.  For instance,
  216. Bill is correct in saying that the actual weighting is not
  217. important.  This is borne out by my description where the
  218. scaling factor between position error and desired velocity
  219. is somewhat arbitrary.
  220.  
  221. I'm not saying it won't work, I'm just saying that by the
  222. time you make it work, you won't have anything new.  You
  223. might call it something different, but the robot controls
  224. folks will recognize the Jacobian when they see it (Like the
  225. old adage:  if it walks like a duck and quacks like a
  226. duck...)
  227.  
  228. Just to sum up.  I agree with the essence of the approach
  229. but disagree with the (implicit) statement that it
  230. represents something that is revolutionary.  It's possible
  231. that you might be on to something in that you can assess to
  232. what degree our approximation of the Jacobian can be
  233. degraded and still work, but I maintain that you ARE using a
  234. transformation which approximates the geometrically-based
  235. Jacobian transformation.
  236.  
  237. Whew, I hope you've stuck with me through this.  I think one
  238. of the pre-requisites for becoming a professor is the
  239. ability to yammer on without getting tired of hearing
  240. yourself.   Let me respond to a few more specific comments
  241. then I'll kick back and wait for the response.
  242.  
  243. First, Bill P.  (930121.0830)
  244.  
  245. >I'm quite pleased, actually, that you didn't consider my
  246. >previous post to be a nut letter. It's been hard to get
  247. >real control engineers to listen long enough to see that
  248. >there is another point of view possible.
  249.  
  250. For one thing, don't confuse me with a 'control theorists'.
  251. Those are the guys that will tell you that it can't work
  252. because the math says so, even if you have it running along
  253. quite smoothly in the lab.  I'm an engineer and am happy to
  254. look at new approaches even if they didn't start on the
  255. firmest theoretical footing.  I think it's more fun this way
  256. anyway.
  257.  
  258. >I spell analogue with the -ue in the same way some people
  259. >still build bathtubs with claw feet.
  260.  
  261. I just figured you were from the 'empire' somewhere.
  262. Probably talked about things like colour, behaviour and
  263. carried a spare tyre in your boot.
  264.  
  265. >FORTRAN single precision is what, 18 bits?
  266.  
  267. For what its worth, single precision is usually 32 (4 bytes)
  268. which gives you about 6 or 7 significant digits in
  269. computation.  But, like I said above, I think we're running
  270. a little wide of the issues here.
  271.  
  272. Bill, I've received your request for help with the rotations
  273. and will be happy to comply, but we might want to re-think
  274. the 7 DOF model.  I think the discussion is valid for the 3
  275. DOF case.
  276.  
  277. I'd like to close this (much too) long post with a brief
  278. response to Rick Marken (930122.0800):
  279.  
  280. >We now apparently have several "real" roboticts listening
  281. >in on the net. How about asking them to provide a
  282. >"requirements document" for such a robot.  Clearly we (you,
  283. >Bill, others and myself) have a very poor grasp of what
  284. >might impress our target audience (people who are
  285. >presumably interested in understanding the behavior of
  286. >living --and artifactual--systems).
  287.  
  288.  
  289. The only way I know to impress an 'expert' in  a given field
  290. that you have an approach that's better than one he (or she)
  291. knows is to put your approach in the expert's framework.
  292. That way the expert won't have to dig through the jargon to
  293. find the truth about the differences (and similarities)
  294. between existing and proposed methods.  This is, in essence,
  295. what I'm trying to help accomplish here.
  296.  
  297. >If (as I suspect) all they want is impressive surface
  298. >appearances (the Disneyland syndrome?) then we don't need
  299. >to waste our time; ...
  300.  
  301. Ouch.
  302. Sure, pretty pictures and glitzy demos are important in
  303. getting attention, the bottom line for controls engineers
  304. and "real" roboticists is math, plain and simple.  And in
  305. this case the bottom line is stability.  Can you *prove*
  306. that the approach is stable?  The local control schemes,
  307. both with the Jacobian and with the inverse kinematics can
  308. be proven to be stable using the Lyupanov stability theorem
  309. for non-linear systems.  This is the approach which must be
  310. taken to be taken seriously in the engineering controls
  311. crowd.
  312.  
  313. (by the way, I think it might be possible to approach it
  314. that way)
  315.  
  316. >So this is an open solicitation for contributions to a
  317. >"robot requirements document" (RRD). What behavioral
  318. >capabilities would be impressive in a robot? These should
  319. >become requirements in the RRD.
  320.  
  321.  
  322. Just to repeat myself once more in an effort to make it
  323. clear:  It's not capability that I'd look for, it's
  324. comparison to existing methods.  So far, I don't see
  325. anything which I consider to be *significantly* different
  326. from well-researched robot control schemes.  And again, let
  327. me repeat, that's not the same thing as saying that the
  328. approach is not significant.  I happen to agree with the
  329. basic premise.  The argument that biological motor
  330. coordination is done this way is compelling, and this is
  331. what has drawn me to this forum.
  332.  
  333. Well, I've gone on MUCH longer than I intended and it's
  334. getting MUCH too late.  I'll just duck down in my foxhole
  335. and wait to see what gets tossed back.
  336.  
  337. Adios
  338.  
  339. John Gardner
  340.