Received: from watserv1.uwaterloo.ca (watserv1.waterloo.edu) by karazm.math.UH.EDU with SMTP id AA04583 (5.65c/IDA-1.4.4 for ); Sun, 20 Oct 1991 00:15:52 -0500 Received: by watserv1.uwaterloo.ca id ; Sun, 20 Oct 91 01:11:49 -0400 Date: Sun, 20 Oct 91 01:11:49 -0400 From: Dave Stampe-Psy+Eng Message-Id: <9110200511.AA00440@watserv1.uwaterloo.ca> To: glove-list@karazm.math.uh.edu, jdb9608@cs.rit.edu Subject: Re: sampling techniques and response time John D Beutel (jdb9608@cs.rit.edu) 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