home *** CD-ROM | disk | FTP | other *** search
/ Virtual Reality Zone / VRZONE.ISO / mac / PC / PCGLOVE / O2GLOVE / GESTURE.TXT < prev    next >
Text File  |  1995-04-04  |  17KB  |  281 lines
  1. Power Glove Gesture Recognition
  2.  
  3. Foreword:
  4.  
  5.     Perhaps everyone who has used the Nintendo Power Glove, whether it be for 
  6. entertainment or development purposes, has gained insight into its usefulness as a gesture 
  7. sensing device - something that "knows" what you are trying to say with your body.  Of 
  8. course, even the Power Glove is limited to hand and wrist input, but it is clearly a far more 
  9. natural input device than the keyboard, mouse, or even the touch screen.  To be more 
  10. quantitative, the glove offers fully 8 channels of completely independent input, as opposed 
  11. to 4 for the mouse or joystick (X, Y, and 2 buttons) and (essentially) 1 for the keyboard.  
  12. It is as though you are playing an 8 string guitar that your computer can "hear" perfectly, 
  13. (although some of the strings only have 4 frets.)  What I want to implement is a program 
  14. to take the flood of glove input and boil it down to easily-interpreted commands like 
  15. "punch", "move left", "move forward", "twist left", "twist right", "fist", and so on and so 
  16. forth.  It is much easier to write a useful application when this filtering has already been 
  17. taken care of.  I see the first and most important application of this implementation to be 
  18. virtual reality.  Simply put, VR is the attempt to make a computer "look and feel" more 
  19. like real life and less like a stupid machine.  The glove puts people in closer contact with 
  20. computer mechanics, and perhaps more importantly, it puts the machine in closer contact 
  21. with the human user!  This much power will probably find other applications as well, and I 
  22. list some potential ones later in the text.
  23.     This paper gives a brief description of how I will implement an excellent gesture 
  24. recognition system.  At this point I'm not asking for input on what you think of this, so if 
  25. you don't like it, ignore it.  The discussion is very technical and contains a lot of "stream of 
  26. consciousness" writing.  If this bothers you, I'm sorry, I don't have a lot of time to polish it 
  27. at this point.  I need to start coding as quickly as possible.  If it bugs you that I'm releasing 
  28. this before the code is done, well, read the afterword, then go back to your private, selfish 
  29. excuse for a life.  The rest of us are getting down to work.
  30.  
  31. Section I - How simple should recognized gestures to be?
  32.  
  33. Fingers:  Thumb, Index, Middle, Ring.
  34. Location: X, Y, Z, and Rotation.
  35.  
  36. Gesture consists of finger "delta" and/or location "delta" ("delta" = "change in glove 
  37. input").  More subtle observation - we may wish to ignore the delta of any of the eight 
  38. parameters.  Do finger deltas need to be handled differently?  (My answer turns out to be 
  39. an emphatic "NO".)  Big issue is one of gesture "combination".  Should two identical rapid 
  40. gestures be interpreted as a "double-click"?  I think so, (though later I'll reject this.)  The 
  41. concept can be extended like so:  Say the gestures listed in the 1st paragraph can be 
  42. sensed.  If several gestures occur rapidly, there might be a gesture in the event queue like 
  43. "punch-twirl-punch-punch"  which would be distinguished from "punch", "twirl", "punch", 
  44. "punch" (4 separate queue events) by the delay between the gestures.  Clearly a queue of 
  45. gestures would be required, similar to an event queue for mouse clicks.
  46.     Another possibility is the "shifting" of gestures.  That is, if a gesture does not use a 
  47. parameter delta (in other words "an input channel is ignored in a particular gesture"), that 
  48. parameter could be used as a kind of "shift key".  The most logical extension would work 
  49. like this:
  50.   - User picks a "shift" gesture, such as holding the thumb close to the palm.
  51.   - The shift gesture parameter (in this case the thumb delta) cannot be used in any of the 
  52. "regular" gestures.  (This is to prevent "overlap" see below for more.)
  53.   - Now any regular gesture can be shifted, giving twice as many fundamental gestures.
  54.   - The # of fundamental gestures could in fact be doubled a few more times by adding 
  55. additional "shifting" gestures in the manner of the <Ctrl> and <Alt> keys on most PC 
  56. keyboards.  (One idea I had was to change the meaning of gestures based on the 
  57. "quadrant" that the user is pointing at - upper left, upper right, lower left and lower right.  
  58. E.g. "fist" can be broken into "upper left fist", "lower right fist", etc.)  HOWEVER, using 
  59. shifting gestures encourages modality in the client application, which is usually very 
  60. frustrating to the end-user learning an application.  The human mind, really, only operates 
  61. in one "mode".  I imagine that this is disturbing to some of you.  User interfaces have 
  62. progressed past the "insert mode," "delete mode", "change mode" type.  Equally offensive 
  63. to me are the "just hold down the shift to key to modify commands in such-and-such a 
  64. way."  (E.g. shift-left-mouse-button to copy, ctrl-left-mouse-button to move, or Shift-F10 
  65. to print and Ctrl-F10 for print preview.)  The human mind can't handle layers like that, but 
  66. the computer will store them forever.  How many times have you moved a file when you 
  67. wanted to copy it, or printed a file when all you wanted was a preview?  This happens 
  68. most frequently in beginning users, and users who have not used a program in a while.  So 
  69. those of you who think that "shifting" gestures is neat had better grow up.  If I choose to 
  70. implement them, it will be for a better reason than that 
  71.   -  Another basic problem is that to be effective, the shifting gestures must lock out an 
  72. entire channel of input which may limit the variety and intuitiveness of the "unshifted" 
  73. gestures.  (What's the difference between a "shifted-fist" and an (unshifted) "fist" if the 
  74. shifting gesture is the thumb tucked into the palm?)  More and more I'm thinking one shift 
  75. gesture is probably too much.  Might want to make it optional for certain applications.
  76.     It would be useful for the gesture recognition system to do automatic "globbing".  
  77. E.g. the "punch-twirl-punch-punch" command would automatically be shortened to 
  78. something like "knockout".  This is different from gesture combination in that it does not 
  79. directly involve time.  Example - "punch" followed later by another "punch" could be 
  80. globbed to "twopunch".  This way, "punch", "knockout", and "twopunch" would all be 
  81. separate gestures, even though they all involve a rapid thrust toward the screen.  The 
  82. client app would not need to do any special interpretation to receive them correctly.
  83.     There is more about shifting, combination, and globbing later in this article.
  84.  
  85. Section II - Uses of this implementation
  86.  
  87.     The intended implementation would allow the end user to define the gestures 
  88. he/she is most comfortable with.  What the computer is supposed to do when a gesture is 
  89. received is not the subject of this article.  There are a myriad of applications that could use 
  90. gesture receipt to trigger a function.  Ideas:
  91.     Virtual Reality
  92.         Communicating between multiple users
  93.         Constructing rooms & objects
  94.         Movement within the world
  95.         "Training" of autonomous moving objects
  96.     Disabled persons
  97.         Simplified communication (speech synthesis, text generation)
  98.         Therapy, muscular exercise
  99.     Windowing/User Interfaces
  100.         Sizing, moving, selecting windows and data chunks
  101.     Education
  102.         Training for sign language
  103.         Visual computer programming
  104.         Introductions to computers
  105.     Multimedia applications
  106.         Moving between subjects.
  107.     Games
  108.     Control of unusual peripherals (robotic arms)
  109.  
  110.     Perhaps with the glove and good gesture recognition, we can break out of "flat" 
  111. computer interfaces and put computers within the reach of more people.  Keep your 
  112. fingers crossed!
  113.  
  114. Section III - The implementation itself
  115.  
  116.     We need a way to "name" the gestures without using the keyboard.  One way is to 
  117. have a built-in gesture set designed for entering alphabetic characters (similar to the way 
  118. hearing-impaired people do proper names).  Another way is to just have a long list of 
  119. gestures that can be assigned, and you just select the gesture you want to define menu-
  120. style.  I think we want a combination of the above - I'll supply a list but users can also add 
  121. their own.  Keep in mind that these ASCII names do not go into the event queue, they are 
  122. there solely for the convenience of the application.  I imagine that once the gestures are 
  123. loaded from disk and any modifications are made by the end user, the names can be 
  124. removed from memory.  They only need to be reloaded if the user wants to change the 
  125. definition.  The app refers to the gestures via a pointer (or "handle").  (Side note: I've read 
  126. some discussion on Compuserve about whether to use #defines or constant strings to refer 
  127. to the gestures.  NEITHER OF THESE METHODS IS FLEXIBLE ENOUGH.)  Clearly 
  128. I need a way of saving/loading gestures/gesture-sets to/from disk.  I will avoid "binary 
  129. dumps"; however, don't expect them to easily interpretable.  (Although you never know!)
  130.     Okay.  I am assuming that the glove will be sampled at regular intervals.  The 
  131. length of this interval is not terribly important, but most applications are going to need 
  132. real-time input.  When I refer to a "click" or a "time click" below, I mean the time between 
  133. glove samples.  I suppose you could still do gesture recognition if the glove is sampled 
  134. irregularly, as long as the time between each sample is recorded, or maybe a time stamp on 
  135. each sample or something like that.  It would still be a pain in the butt compared to regular 
  136. sampling.  Basic objects are shown below:
  137.  
  138.  
  139. Sample:
  140.     One UNSIGNED byte for each of the following X, Y, Z, Rotation, Thumb, Index, 
  141. Middle, Ring.  (Practically speaking, the straight glove data.)
  142.  
  143. Gesture:
  144.     1 word pointer to a Recognizable.
  145.  
  146. Recognizable:
  147.     One SIGNED byte for each of the following: delta X, delta Y, delta Z, delta 
  148. Rotation, delta Thumb, delta Index, delta Middle, delta Ring
  149.     8 bit value with each bit signifying whether the corresponding "channel" is to be 
  150. used or ignored for the gesture.
  151.     One size_t time (in clicks) for the length of the gesture.
  152.  
  153. EventQueue:
  154.     A queue of Gestures.
  155.  
  156. SampleBuffer:
  157.     A random access array of Samples (updated after each click.)  Must hold as many 
  158. samples as the largest Recognizable in the GestureList.
  159.  
  160. GestureList:
  161.     A sorted list of Recognizable objects.  The sorting key is the length of the gesture.
  162.  
  163.  
  164.     The main engine works like so:
  165.  
  166. 1. A new Sample is added to the SampleBuffer.
  167. 2. Step through the GestureList:
  168.     a.  Compute a delta vector for the current Recognizable, (if it is not the same as 
  169. the last one.)  This is done by subtracting each of the current Sample values from the 
  170. Sample values N clicks ago (which will be present in the SampleBuffer), where N is the 
  171. length of the current Recognizable.
  172.     b. See of the delta vector lies within Epsilon of the current Recognizable's delta 
  173. vector.  Epsilon is a constant vector to allow for "close enough" user input.  I will supply 
  174. the appropriate Epsilon vector for the Power Glove after experimenting.
  175.     c.  If 2b. is true, add the address of the Recognizable to the event queue.  The 
  176. address of the Recognizable is in fact a Gesture.
  177. 3.  Continue forever!
  178.  
  179.     Hmmm.  This isn't quite right.  Depending on how quickly the user makes a 
  180. gesture, it might make it to the queue several times, instead of just once as hoped.  We 
  181. need to amend the data structures.
  182.  
  183.  
  184.  
  185. Recognizable:
  186.     Same as above, plus an 8 byte "work vector" and a 1 bit flag to say whether the 
  187. gesture is currently being sensed (the "sensed bit").
  188.  
  189. Gesture:
  190.     Same as above, plus a 1 bit value that is TRUE when the gesture is first 
  191. recognized, and FALSE when the gesture has been released.
  192.  
  193. In case you can't tell, event queue messages now take the form "punch(sense)" followed 
  194. later by "punch(release)".  This is similar to the way mouse "click-hold-and-drag" 
  195. operations - one message is sent when the gesture is first "seen" and another is sent when 
  196. the gesture is finally released.  Hmmm, rather than setting and resetting a bit to indicate 
  197. whether the gesture is turning on or off, why not just have the client app assume that 
  198. identical queue messages will be sent.  The first one will always be the "turning on" 
  199. message, and it must be followed by another identical "turning off" message at a later 
  200. time.  But the messages may not occur one right after another.  Does that put too much 
  201. responsibility on the client?  Hmmm.  It would be nice to have just a single pointer in the 
  202. queue, but I'm leaning toward keeping the extra bit.  Many client apps will want to ignore 
  203. the "release" message, and they would just have to check that bit to distinguish the 
  204. irrelevant messages.  Otherwise they'll have to keep track...
  205.     I'll modify the engine as follows:
  206.  
  207. 2. Step through the GestureList:
  208.     a.  Compute a delta vector for the current Recognizable, (if it is not the same as 
  209. the last one.)  This is done by subtracting each of the current Sample values from the 
  210. Sample values N clicks ago, where N is the length of the current Recognizable.  If the 
  211. "sensed bit" is set, subtract the current values from the work vector (rather than from the 
  212. sample N clicks ago.).
  213.     b. See of the delta vector lies within Epsilon of the current Recognizable's delta 
  214. vector.  Epsilon is a constant vector to allow for "close enough" user input.  I will supply 
  215. the appropriate Epsilon vector for the Power Glove after experimenting.
  216.     c.  If 2b. is true, and the "sensed bit" is not set, then set the "sensed bit" and add 
  217. the address of the Recognizable to the event queue, making sure it is a "turning on" 
  218. gesture.  Also, copy the Sample from N clicks ago into the work vector!
  219.     d.  If 2b is false, and  the "sensed bit" is set, then send a "turning off" queue 
  220. message.
  221. 3.  Continue forever and ever!
  222.  
  223.  
  224.     It should be plainly obvious how users can create their own gestures using JUST 
  225. THE GLOVE!  They'll hit one of the glove buttons to start a gesture, make the gesture, 
  226. then hit the glove button again.  All you need to store are the sample deltas and the length 
  227. of the gesture.  What could be easier?
  228.     Glove gestures as I have defined them are rather "elemental".  It is not possible to 
  229. define a gesture like "move hand up, wiggle your index finger, move toward the screen 
  230. and twist your wrist left"  However, you COULD define 4 or 5 elemental gestures that 
  231. would be "added up" by the client application and interpreted as a single gesture!  I will 
  232. include one or more relatively simple examples of this with the code, but I'm not sure if 
  233. they'll be the combination or globbing type.
  234.     That about covers it.  I'm still not sure about shifting, combination, or globbing.  I 
  235. have some deeper questions about these concepts which I have not really addressed here.  
  236. If you have understood everything I said, you probably have the same questions!  I'll 
  237. probably use Borland's C++ CLASSLIB library to handle the queue, buffer, and array in 
  238. the first cut.  I'll probably release that mainly to show beginning OOP programmers how a 
  239. class library is used.  (I know there's a lot of you out there.)  But the real version will not 
  240. use CLASSLIB for three reasons: 1) Portability, 2) Execution speed, and 3) Memory 
  241. usage.  Good reasons don't you think!  Only disadvantage is perhaps maintainability.  But 
  242. this is a REAL TIME application.  Compactness in both speed and size are penultimate.  I 
  243. will promise you that it will be object oriented as well.  I really want this thing to reach a 
  244. wide audience.  If you doubt my credentials read MTP.BIO in the COMART forum on 
  245. CompuServe.
  246.  
  247. Afterword:
  248.     The system will be freeware with the provision that you give me credit if you use 
  249. any part of the source code for any purpose.  It will be copyrighted.  It is my opinion that 
  250. good software is only of value to the intellectual community when it is accessible.  I am 
  251. making every effort to put this tool in a position where it will be used.  Please use it!  In 
  252. the spirit of Richard Stallman's work, I am permitting you to take advantage of my ideas.  
  253. If you make any significant improvements to the engine, please let me know.
  254.     If my gesture recognition system sounds good to you, here's how you can pay me 
  255. back.  Think about what gesture sets will be useful to you.  When the code is done, use it 
  256. to create the gesture sets you want.  But I WANT TO SEE WHAT YOU HAVE DONE.  
  257. This is only fair.  You may sell your application if you must, but you still owe it to me to 
  258. let me have your gesture sets.  It's the only way I can see the effect of my effort.  It will 
  259. encourage me to stay focused on this important area.  There's obviously no way I can 
  260. force you to do this without investing big $$$, which I don't have.  I just want you to "Be 
  261. Nice to Me" as Todd Rundgren so aptly put it (in 1971).
  262.     Also, if you're willing to hire me to work on Virtual Reality construction tools or 
  263. let me help in constructing actual Virtual Worlds, please contact me (see below).  My 
  264. present job is very boring, and this kind of stuff is one of the few things which stimulate 
  265. me.
  266.  
  267.  
  268.  
  269.             Mark T. Pflaging
  270.  
  271. Home:
  272.     7651 S. Arbory Lane
  273.     Laurel, MD 20707
  274.     (301)-498-5840
  275.  
  276. Work:
  277.     Cambridge Scientific Abstracts
  278.     7200 Wisconsin Avenue
  279.     Bethesda, MD  20814
  280.  
  281.