From: cdshaw@cs.ualberta.ca (Chris Shaw)
Newsgroups: sci.virtual-worlds
Subject: Re: TECH: DataGlove packet rate
Date: 17 Nov 92 06:00:43 GMT
Article-I.D.: u.1992Nov18.045717.22837
Organization: University of Alberta
Originator: hlab@stein.u.washington.edu


In article <1992Nov14.011645.11929@u.washington.edu> dejohnso@asylum.cs.utah.edu
 (David Johnson) writes:
>I have a little distributed VR system set up - SGI's, DataGlove and
>Polhemus.  I have only been getting about 7 frames/sec so I have been
>doing some careful timing to see where the bottleneck is - and it's
>mostly in trying to read the Polhemus 3Space.  Right now it is configured for
>2 sensors, binary, non-continous mode, 19200 baud serial port and I
>can't get close to the 30 data packets/sec that they claim.  Is this
>experience common?  What kind of data rate do you get using the MR
>Toolkit? Any suggestions?

It all depends on your polling structure. If you're polling the Isotrak once 
at the start of each update loop, you're going to guarantee a wait of 1/60 
second until the data packet is returned. Do that once per Isotrak, and you've
lost 33 milliseconds already.  Sometimes, the timing of the situation can
be such that you'll get HALF the update rate when polling -- 15 Hz on your
case.  Running in continuous mode eliminates this polling lag. 

Our study of this problem, published in the User Interface Software and
Technology 1991 Conference (ACM UIST'91) indicates that using
continuous mode can reduce lag by up to 50 milliseconds.

Using ascii polling mode on our slowest machine, the MR Toolkit can get at 
least 13 samples per second on a 3-way sync'd Isotrak using a SGI 3130 (20MHz 
68020). Back in the old days, we used a 3130 and a SGI 2400 (15MHz or 20MHz 
68010 box) as our stereo HMD drivers, and could get 15 updates per second
on dirt simple models (hand plus 3 polygons). Considering that the maximum
packet throughput on these machines is about 60 TCP/IP packets per second,
this ain't too shabby. On more modern machines, we get 60 updates per
second on our Isotrak and glove drivers, using binary continuous mode.

The key point to note here is that you should always try to eliminate
needless synchronization of the visual update upon other updates, such as
tracker update. Polling the tracker requires you to hang around waiting for
the latest data to show up. You can't always guarantee that you can fill
this time with something useful.

>Also - my VR thumb looks goofy - can anyone describe well how to model
>its motion?

Depends on your glove. We use a "finger" rotated 90 degrees so that the
hinge-like joints' axes are perpendicular to the palm, then rotate out at
the base of the thumb by 20 degrees or so. If you have more sensors, you
can do more, of course.

  |||| <- fingertips                      | <- fingertips
/ ||||                                    |
|                           thumb tip-> \ |
\                                        \|
Back of hand view.                Hand as seen while "karate chopping"
Thumb on left. Thumb joint        Rotate thumb counter-clockwise by 20 degrees
axes come out of page.            Rotation axis comes out of page.

>David Johnson
>dejohnso@cs.utah.edu

--
Chris Shaw               University of Alberta
cdshaw@cs.UAlberta.ca    CatchPhrase: Bogus as HELL !
Newsgroups: sci.virtual-worlds