This post was updated on .
Here is a quick tutorial on how to successfully run an OpenNI/PCL example using a Carmine 1.09 with a fresh Ubuntu 12.04 x64 installed.
Install PCLFollow Ubuntu instructions at PCL download page
Clean previous OpenNI & install dependenciesFollow points 2 and 4 of this wiki.
Install OpenNI & Sensor from PrimeSense gitMake sure this directory exits :
sudo mkdir -p /usr/local/bin
Follow "Install from PrimeSense git repos" on this wiki.
Go step by step and check if everything is fine.
Try to run an exampleGo to this directory and run the example (it takes 2/3 secondes before you get data) :
cd ~/primesense/OpenNI/Platform/Linux/Bin/x64-Release && ./Sample-NiSimpleRead
Reading config from: '../../../../Data/SamplesConfig.xml'
Frame 1 Middle point is: 0. FPS: 0.000000
Frame 75 Middle point is: 0. FPS: 0.000000
Frame 76 Middle point is: 0. FPS: 30.562925
Frame 77 Middle point is: 0. FPS: 30.554913
If you get an error, go to the next section
USB related error messagesIf you get an error like this one :
Open failed: Failed to set USB interface!
Find your GlobalDefaults.ini file :
sudo find / -iname GlobalDefaults.ini
Edit the right one (should be in usr directory) :
sudo gedit /usr/local/etc/openni/GlobalDefaults.ini
Find the following line and uncomment it :
Sometimes changing the USB port fixes the problem
Try te re-run the OpenNI example.
If the example get stuck when you launch itIf your app doesn't work or you get something like :
Reason: Got a timeout while waiting for a network command to complete!
The XnSensorServer is probably still running. Close all your examples and kill the process :
ps -ef | grep Xn
root 3948 1 0 10:57 ? 00:00:00 [XnSensorServer]
dell 3955 3828 0 10:57 pts/3 00:00:00 grep --color=auto Xn
sudo kill 3949 && ps -ef | grep Xn
dell 4176 3828 0 10:59 pts/3 00:00:00 grep --color=auto Xn
Sometimes changing the USB port also fixes the problem. Try te re-run the OpenNI example.
Running a PCL exampleThis example from the PCL tutorials works fine but it doesn't show the RGB stream. Don't forget to zoom out when you start the app (or press multiple times 'r').
This openni_grabber_v2.tar.gz works fine with RGB stream. Build it :
cd openni_grabber_v2/build/ && cmake ../src && make
Then launch it
Don't forget to zoom out (or press 'r' multiple times).
Of course, don't expect perfect interface, some times you might need to change usb port or something similar (not very often according to my experience), but considering the hacky nature of the solution, it works pretty good, especially for offline capturing and processing. I've been working with this solution for the past few weeks (sorry for not posting earlier) with no worth-mentioning problems.
That means that the hacky solution gives a quite good interface with the carmine, allowing capturing bot RGB and Depth at ~30fps (didn't try to see if I can get higher fps).
a few weeks ago I posted this hacky solution to interface with the Carmine 1.09
and I reported these FPS numbers
These numbers were reported while doing capturing+displaying at the same time!
(there is a correlation between the resolution and the fps number, they are inversely proportional)
I found out that totally kicking out the display gives ~30 fps for both cameras.
On Tue, Jan 21, 2014 at 11:24 AM, VictorL <[hidden email]> wrote:
Here is a quick tutorial on how to successfully run an OpenNI/PCL example
[hidden email] / http://pointclouds.org
Glad you got it working. Yes when we say "30 fps" we also mean saving to disk at that rate. Visualization is often slower.
We also found that the compression for saved data can matter a lot and can limit framerate due to CPU or disk bandwith. Also if you want to not drop frames periodically ("hiccups") over longer term (more than ~30s) then a buffering strategy seems needed.
Our analysis of the various tools for saving OpenNI data is here:
The bottom line is that of the various options, if you want to stick with something in standard PCL or openni then the one to go with is pcl_openni_image. It saves in pclzf format which doesn't take too much cpu or disk bandwidth, and it implements a circular buffer to avoid hiccups.
We also recently released our imucam code
which has a utility for saving to pclzf+xml compatible with pcl_openni_image but with more options. Also we found that (at least in the version we were testing a few months ago) pcl_openni_image could have some lag in visualization because it uses a separate buffer for that and aims not to drop frames. Our imucam code buffers frames to disk but drops frames as needed for visualization.
So, actual storing is offline, while all acquired frames go only to the RAM memory ;)
and actually store them on the disk only at the end of the capturing procedure.
I kick out the display in order to increase the frame rate, but I first store the acquired frames only in RAM, to avoid the HDD bottleneck,
Hi Marty,I should have formulated this a bit more carefully.
That being said, if you achieve ~30 fps while concurrently storing on the disk, then probably you do something better.
Also, thanks for all the material that you put online, it's helpful not only for your lab and your students, but also for the rest of us :)
On Mon, Feb 10, 2014 at 5:26 PM, martyvona <[hidden email]> wrote:
[hidden email] / http://pointclouds.org
|Free forum by Nabble||Edit this page|