Ask Your Question

Revision history [back]

This sounds like your settings for the interplay between rgbdslam and octomap_server are incorrect. The fixed frame should not be openni_camera, but whatever you set as parameter "fixed_frame_name" for rgbdslam.

rxgraph lets you easily see, whether the rgbdslam and octomap-server node are communicating on the same topic.

The pointclouds streamed to the octomap server need much bandwidth and much processing by the octomap server. Make sure your computer is capable of keeping up or adapt rgbdslam's parameter "send_clouds_rate".

Using the Xtion Pro is fine, you only need to adapt the input topics of rgbdslam, which seems to work as you see the cloud correctly in rgbdslam's gui.

The transform publisher you use makes no sense. The frame id set in /rgbdslam/batch_clouds is the fixed_frame_name as mentioned above. Make sure you set that same frame name for the octomap_server (see rgbdslam/launch/octomap_server.launch for an example).

Edit: I found a bug in rgbdslam, where the tf frames of the old openni_camera driver are hardwired in the code. Because of this, octomap_server will not find a transformation between /map and the point cloud frame when using openni_launch. I'll try to release a fix soon.

This sounds like your settings for the interplay between rgbdslam and octomap_server are incorrect. The fixed frame should not be openni_camera, but whatever you set as parameter "fixed_frame_name" for rgbdslam.

rxgraph lets you easily see, whether the rgbdslam and octomap-server node are communicating on the same topic.

The pointclouds streamed to the octomap server need much bandwidth and much processing by the octomap server. Make sure your computer is capable of keeping up or adapt rgbdslam's parameter "send_clouds_rate".

Using the Xtion Pro is fine, you only need to adapt the input topics of rgbdslam, which seems to work as you see the cloud correctly in rgbdslam's gui.

The transform publisher you use makes no sense. The frame id set in /rgbdslam/batch_clouds is the fixed_frame_name as mentioned above. Make sure you set that same frame name for the octomap_server (see rgbdslam/launch/octomap_server.launch for an example).

*2nd Edit: The latest release of my rgbdslam package includes the ability to compute the octomap internally. You can save it directly from the gui or via ros service call. See the wiki or the readme file for instructions. *

Edit: I found a bug in rgbdslam, where the tf frames of the old openni_camera driver are hardwired in the code. Because of this, octomap_server will not find a transformation between /map and the point cloud frame when using openni_launch. I'll try to release a fix soon.

This sounds like your settings for the interplay between rgbdslam and octomap_server are incorrect. The fixed frame should not be openni_camera, but whatever you set as parameter "fixed_frame_name" for rgbdslam.

rxgraph lets you easily see, whether the rgbdslam and octomap-server node are communicating on the same topic.

The pointclouds streamed to the octomap server need much bandwidth and much processing by the octomap server. Make sure your computer is capable of keeping up or adapt rgbdslam's parameter "send_clouds_rate".

Using the Xtion Pro is fine, you only need to adapt the input topics of rgbdslam, which seems to work as you see the cloud correctly in rgbdslam's gui.

The transform publisher you use makes no sense. The frame id set in /rgbdslam/batch_clouds is the fixed_frame_name as mentioned above. Make sure you set that same frame name for the octomap_server (see rgbdslam/launch/octomap_server.launch for an example).