RGB-D camera topic /head_xtion/depth/points slowing over time

[gestom]

The /head_xtion/depth/points gets slower and slower over time leading eventually to a halt - typically in a matter of days. Restarting the openni-related nodes does not seem to solve the problem.

[RaresAmbrus]

Are you using the 600 or the 601 for this ?

[cdondrup]

The 600 version.

[RaresAmbrus]

I'm working on a ros wrapper around the openni 2.2 drivers (I think the ones currently in ROS are much older), I just have to convert it to a nodelet so that it's more efficient and I'll add it; maybe this will solve the issue.

[RaresAmbrus]

@gestom
I've implemented a ros wrapper for the latest version of the openni drivers (v2.2) in the form of a nodelet, and I've tested it for about 24h (subscribed to the depth image, rgb image and colored point cloud) and I haven't witnessed a drop in framerate. This implementation is currently in my fork of the scitos_robot repo (https://github.com/RaresAmbrus/scitos_robot.git), and it's integrated in scitos_bringup, so you would run it the same way as before (i.e. roslaunch scitos_bringup scitos.launch). It would be great if you could give it a try and see if you still get the framerate slowing down issue.

[gestom]

Thanks. I will try it and get back with the results.
So far, we have "solved" the problem by restarting the openni stuff every time Linda is charging, but your solution seems to be much better. What framerate do you get on /head_xtion/depth/points ?

[RaresAmbrus]

That depends. I am checking this using rostopic hz on the console, and the rate depends on what other topics I am subscribed to.

Currently I am running the patroller with all the processes and I am subscribed only to the depth image in rviz and I get about 29-30Hz. However, if I subscribe to the colored point cloud in rviz (depth_registered/points) then the framerate drops to about 15-18Hz. I'll let it run for the rest of the day and check that the framerate stays the same.

[gestom]

@RaresAmbrus Hi Rares, your version of the driver has been running for three days now and did not get stuck, nor slower. Consider to open a pull request.

[RaresAmbrus]

@gestom: Great! I'm currently out of town but I'll try to do it in the next couple of days. Also, this version of the driver seemed to work on the 601 as well for me - maybe you could give it a shot and see if you get good results?

[marc-hanheide]

If that turns out to be true, you'll officially be our hero of the month if not year!

[RaresAmbrus]

@gestom Hi Tom, thanks for trying this out. We've been using over here as well and it seems stable enough so I think I'll merge it to the trunk. One question though: I am using a 3rd party dependency (openni 2.2) which I've directly added in a "3rd_party" folder in the package - is that the way to proceed or do we want to keep 3rd party software in a different package / repository altogether ?

[gestom]

@RaresAmbrus : I am not sure about what would be considered the best practice in this case. Maybe @marc-hanheide would know.

[marc-hanheide]

Hi,

we don't have a proper management of 3rd party dependencies at the moment. But we have a similar case in strands_webtools. IMO, the preferred solution is not to include binaries (not everybody uses the same Ubuntu, some even use a Mac, like @hawesie), but to include the OpenNI source code as a git submodule (see http://git-scm.com/book/en/Git-Tools-Submodules) to point to the tag 2.2 of openni, i.e. https://github.com/OpenNI/OpenNI2/tree/2.2-beta. Then you can add a custom build target in the CMake to first build OpenNI as part of this repository. Any other opinions?

Marc

[RaresAmbrus]

Hi,
Thanks for the info - keeping sources would be preferable, I agree, and in fact in the past I've used SVN in a similar fashion (via externals pointing to other repos). I'll take a look at git submodules and see if I can get it to work in the current setup.
However, sometimes it's good to keep track of binaries as well, as we're not sure what will happen to external repositories, they might get modified, deleted, etc. - that might not be the case here though, as the openni sources are hosted on github and specifically marked as a tag, but just as a thought, in general.