|
| | | Junior Member
 
Group: Forum Members
Last Login: 9/20/2008 8:39:52 PM
Posts: 10, Visits: 59 |
| Hi. As some of you might know I've been working with figuring out the data the VR920 sends to the computer to build a Linux driver/programming interface for the head tracking (and hopefully stereo 3D in the future). Well, I've made some progress so far...
Here's a link to a picture of what it looks like with my little test program right now. Note that the on-screen object is mimicking the alignment of the VR920.
http://cybersanitarium.com/tmp/vr920_Linux_1.jpg
There's a little programming interface I've created that basically just allows a coder to get three vectors (up, right, back, and their inverses) that define the alignment of the VR920, the ability to set a zero alignment, and the ability to get a matrix (to transform an object) or inverted matrix (to transform the world around the viewer, possibly) that can be passed directly into OpenGL as a transformation matrix (see: glMultMatrixd()).
Now, I'll be the first to tell anyone that my skills with vector and matrix math aren't quite what they were when I last took a college linear algebra class. So I'm not entirely sure how to get yaw, pitch, and roll values individually without running into problems with "gimbal lock" almost immediately. I think it's probably a symptom of any Euler angle representations like that, but it would certainly help for more simple applications of the tracking features.
There's also the problem of calibration that I need some help with if the developers would be so kind as to lend me a hint about this. The tracking works fine for some angles, but starts to get pretty twitchy at others. This is only concerning the yaw rotation, though, as I can almost always seem to accurately determine the pitch and roll.
So this is what I determined to be the data that the VR920 was sending to the computer every time it read data from it...
3 bytes that do not seem to change
3 16-bit integers giving an 'up' vector
3 16-bit integers that give a vector going up and to a side
1 more byte that does not change
Is this (more or less) accurate? Should I be looking at the data a different way? The 'up' vector is there, and I take the cross product of that with the other vector to get the headset's z-axis, then the cross product of that z-axis vector with the 'up' y-axis vector to get the x-axis vector. All the vectors are then normalized so their magnitude is 1. The transformation matrix is then made from that.
I was going in a different direction early on, and would find min/max values for each of the 16-bit integers as I thought that's what was going on in the calibration in the Windows driver. It would then turn each number into a floating point number from -1 to 1 from that, meaning that the lowest they would go would always be -1, and the highest would always be 1. I'm wondering, is this an approach I should use? Would it fix the problems of it becoming really unstable at certain angles?
Thanks for any input anyone might have. I'm really having a lot of fun working with this thing.
As for my code, I'd like to clean it up and solve this instability problem before posting it up. I also need to add more error checking so the test app doesn't freeze horribly when you unplug the thing. 
|
| |
| | | Forum Newbie
Group: Forum Members
Last Login: 10/16/2008 10:35:43 AM
Posts: 3, Visits: 120 |
| | Hi, i am new to this forum, but i have been following every news i can find about the vr 920 for quite some time now, that is how i heard about your project on the stereo3D.com forum, and now here. I have to say, what you describe seems very impressive, i wish you success in your project. My knowledge in maths is unfortunately too thin to be of any help, but i did heard about a project, i think similar to yours for 3D glasses, with headtracking capabilities. Let me know if you are interested in having a look at it  |
| |
| | | Forum Newbie
Group: Forum Members
Last Login: 9/18/2007 12:47:09 PM
Posts: 2, Visits: 7 |
| | I'm a Linux user and a programmer. Is there any way I could get a copy of your code? I might be able to help with some of the stability problems, but my matrix math skills are also old and rusty. |
| |
| | | Supreme Being
Group: Moderated Users
Last Login: 12/4/2008 1:36:50 PM
Posts: 539, Visits: 1,120 |
| | Can you get accelerometer readings? For example, if you shake the HMD without tilting it, do the values change? Or do they stay the same? The first vector (the "up" vector) could actually be the three accelerometers, just like in a Wii Remote. Accelerometers measure a mixture of the up vector (with magnitude of 9.8m/s/s, or 1G) combined with the acceleration. This is because accelerometers are basically just a weight on a spring, or you could say it is like a person on a bus. When the bus accelerates forwards, the passengers feel pushed towards the back of the bus, when the bus stops suddenly (decelerates) the passengers feel flung towards the front of the bus, and this measures the acceleration of the bus. But if a giant picks up the bus and tilts the nose of the bus towards the sky, the passengers will also feel pushed towards the back of the bus, due to gravity. There is no easy way to tell which is which. Unfortunately you also can't tell what speed the bus is moving at, since it feels the same to the passengers when it is moving at any constant speed as it does when it is stopped, you can only feel the accelerations or decelerations. The second vector could be some kind of compas. See if you can tell which direction is north. Or they could both be genuine direction vectors produced by complex algorithms inside the hardware, and you might not have any access to the accelerometer or compas data. Accelerometers would be useful, because then we could detect jumping and crouching at least, and possibly other gestures. We may even be able to detect walking on the spot, or genuine walking, which would be more intuitive than using a keyboard to walk around. |
| |
| | | Junior Member
Group: Forum Members
Last Login: 9/20/2008 8:39:52 PM
Posts: 10, Visits: 59 |
| Okay. I'll dig out the (really messy) code and post it here in a bit.
I haven't had a chance to work on it recently, though. |
| |
| | | Junior Member
Group: Forum Members
Last Login: 9/20/2008 8:39:52 PM
Posts: 10, Visits: 59 |
| http://cybersanitarium.com/tmp/vr920_driver1.tar.gz
Here's the driver. Like I've said before, the code is pretty messy.
The driver was first generated by running this script: http://lindi.iki.fi/lindi/usb/usbsnoop2libusb.pl on a usbsnoop ( http://benoit.papillault.free.fr/usbsnoop/ ) log. Then modified from there.
It includes a test program that uses SDL and OpenGL to render an object at what it thinks is the alignment of the VR920. Pressing 'z' in the test app will set the zero for the headset.
There is no form of proper calibration right now, except some code that is commented out in a large block because it didn't work and is probably the wrong approach anyway.
I still haven't received a copy of the SDK, so I'm kind of shooting in the dark still. But here goes anyway. |
| |
| | | Supreme Being
Group: Moderated Users
Last Login: 12/4/2008 1:36:50 PM
Posts: 539, Visits: 1,120 |
| | The SDK simply provides values for yaw, pitch and roll as integers between -32768 and 32767, representing -180 and +180. The pitch values it returns go up to +/-90. It doesn't provide any raw information or how it generated those values. |
| |
| | | Junior Member
Group: Forum Members
Last Login: 9/20/2008 8:39:52 PM
Posts: 10, Visits: 59 |
| That's interesting. Then it looks like all that's left to do is somehow stabilize the values coming out of the thing.
Anyone have any ideas? |
| |
| | | 
Technical Support
Group: Administrators
Last Login: 1/5/2011 11:16:13 AM
Posts: 176, Visits: 468 |
| @Mal: I'm sorry you haven't gotten a copy of the SDK. Please send me an email, and I'll get that taken care of immediately.
~~~~~~~~~~~~~~~~~~~~~~~
If it ain't broke, break it. Then you can fix it.
~~~~~~~~~~~~~~~~~~~~~~~
Todd R. Ferguson
Technical Support
Vuzix Corporation
585.359.5909
todd_ferguson@vuzix.com |
| |
| | | Junior Member
Group: Forum Members
Last Login: 9/20/2008 8:39:52 PM
Posts: 10, Visits: 59 |
| I've got the SDK and I think I've come up with a suitable calibration method. My only problems right now start to show up when the headset is turned around 180 degrees. The software will think it's at an angle that's not exactly opposite of when it's pointing the other direction. However given that I think I've solved the problem of it jumping around all over the place, and it will actually smoothly rotate around (though not 100% accurately) I might just have to say that this is "good enough".
Basically, this is what I've done:
There is commented out code in the source that I posted dealing with v1min, v1max, v2min, v2max, and so on. This was on the right track but the VR920's output sometimes jumps or spikes if it's moved too suddenly. This will totally throw off the calculation of the min/max values by making it think there's a maximum or minimum way beyond what there should be. The solution to this is to somehow compensate for these, which seem to happen all the time (even slighty shaky hands seem to cause it). So I can either entirely ignore values that seem to have jumped too fast, or I can slowly increment/decrement the min/max up to them during the calibration.
I opted for the simple route in my code and changed this...
if(v1.x > v1max.x) v1max.x = v1.x; into this:
if(v1.x > v1max.x) v1max.x += (v1.x - v1max.x) / 4.0; (repeating for all the min/max parts of that code)
The 4.0 is an arbitrary number I picked. Higher numbers mean more stability, but longer time to calibrate. Lower numbers will have more problems with sudden spikes throwing everything off, of course.
If anyone thinks this is a horrible hack and I should die in a fire for it, please speak up. Especially if you think you have a better way. ;]
Is anyone having any issues with the code I posted? Does it compile and run okay?
|
| |
|
|