rgbdslam crashes with elas_ros [closed]

asked 2012-11-21 07:22:13 -0500

updated 2014-01-28 17:14:19 -0500

ngrennan gravatar image

Hi everyone,

I am currently trying to evaluate rgbdslam using the stereo processing capabilities of elas_ros. While I have been able to make things work with regular stereo, for some reason this time rgbdslam crashes halfway through. I can't even get the camera input in the GUI, so maybe I am making some kind of mistake in remapping. I couldn't find any relevant info in the log files.

Here is my launch file, please tell me if you need any more info:

NOTE: I am also running stereo_image_proc, merely for image rectification.

<!-- This file demonstrates the parameters that can be set via the parameter server.
     The settings here typically show the default values (c.f. parameter_server.cpp)
     This file strives to enlist all possibilities, to be a good copy-paste source.
     In general most options/tags don't need to be altered/used. -->
  <env name="ROSCONSOLE_CONFIG_FILE" value="$(find rgbdslam)/log.conf"/>
  <env name="ROSCONSOLE_FORMAT" value="[${severity}] [${time}]: ${message}"/>

  <arg name="debug" default="false"/>
  <!-- Several possibilities to debug (uncomment only one)-->
  <arg if="$(arg debug)" name="launch_prefix" value="/usr/bin/gdb -ex run -args"/>
  <!--arg if="$(arg debug)" name="launch_prefix" value="/usr/bin/xterm -rv -e gdb -ex run -args"/-->
  <!--arg if="$(arg debug)" name="launch_prefix" value="/usr/bin/valgrind -DELeTEME-tool=cachegrind -DELETEME-cachegrind-out-file=/tmp/cachegrind.out"/-->
  <!--arg if="$(arg debug)" name="launch_prefix" value="/usr/bin/valgrind -DELETEME-leak-check=full "/-->
  <arg unless="$(arg debug)" name="launch_prefix" value=""/>

  <remap from="/videre_camera/left/image_rect_color" to="/stereo/left/image_rect"/>
  <remap from="/videre_camera/left/camera_info" to="/stereo/left/camera_info"/>
  <remap from="/videre_camera/right/image_rect_color" to="/stereo/right/image_rect"/>
  <remap from="/videre_camera/right/camera_info" to="/stereo/right/camera_info"/>

  <node name="videre_camera" pkg="videre_camera" type="videre_camera" />
  <node name="stereo_image_proc" ns="/videre_camera" pkg="stereo_image_proc" type="stereo_image_proc"/>

  <node pkg="elas_ros" type="elas_ros" name="elas" args="stereo:=stereo image:=image_rect" respawn="true">
    <param name="approximate_sync" value="true" />

  <node pkg="rgbdslam" type="rgbdslam" name="rgbdslam" cwd="node" required="true" output="log"  launch-prefix="$(arg launch_prefix)"> 
    <!-- Input data settings-->
    <param name="config/topic_image_mono"              value="/camera/rgb/image_mono"/> <!--could also be color -->
    <param name="config/topic_image_depth"             value="/camera/depth/image"/>
    <param name="config/topic_points"                  value="/camera/rgb/points"/> <!--if empty, poincloud will be reconstructed from image and depth -->
    <param name="config/camera_info_topic"             value="/camera/rgb/camera_info"/>
    <param name="config/wide_topic"                    value="/videre_camera/left/image_rect_color"/>
    <param name="config/wide_cloud_topic"              value="/elas/point_cloud"/>
    <param name="config/subscriber_queue_size"         value="2"/>
    <param name="config/drop_async_frames"             value="false"/> <!-- Check association of depth and visual image, reject if not in sync -->
    <param name="config/depth_scaling_factor"          value="1.0"/> <!-- to correct bad depth scaling of kinect -->
    <param name="config/bagfile_name"                  value=""/><!-- read data from a bagfile, make sure to enter the right topics above-->
    <param name="config/data_skip_step"                value="1"/><!-- skip every n-th frame completely -->

    <!-- Output data settings-->
    <param name="config/store_pointclouds"             value="true"/> <!-- if, e.g., only trajectory is required, setting this to false saves lots of memory -->
    <param name="config/individual_cloud_out_topic"    value="/rgbdslam/batch_clouds"/><!-- The point clouds, e.g., for octomap server (the corresp. sensor poses are sent ...
edit retag flag offensive reopen merge delete

Closed for the following reason question is not relevant or outdated by tfoote
close date 2015-08-31 20:34:58.826630


I don't understand the meaning of the remap tags outside of nodes. Is that possible? What does it do?

Felix Endres gravatar image Felix Endres  ( 2012-11-21 08:29:43 -0500 )edit

AFAIK it has the same effect, except in a global scope. In rxgraph, I saw that nodes that expected the /stereo namespace would get their data and nodes that expected the /videre_camera namespace would also get their data. I used that before in another launch file, but maybe there's something wrong

georgebrindeiro gravatar image georgebrindeiro  ( 2012-11-21 13:04:29 -0500 )edit

You could debug whether the topics are correctly set using rxgraph. Rgbdslam should be connected via /camera/rgb/image_mono, /camera/depth/image, /camera/rgb/points and /tf to your data source.

Felix Endres gravatar image Felix Endres  ( 2012-11-22 22:06:03 -0500 )edit

BTW, I haven't tested this in a long time, but you can also use the parameters "wide_topic" and "wide_cloud_topic" if you have no depth image, instead of topic_image_mono/depth/points. We used this for the PR2 wide_stereo_camera, hence the weird names.

Felix Endres gravatar image Felix Endres  ( 2012-11-22 22:08:07 -0500 )edit

Yeah, I have been using "wide_topic" and "wide_cloud_topic" with my stereo camera. It worked with the point cloud generated by stereo_image_proc, but not by elas_ros. No idea why, though.

georgebrindeiro gravatar image georgebrindeiro  ( 2012-11-23 01:44:34 -0500 )edit

Could synchronization be an issue here? I mean, my cloud is coming out of a node that takes the wide_topic image as input, so there is an inevitable delay there. Looking through the source code I see you used an ApproxTimeSynchronizer. Maybe rgbdslam will be able to sync with a bigger queue size?

georgebrindeiro gravatar image georgebrindeiro  ( 2012-11-25 23:07:58 -0500 )edit

Yes, that sounds reasonable. I do not know whether the queue size will help. Try it. You definitely need to check whether the corresponding image and the cloud have approximately (or exactly) the same timestamp.

Felix Endres gravatar image Felix Endres  ( 2012-11-27 01:28:38 -0500 )edit