Kinect LabView Drivers

[jhersh]

Originally Posted by ygd

You could theoretically program the FPGA on the cRIO to act as a USB host, and from there, you could control the Kinect. I haven't actually tried it, but it seams feasable.

The FPGA could theoretically implement the host controller features, but you would still need a USB phy (physical layer interface) to host the USB electrically. Also, the host controller is terribly complex and not really a reasonable engineering approach. You would be far better off using a device that already has a USB host controller (such as the cRIO 9022 mentioned earler, a laptop, a TI Beagle Board, or even a Luminary (now TI) Stellaris part with USB OTG support).

[Ryan Gordon]

I've got the LabView drivers fully working but still not completely stable yet. The dlls that run behind the scenes still need a lot of polishing but this is a great start so far. The next big challenge will be to find a reliable/easy way to get the Kinect to run through the cRIO as we wait for the dlls to stabilize.

I'll hopefully have the development source code up in my github repository within the next weeks.

Cheers,
Ryan

[Gdeaver]

Aside from getting the data into the c-rio, there is the raw computational power of doing anything useful with the data. Wouldn't a better strategy be getting the data back to the driver station lap top and do the processing there?
A 400 mhz power pc vs. a dual core x86? The c-rio could be by passed completely. A usb host controller interfaces to the kinect and then sends it by lan to the gaming router back to the laptop. First would have to change the
ruling on no lasers. I believe the Kinect has a true infrared laser. The kinect could have tremendous affect on our robots in the future. You may want to keep an eye on Microsoft's robotic studio. Word has it they may be releasing some drivers.

[Ryan Gordon]

Originally Posted by Gdeaver

Aside from getting the data into the c-rio, there is the raw computational power of doing anything useful with the data. Wouldn't a better strategy be getting the data back to the driver station lap top and do the processing there?
A 400 mhz power pc vs. a dual core x86? The c-rio could be by passed completely. A usb host controller interfaces to the kinect and then sends it by lan to the gaming router back to the laptop. First would have to change the
ruling on no lasers. I believe the Kinect has a true infrared laser. The kinect could have tremendous affect on our robots in the future. You may want to keep an eye on Microsoft's robotic studio. Word has it they may be releasing some drivers.

This wasn't ever meant to be used during competition in FIRST The laser is a Level 1 Class laser but it's perfectly safe as there is a million safety features that PrimeSense and Microsoft built in to make sure it stays safe.

But the showstopper here is that there is too much interference with multiple Kinect's moving around. I'm just building this so I can make a robot do things by itself autonomously; The idea of true autonomy is very poorly implemented in FIRST, mainly because the complexity and lack of technology to make it more plausible. I quite think this would help others interested in exploring truly autonomous robots. Every year that passes by goes more decommissioned pieces of metal that never get put into competition again and I quite think this would make for some interesting projects with those old robots. That is certainly what I'd like to do off-season with them.

[Brandon_L]

I am EXTREMELY interested in this. Do you plan on releasing it when its done?

[SuperS_5]

Hi, this has grabbed my interest. I believe that LabVIEW does support isochronous connections. Although I could only find documentation on Firewire and isochronous data transfer, I have successfully used every USB webcam that I have tried with LabVIEW. The IMAQ USB drivers have to be installed. They are available to download from NI, but, I am unsure of any licensing. (I think only the NI Vision module has to be activated, not the drivers) If the device can be enumerated via USB devices, it should work via IMAQ USB capture.

[Ryan Gordon]

Originally Posted by SuperS_5

Hi, this has grabbed my interest. I believe that LabVIEW does support isochronous connections. Although I could only find documentation on Firewire and isochronous data transfer, I have successfully used every USB webcam that I have tried with LabVIEW. The IMAQ USB drivers have to be installed. They are available to download from NI, but, I am unsure of any licensing. (I think only the NI Vision module has to be activated, not the drivers) If the device can be enumerated via USB devices, it should work via IMAQ USB capture.

At this point, I've switched to using the OpenKinect project as a dll (based on cross-platform libusb). Much easier to work with their framework rather then reinvent the wheel I previously tried using the VISA interface for USB capture which doesn't support isochronous transfers.

Originally Posted by Brandon_L

I am EXTREMELY interested in this. Do you plan on releasing it when its done?

I certainly am; I should have source code up in my github fork within the next few days.

[SuperS_5]

The only reason why using LabVIEW for the image acquisition is that IMAQ uses the Vision module. It is all reference based, and very well designed. It is fast, and has a ton of primitives for image manipulation/measurement. For automation, this would surely make life easier. The first time I used the Vision, I built a flag follower module that ran on the cRIO in about 2 hours. I suppose that the image could be sent to the Vision module, but there may be performance issues that would have to be worked out. I would be more then happy to help out with the LabVIEW side.

[Ryan Gordon]

I'll do some timing to see what kind of performance we get out of this; Converting to something that IMAQ can handle isn't too hard.

I'd surely like anyone's help (who wants to) to improve this

[SuperS_5]

If you have any modified code from the last time you posted, please re-post or we setup some kind of code repository. Also, which version of LabVIEW do you use? I don't want to up-save, and cause troubles when you try to open the code.

[SuperS_5]

I have setup a Google code repository account/project. This can be changed, I just wanted to try out their repository anyways.

https://code.google.com/p/kinect-labview-api

I have not seriously used their repository before, so I am still learning how to configure it.

[Ryan Gordon]

I already have it up on a github account since the OpenKinect project is located there and forking/syncing is easy.

https://github.com/RyanGordon/libfreenect/ -> Unstable branch -> wrappers/labview/

I'm using LabVIEW 8.6

[TriRulz]

This is the XboX 360 kinect or am i thinking wrong?

[davidthefat]

Originally Posted by TriRulz

This is the XboX 360 kinect or am i thinking wrong?

Yes it is the 360 Kinect

[jcabrer]

Hello all.

LabVIEW VISA USB does not support isosynchronous communications. This is stated in documentation describing how to install a RAW USB driver for low-level USB device communication.

The easiest way to use the kinect with LabVIEW is to have it be recognized as a USB camera, and acquire the image data via IMAQdx. I've manged to get this working in the last couple of days, and will be posting a tutorial video on how to get there, as it's a bit involved, especially if you've been playing with all of the other kinect drivers out there from CL, OpenKinect, and PrimeSense.

Of course this limits you to using a PC running Windows OSes, so not really applicable to cRIO integration.