Subject: Interfaces to VR devices

From: Francis Taylor <[email-masked]>
Date: Sat, 19 Oct 91 18:53:53 -0700

Hi.  I'm hacking interfaces to user interface devices at the HIT Lab
in Seattle, and I've been watching this list with great interest.
Lately I've seen interface software going by, and I figured I should
get in my two cents' worth (I'm optomistic).  

There should be a standard for the software interfaces to devices like
the PowerGlove, the DataGlove, the Exos DHM, the Polhemus and Bird
position sensors... so we can all run the same software, whether we
use a $50 Mattel PowerGlove or a $5000 VPL Dataglove. And, of course,
who knows what wonderful sensors the future will bring.  Won't it
be nice to buy that great new device, plug it in, and get all its
functionality, even using the same software you've worked with so
much.

The precision, range, and units of data from the sensors will be
different. Also, people with floating-point processors will want to
work with floats, and others may want fixed-point numbers for speed.

In any event, efficiency is paramount.  If a standard interface
introduces significant overhead into a system, speed freaks won't use
it, and we VR hackers certainly qualify as speed freaks. If you show
me a computer made today that's 'fast enough' for VR, I'll buy it (I'm
broke, but I'm confident).

My solution to this problem (encompassing the famous Media-Lab "all of
the above" attitude) is that the interface provides the data in as
many different formats as suitable, and also provides the relative
costs of the different formats.  The application decides which formats
it wants, and informs the interface, which provides exactly what is
needed. The concept is similar to that of an Internet Telnet
connection; each figures out what the other's got so the most
featureful connection possible is established.

If the interface library can provide this kind of functionality by
clever use of preprocessor macros, then very efficient code can be
produced for a variety of different situations. For example, I've
written an RS-232 library that works with POSIX, BSD, System V, and
Macintosh systems.  Thanks to clever and careful use of macros, the
application code is generic, and the implementations are optimal.

If you're interested in pursuing these goals with me, or if you have
an idea, please send me e-mail.  All HIT Lab software carries the GNU
Copyleft Notice, in case you're concerned about proprietary ideas.

---

From: James Helman <[email-masked]>
Date: Sun, 20 Oct 91 12:02:17 -0700

Francis-

At least the Ascension, Polhemus and Logitech devices do roughly the
same thing: measure position and orientation of one or more sensors.

But providing a common interface to all the different gloves on the
market (Mattel PowerGlove, VPL DataGlove, Exos DHM, Virtex CyberGlove)
is another matter.  They all have different numbers and locations of
sensors, ranging from the PowerGlove on the low end to the 22 sensor
CyberGlove on the high end.  Combine this with varying built in
abilities to do gesture recog, internal calibration and force/tactile
feedback and the MIT "all of the above" strategy becomes, well,
challenging.

   The application decides which formats it wants, and informs the
   interface, which provides exactly what is needed.

A good idea in principal, but it would require the interface software
to do things like building a 22 degree-of-freedom hand model from
PowerGlove input (map all to high-end strategy) or only providing a
minimal PowerGlove hand model to all apps (lowest common denominator
strategy).  In the former case, many apps will behave strangely with
the low-end device guessing (better though than not behaving at all),
in the latter, you're throwing away $6K worth of hardware.

A more complex negotiation between the application's requests and the
device's capabilities would be possible, but increases (probably
unacceptably) the complexity both of the interface software and the
app.

I'd love to hear any ideas or progress the HIT lab makes on any of
this.

-jim

Jim Helman					Lab:  (415) 723-9127
Stanford University				FAX:  (415) 591-8165
([email-masked]) 			Home: (415) 593-1233

"The power of the computer is locked behind a door with no knob."
							-B. Laurel

---

From: Yanek Martinson <[email-masked]>
Date: Sun, 20 Oct 91 16:11:32 EDT

> feedback and the MIT "all of the above" strategy becomes, well,

We could have some set of operations/functions that all interfaces
should support, either using the hardware feature or simulating it in
software. Then any application that uses only that basic set of
operations will work with any device. Then, there would be options
unique to a specific device. These interfaces would still support the
basic standard, but add on some new function calls. Then a program may
be written that requires a specific device.

Something like we have with modems. There is a basic command set (hayes
AT set) for neccessary things like RESET, DIAL, ANSWER, HANGUP, etc.
Any software that uses only these commands will work with most modems.
Then there are optional things some modems have, like MNP COMPRESSION,
protocols, interface speed locking, buffers, etc. A program can use
these features but then it will not work with other modems.

---

From: [email-masked] (John D Beutel)
Date: Sun, 20 Oct 91 23:44:51 EDT

> software.

It's difficult to plan the union of these fundamental functions
when constraints like speed are so important and most of these
devices are unknown.

Take the PowerGlove, for example.  I have to take back my
suggestion of a standard interface function called pre_glove().
Originally it was for the interrupt driven version of the
hi-res driver I was working on, to free up the CPU for graphics.
I thought that starting the glove poll about 70 ms before the
data was needed would be a crucial optimization, before it
occured to me that the important data should be gotten in the
first 1 ms so the poll could be started and the important
data returned in one function call.  Now, pre_glove() isn't
needed.

Since we're just starting to learn how to interface with the
glove, there may be more fundamental changes in the way we do
it.  So, we shouldn't make a standard yet.  On the other hand,
if we could nail down a standard interface before we had much
experience making programs for it, then the programs would be
compatable, which is desirable.  It's a catch-22.

The various techniques of using the PowerGlove have differences which
must be small compared to the ones of different devices, and I've never
used any of the other VR input devices, so I can't suggest what
the fundamentals should be.  Judging by the PowerGlove so far,
I do expect more differences than there at first seems to be.
Francis, I second the request for more info on what the
HIT Lab has learned on standards for the variety of VR devices.
Without practical experience with these other devices,
I think making a standard for their use would be largely
a waste of time.

I'd really like to see a nice PowerGlove standard, at least
on the fundamentals like how it'll be polled or interrupt
driven.  For example, people using fast polling with
interrupts, or especially people who get 68HC11 boards working
and send serial data only when it's ready, will probably want
a standard function that will be called by an interrupt whenever
the next data packet arrives.  That hasn't been mentioned
for the glove standard yet because nobody's implemented that
kind of interface yet.  But they will...

--
J. David Beutel  11011011  [email-masked]  "I am, therefore I am."