Running rgbdslam over multiple machines

asked 2012-06-28 12:31:31 -0500

mmcdermott
43 ●1 ●3 ●5

updated 2014-01-28 17:12:50 -0500

ngrennan
1 ●1 ●1

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

edit retag flag offensive close merge delete

Comments

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?

longzhixi123 ( 2013-07-16 22:51:30 -0500 )edit

add a comment

4

answered 2012-07-09 06:06:39 -0500

Felix Endres

6468 ●28 ●57 ●93 http://www.informatik....

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.

edit flag offensive delete link

Comments

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.

mmcdermott ( 2012-07-09 08:04:42 -0500 )edit

add a comment

0

answered 2012-11-20 01:58:05 -0500

JP Schubert
16 ●2 ●2 ●3

I am having the same issue. If this was solved what was the solution??

edit flag offensive delete link

Comments

For my setting the "subscriber_queue_size" to a higher value (6 in my case) solved the issue. You can set this through the launch files in RGBDSLAM/Launch.

Merdad ( 2013-01-25 12:13:14 -0500 )edit

More specifically, for those wondering, add <param name="config/subscriber_queue_size" value="{VALUE}" /> between "<node>" and "</node>" in rgbdslam/launch/{filename}.launch

magnate ( 2013-02-15 11:23:36 -0500 )edit

add a comment

0

answered 2013-01-26 06:27:13 -0500