6 DOF Head Tracking Ideas

Post by **cadcoke5** » Fri Aug 10, 2012 9:25 pm

I recall looking in to some ultrasonic 3D pointing devices many years ago. I seem to recall an accuracy around 6". Part of the reason for that is air doesn't always stay still for you. Especially, in a large area, you are going to have air currents adding or subtracting from your measurement. Also, temperature, air pressure, and humidity affect the speed of sound, and therefore your results. Though, you don't need to directly measure this. You just need to compare distance to a known target to calibrate. This calibration would be good for a while and would not vary from minute to minute like air currents would. One more thought, can temperature vary greatly from ceiling to ground in a large room.

Regarding video processing of an unmarked room. I wonder if a super fast method could be created that didn't really try to find anything, but functioned like an optical mouse. In fact, maybe a mouse sensor could be used. If it could stay focused enough on distant targets, then with more than one mouse, you would have enough information to get relative roll, pitch and yaw. Perhaps this would be better than accelerator based gyro info.

Of course, the camera target tracking equipment could do this as well. Perhaps it would do the optical mouse trick 90% of the time, and then hunt for targets the remaining 10%. (or some other ratio) But the mouse idea would be great it it could be implemented easily, because the hardware is so cheap. I suspect, however, that the act of focusing and positioning the lens would be a challenge.

Joe Dunfee

Post by **Nick3DvB** » Fri Aug 10, 2012 10:07 pm

On the face of it an (ultra)sonic system should be viable, bats seem to manage ok with it, but then we are using very crude sensors in comparison, and they've been working on it for a few million years longer than us! As you say there are probably just too many environmental factors to work around, and if we want low latency the speed of sound doesn't help either.

I might have got the wrong end of the stick again but I seem to remember John saying that he'd talked to intel about some sort of "optical rate sensor" and didn't get very far, but that it "would make a good PhD project for someone". I immediately thought of an optical mouse to, but if that form of sensor would do it I'm sure we wouldn't be having this discussion. I think it was in the keynote somewhere, I'll try and find it.

The more I think about it a mechanical solution doesn't sound so crazy after all, I was planning on sticking a cable hook on the ceiling anyway so why not replace it with a $20 GameTrack on a projector ceiling mount? I can live without an accurate vertical reading, so could do away with the retracting tracking cord and just replace it with the combined signal cable (lightly tensioned / super-thin) going to a small slip-ring on top of the HMD. For zero latency I'm half tempted to try it...

http://janoc.rd-h.com/archives/129

Post by **android78** » Sat Aug 11, 2012 12:52 am

@joe (cadcoke5): I'm really wondering about the idea of using the optical trackers from mice, since they have really fast image sampling rates and already have processors to translate into an accumulated movement. Adding a lens to focus on walls shouldn't be hard at all. The thing that i'm trying to work out is how you could use 4 of these (front, back, left and right) and the relative observed movement from each to determine your movement in the room. if you had a textured roof and always held your head straight up and down, it could work well.
Maybe the best way would be to have textured roof, and combine the tilt of your head from the accelerometers (this is usually pretty accurate) to determine the position? You would need to make sure that you were not ducking down for this though.

Post by **Nick3DvB** » Sat Aug 11, 2012 8:28 am

Focusing is a real problem, maybe some sort of plenoptic light-field sensor will solve it one day, but laser range tracking might be an option? I wonder if the same mouse DSPs, or at least the same DDIT algorithums could be used with much larger camera CCDs? I assume these mouse DSP chips need a pin-sharp image to track on, but they are so cheap maybe you could use dozens of them together at different angles / focal lengths?

Post by **cadcoke5** » Sat Aug 11, 2012 7:36 pm

Here is a link to a guy who hacked an optical mouse to use it to scan a page of text... well at least a few letters.
http://spritesmods.com/?art=mouseeye

I don't know if it really applies here, but it shows that they can be hacked to do things.

Regarding how two mice can give you roll,pitch, and yaw; Imagine you have one mouse looking up from the top of your head. That will give you roll and pitch, but not yaw. A 2nd mouse pointed horizontally can then give you yaw. But, and a big but, is if the sensor can be focused at objects at a distance.

I would think this has been discussed within the robotics community, and either used or abandoned as no workable. They hack old fashioned mice with roller balls, to get their encoders for the robot's wheels. Just aiming a mouse at the floor would be an even easier hack... if the lens part were easy.

I just found a great article about using these mice chips to aim at a few inches for robot odometry. He also cites a number of other resources.
http://home.roadrunner.com/~maccody/rob ... oms-1.html

Another vague memory I have is an article about getting an image directly off of a memory chip by just cutting the top off of a chip, and focusing an image on the chip itself. Now, please understand that this is a vague memory, so perhaps it is not fully accurate. I have not been able to find it again.

Joe Dunfee

Post by **Nick3DvB** » Sun Aug 12, 2012 9:59 am

Great links Joe, I'll have to try that mouse mod out at some point. This might actually be good for translation tracking to, I wonder if you could do the surface illumination with a brighter / larger area light source mounted on the ceiling / walls themselves, then you just have to worry about sensors autofocus mechanism, which could be the complex / expensive part.

Post by **cadcoke5** » Sun Aug 12, 2012 11:21 am

Ideally, you would want a system that doesn't need focusing. Fixed focus has been on cameras a long time, but they had to accept a limit on how close you could take a picture. I wonder if it might be possible to go for a range of 3' to infinity, and that would be acceptable fixed focus.

However, if the idea of a camera with on-board processing and looking for targets is used, this optical mouse type tracking is probably best done on the same camera. But, if the camera does not have on-board processing, then the mouse sensor may be a good supplement to that method because of the hardware response time being so good.

I know there is one other industry that uses linear optical sensors. The auto-focus in a camera needs to line up the two bits of image in the center of the lens. Years ago, when auto-focus was just being introduces, I recall reading about this. But, nowadays, i don't know if these are separate sensors, or just part of the main imaging sensor that is processed differently.

Joe Dunfee

Post by **brantlew** » Sun Aug 12, 2012 3:06 pm

cadcoke5 wrote:Regarding how two mice can give you roll,pitch, and yaw; Imagine you have one mouse looking up from the top of your head. That will give you roll and pitch, but not yaw. A 2nd mouse pointed horizontally can then give you yaw. But, and a big but, is if the sensor can be focused at objects at a distance.

I think it could be tricky deriving rotations from a mouse-like optical solution - hence the need for good resolution and focus. If however you left rotation to traditional gyros and just detected lateral and vertical motion using camera optics, it might simplify the problem. Then all you need to do is detect the direction of image pans which seems a lot easier to do even with low quality video and poor focus, and not nearly as ambitious as a PTAM solution that attempts to reconstruct a whole scene.

Post by **FingerFlinger** » Sun Aug 12, 2012 3:22 pm

Found a paper on the use of optical mice for robot navigation. http://www.ri.cmu.edu/pub_files/2009/7/DilleFSR09.pdf

Post by **GekkePrutser** » Mon Aug 13, 2012 7:22 am

Hi Everyone!

Just another lurker here, been thinking about building my VR setup but the right hardware wasn't available.. Until now of course

I ordered my Oculus the first day. I'd been following the forum for a while.

I was also thinking about making something with free room tracking... Because that would be the best way for immersion. What I was thinking about (I'm a HAM radio operator so I'm thinking along those lines), was 2 radio antennas transmitting a radio signal which is perfectly in sync (one transmitter with 2 cables of the same length to the antennas ought to do that).

The wave interference pattern would create a pattern of hotspots/low spots like so:

(Image not mine, I just googled it). This is similar to sound waves cancelling each other out depending on the phase. The radius of the circles will depend on the frequency used (for high-resolution you'd want a high frequency with not much spoiling interference so 2.4Ghz is totally out of the question), but maybe 5Ghz is possible as long as it's free of license (not sure if this is the case, haven't looked it up yet). But the user him/herself may block the signal if it's too high in frequency.

If you walk around then with a signal strength meter (tuned to the right frequency), you should get a varying strength als you walk around. With 4 receive antennas in a known square you could perhaps derive some kind of distance information because you could track the signal moving around the room. Unfortunately as you can see the distance between hotspots is not uniform, not predictable, and they don't occur in straight lines, and it's also dependent on the room: If the radio signal starts bouncing off items or walls nearby the pattern may be messed up so much that it becomes static (the wave pattern will be destroyed). But perhaps this is manageable by using as low power as possible.

But I was thinking that if this information is combined with gyro/accelerometer data, it could be used to augment the data.

Not sure if this would actually work but if I have some time I'll see if I can set something up and see if it's in any way useable. It's just something that came to me when I was thinking about this problem, and I just wanted to put this out there in case any of you were thinking along the same lines.

Post by **brantlew** » Mon Aug 13, 2012 8:02 am

@GekkePrutser: Keep working on it. There a few guys on the forum working on RF tracking solutions. RF is great because you avoid the occlusion problem, but it can get complex dealing with the signal timings and bounces.

Post by **GekkePrutser** » Mon Aug 13, 2012 8:43 am

brantlew wrote:@GekkePrutser: Keep working on it. There a few guys on the forum working on RF tracking solutions. RF is great because you avoid the occlusion problem, but it can get complex dealing with the signal timings and bounces.

Thanks, I wasn't aware of them.. I'll have a look around on the forum!

And yes you would avoid the occlusion problem, although depending on the frequency of the signal, the human body will block it a bit, or change the signal pattern a bit (the large bag of salt water which we are is basically a conductor and will couple itself to the antenna). Like when TV reception improves or gets worse when you stand close to the antenna.

I was thinking of putting the 4 receive antennas on top of the head (and hope nobody sees it

) and have the transmit antennas high up so this would not be so much of a problem, but I don't know how much it will be. And I don't think you could bend over very much.

The main thing I was hoping for was a bit higher resolution, as anything camera based is fairly low (even a full HD cam tracker would only have 1920 measuring points horizontally).

Post by **brantlew** » Mon Aug 13, 2012 8:49 am

The subject is touched on a few times within this thread. Krenzo seems to have made some great progress with an RF approach.

http://www.mtbs3d.com/phpBB/viewtopic.p ... =45#p75456

Post by **GekkePrutser** » Mon Aug 13, 2012 9:00 am

brantlew wrote:The subject is touched on a few times within this thread. Krenzo seems to have made some great progress with an RF approach.

http://www.mtbs3d.com/phpBB/viewtopic.p ... =45#p75456

Oops, sorry! I make a point of reading through a thread before I reply to it but I kind of skimmed this one because it was so many pages. I missed that. His sounds much better, he's clearly put a lot of time on it. I like the idea of modulated radios, I assume he's measuring the distance from several transmitters. I also like the way he can filter out reflections. It must be pulsed for that I assume.

Like I said, I don't have anything at the moment, just that idea, it's good to see people are working on it and are so far with it. I'm already very busy for the next month but after that I might have the time to start some experiments.

Post by **bobv5** » Mon Aug 13, 2012 11:39 am

http://www.youtube.com/watch?v=-KxjVlaLBmk
http://hackaday.com/2009/07/30/amazing-robot-dexterity/

Thought you guys might like these, shows how fast tracking can be.

Brantlew, I could have told you wiimote was 100Hz, in Freetrack anyway. I think that what you called inital latency is what I was worried about. I would say that 100Hz is the update rate, and the latency is still unknown. Perhaps I am using the wrong words, but what I mean is if the update rate is 100Hz, and the wiimote takes 10 cycles to process the signal before it gets to the PC, then that would mean the latency was actually 100ms, not 10ms.

For sonic tracking, it might be posbile to use 2 different frequencies, for example 50kHz and 60kHz. The different frequencies could be alternated, allowing the 50kHz echos to drop off while the next cycle uses 60kHz. By the time the next 50khz cycle was due, the echoes from the previous one shoud be low enough to ignore even if not completely dead.

I think the lateral postioning of the Hillcrest tracker has some value as a simple on/off type tracking, for example, ducking or standing, leaning or not leaning, just mapped to key presses.

Another idea is to use multiple acelerometer chips. If the errors produced are random, using 2 or more chips and averaging the results should give better accuracy. I have no idea how to program something like that, but I bet even a *pie script and a pair of wiimotes would be enough to check the general idea. If the sensors always drift the same direction, it might be possible to use two mounted the opposite way, and cancel the errors that way. This still won't be perfect, but it might be enough to make the Kinect+Inertial idea work.

Post by **brantlew** » Mon Aug 13, 2012 12:29 pm

@bobv: Wow! Those videos are shockingly good. That robot throwing and catching the cell phone is amazing! So yes, I believe that proves the point that optical can be an extraordinarily fast and accurate motion sensor.

Post by **divide** » Mon Aug 13, 2012 3:04 pm

I read that the PS3 Eye webcam, when used on PC, had extremely low latency (around 16ms).
If this is true, you could get something very nice out of a pattern based 3d tracker like ARToolkit (I've been using it a few years ago).
However I guess this is the same as using a Track IR kit, which has even smaller latency (10ms).
The only problem with theses solutions is that you are limited to a front view (no 360).

My other idea today was mounting a smartphone in front of the HMD, and do some PTAM tracking coupled with the sensors from the smartphone. You would have full freedom, but it gets a bit complicated (porting PTAM on smartphone, coupling with sensors and sending back by wifi...).

Post by **divide** » Mon Aug 13, 2012 3:18 pm

...or you could mount a PS3 Eye on the HMD and do PTAM on the computer: fast, accurate, 6 DOF with full freedom of movement.
Plus the wild field of view (75 degree) is perfect for stable tracking, and latency can go under 10ms when used at 320x240@120fps. You could even use the 3d tracked points to issue a warning if you're getting too close to a real object while you're in the virtual world

The only downside would be the added weight (? cannot find any record about that). You could still dismount the camera to only keep the optic, sensor and electronic to drop some weight. The camera is pretty cheap anyway ($22).

Post by **brantlew** » Mon Aug 13, 2012 4:24 pm

After you have run through all the candidate technologies and assess their strengths and weaknesses, it seems like everybody tends to eventually arrive at the same general conclusion. Head mounted camera technology like PTAM is probably going to be the best overall solution to the 6DOF problem. Unfortunately its probably also the most challenging technology for the hobbyist. You practically need a masters degree in EE and signal processing to start down that path, which is why everybody is looking for shortcuts that just require basic trigonometry. Maybe there are some decent image processing toolkits available that can help the layman get some basic things working relatively easy. But it would be difficult to extend the functionality without digging pretty deeply into the theory and code.

Post by **divide** » Mon Aug 13, 2012 4:35 pm

I'm talking about PTAM because I know there's already a rock stable solution available with a free source code

http://ewokrampage.wordpress.com
So it's just a matter of software integration, no PTAM R&D required. Check out the videos:
http://www.robots.ox.ac.uk/~gk/PTAM/

A few years ago I've been implementing ARToolkit in a tracking software for film postproduction so I guess it's pretty similar here.

Post by **brantlew** » Mon Aug 13, 2012 4:59 pm

@divide: It certainly does look promising - especially for the unidirectional/seated case. If calibrated against a cluttered background the results look really good. I would love to see someone try to implement this with PSMove camera or similar and feed the results into something like the Valve engine.

It's not clear to me that it works for 360 turning or the free-walking scenario, but I need to allocate some time to download it and figure out exactly what its limitations are.

I'm definitely interested.

Post by **FingerFlinger** » Mon Aug 13, 2012 5:03 pm

Libviso2 is another option to look at. They claim high-performance stereo visual odometry, but I haven't done much except download the library yet.

Post by **Nick3DvB** » Mon Aug 13, 2012 7:49 pm

I've been looking into SLAM / PTAM for a while, a lot of work has already been done around the OpenCV lib: http://www.cvpapers.com/rr.html

Camera "pose estimation" seems pretty fundamental for our needs:

http://cvlab.epfl.ch/software/EPnP/ (MatLab)
http://www.morethantechnical.com/2010/0 ... cv-w-code/
http://www.visual-experiments.com/tag/gpusurf/

brantlew wrote:It's not clear to me that it works for 360 turning or the free-walking scenario, but I need to allocate some time to download it and figure out exactly what it's limitations are.

Maybe of interest: http://www.visual-experiments.com/2010/ ... g-reality/

I was hoping there might be an "off the peg" Android PTAM package by now, to run on the RasPi / smartphone, but all I can find is some Korean research project.

PTAM with a cheap PSeye camera (or two) is starting to seem like a very good option, it looks like we are half way there already?

Post by **brantlew** » Mon Aug 13, 2012 8:09 pm

Nick3DvB wrote:PTAM with a cheap PSeye camera (or two) is starting to seem like a very good option, it looks like we are half way there already?

I bet Oculus is at least considering this technology for the consumer version. It fits well with the single self-contained device strategy, plus you get pass-through navigation cameras for free.

Post by **cybereality** » Mon Aug 13, 2012 8:43 pm

I agree that markerless-tracking is ultimately the way to go. Seems like there are a few solutions out that that look promising.

Post by **Nick3DvB** » Mon Aug 13, 2012 10:25 pm

brantlew wrote:I bet Oculus is at least considering this technology for the consumer version. It fits well with the single self-contained device strategy, plus you get pass-through navigation cameras for free.

AR applications for HMDs might not be an option for quite some time, because of the focus problem with current display technologies etc, but I think instant (button-press) visual pass through could be critical to mass-market acceptance of HMDs anyway, not only for navigation, or the obvious "safety" reasons, but just basic things like looking at your keyboard, finding your drink, or seeing who just walked in the room. The fact they solve all your tracking issues to is just an added bonus! The cameras shouldn't add too much weight / cost to the HMD, we have the compute power so this is really a software problem. The likes of Nintendo and Apple probably have it solved already, but hopefully there is enough research in the public domain for a small player to put a decent PTAM solution together now.

I found a few more bits on pose estimation here:

http://www.es.ewi.tudelft.nl/papers/201 ... mation.pdf
http://av.dfki.de/publications_2011/mar ... n-overview
http://homepages.inf.ed.ac.uk/cgi/rbf/C ... pl?TAG1159
http://people.ee.ethz.ch/~gfanelli/pubs/dagm11.pdf

Post by **divide** » Tue Aug 14, 2012 2:16 am

brantley: Sure if you do a pure 360 with no translation the tracker cannot recover depth data, but fortunately our eyes do translate when we rotate our head due to the neck-eyes distance. Also check out this video, it has some long walk and rotations in it:
http://www.youtube.com/watch?v=Y9HMn6bd-v8
It also shows a few case where tracking fails, though some of them were improved in later revision of the source code.

Nick3DvB: I've been checking all your links but it's either refering to papers/experiments (you still have to write the full algorithm, implementation and tweaks) or limited libraries (either requiring stereo camera or constrained motion). So I'd probably stick with the PTAM I linked a few post earlier I guess.

The only worry is the computation time, according to the original paper it was around 20ms in 2007. That was with a Core 2 Duo 2.66Ghz and the first iteration of the algorithm (changelog shows various optimizations). I wonder how it scale now. Anyway, according to theses numbers global latency would be between 25ms-35ms. Not too bad ! And if it's not low enough, it would be no problem to integrate the latest gyros and accelerometers data to the PTAM result over such a tiny timeframe, since integration error would be almost non-existent. This way you could go as low as 8ms latency. Additionnaly, the accelerometers could also automatically scale the PTAM tracking to real world dimensions.

Also I asked a friend of mine to weight his PS3 Eye, good to know it's only 30 grams

Post by **brantlew** » Tue Aug 14, 2012 7:47 am

divide wrote:The only worry is the computation time, according to the original paper it was around 20ms in 2007. That was with a Core 2 Duo 2.66Ghz and the first iteration of the algorithm (changelog shows various optimizations). I wonder how it scale now. Anyway, according to theses numbers global latency would be between 25ms-35ms. Not too bad !

Even if the speed is good enough, I wonder if the drag on CPU and memory bandwidth would hurt gaming frame rates. The best would be if you could task all the image processing to a mobile phone or dedicated computer and then just transmit the computed motion to the host computer.

Post by **divide** » Tue Aug 14, 2012 7:53 am

Unfortunately mobile phone cameras have about 200-300ms latency... Also, you would need to do some heavy optimization: the Android port of PTAM is running 5fps, and the iPhone port is much less accurate to be able to run realtime :/
A dedicated computer could do it, but then I'm not sure how you would retrieve the data back with no latency for gaming.

NB: from what I understand PTAM use only 2 cores, so you still have the 2 other cores (on a quad CPU) for gaming.

Post by **brantlew** » Tue Aug 14, 2012 8:13 am

divide wrote:A dedicated computer could do it, but then I'm not sure how you would retrieve the data back with no latency for gaming.

You can push UDP packets over Ethernet or even WiFi with just a couple milliseconds of latency. That's a very worthwhile exchange for all the host latency you save by not consuming half your resources with image processing.

Post by **Nick3DvB** » Tue Aug 14, 2012 8:19 am

Network latency should not be a major problem, but sadly I seems that current smartphones or RasPi would not have the horse power for low latency PTAM, but we already have more CPU cores than most games know what to do with, and this really is "the perfect job for CUDA" (cringe!

), a few people have already ported certain elements over to it with good results.

I just posted those links for background information, there are some great resources available and it's good to see a lot of work continues to be done in this area, but you would definitely want to start with the Oxford reference implementation. I'm not sure if it can make good use of a second camera yet but I also think it makes sense to use PTAM in conjunction with other sensors, even if there is currently no mechanism for them to inform the PTAM system itself.

Post by **brantlew** » Tue Aug 14, 2012 9:53 am

A lot of the example videos I have seen seem to be doing full scene reconstruction for AR purposes. I wonder if for just gross motion detection you don't need quite as much image fidelity. If so then maybe just for motion detection you could use low resolutions like 320x200 or even lower? Your precision will fall off - ie. maybe you go from detecting 1 millimeter camera motion to 3 or 4 millimeters, but that might be a reasonable trade-off if you could, for example run the process on a smart phone, or reduce the drag on the host computer by a factor of 4. We discussed earlier that latency and precision are not as crucial for translations as they are for rotations.

So (pulling numbers out of my a$$), maybe a reasonable tradeoff could be achieved by running low-res camera translation detection on a smart phone at 15fps and using a fast gyroscopic tracker for rotations. Sure it's not perfect, but it could still offer very good subjective results.

Post by **divide** » Tue Aug 14, 2012 10:15 am

I'm not sure this would reduce computation costs a lot, since PTAM use different level of details anyway (640x480 picture is automatically scaled down to 320x240, 160x120, etc).
Plus I think it's good to have absolute rotation from PTAM too, as gyros tends to drift over time.

Post by **Nick3DvB** » Tue Aug 14, 2012 10:22 am

If we can effectively integrate the gyro data, and make use of stereoscopic odometry, maybe we can get away with a faster "bare-bones" PTAM implementation, just cherry-picking the elements required for translation and to work as a reference to correct drift.

Post by **brantlew** » Tue Aug 14, 2012 10:41 am

divide wrote:I'm not sure this would reduce computation costs a lot, since PTAM use different level of details anyway (640x480 picture is automatically scaled down to 320x240, 160x120, etc).
Plus I think it's good to have absolute rotation from PTAM too, as gyros tends to drift over time.

This is one of those places where understanding the theory would really help. I guess I'm postulating that you could run the whole image processing chain at half the resolution to get half or quarter precision. So your step sizes would now be 160x120, 80x60, etc... At some point this would just break-down once the information level drops below some threshhold, but maybe you could still retrieve useful information at resolutions much lower than 640x480.

For angular precision you would need high resolutions, so I would be willing to go with gyros if it meant I could get decent translations at a reasonable cost. Besides, gyro drift is seldom a problem in practice - especially for 360 free rotation. If it is a problem there are other methods to control yaw drift.

So this is basically the "fancy" version of the optical mouse solution. Low-res image pan detection combined with gyro rotations. Now I just need to get my masters degree in image processing so I could actually modify the PTAM libraries for this purpose

Edit: @Nick: Yeah that's what I'm sort of saying. Just streamline the algorithm to the absolute bare essentials.

Post by **Nick3DvB** » Tue Aug 14, 2012 11:40 am

brantlew wrote:Now I just need to get my masters degree in image processing so I could actually modify the PTAM libraries for this purpose

I wouldn't know where to start, but you've got until November ok!

We really need to collar someone in the field and explain our requirements, there may be a ready made solution out there already. Maybe post something here:

http://cvisioncentral.com/forums/
http://tech.groups.yahoo.com/group/OpenCV/messages

Post by **divide** » Tue Aug 14, 2012 11:49 am

You don't seem to realize the amount of R&D iterations this would require until a rock stable and optimized solution is ready...
Stereo camera raise the problem of syncing the cameras (zero latency between the 2). Then you would have to develop a stable AND optimized tracking specifically for stereo cameras. AND it still has to be PTAM if you don't want your 3d tracking to drift over time.

Also, monocular feature projection only takes 3ms over the 20ms process in Klein's PTAM so you would not gain that much computation time with stereo cameras... You may even loose some time by doubling the frame processing.

I'm not saying you should not dream about such solution, but if you want a working solution right now with Oculus Rift you'd probably stick with the already working solutions such as Klein's PTAM and PS3 Eye, trust me there will already be enough work to do for a proper integration, not even talking about gyros/accel integration, properly mounting the hardware and injecting the 6DOF into video games...

Post by **Nick3DvB** » Tue Aug 14, 2012 12:10 pm

I hear what you're saying divide; there is certainly no point re-inventing the wheel! But a lot of work has already been done by robotics guys on stereo VSLAM (some using lens splitters on a single camera), so I'm just saying it might be worth finding out if there are "any other wheels" that would do the job, PTAM certainly seems like the best option at the moment but I think it is still worth asking the question, if we can find someone to ask...

Post by **brantlew** » Tue Aug 14, 2012 12:17 pm

Talk is free. We're exploring everything from cobbled together off-the-shelf parts to speculative software methods.

For a quick and dirty off-the-shelf method, it seems like sticking a Hydra on your head is currently the easiest option.

Post by **divide** » Tue Aug 14, 2012 12:19 pm

brantlew wrote:For a quick and dirty off-the-shelf method, it seems like sticking a Hydra on your head is currently the easiest option.

Not sure about that, Carmack has been experimenting with the Hydra ( http://www.youtube.com/watch?v=wt-iVFxgFWk , starting 2h05) and he found out the 3d positioning is not linear; he tried building a calibration map for it but it ended up being too complex.