Subject: Re: Power glove standardization

From: [email-masked]
Date: Mon, 21 Oct 1991 23:44 EDT

Here is my 2 pennies worth of ideas on standardization of similiar glove
inputting device...   I think standardization is a good thing.  I would
like to suggest to move away from the powerglove data structure as it
seriously limits the possible type of performance for future devices.
Some  obvious limitations is the # of bits per finger and the rotational
angle resolution.  One  can easily get 6-7 bit of resolution if one
simply replaces the Glove CPU and add $3.00 worth of hardware.  At the
moment, the glove data structure might seem more convient.  I just
think it is worth while to set a proper standard.

I would also like to add a new function for the glove.  This function is
to be called after initialization.  This informs the host program of the
capabilities of the input device.  The host program can then perform the
necessary transformation(s) required to the input packet stream.

Inquire_Glove();

This function returns a pointer to a structure that contains the following:
   count - this tell the program how many words are there in a packet
   wordsize - the word size used in packet:byte,int,long
   tags  - this points to an array of tags that describe what each of the
           words in the packet are for and what is the maximum ranges of
           data to be expected.

Tags array:
Name - a char string with ASCII text identifying the corresponding word
       in the packet eg. "Finger 1", "Receiver 1", "Distance X", "Rotation"
       The ASCII text would have to be standardized.  New tags can be added
       for future devices as they becomes 'available'.  Programs would only
       read off tags that they understands and ignore the rest.
       Try to make it obvious and understandable by someone else.
       Avoid using obscure short form for tags as they make
       guess at it difficult and some programmers (like me) likes to
       use the tag as part of the items on menus (when they make sense)

Max - The maximum upper limit of the corresponding word in the packet.
(eg.  Max = 12 for the rotation from the glove.   For others, it might
      be 360 for 1 degree resolution. )

The function Read_Glove() would now return a pointer to a packet of
size count*wordsize bytes.

If any of the data in the packet is > than their corresponding Max
values, that means that piece of data is unavailable for the current
sample.  (eg.  One of the receiver misses)

It might also be possible to have the inquire function return a second
tags array describing the possible operating modes available from the
glove.  eg. possible modes:  "Joystick", "X,Y,Z,Rot,Fingers", "Raw",
"Sample on demand", "Sample rate".  An extra function is used to set
the glove into one or more operating modes.  The program might also
ask the glove to only include a selected list of data in each packet.
(ie.  The program get what it wants, not everything the glove gets.
This is to lower the overhead of data communication between the host
and the glove.)

I hope I have not gone way of tangent here.    I feel if we are going
to have a standard here, then we should do it right ie. not to limit
ourselves to a particular product or model (eg to save 5 machine cycles)
, allow for expansion in terms of new devices and/or higher resolution.
Some of the hard coder there might want to argue efficiency with me
about the extra processing required...   To me programming in bare metal
refers to laying out the transistor connections in a custom chip that
performs the equivalent software function.  :)  If I want speed, I'll
build some hardware for the task.

As for the interrupt/poll, leave it to the particular machine.  I like
the device model on my Amiga that provides both sync & async I/O.  Why
force your particular model (TSR, Interrupt, Polling, Multitasking) on
others ???

K. C. Lee
Elec. Eng. Grad. Student