Help building on Ubuntu 13.04

[chriskilding]

Hi Ben,

In a similar vein to the previous issue #4 , I'm finding building fails at the line /usr/bin/ld: cannot find -lNiTE2 after following the wiki instructions on a vanilla install of Ubuntu 13.04 x64. The error trace is identical to the one in the other issue - the only difference is in what the linker couldn't find.

In my case, I have both OpenNI1 and OpenNI2 installed (plus dev headers) from apt for some other work I am doing with the Point Cloud Library. Those work fine in PCL applications, and judging by the fact that the linker didn't complain about the absence of -lOpenNI2, I guess it managed to pick it up from the system.

FWIW when I run the install.sh for NiTE2, precisely nothing useful seems to happen: it echoes 2 variables to the NiTEDevEnvironment file, and... that's it. No prompt for a license key or whatever.

Ideas?

[bengfarrell]

Man, I'm really hating these linking issues! So, you're running the exact same version of Ubuntu I am - so at least (hopefully) it's just a file placement problem.

It's also interesting that its NiTE2 that failed and not OpenNI. What does your file structure look like? Do you have the redistributable folders for OpenNI and NiTE in that same folder as the binding.gyp file? It says to do that in the Wiki, but if I wrote it up badly, I'd love to know so I can fix it.

Past that, like I said - it sounds like it can find OpenNI but not NiTE2. If I had to guess, I'd say that the binding.gyp file can't find either one, except that you have the OpenNI path already set up as an environmental variable in your other application, but not NiTE2.

And thats all the installer really does, is it just seems to set up the environmental variables. I tried to avoid the need for them the way I have the project set up as I thought it would complicated matters to need an install.

Anyway - if you have the OpenNI2 and NiTE2 redistributable files in your root next to your main node file and the binding gyp file, you should be fine. If you're not fine after you've made sure of this - you can go down the path I had to do when I was initially testing how to link.

Edit the binding.gyp file to try and adjust the relative pathing to something that works for you.

If you remove the (ONI_Root) var it should simply link to your "installed" version if you have it installed. "libraries": ["-l<(ONI_Root)OpenNI2", "-l<(ONI_Root)NiTE2", "-Wl,-rpath ./"]

Or you can tweak that: "ONI_Root%": "",

to something else. The empty space is the relative path. Perhaps try a "./".

The only other thing I can think of is that in 0.1.2, a contributor wanted to move the binding.gyp file from my src folder to the root of the project as it seemed the better practice. I've been able to build fine with it, so I accepted the commit. You can try rolling back to 0.1.1 to see if that resolves any bad pathing from moving the file.

Hopefully this is just a documentation misunderstanding - and it will be easy to word it better if you missed something. Let me know if you have any luck!

thanks

[chriskilding]

My folder structure looks like this:

project_dir
    -> [my node file]
    -> node_modules
        -> [various other node modules]
        -> nuimotion (cloned from Git)
            -> src
            -> quickstart etc.
            -> binding.gyp
            -> OpenNI2
            -> NiTE2

Is that the right way to lay it out?

Also:

• I couldn't run node-gyp rebuild from inside src/ as it was unable to find the binding.gyp file
• changing oni_root from "" to "./" made no difference

[bengfarrell]

Ahhh, so no, I'm building like this:

project_dir -> [my node file] -> OpenNI2 -> NiTE2 -> node_modules -> nuimotion

So it looks like you just need to pop the OpenNI/NiTE2 files at the actual project root. The reasons are 2-fold. One for compiling, and then when your project runs, it actually needs to link to the libs at runtime as well. So I figured that was the best place to put them, rather than stashing them all the way in the node module folder.

If that works, and anything could be better written to not have put your through that headache in the first place, please do let me know how I could improve the docs.

thanks!

[chriskilding]

The formatting on your project structure is a little unclear (no indentation), so did you mean

project_dir
    -> [my node file]
    -> OpenNI2
    -> NiTE2
    -> node_modules
        -> nuimotion (subfolder of node_modules)

or that nuimotion should be in the project root as well? (In which case what becomes of the nuimotion NPM module?)

[bengfarrell]

Man you're right - it lost all the formatting. NuiMotion is a normal NPM module. It belongs in the node_modules folder, just like any other NPM module. The difference here is that OpenNI2 and NiTE2 do NOT belong in the node_modules->nuimotion folder. They belong right beside your [my node file] in the root of your Node.js project.

You've laid things out correctly in the above comment. Hope that works. If you do a fresh NPM install, it should put everything where it needs to be correctly, with the only caveat that you have to manually place the OpenNI2 and NiTE2 folders in your root.

[bengfarrell]

Also please be sure that these are the redistributable files that come with OpenNI/NiTE. They ship a lot of samples and whatnot in their install package. You'll want to make certain you see the *.so files.

I've laid out the folder structure on my install page if you missed it: https://github.com/bengfarrell/nuimotion/wiki/Installation

[chriskilding]

Ok, just rearranged my project to lay things out correctly and reran npm install. Alas, no luck - it still fails to find -lNiTE2.

[bengfarrell]

Well OK - I may have been under the false impression that this was doing something else with linking. I just checked my /usr/lib folder and I see a libNiTE2.so file as well as a libOpenNI2.so file.

Try stealing the libNiTE2.so file from your NiTE-2.0->Redist folder and drop it into your /usr/lib folder. That's the only shared library I see - so I don't think there needs to be any other files except at runtime.

If that works, let me know - I'll need to update my docs when I get a chance.

[chriskilding]

Putting libNiTE2.so in with the system libs allowed the C++ component to build - success!

Two minor things I noticed:

• once NITE was in the system libs, I found neither the OpenNI nor NITE folders need to be in the node project any more - at least it compiled and started up okay without them
• it both compiles and runs if you put NITE in /usr/lib, but only compiles (crashes on running) if you put NITE in /usr/local/lib, so it would be useful to record that distinction in the docs.

Thanks!

[bengfarrell]

No thank YOU! Sorry it was a bit painful - I'm glad we uncovered this though. I was under the impression that it was linking at runtime to files in your project root. I'll have to do a lot more experimentation to uncover what's going on here, and I'll update the docs soon.

thanks again!

[chriskilding]

So my optimism was somewhat premature... though it compiles and the node server starts, once it hits nuimotion.init() it complains that it couldn't create the user tracker and progresses no further. (This may or may not be a different bug though - feel free to re-file it if it is.)

As before, the Kinect is plugged in, light's on, and my PCL applications (which access it through OpenNI) are running fine.

[bengfarrell]

Oh no! You are actually using the MS Kinect on Ubuntu? Im afraid that might be somewhat of a showstopper.

Sadly, OpenNI discontinued support for the Kinect on any platform besides Windows starting with version 2.0. The idea was that MS has proprietary drivers and if OpenNI adapted/included them in the project, it was legally questionable (at least thats how i understand things)

For your other application, i wonder if you are using OpenNI 1.x over there. Ive tried that out and verified that it works with my Kinect.

I have heard of a project called OpenKinect, and supposedly that may have some driver support to interface between the Kinect and Ubuntu.

Past that, i would say you have 2 options:

First, buy a Asus Xtion or a Primesense Carmine. I have the Asus Xtion Pro Live, its fantastic. Its smaller and USB powered however no motorized head like on the Kinect.

Secondly, you can just use OpenNI 1.x. Look up pgte on github, he has a Node.js interface for the older version of OpenNI.

Hope that helps, good luck!

[chriskilding]

I believe that the xbox kinect is supported by the unofficial libfreenect driver on non-windows platforms, so I don't think that can be the problem.

I also used the Xbox kinect on a mac in a previous web app that was built with the zigfu browser plugin, which uses openni and nite for skeleton tracking internally, so i am even less convinced this could be the cause.

If we ignore the fact that it is a kinect for now, is there anything you can think of which would cause nite to produce this error from a generic openni device?

[bengfarrell]

So I just checked out ZigFu, and I can see history on it dating back to 2011 which is before OpenNI 2.0 was released - which makes me guess that it uses OpenNI 1.x.

Also I found this on Github: https://github.com/piedar/OpenNI2-FreenectDriver - it looks like someone has created a binding for OpenNI2 and Freenect, as they are otherwise competing projects (or so I read).

If we ignore the fact that you are using a Kinect on OpenNI 2, I would almost say to make sure that you have the redistributable files in the root as we discussed before. However, given that it gets so far as to create instances of NiTE before failing on creating the user tracker, I'd guess that you have everything in the right place.

Really this just seems like an interface/driver issue. Are you able to run any of the OpenNI2 samples they have in their install package? That would be key in identifying if the issue is using the Kinect vs using my Node.js addon

[chriskilding]

When I ran the Nite2 samples, and also when I ran the OpenNI2 samples, I get a weirder error: 'Failed to open device: DeviceOpen using default: no devices found'. (To be clear, I get this same error in both oni2 and nite2 samples.)

When I start the node server, I guess Nite2 is able to load because it can find libopenni2, which was installed through APT. (If that wasn't there, it would have crashed earlier at the 'Nite initialization failed' stage.) But the fact that it then crashes when it tries to connect a usertracker to the ONI device, coupled with the fact that the ONI2 samples don't work suggest that, as you say, the ONI2 / Nite2 stack on my machine has never worked - and my PCL stuff must indeed be using OpenNI1.

Oh well, I'm off to find me an updated SensorKinect (or an older Nite)... thanks for the help though!