PS Move API head tracking test

[Fredz]

[youtube]http://www.youtube.com/watch?v=6aAJZDBsC6M[/youtube]

Tracking of a PS Move controller with a PS Eye camera on a PC while rendering a holodeck-like room to simulate head tracking. It works on a Linux machine (Debian/unstable) using the PS Move API for tracking and Allegro/OpenGL for rendering.

The video doesn't do justice to what it looks like in reality, thanks to my old Canon camera that doesn't seem to be able to correctly handle 60Hz rendering.

The calibration doesn't seem to work correctly since there is a lot of rotational drift, even when not moving the controller. The position seems to be tracked with a good precision and accuracy with low latency when orientation capture is disabled in the first part of the video.

PS Move API : http://thp.io/2010/psmove/
Allegro : http://alleg.sourceforge.net/

[brantlew]

Very nice.

[cybereality]

Cool man! Looking good.

[Fredz]

Thanks for the comments.

The rotational drift is a big problem for now but I think it should be possible to get rid of it. The author of the PS Move API posted a showcase video where there doesn't seem to be any problem with orientation.

He has also updated the webpage for his project today and has added a link to his master thesis about sensor fusion. The full text is not available yet but he gives interesting informations about the capabilities of the system.

Link to the thesis : http://thp.io/2012/thesis/

Test machine : Intel Core 2 Duo 2.53 GHz (single-threaded)
Controller tracking : 68 frames/s
Inertial sensor retrieval : 87 updates/s

Test machine : 1.40 GHz Linux machine
Total end-to-end latency : 68 ms (± 3 ms)

[PasticheDonkey]

i wonder if you could get absolute position and angle with just two illuminated balls. rare cases of occlusion could be worked around i think. of course that could end up with you looking like some kind of mickey mouse. maybe better to have the camera on the head and the balls say attached to surround speakers if you've got them.

[Fredz]

i wonder if you could get absolute position and angle with just two illuminated balls. rare cases of occlusion could be worked around i think.

Yes I guess it can be done with two PS Move and optical tracking only, but as you said it'll probably suffer from line of sight problems. It'll also add undesirable weight to the whole, but that could be overcomed by simply using ping-pong balls with LEDs inside.

But I wont take this approach though, my goal was to implement a tracking solution that anybody can use and at the lowest possible cost. That means using widely available off-the-shelf components that work out of the box with no technical skills required.

A PS Eye + PS Move bundle was the perfect candidate for that, it can be bought for less than $70 (PlayStation Move Essentials Pack), which I think could make it the cheapest possible 6dof tracking solution. All the 9dof trackers I've seen (SparkFun, Hillecrest, Yost, Mongoose) cost at least $100 and only provide 3dof rotational tracking and often require soldering skills.

There is also the added benefit of being able to use it directly on a PS3 for indie programmers.

I think the jittering problems I've been experiencing are only related to the software side. I've tested different gain values for the Madgwick fusion algorithm and the jitter was basically gone, but it produced a continuous drift always in the same direction. I'll try with the previous version of the algorithm that seemed to take this problem into account.

maybe better to have the camera on the head and the balls say attached to surround speakers if you've got them.

Several people have already started working on this, but I'm not sure it'll be that easy to implement. I didn't go this route either because some control over your environment would be needed. If you're interested in this you may have a look at the thread about Visual Odometry where there have been interesting discussions going.

[PasticheDonkey]

oh i like that your taking the approach of making it usable for the most people. nice to have that clarified.

the only problem is that even in official implementations you get drift that can only be rectified with thrusts towards the camera. it's still not air tight. i hope the presumed move 2 can solve some of these problems and fit with your approach in the not too distant future, or that you can find a software work around.

so i checked out the Visual Odometry thread and it's not really for me. i'm too much of a generalist who can only offer suggestions of little tweaks to things to improve general usability/performance.