Vuzix Forums / VR920 / Tracking / Linux driver progress / Latest Posts

RE: Linux driver progress

CharliJones — Thu, 17 Nov 2011 04:51:36 GMT

Which version of Linux driver is best for using any OS.And give me information about latest version of Linux drivers?

RE: Linux driver progress

Diversant — Mon, 29 Aug 2011 05:28:44 GMT

So, anyway, is there any progress with Linux realization for VR920?
Is there any way of using Win drivers or Vuzix native applications through WINE itself? Or is it technically impossible?

RE: Linux driver progress

mickeyjaw — Sat, 12 Sep 2009 07:38:39 GMT

[quote][b]Mal (10/2/2007)[/b][hr] I think, but to work with other things you'd need to use an LD_PRELOAD library that overrides stuff in libGL.so to mess with the perspective. Something like that VRizer library did to get anaglyph 3D stereo out of most Linux games. Sadly that library is closed source and not updated anymore, so I don't have anything to go off of except for an idea of how it must be done.

It needs more work, without a doubt, but in the meantime, I'm going to go play GLTron in 3D. :][/quote]

Although Vrizer is closed source, it is quite flexible - read the README and you will find that is possible to configure it to output above/below and side/side and even generate a 3 walled cave for passive/active projection. I have been using it with e-dimensional shutterglasses in sync doubling mode and above/below for some time now. If you want any help configuring it or to maybe help me with my project for a configurator tool, check out my threads on MTBS3D:

[url]http://www.mtbs3d.com/phpBB/viewtopic.php?f=3&t=4316[/url] and [url]http://www.mtbs3d.com/phpBB/viewtopic.php?f=3&t=2939&start=0&hilit=linux[/url]

If you search google you can find a hack to disable the watermark/logo too

Maybe with enough harassment/praise as appropriate the author might release the source?

There is also VRGL, which is part of caveUT. It does opengl frustum manipulations and is open source. It was designed for unreal tournament in a cave. Check out publicvr.org and planetjeff.net.
The only problem with VRGL is that is designed for you to run 2 or more instances of the game with each instance generating a separate view. That is fine if you only want to run games which support spectators in network mode. In fact, you can do dual output stereo with games which support network play with spectators and like this:

2 instances of game 1 fullscreen on each output
network game
1 player 1 spectator
write external script to capture position/orientation of player from packet capture & send offset tracking data/movement commands to the spectator.

No messing with opengl required!!
(not that i have actually tested it this way, but it appears to be the essence of how caveUT works)

RE: Linux driver progress

Snack — Thu, 25 Dec 2008 14:47:08 GMT

[quote][b]Codefire (9/4/2008)[/b][hr]I'm sorry if I missed the thread but you're talking mostly about getting the head tracker to work with Linux. I'm curious about getting the displays to work with Linux, tech support says there are no drivers for the displays in Linux. Has anyone come up with some?

Thanks in advance[/quote]

I've been using a VR920 in stereo on linux for about 6 months. I use a Quadro 560. Stereo only works for quad buffer apps. There's no magic stereo conversion driver like on Windows. On the plus side, you can run stereo apps in a window.

I mainly play ioquake3 (cleaned up Quake3 engine) and Darkplaces (greatly enhanced Quake engine) based games and mods in stereo. These engines give you fine control over stereo seperation and z projection. I like this because you can really enhance the 3d effect or even give yourself a headache if you're so inclined. ;) You'll need to use the console though.

Geforces and Radeons unfortunately don't support stereo in linux. Firegl cards do but I don't think they support stereo ddc output.

If you want to do this, be sure to get a Geforce 7 based Quadro or earlier (ie Quadro 560, 1500, 3500) as they are the last generation to support stereo ddc output. Quadros aren't meant for gaming but mine works well enough for my purposes.

Adjusting settings like the backlight with the VR920's built in thumbwheel will lockup the VR920 after two adjustments. You can bring it back to life by unplugging and reinserting the VR920's USB cable. This is with the latest firmware and does not happen under Windows.

I'd love to have even rudimentary headtracking. Let me know if there's something I can do the help.

RE: Linux driver progress

MWorks — Sat, 20 Dec 2008 06:20:39 GMT

First of all sorry about my english. So, Mal, how's it going? I would like to help you with the driver, in my free time XD. I'm about to have a VR920 so after that I'm ready.

Maybe you can give me the latest version of your driver, that would be a good beginning. Im working with ubuntu linux, by the way.

P.S. I've just created a new post but I just wanted to post a comment here.

RE: Linux driver progress

Victor Tramp — Sat, 29 Nov 2008 23:15:57 GMT

bump..

RE: Linux driver progress

CaptainS — Sun, 21 Sep 2008 15:45:17 GMT

ok hope u keep on :)

RE: Linux driver progress

Mal — Sat, 20 Sep 2008 20:41:05 GMT

I had to send my VR920 back because the firmware was un-upgradable. I just got it back today and I'll probably start tinkering with it again soon. There hasn't actually been much progress to speak of otherwise (on my front, anyway).

RE: Linux driver progress

CaptainS — Fri, 19 Sep 2008 15:45:35 GMT

hmm... any progress?

RE: Linux driver progress

Codefire — Thu, 04 Sep 2008 09:09:25 GMT

I'm sorry if I missed the thread but you're talking mostly about getting the head tracker to work with Linux. I'm curious about getting the displays to work with Linux, tech support says there are no drivers for the displays in Linux. Has anyone come up with some?

Thanks in advance

RE: Linux driver progress

Mal — Sat, 30 Aug 2008 09:16:09 GMT

[quote][b]TheMaker (8/29/2008)[/b][hr]Could the tracking be remapped to, say, the mouse?
And how much processing power does it take to track?
I'm building a wearable computer and I want to use thisas its primary display, and it runs pretty slow.[/quote]

Hi. I haven't been working on the driver for quite a while, and I apparently have to contact the company to even update my firmware because it's so old now, so my driver is probably too old to run with the latest version of the headset.

By remapping it to a mouse, do you mean just like a simulated mouse in X11? I'm pretty sure that could be done. I don't know about actually creating a fake mouse device, though.

RE: Linux driver progress

Gargoyle — Fri, 29 Aug 2008 22:43:14 GMT

Could the tracking be remapped to, say, the mouse?
And how much processing power does it take to track?
I'm building a wearable computer and I want to use thisas its primary display, and it runs pretty slow.

RE: Linux driver progress

wuhlei — Wed, 21 Nov 2007 21:44:35 GMT

does stereo for vr920 work in linux?

RE: Linux driver progress

Mal — Tue, 02 Oct 2007 20:47:30 GMT

That's odd. I don't think I've encountered that. But I guess I stopped looking at the raw numbers a while ago.

In other news: I got stereo 3D working. That was much easier. XD

And by that I mean that my driver just sends left eye/right eye commands like the real SDK does. That also means that it doesn't work in any game that's not designed to use it. It's pretty easy to add the feature into a lot of open source 3D games, I think, but to work with other things you'd need to use an LD_PRELOAD library that overrides stuff in libGL.so to mess with the perspective. Something like that VRizer library did to get anaglyph 3D stereo out of most Linux games. Sadly that library is closed source and not updated anymore, so I don't have anything to go off of except for an idea of how it must be done.

It needs more work, without a doubt, but in the meantime, I'm going to go play GLTron in 3D. :]

RE: Linux driver progress

CarlKenner — Sun, 30 Sep 2007 03:01:38 GMT

Today reports are ending with 0x3B.

RE: Linux driver progress

CarlKenner — Fri, 28 Sep 2007 04:53:39 GMT

When the unknown byte after the report number is 3 instead of 2, the start of the report contains different information. It looks like this:

02 03 00 01 02 01 01 01

Note that it ends halfway through the forwards acceleration. Everything starting from the second half of the forwards acceleration is a normal, valid report, except that if there are a few reports in a row with unknown=3 (like there normally is) then the last part doesn't change.

The other day I said that the reports always ended with 0x33. Today they are ending with 0x37. I don't know why.

RE: Linux driver progress

CarlKenner — Thu, 27 Sep 2007 13:34:11 GMT

I've dealt with three accelerometer HID devices. The Wiimote, Nunchuk, and the Sixaxis.

The VR920 was the easiest though.

RE: Linux driver progress

Mal — Thu, 27 Sep 2007 12:04:28 GMT

Awesome. That certainly clears up a lot of mysteries for me.

I've never dealt with accelerometers or HID devices at all, so that's a big help. Thanks!

RE: Linux driver progress

CarlKenner — Thu, 27 Sep 2007 08:52:51 GMT

The VR920 is a HID device. Once you open a handle to it, it continuously sends input report number 2. Input report 2 looks like this:

Report number: byte = 2

Unknown: byte = 2 (normally), or 3 (possibly due to using the SDK at the same time, it returns a couple of reports with unknown 2, then several with unknown 3. While the unknown is 3 the vectors seem frozen)

zero: byte = 0 (Don't know the purpose of this)

HorizontalAccelerometer: 2 byte signed little-endian, positive means accelerating left

VerticalAccelerometer: 2 byte signed little-endian, positive means accelerating up

ForwardsAccelerometer: 2 byte signed little-endian, positive means accelerating forwards

HorizontalCompas: 2 byte signed little-endian

VerticalCompas: 2 byte signed little-endian

ForwardsCompas: 2 byte signed little-endian, this seems to be permanently large, possibly due to the earphones

Unknown2: byte = 33H (0x33)

Surprisingly, both the accelerometer and the compas detect accelerations. The accelerometers also detect gravity. Seperating out the gravity from the accelerations is difficult.

The accelerometers values corresponding to -1G and +1G are about -400 to +400. But there is a huge amount of variation between individual glasses, so they require calibration.

The accelerometers max out at a bit more than 2Gs.

I haven't played with the compas values yet, since I'm more familiar with accelerometers.

RE: Linux driver progress

Mal — Fri, 21 Sep 2007 04:29:27 GMT

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?

RE: Linux driver progress

TechSupport — Wed, 19 Sep 2007 17:51:21 GMT

@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.

RE: Linux driver progress

Mal — Sat, 15 Sep 2007 20:34:10 GMT

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?

RE: Linux driver progress

CarlKenner — Sat, 15 Sep 2007 03:16:32 GMT

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.

RE: Linux driver progress

Mal — Fri, 14 Sep 2007 22:30:16 GMT

[url]http://cybersanitarium.com/tmp/vr920_driver1.tar.gz[/url]

Here's the driver. Like I've said before, the code is pretty messy.

The driver was first generated by running this script: [url]http://lindi.iki.fi/lindi/usb/usbsnoop2libusb.pl[/url] on a usbsnoop ( [url]http://benoit.papillault.free.fr/usbsnoop/[/url] ) 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.

RE: Linux driver progress

Mal — Fri, 14 Sep 2007 21:04:01 GMT

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.

RE: Linux driver progress

CarlKenner — Fri, 14 Sep 2007 13:14:34 GMT

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.

RE: Linux driver progress

bendotron5000 — Fri, 14 Sep 2007 12:26:10 GMT

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.

RE: Linux driver progress

bouslim — Thu, 09 Aug 2007 12:18:51 GMT

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 ;)

Linux driver progress

Mal — Tue, 31 Jul 2007 23:43:38 GMT

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.
[url]http://cybersanitarium.com/tmp/vr920_Linux_1.jpg[/url]

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. :D