What are differences to ros-drivers/openni2_camera?

[cdondrup]

@RaresAmbrus, if I'm not mistaken you implemented this wrapper before there was official ROS support for openni2. For a while now already there is the openni2_camera package. So my question is: Where are the differences between these two? Is there some STRANDS specific things in here? Could we just use the openni2_camera package instead?

That would spare you some work and we wouldn't have to rely on our package for the camera drivers but could let everybody use the official one.

[RaresAmbrus]

@cdondrup yes, I made the wrapper before openni2 was officially a part of ROS. We had some STRANDS specific things in there for running 2 cameras at the same time, but that's no longer needed now. I also noticed a while ago that there was an official openni2_camera package, but haven't really tried it out, so I don't know if/how well it works.

The biggest downside is that I've integrated CLAMS (http://alexteichman.com/octo/clams/) in my fork of the openni_wrapper, and I've been testing it for a while before merging it to the master; this is definitely not available in the ROS openni2_camera. In my fork, the CLAMS correction is applied on the openni image before it's published (with the option of disabling it), but I guess I could change it so that CLAMS acts as a node between the openni2_camera and the rest of the ROS image processing pipeline.

But you're right, using the ROS openni2_camera package would definitely spare me some headaches, so I'm all for it, if it performs well and we don't get any USB-related issues.

[cdondrup]

That sounds reasonable. Do you have time to test this on your robot to see if and how it works? Linda is still not operational.

[RaresAmbrus]

Rosie is undergoing surgery at the moment - we're installing the 2nd PC and the new kinect. But I'll give the ROS openni2_camera a try when we're done and see if everything works as before.

[cdondrup]

Great. Thank you!

[marc-hanheide]

@RaresAmbrus shall we close this?

[cdondrup]

I still think we should use the default one.

[RaresAmbrus]

Having access to the low level driver allows us to do certain things like change the exposure or the whitebalancing, which we might want to experiment with in the future; it also allows us to apply certain correction functions (e.g. CLAMS or others) directly on the images coming out of the sensor. If at all we decide to do something along these lines, I don't know how easy it would be with the default openni2 package.

@cdondrup I see now that I was supposed to look into the openni2_camera package which I completely forgot. Do you know whether it is stable? Also, does it have any functionality you need which we don't have at the moment?

[cdondrup]

Indeed the oepnni2 seems to be stable. It does not have any functionalities I need in particular but if we ever need the skeleton tracker working, this would be an easy solution.
The main reason why I would like to use it is, to have consisten default parameters for the higher level components like topic names and image types. That would allow to just exchange it without any extra effort. Currently the depth topic for example does not publish the same image type like the openni2 one and you need a different topic.

[RaresAmbrus]

Yes, consistent topic names and types sounds good, I can look into it. What about the skeleton tracker? Why would that work with the openni2 and not with ours, as long as we feed it with the proper topics? The data should be the same.

[cdondrup]

Afaik, the tracker does not work on topics but directly on the hardware resource which is blocked when using our wrapper but still accessible when using openni2