Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uwm.edu!ogicse!milton!hlab From: mark@cs.ualberta.ca (Mark Green) Newsgroups: sci.virtual-worlds Subject: Re: VR hardware questions Message-ID: <1991Jun25.155424.29122@milton.u.washington.edu> Date: 24 Jun 91 13:56:44 GMT References: <1991Jun25.000625.19611@milton.u.washington.edu> Sender: hlab@milton.u.washington.edu (Human Int. Technology Lab) Organization: University of Alberta, Edmonton, Canada Lines: 100 Approved: cyberoid@milton.u.washington.edu In article <1991Jun25.000625.19611@milton.u.washington.edu>, dtj@sumac. cray.com (Dean Johnson) writes: > In article <1991Jun24.195408.13585@milton.u.washington.edu>, mark@cs. ualberta.ca > (Mark Green) writes: > > > >In article <1991Jun24.153351.13571@milton.u.washington.edu>, dtj@sumac.cray.c om > > > (Dean Johnson) writes: > > > >> 1. Does anybody have any idea what the cost of a plain Polhemus emitter (th e > >> thing on the top of the eyephones) costs all by itself, not including th e > >> boards, etc. that go with it? I am trying to get a handle on what it wou ld > >> cost to prototype other devices, presuming that you have bought atleast > >> one "full boat" system. > > > > I'm not sure why you would want this. The source and sensor are relatively > > easy to fabricate. The Polhemus itself is relatively old technology > > and could be improved greatly if it was reimplemented using current > > handware devices. For the technical details on the Polhemus see the > > Sept. 1979 issue of IEEE Transactions on Aerospace and Electronic > > Systems. > > Because I know little or nothing about hardware and the underlying technology, > but I'm hoping that it would be trivial to mount an emitter on something other > than an eyephones unit. I am looking at the polhemus as a black-boxe and I > want to staple them ;^) to something else. Additionally, I am hoping that usin g > existing mechanisms, the amount of programming (and debugging) is minimal. > >From a totally hardware naive perspective, if reimplementing the polhemus > in newer technology was easy, why hasn't someone done it? At least I haven't > seen it done. I don't mean that to sound like I am being critical of the > statement, but I do express my skepticism. Thanks for the reference, it gives > me somewhere to start working on opening the blackbox. > I'm not sure if this is answering your question, but the Polhemus can be purchased as a separate unit. The base model cost around $3000 and can be purchased from Polhemus Navigation Systems (a rather obvious name :-) ). We have had one of their standalone units in our lab. for 4 or 5 years. You can mount this device on anything you please or just hold it in your hand. > > > >> 2. Does anybody have any experience with drivers and interfaces to the > >> dataglove, other than through the Macintosh and "Body Electric". > >> Someone *has* to have tried to hook it up to a Sun or something like tha t. Even > >> instances where you hit a "show-stopper" is of great help. Perhaps we > >> can get a collaborative effort going for the DG like is going on with > >> the PowerGlove. > > > > For several years we have used a client-server model for driving the > > DataGlove. One process runs on one of our SGI workstations and interface > > with the DataGlove using the standard serial protocol. This process > > handles all the low level details of the interaction with the DataGlove. > > The user process uses a subroutine library to communicate with the > > server process. The user program can reside on any of the workstations > > on our laboratory. Communications between the two processens is through > > TCP/IP over an ethernet. > > Yep, that is exactly what I am interested in! Having done that, have you > seen any improvement in the speed in interacting with the world? I guess > what I am looking for is whether or not the Mac is a bottleneck to the > overall system? This leads to question of world building and controlling > software, did you "roll your own" or are you using some commercial package? Yes we have definitely done this, we have been using this approach for about 2 years now (see Graphics Interface'90 Proceedings for a description of our early software). All of our software is home-grown. It currently runs on SGI machines, and we will start porting it to DECstation 5000's any day now. The lag time for the Polhemus is an interesting issue. We have done numerous experiments to measure the lag time for different software configurations. Our measurements vary from 85ms using direct access to the Polhemus, every possible optimization and no application software, to around 140ms when the client-server model is used with a 20 Hz sample rate (the peak sample rate for the Polhemus is 60Hz). Using a client-server model significantly simplifies the software engineering side of dealing with the Polhemus and reasonable update rates. > > -- > -Dean Johnson > Software Berserker/Rabid-Prototyping Specialist > Tools, Libraries, and Commands Group > Cray Research Inc. Eagan,MN (612) 683-5880 [MODERATOR'S NOTE: Three rounds of inclusion may be all the human mind can tolerate. (A lesson for designers?) This interesting dialogue should now be started anew, typographically, for ease of understanding and editing. Thanks. -- Bob Jacobson]