No point cloud when using hardware depth registration

[bit-pirate]

When turning on hardware depth registration both the unregistered and registered point cloud stop being published.

Looking further into this I noticed that one of the inputs of the registration module, /camera/depth_registered/image_rect_raw, is not being published. However, the module responsible for this gets its input /camera/depth_registered/image_raw. So, on the first look I would say the image_proc/rectify nodelet doesn't work properly.

[bit-pirate]

OK, the solution is actually quite simple. The new version uses the hardware depth registration argument (depth_registration) to decided whether or not to loaded specific nodelets (introduced with cf357ef).

That works fine as long as people only use the arguments in the launch file. But we have forgotten to take the option of dynamic reconfiguration into account. If hardware depth registration is turned off at start, but turned on in runtime, it can't work since it's missing important processing nodelets.

So we can either add a note about this to the wiki, e.g. turn on depth_registration when you like to play with it, or we need to make sure that the required nodelets are launched for both cases.

I would prefer the later solution. Having multiple nodelets running even though they are not used, should be fine, since there is no processing going on when they don't get input.

[bit-pirate]

Aish! This openni launcher really can give me headaches! :-)

If we remove the depth_registration arg from the processing modules, we will get this annoying service error again. Its hard to avoid this, since everything is chained, e.g. depth rectify -> depth registration -> disparity. I played around a bit, but haven't found a good solution yet (example here: https://github.com/bit-pirate/openni_launch/compare/hydro-devel; won't work with disparity).

[piyushk]

@vrabaud Were you using dynamic reconfigure to set the parameter, or just setting the parameter at the node level I've been testing only using the command line, and @bit-pirate's observations here match what I see.

@bit-pirate IIRC I tried a year ago when I wrote freenect_launch to get rid of the service warning, but was unable to. I can't remember the exact reason why, but I believe I concluded at that time that it was not possible without some sort of service mux (that would take in the depth_registration parameter, forward the right services and set the parameter for the openni node)

+1 for removing depth_registration from dynamic reconfigure and adding a note to the wiki. I think it is a better solution than seeing the service error. The parameter should still work through the launch file correctly.

[piyushk]

@bit-pirate I just looked at your code and extended the same idea to disparity. I think it's working, though I am not sure what the best way to test disparity images is. The code is here: https://github.com/piyushk/openni_launch/tree/fix_service_error

[brotherxiang00]

@bit-pirate Hi, I encounter the same problem following instruction on http://wiki.ros.org/openni_launch.

When rosrun image_view disparity_view image:=/camera/depth/disparity, it works well. But when I enable depth_registration by rosrun rqt_reconfigure rqt_reconfigure, there is image displayed. I use rostopic echo /camera/depth_registered/disparity, the output is a lot of zero on terminal.

Could you please tell me how to fix it? As I am very new to ROS, could you please give me a step by step solution? Many thanks.

[130s]

Moved to openni_camera repo. Please follow the referenced link.