OpenKinect Project: State of Support, 2010-11-12

[Kyle Machulis]

qDot here, your friendly repo integrator and code janitor, with an update on the OpenKinect project platform support (and hereby refering to myself in third person for the rest of the email so things don't sound quite so personal around me):

---

WE HAVE A MAIN REPO

Just in case you didn't see JoshB's email last night, it's at

https://github.com/OpenKinect/openkinect

---

WINDOWS IS ALIVE (sorta) - win32-iso BRANCH ON MAIN REPO...

Thanks to work over the past 24 hours by quite a few people on the #openkinect IRC channel, the windows driver is now up and running. ofTheo, being some combination of magic and awesome that forms into a voltron of driver fixing kickass, found a message board post the evening that made the packet/transfer situation make more sense, and implemented it on top of the win32 branch from Majority and qDot with API changes. So, on the main repo, I've killed the win32 branch, and made a win32-iso branch consisting of (in branch merge order, oldest to newest):

- qDot's win32 testing start from last night (OpenKinect repo, win32 branch)

- Majority's push request with api changes (Partial fulfillment of pull request https://github.com/OpenKinect/openkinect/pull/1 - Just didn't bring in the binaries because git hates binaries)

- ofTheo's changes (Sent via zip file to qDot)

- qDot's integration work on top of this, which includes

-- C89izing of ofTheo's code so it'll build in VS (was developed under mingw)

-- function renaming (changed CamelCase to underscore_seperated, to follow Hector's original calls and what you usually see in C projects like this, code style is totally up for debate of course, just makes life easier on me as integrator right now)

-- Split cameras.c into cameras-libusb.c (marcan's original with some functions) and cameras-win32.c (ofTheo's final version), some function shuffling in both 

-- Commented out Majority's led/motor functions until we get them working on OS X and linux (they'll get uncommented once we fix that, should be super quick tomorrow)

-- Widened the PTHREAD_AND_GLUT define to make sure that if it's not defined, all we get is a command line program that will do transfers. Tested on windows and OS X.

Right now, building for windows still requires you to hand construct a project. ofTheo's work was based in a CodeBlocks (mingw) based project, and qDot updated it for VS, so both should work now. Hopefully tomorrow we'll bring the CMake pull request in and add the windows stuff to it, possibly getting us a completely platform unified project.

---

OS X IS MORE ALIVE THAN IT WAS...

qDot did some number futzing earlier this evening and found that upping the packet/transfer numbers on the OS X side made for more reliable transfers. Also, for some reason the driver receives 2 0x75/0x85 image end messages on OS X, causing it to render before frame completion. This was fixed and merged into the master of the main repo, has been confirmed by Kyle McDonald and Felix.

---

Linux was always alive. Not much to say there, except yay Linux. Could use some sanity testing after all of this OS X and windows work though. 

---

I think the main thing to remember in all of this is that what we're doing right now with libfreenect extensions and glview is TEMPORARY. People are going to come along and do platform drivers, those will be the end all be all. IMO the main task right now is to give them the best proof of concept and feature testing framework we can so they can concentrate on the nastiness that is the platform specific driver SDKs. So don't stress too much on API or what not here, 'cause it's not gonna last. :)

--- 

So, some random possible next steps:

- We needs LOTS of windows testing

- C# bindings would be awesome too

- Since motors, LEDs, and cameras are decently nailed down, we need to document those protocols fully and get started on audio just to fill out the end.

- Understanding more of what the hell init does would be nice, we're still straight up replaying things blindly. Even knowing what turns on the IR projector would be great so we could turn it back off.

- More Cmake scrubbin's.

---

IF YOU HAVE ANYTHING TO ADD...

Obviously, mailing list is awesome. However, if you have specific bugs/tasks/features for this stage of the driver (i.e. we don't really want to start adding things like "skeletal tracking" here), add them to the git issues for the OpenKinect project at

https://github.com/OpenKinect/openkinect/issues

---

Bedtime for me, and good morning european OpenKinect team, interested to see what you have when I wake up. :)

qDot

[Kyle Machulis]

OH!

And I broke depth image rendering in the win32-iso branch at some point. If someone wants to fix that, that'd be swell. 

And making PTHREAD_AND_GLUT a cmake option would be nice too.

Ok, now bedtime.