ROS Electric openni_node no longer publishes /camera/rgb/points correctly

[pirobot]

Before the OpenNI update back in December 2012, one could run:

$ roslaunch openni_camera openni_node.launch

then subscribe to the topic /camera/rgb/points in RViz and view the XYZRGB pointcloud. Now, as soon as the topic is subscribed to, a message appears in the openni_camera window that says:

[ WARN] [1362930566.478614323]: turning on depth registration, since PointCloudXYZRGB has subscribers.

At that point, the pointcloud image in RViz freezes even though the Status is OK and messages are being received.

One can subscribe to /camera/depth/points and turn off registration using dynamic_reconfigure to see the pointcloud but then you don't have the the RGB option in the Color Transformer setting.

[jkammerl]

Hi Pirobot,

if depth registration is activated, openni_launch switches from /camera/depth/[points,image,image_raw] to /camera/depth_registered/[points,image,image_raw]. Could you test if subscription to /camera/depth_registered/points works for you?

Best,
Julius

[pirobot]

Thanks Julius--yes, /camera/depth_registered/points works fine. However, I (and perhaps others) have a lot of code (and documentation) that subscribes to /camera/rgb/points and this used to work fine. Is there anyway to allow /camera/rgb/points to still work the way it used to?

[jonbinney]

This should be easy to achieve using a remapping in the launchfile: http://www.ros.org/wiki/roslaunch/XML/remap

for example, you can create your own copy of openni.launch which has

<remap from="/camera/depth_registered/points" to="/camera/rgb/points"/>

[chadrockey]

Oooo, interesting? So the new functionality is that all colorized pointclouds use registered depth images?

The old behavior was (I think):
depth/points -> Uncolorized pointcloud generated from depth/image_raw
depth_registered/points -> Uncolorized pointcloud generated from depth_registered/image_raw
rgb/points -> Colorized pointcloud generated using depth or depth_registered depending on which was published

The new behavior is (I think):
depth/points -> Uncolorized pointcloud generated from depth/image_raw
depth_registered/points -> Colorized pointcloud generated using depth_registered/image_raw

Does this significantly increase CPU usage for Kinects (ASUS have hardware registration)? I think one of the main reasons for leaving the poor registration available was so that turtlebot could try to run this. Maybe @dgossow knows. I have spare turtlebot netbooks if you need to test @jkammerl.

[pirobot]

Thanks @jonbinney--yes, I could remap but I was hoping not to have to do that. My understanding is what @chadrockey says above. So I'm wondering if it would be possible to go back to where rgb/points holds a colorized pointcloud.

[jonbinney]

It sounds like the only reason to use colorized, non-registered point clouds is CPU usage. Can anyone confirm that there's a big difference in processor usage?