ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

Revision history [back]

In case of crashes, please do the following:

  • In your launchfile, set the launch-prefix in the rgbdslam node-tag to a debugger and
  • Set the "output" attribute of the node-tag to "screen" e.g.

    <node pkg="rgbdslam" type="rgbdslam" name="rgbdslam" cwd="node" required="true" output="screen" launch-prefix="/usr/bin/xterm -rv -e gdb -ex run -args">

  • Launch the launch-file. An extra terminal "xterm" will be opened.

  • When the program crashes, check the error message in xterm
  • In xterm, run "backtrace"
  • Post the output of that command and the output of rgbdslam before
  • Format it as code (the button with the 1s and the 0s)

Thanks for helping

click to hide/show revision 2
Further debugging help and specific thoughts about the problem cause

In case of crashes, please do the following:following (not specific to rgbdslam):

  • In your launchfile, set the launch-prefix in the rgbdslam node-tag to a debugger and
  • Set the "output" attribute of the node-tag to "screen" e.g.

    <node pkg="rgbdslam" type="rgbdslam" name="rgbdslam" cwd="node" required="true" output="screen" launch-prefix="/usr/bin/xterm -rv -e gdb -ex run -args"> -args">

  • Launch the launch-file. An extra terminal "xterm" will be opened.

  • When the program crashes, check the error message in xtermthe xterm window
  • In xterm, the xterm window, run "backtrace"backtrace. Also helpful:
    1. jump to the first frame (lowest number) where the path of the file location contains "rgbdslam". In the above question post, this would be done by frame 2
    2. use list to print some of the source code of that frame, centered at the line that provoked the crash.
    3. use print <variablename> to inspect values of variables that may be involved in the crash (e.g., pointer values, array indices...)
  • Post the output of that command these commands and the some output of rgbdslam before
  • Format it as code (the button with the 1s and the 0s)

Thanks for helping

Edit:

Hm, the backtrace is interesting. The segfault happens in the visualization code, which explains, why it works (longer) in headless mode. I can not reproduce the problem. However, here are some thoughts:

  • I've found and fixed a bug concerning the deletion of clouds. Please update (you are using the code from the alufr-ros-pkg repository on google code, I assume) and recompile. It may be the source of your problem.
  • If you are running low on main memory, you could try to uncomment #ADD_DEFINITIONS(-DRGB_IS_4TH_DIM) in CMakeLists.txt an recompile. This effectively halves the size of the clouds in memory.
  • Setting values > 1 for the parameter visualization_skip_step in your launchfile will also reduce the impact on memory (including the memory of the graphics card)
  • Exit code -6 is fine (it's a workaround to a deadlock on exit), -11 is memory access releated.
  • If you want the GUI, but don't need the 3D view set the parameter "use_glwidget" to false

In case of crashes, please do the following (not specific to rgbdslam):

  • In your launchfile, set the launch-prefix in the rgbdslam node-tag to a debugger and
  • Set the "output" attribute of the node-tag to "screen" e.g. <node pkg="rgbdslam" type="rgbdslam" name="rgbdslam" cwd="node" required="true" output="screen" launch-prefix="/usr/bin/xterm -rv -e gdb -ex run -args">

  • Launch the launch-file. An extra terminal "xterm" will be opened.

  • When the program crashes, check the error message in the xterm window
  • In the xterm window, run backtrace. Also helpful:
    1. jump to the first frame (lowest number) where the path of the file location contains "rgbdslam". In the above question post, this would be done by frame 2
    2. use list to print some of the source code of that frame, centered at the line that provoked the crash.
    3. use print <variablename> to inspect values of variables that may be involved in the crash (e.g., pointer values, array indices...)
  • Post the output of these commands and some output of rgbdslam before
  • Format it as code (the button with the 1s and the 0s)

Thanks for helping

Edit:

Hm, the backtrace is interesting. The segfault happens in the visualization code, which explains, why it works (longer) in headless mode. I can not reproduce the problem. However, here are some thoughts:

  • I've found and fixed a bug concerning the deletion of clouds. Please update (you are using the code from the alufr-ros-pkg repository on google code, I assume) and recompile. It may be the source of your problem.
  • If you are running low on main memory, you could try to uncomment #ADD_DEFINITIONS(-DRGB_IS_4TH_DIM) in CMakeLists.txt an recompile. This effectively halves the size of the clouds in memory.memory, but requires rgbdslam to compute the cloud itself from rgb image and depth image, which means you may not subscribe to the ".../points" topic.
  • Setting values > 1 for the parameter visualization_skip_step in your launchfile will also reduce the impact on memory (including the memory of the graphics card)
  • Exit code -6 is fine (it's a workaround to a deadlock on exit), -11 is memory access releated.
  • If you want the GUI, but don't need the 3D view set the parameter "use_glwidget" to false

In case of crashes, please do the following (not specific to rgbdslam):

  • In your launchfile, set the launch-prefix in the rgbdslam node-tag to a debugger and
  • Set the "output" attribute of the node-tag to "screen" e.g. <node pkg="rgbdslam" type="rgbdslam" name="rgbdslam" cwd="node" required="true" output="screen" launch-prefix="/usr/bin/xterm -rv -e gdb -ex run -args">

  • Launch the launch-file. An extra terminal "xterm" will be opened.

  • When the program crashes, check the error message in the xterm window
  • In the xterm window, run backtrace. Also helpful:
    1. jump to the first frame (lowest number) where the path of the file location contains "rgbdslam". In the above question post, this would be done by frame 2
    2. use list to print some of the source code of that frame, centered at the line that provoked the crash.
    3. use print <variablename> to inspect values of variables that may be involved in the crash (e.g., pointer values, array indices...)
  • Post the output of these commands and some output of rgbdslam before
  • Format it as code (the button with the 1s and the 0s)

Thanks for helping

Edit:

Hm, the backtrace is interesting. The segfault happens in the visualization code, which explains, why it works (longer) in headless mode. I can not reproduce the problem. However, here are some thoughts:

  • I've found and fixed a bug concerning the deletion of clouds. Please update (you are using the code from the alufr-ros-pkg repository on google code, I assume) and recompile. It may be the source of your problem.
  • If you are running low on main memory, you could try to uncomment #ADD_DEFINITIONS(-DRGB_IS_4TH_DIM) in CMakeLists.txt an recompile. This effectively halves the size of the clouds in memory, but requires rgbdslam to compute the cloud itself from rgb image and depth image, which means you may not subscribe to the ".../points" topic.
  • Setting values > 1 for the parameter visualization_skip_step in your launchfile will also reduce the impact on memory (including the memory of the graphics card)
  • Exit code -6 is fine (it's a workaround to a deadlock on exit), -11 is memory access releated.
  • If you want the GUI, but don't need the 3D view set the parameter "use_glwidget" to false

Edit2:

Concerning the second traceback: This error is very weird, in particular as it occurs after the 430th frame. I've never had this problem, opencv should choose the data type on its own. Since it doesn't do so, try the following. At the end of the file src/node.cpp, could you please replace

cv::reduce(descriptors, sums_vec, 1 /*sum over columns*/, CV_REDUCE_SUM);

by

cv::reduce(descriptors, sums_vec, 1 /*sum over columns*/, CV_REDUCE_SUM, CV_32FC1);

Then recompile.