dtj@sumac.cray.com (Dean Johnson) (06/24/91)
Since pounding on the moderator (sorry Bob!) about the lack of "reality" in
this Virtual Reality group, I realized that I have done little help the
situation. It is now time for me to stop bitching and start working!
1. Does anybody have any idea what the cost of a plain Polhemus emitter (the
thing on the top of the eyephones) costs all by itself, not including the
boards, etc. that go with it? I am trying to get a handle on what it would
cost to prototype other devices, presuming that you have bought atleast
one "full boat" system.
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 that. 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.
3. How 'bout starting a list of scientific problems for which VR may
serve as a "silver bullet". This group of problems does not include
things like "flying around the Puget Sound" (sorry Bob) or entertainment
type problems. An example of a "silver bullet" solution would be something
like a flight simulator, with which a company (or government) can
economically and safely train and test pilots. I would also like to try
and keep to a minimum, the problems where VR is just an incremental
improvement over more traditional 3D graphics. I am talking about big
wins with problem solving enhancements in the realm of magnitudes.
--
-Dean Johnson
Software Berserker/Rabid-Prototyping Specialist
Tools, Libraries, and Commands Group
Cray Research Inc. Eagan,MN (612) 683-5880mark@cs.ualberta.ca (Mark Green) (06/24/91)
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]
mark@cs.ualberta.ca (Mark Green) (06/25/91)
In article <1991Jun24.153351.13571@milton.u.washington.edu>, dtj@sumac.cray.com (Dean Johnson) writes: > Since pounding on the moderator (sorry Bob!) about the lack of "reality" in > this Virtual Reality group, I realized that I have done little help the > situation. It is now time for me to stop bitching and start working! > > 1. Does anybody have any idea what the cost of a plain Polhemus emitter (the > thing on the top of the eyephones) costs all by itself, not including the > boards, etc. that go with it? I am trying to get a handle on what it would > 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. > 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 that. 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 processes is through TCP/IP over an ethernet.
dtj@sumac.cray.com (Dean Johnson) (06/25/91)
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.com > (Dean Johnson) writes: > >> Since pounding on the moderator (sorry Bob!) about the lack of "reality" in >> this Virtual Reality group, I realized that I have done little help the >> situation. It is now time for me to stop bitching and start working! >> >> 1. Does anybody have any idea what the cost of a plain Polhemus emitter (the >> thing on the top of the eyephones) costs all by itself, not including the >> boards, etc. that go with it? I am trying to get a handle on what it would >> 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 using 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. > >> 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 that. 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? -- -Dean Johnson Software Berserker/Rabid-Prototyping Specialist Tools, Libraries, and Commands Group Cray Research Inc. Eagan,MN (612) 683-5880 [MODERATOR'S NOTE: Do I detect some value to the newsgroup? Hmmm? ;-)] n
testarne@athena.mit.edu (Thad E Starner) (06/25/91)
About Polhemi:
Polhemus Boxes cost around $2000 - or so I've been told.
The address on the 3Space manual says:
Polhemus
A Kaiser Aerospace & Electronics Company
P.O. Box 560
Colchester, Vermont 05446
The RTI boards people use for real time sampling aren't necessary if you
are running a decent machine. It spills out RS-232 at different baud rates.
If you avoid ASCII mode (and scanf) and optimize things for UNIX
(use select and partial reads), you can easily pull stuff in at the ~60Hz in
the background on a SparcStation 1. Really not that much overhead for
today's boxes.
You probably want to multi-thread your application.
One process to poll the box; one to sit on the RS-232, collect the data,
(optionally) filter it, and respond to queries from the higher level
application; and the application itself.
You can also multiplex the things so that you can have a couple Polhemi
sensors running without interference. The number of samples a sec
is ninversely proportional to how many you run of course (2 - 30 Hz, 3 -
20 Hz, etc.). If there is enough interest I'll post the circuit to
do the multiplexing (simple 555 circuit).
So far, I prefer them to Birds, but I haven't played with the Bird much.
Thad
testarne@media-lab.media.mit.eduesz001@cck.coventry.ac.uk (Will Overington) (06/25/91)
In article <1991Jun24.153351.13571@milton.u.washington.edu>, dtj@sumac.cray.com (Dean Johnson) writes, in part: >3. How 'bout starting a list of scientific problems for which VR may > serve as a "silver bullet". This group of problems does not include > things like "flying around the Puget Sound" (sorry Bob) or entertainment > type problems. An example of a "silver bullet" solution would be something > like a flight simulator, with which a company (or government) can > economically and safely train and test pilots. I would also like to try > and keep to a minimum, the problems where VR is just an incremental > improvement over more traditional 3D graphics. I am talking about big > wins with problem solving enhancements in the realm of magnitudes. On the matter of keeping to a minimum the problems where VR is just an incremental improvement over more traditional 3D graphics... The plain fact of the matter is that for me, and, I suspect many others, particularly people who are not at the centre of things in virtual reality, but would like to learn more and contribute where they can, it is a question of doing what one can with a standard PC and maybe some special board or a virtually home made gadget to plug into the back of the PC via a standard port. Otherwise one can do nothing. Now, I agree that to get anywhere significant, things that are in a league above this need to be the main thrust. However, can I suggest that, in carrying out your excellent suggestion, the group seeks to find a number of areas where lower level contribution, such as by final year undergraduates doing a project on a PC with a few electronic components, if any, plugged in the back, would be valuable. Such projects, well done, could well be the starting point for later postgraduate work. At least, it would be a way to get started. [MODERATOR'S NOTE: Contact Randy Pausch (Univ. of Virginia) at pausch@cs.uva.edu for details on his PC-based system. There are also systems running on Amiga's (check the archives of last Autumn 1990) and Autodesk has been running its Cyberspace prototype on PC's, also. Finally, Sense8 uses a Sun workstation, almost a PC. The fact of the matter is that one can work on a PC, but the design options are extremely limited currently. Others may have other opinions. -- Bob Jacobson]