rgbdslam crashes on repeated "send model" request

RGBDSLAM

asked 2012-02-14 07:12:56 -0500

jwrobbo
258 ●13 ●19 ●21

updated 2014-01-28 17:11:22 -0500

ngrennan
1 ●1 ●1

I would like to repeatedly query RGBDSLAM for pose estimate (map is less important but would be nice as well).

However if I make repeated calls to "send model" or "save trajectory", either in the GUI or using service calls I get the following error message:

[rgbdslam-7] process has died [pid 20770, exit code -11]. log files: /home/james/.ros/log/6dd532b8-573d-11e1-8050-002608dcf037/rgbdslam-7*.log

I have tried different request intervals but it still happens when I wait more than 10 seconds between each request, and ideally I would like much more frequent tf information than this.

I am using ubuntu 11.10 and ROS electric on a 2.8ghz core 2 duo with 8gb of RAM. Could the speed of my computer be the problem? Is there anything else I can try?

Thanks in advance,

James

edit retag flag offensive close merge delete

add a comment

3 Answers

Sort by » oldest newest most voted

answered 2012-02-15 23:07:45 -0500

Felix Endres

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

updated 2012-02-19 00:22:30 -0500

Hi James, sounds weird. Have you looked into the logfile mentioned in the error message? Otherwise you would either need to run it in a debugger or fiddle a little with the code, as I cannot reproduce the problem.

Concerning the speed, you can have a look at the function "void GraphManager::sendAllClouds()" in graph_manager.cpp around line 1350. There the frequency of sending the transforms and clouds is throttled to 5 Hz in the line

ros::Rate r(5); //slow down a bit, to allow for transmitting to and processing in other nodes

You can set that any value.

You can omit sending of the cloud by removing (or commenting out) the following line:

graph_[i]->publish("/openni_rgb_optical_frame", now, batch_cloud_pub_);

Are you only interested in the current pose estimate or in the whole trajectory?

Edit: I added the feature to send the current pose estimate after each processed frame. That means, you can just listen to the transformation from /map to /openni_camera and use the sending of the clouds only if you want to update the map. This doesn't fix the crash you mentioned though. Please download it here and report back whether that works for you. You need to replace the rgbdslam folder with the folder rgbdslam_dev-f4835f9e1e39 (i.e. rename the latter to the former) and rebuild.

edit flag offensive delete link

add a comment

answered 2012-02-24 04:01:57 -0500

jwrobbo
258 ●13 ●19 ●21

Hi Felix,

Sorry - only just had a chance to try this out. Works like a charm. Thanks a lot for adding that feature. Exactly what I needed! As you say it doesn't fix the crashing problem that I've been having with octomap_server running so producing maps in realtime still isn't really an option but the localisation side of things works great. Interesting about the mutex - I'll have a look too but probably a bit over my head. Would obviously still be extremely interested if you found a solution!

Thanks again,

James

edit flag offensive delete link

add a comment

answered 2012-02-16 03:12:47 -0500

jwrobbo
258 ●13 ●19 ●21

updated 2012-02-19 00:02:37 -0500

Felix Endres

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

Thanks for your quick answer Felix. I've just realised that this only happens when octomap_server is running as well.

I tried the options you suggested and commenting out the cloud sending line definitely seems to speed things up a bit (without octomap_server running) but unfortunately neither seems to solve the problem I've been having.

I'm mainly interested in the current pose estimate (ideally updating every second or so). I think I've found a way to use this estimate instead of AMCL in the navigation stack using fake_localization which would have quite a lot of advantages for the quadcopter project I'm working on (mainly that I don't currently have another odometry source or a mocap system and that it would be insensitive to the quadcopter angle). Ideally I would like to be able to use RGBDSLAM + Octomap for mapping as well but the map updates don't need to be particularly frequent (so if sending the PCs is slowing things down I guess I might look into writing another publisher function so that one is called frequently to publish the pose estimate and the other less frequently to publish the point cloud).

It would be great to get it working with octomap but if this isn't possible is there a way of specifying the fixed_frame parameter manually so that RGBDSLAM publishes the transform between this and the camera?

I had a look at the log files from the crash and couldn't see anything that was obviously causing it:

The bottom of "rgbdslam-7-stdout.log" looks like this:

[0m[ INFO] [1329245739.550899959]: init_base_pose_: Translation 0 0 0[0m
[0m[ INFO] [1329245739.550920319]: init_base_pose_: Rotation 0 0 0 1[0m
[0m[ INFO] [1329245739.550944119]: World->Base: Translation 0.0132167 -0.00293548 0.0483612[0m
[0m[ INFO] [1329245739.550965359]: World->Base: Rotation -0.0532939 -0.037762 -0.294945 0.953279[0m
#Features:  1243
[Get Feature List]: 0.091
[0m[ INFO] [1329245739.609814039]: Pointcloud with id 3 sent with frame /openni_rgb_optical_frame[0m
[Feature Orientations]: 0.035
#Features MO:   1425
[MultiO Feature List]:  0.025
[Download Keypoints]:   0
[Get Descriptor]:   0.043

and the chunk of the roslaunch log around the crash looks like this:

[roslaunch][INFO] 2012-02-14 18:55:14,884: ... successfully launched [octomap_server-8]
[roslaunch][INFO] 2012-02-14 18:55:14,884: ... launch_nodes complete
[roslaunch.pmon][INFO] 2012-02-14 18:55:14,884: registrations completed <ProcessMonitor(ProcessMonitor-1, started daemon 140487389554432)>
[roslaunch.parent][INFO] 2012-02-14 18:55:14,884: ... roslaunch parent running, waiting for process exit
[roslaunch][INFO] 2012-02-14 18:55:14,884: spin
[roslaunch][ERROR] 2012-02-14 18:55:40,014: [rgbdslam-7] process has died [pid 20770, exit code -11].
log files: /home/james/.ros/log/6dd532b8-573d-11e1-8050-002608dcf037/rgbdslam-7*.log
[roslaunch.pmon][INFO] 2012-02-14 18:55:40,014: ProcessMonitor.unregister[rgbdslam-7] starting
[roslaunch.pmon][INFO] 2012-02-14 18:55:40,014: ProcessMonitor.unregister[rgbdslam-7] complete

I tried running rxconsole in debug mode as well but as far as I could tell it didn't mention anything about the crash.

Again thanks a lot ... (more)

edit flag offensive delete link

Comments

Hm, it's a segmentation fault and the last thing happening was the SIFTGPU detection. I'll look into it. Maybe the QMutex optimizer_mutex should be locked/unlocked where batch_processing_runs_ is switched on/off

Felix Endres ( 2012-02-19 00:12:31 -0500 )edit

add a comment

rgbdslam crashes on repeated "send model" request

3 Answers

Comments

Question Tools

Stats

Related questions

rgbdslam crashes on repeated "send model" request edit

3 Answers

Comments

Question Tools

Stats

Related questions

rgbdslam crashes on repeated "send model" request