The site is read-only. Please transition to use Robotics Stack Exchange
| ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange |
 | 1 | initial version |
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
[0m[ INFO] [1329245739.609814039]: Pointcloud with id 3 sent with frame /openni_rgb_optical_frame[0m
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<="" p="">
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 for your help. Any further thoughts would be much appreciated!
James
| | 2 | formating |
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:
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 for your help. Any further thoughts would be much appreciated!
James
ROS Answers is licensed under Creative Commons Attribution 3.0 Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.