0
$\begingroup$

Rosanswers logo

Hi,

I am trying to run rgbdslam over a distributed ROS system, running the openni nodes on a laptop aboard an iRobot Create with a kinect and running rgbdslam on a desktop computer. When I run rosrun rgbdslam rgbdslam (or roslaunch rgbdslam kinect+rgbdslam, or a modified launch file I made that is the same as kinect+rgbdslam but doesn't start the openni stuff), the GUI loads fine, I get no errors, but it always sits with blank screens in a 'waiting for image/motion' state.

Both computers can ping and ssh into each other and other applications (such as gmapping, amcl, and others) work fine when distributed like this (the data collection and minimal processing on the laptop, and heavier processing on the desktop). Furthermore, I can view the various camera streams from the kinect on the default topics on the desktop with image_view. I also can view rxgraph and the info on the various topics that rgbdslam needs and it all appears fine (identical to when I run everything on the desktop and it works).

Furthermore, as implied by the above comment, I can run rgbdslam on the desktop with a handheld kinect and it works fine.

The desktop and laptop are both running x64 Lubuntu 11.10. We're using ROS electric, and the current builds of rgbdslam and openni.

Is there any reason rgbdslam will not work distributed like this, or am I just doing something wrong?

Thanks in advance


Originally posted by mmcdermott on ROS Answers with karma: 43 on 2012-06-28

Post score: 4


Original comments

Comment by longzhixi123 on 2013-07-16:
Hello, I am also in accordance with this distributed approach. But I found a notebook from the robot pass over the kinect depth data and color data is not synchronized. This may lead to RGBDSLAM failure. How would you solve this problem?

$\endgroup$

1 Answer 1

0
$\begingroup$

Rosanswers logo

The only answer I can think of right now is that the approximate time synchronizer fails because of lag. Ways to possibly solve this, sorted by required effort:

  • Set the "subscriber_queue_size" to a higher value.
  • have rgbdslam reconstruct the point cloud -> use an empty topic for parameter "topic_points". The two images are quicker sent than the 10Mb cloud.
  • If this fails, try setting compressed image transport. I have never tried this though.
  • If that fails too, you can modify the constructor in openni_listener, so that it can listen to point_cloud only data. Then copy and modify the stereoCallback s.t. it reconstruct the rgb image from the cloud.

If it's not the time sync, I don't know what would be causing this. There is nothing special about the listener code apart from that.


Originally posted by Felix Endres with karma: 6468 on 2012-07-09

This answer was ACCEPTED on the original site

Post score: 4


Original comments

Comment by mmcdermott on 2012-07-09:
Thanks much for the help, it was indeed that the lag was too much. I'm not quite sure why, as we've run some other similar applications like this without the lag being an issue, but now we can at least see if any other changes we make to increase performance are having some effect.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.