Subject: Re: sampling techniques and response time

From: Dave Stampe-Psy+Eng <[email-masked]>
Date: Sun, 20 Oct 91 01:11:49 -0400

John D Beutel ([email-masked]) sends a message on:

- sampling rates on powerglove and delays of data
- motion-to-video delays
- polling of glove vs. interrupt delays in data

First, the REAL sampling rate for data is set by the powerglove itself, and
depends on the sum of all of its sample periods (thus its dependance on the
finger position).  If you wait longer than the sampleing period before you 
read the glove, you just get older data.  
Second, the interrupt-driven method I proposed (use an interrupt every 3-4 mS
to poll the glove) actually results in the freshest possible data.  Your
software can sit in a loop calling get_glove_data() and checking the .new
flag in the result: the glove doesn't care, and you're just looking at
the buffer contents until the interrupt gets new data and updates the buffer.
BTW, there's a good reason for using an interrupt instead of having your 
program poll the glove directly... actually, two.  First, this ensures the
glove is polled with proper spacing (if you see evenly spaced glitches in
the glove XY data, you're talking to the glove too often.  Second, the 
interrupt ensures that you're getting every sample: otherwise the deglitch()
noise reduction won't work properly.

The only way I can figure to speed up the glove sample rate (potentially to
25 Hz) is to disconnect the fingers, short them out (or ground the CPU
sample pin) and connect the finger sensors to an A/D converter (such as
a modified PC game port card).  Seems like a lot of work.

The motion-to-video delay problem IS serious, and isn't going to get any 
better.  If we assume an average of 60mS/2=30mS delay in the glove, 30 mS in
the transfer, 100 mS in rendering, and 16 mS in the display, we have about
180 mS altogether.  Now, I know of commercial aircraft simulators that
have that kind of delay, and they DON'T use eyephone-type displays-- but
their performance make experienced pilots run, not walk, to the nearest
washroom.  Of course, in our systems the field of view won't be so big, and
the amount of "motion sickness" should be less.  Also, if you're just
moving objects with your hand, you can learn to slow down a bit.

The problem is with eyephone displays-- picture movements won't match
head movements very well, so the user will experience dizzying effects
as the scene lags head movements.  (BTW, I have an idea how to partially fix
this, involving some tomfoolery with the sync for the displays, that I'd like
to discuss with someone who has a working system with a head position
sensor and good hardware experience).

The usual method for fixing delay is a Kalman or predictive filter, but I
don't think this will work with the power glove.  The noise filters I
wrote work on the position data, but don't affect velocity noise at all.
This means the Kalman filter would add significant noise.

I think this might be a good time to point out a couple of interesting points
that I think were'nt clear from past postings.  First, saying that a 100 mS
delay can cause "oscillation" by feedback thru the user doesn't imply that
the system is oscillating at 10 Hz.  The human nervous system contains
its own adaptive predictive filters with 100-300mS predictive power.  Add
these to the 100 mS delay and you get an unstable system that can oscillate
at <1 Hz.  This is worst in aircraft simulators where the simulator adds
more lowpass stuff, or when the user is trying for fine positioning.
Second... Hmm, can't remember now, so you KNOW I'm typing this inside of
mail! (B-{)

- Dave Stampe

---

From: [email-masked] (John D Beutel)
Date: Sun, 20 Oct 91 22:28:39 EDT

> read the glove, you just get older data.  

That's what I'm wondering.  If the samples are made at a constant
rate (like by the original hi-res routine), then are the samples that
the glove makes itself limited by this?  I've listened to the clicks
that the glove makes while being sampled at a constant speed,
and I can't hear any difference between open and closed fingers.
I'm not sure I can tell the difference between 13 and 17 Hz,
but I suspect the glove has a constant sample rate when polled
with the original method, independent of finger position.

> the buffer contents until the interrupt gets new data and updates the buffer.

I agree; the quick-polling method you discovered should get
the data the fastest possible way.  I'm worrying about the
graphics routines and how much time they take.  However long
it is, it won't vary according to the polling rate of the glove.
So, there's a trade-off involved with quick-polling.
To keep the response time as fast as possible, the graphics
must be synchronized with the glove polling.  But, if the
fingers are open and there's only 58 ms between polls,
then that's all the time the graphics routines will have,
so they must be able to do their job in 58 ms.  If the
fingers are closed and there's 80 ms between polls, then
the extra 22 ms will be wasted (unless the graphics can
be written to do the minimum rendering in 58 ms and some
worthwhile extra rendering if more time (up to 22 ms) happens
to be available).  Wasting the CPU time on the long intervals
is the trade-off for having a quicker response time.
If the glove sync's itself to the rate it's polled (as it
seems to when polled with the old method) then the
graphics can be written to take a constant CPU time
(e.g., 80 ms), fully utilize the CPU, and still stay
in sync with the glove.  

However, the whole point to sync'ing the code and the glove
is to avoid an average 30 ms extra lag time, so if the
original polling method adds any extra lag time to the
quick-polling method, then it may not be worth sync'ing
(or it may be worth accepting the wasted CPU time).

Maybe I think about this too much.  It shouldn't be
really important unless the glove is being used on
eyephones, and in that case the fingers would be off anyway,
so the sample rate would be constant regardless of method.

I haven't gotten your quick-polling method working (yet)
(I haven't even gotten the original working in the right
order all the time yet), but I'm a little worried about
the "reset after 500 polls of no A0".  That sounds like
a 1 or 2 second interruption of data; how often does it happen?
When and why?

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