rgbdslam crashes with elas_ros
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. -->
<launch>
<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>
<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 via /tf). Requires store_pointclouds to be true. Is sent only on request (service call or gui menu) -->
<param name="config/aggregate_cloud_out_topic" value="/rgbdslam/aggregate_clouds"/>
<param name="config/publisher_queue_size" value="2"/><!-- affects all publishers -->
<param name="config/send_clouds_rate" value="5"/> <!-- When sending the point clouds (e.g. to RVIZ or Octomap Server) limit sending to this many clouds per second -->
<!-- TF information settings -->
<param name="config/fixed_frame_name" value="/map"/>
<param name="config/ground_truth_frame_name" value="/ground_truth_map"/><!--empty string if no ground truth-->
<param name="config/base_frame_name" value="/openni_camera"/> <!-- /openni_camera for hand-held kinect. For robot, e.g., /base_link -->
<param name="config/fixed_camera" value="true"/> <!--is the kinect fixed with respect to base, or can it be moved (false makes sense only if transform betw. base_frame and openni_camera is sent via tf)-->
<!-- Visual Features, to activate GPU-based features see CMakeLists.txt -->
<param name="config/feature_detector_type" value="SURF"/><!-- If SIFTGPU is enabled in CMakeLists.txt, use SURF here -->
<param name="config/feature_extractor_type" value="SURF"/><!-- If SIFTGPU is enabled in CMakeLists.txt, use SURF here -->
<param name="config/matcher_type" value="FLANN"/> <!-- FLANN (not avail for ORB features), SIFTGPU (only for SIFTGPU detector) or BRUTEFORCE-->
<param name="config/nn_distance_ratio" value="0.6"/> <!-- Feature correspondence is valid if distance to nearest neighbour is smaller than this parameter times the distance to the 2nd neighbour -->
<param name="config/max_keypoints" value="1000"/><!-- Extract no more than this many keypoints (not honored by SIFTGPU)-->
<param name="config/min_keypoints" value="600"/><!-- Extract no less than this many ... -->
<param name="config/adjuster_max_iterations" value="3"/>
<!-- Algortithm settings -->
<param name="config/min_translation_meter" value="0.1"/><!-- frames with motion less than this, will be omitted -->
<param name="config/min_rotation_degree" value="5"/><!-- frames with motion less than this, will be omitted -->
<param name="config/predecessor_candidates" value="5"/><!-- search through this many immediate predecessor nodes for corrspondences -->
<param name="config/neighbor_candidates" value="5"/><!-- search through this many graph neighbour nodes for corrspondences -->
<param name="config/min_sampled_candidates" value="5"/><!-- search through this many uniformly sampled nodes for corrspondences -->
<param name="config/max_connections" value="10"/><!-- stop after this many succesfully found spation relations -->
<param name="config/min_matches" value="50"/><!-- Prune unreliable transformations from too few feature matches -->
<param name="config/sufficient_matches" value="400"/><!-- Instead of matching all new descriptors against all of a previous node in one step, sufficient_matches+100 of the new descriptors are iteratively compared to all of the previous node until sufficient_matches are found. Setting this parameter low (e.g. 2x min_matches) speeds up comparisons of frames with many matches, but with a potential loss of accuracy, as the transformation is estimated from less features. Set it to max_keypoints for maximum accuracy -->
<param name="config/ransac_iterations" value="5000"/><!-- these are fast, so high values are ok -->
<param name="config/max_dist_for_inliers" value="3"/> <!--matches considered inliers by ransac (in mahalanobis distance, i.e. std deviations)-->
<param name="config/optimizer_iterations" value="2"/><!-- maximum of iterations in online operation (i.e., does not affect the final optimization in batch mode) -->
<param name="config/optimizer_skip_step" value="1"/><!-- optimize every n-th frame. Set high for offline operation -->
<param name="config/use_icp" value="false"/> <!-- Ignored if ICP is not compiled in (see top of CMakeLists.txt) -->
<param name="config/backend_solver" value="cholmod"/> <!-- Which solver to use in g2o for matrix inversion: "csparse" , "cholmod" or "pcg" -->
<!-- Visualization Settings -->
<param name="config/squared_meshing_threshold" value="0.0009"/><!-- don't triangulate over depth jumps -->
<param name="config/visualization_skip_step" value="1"/> <!-- draw only every nth pointcloud row and line, high values require higher squared_meshing_threshold -->
<param name="config/use_glwidget" value="true"/><!-- 3D visualization needs performance -->
<param name="config/use_gui" value="true"/><!-- No visualization, e.g., on robot -->
<param name="config/show_axis" value="true"/> <!-- do/don't visualize the pose graph in glwidget-->
<param name="config/scalable_2d_display" value="false"/> <!-- do/don't scale input displays. Consumes more cpu if set true-->
<!-- Misc -->
<param name="config/concurrent_node_construction" value="true"/><!-- detect+extract features for new frame, while current frame is inserted into graph -->
<param name="config/concurrent_edge_construction" value="true"/><!-- compare current frame to many predecessors in parallel, might not work with SIFTGPU matcher (but SIFTGPU detector and extractor is ok) -->
<param name="config/voxelfilter_size" value="-1.0"/> <!-- in meter voxefilter displayed and stored pointclouds, incompatible with use_glwidget=true. Set negative to disable-->
<param name="config/preserve_raster_on_save" value="false"/>
<param name="config/min_time_reported" value="0.01"/><!-- for easy runtime analysis -->
<param name="config/start_paused" value="true"/>
<param name="config/batch_processing" value="false"/> <!--store results and close after bagfile has been processed-->
<param name="config/keep_all_nodes" value="false"/> <!-- add nodes with constant motion if no transformation can be found -->
</node>
</launch>
Asked by georgebrindeiro on 2012-11-21 08:22:13 UTC
Comments
I don't understand the meaning of the remap tags outside of nodes. Is that possible? What does it do?
Asked by Felix Endres on 2012-11-21 09:29:43 UTC
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
Asked by georgebrindeiro on 2012-11-21 14:04:29 UTC
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.
Asked by Felix Endres on 2012-11-22 23:06:03 UTC
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.
Asked by Felix Endres on 2012-11-22 23:08:07 UTC
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.
Asked by georgebrindeiro on 2012-11-23 02:44:34 UTC
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?
Asked by georgebrindeiro on 2012-11-26 00:07:58 UTC
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.
Asked by Felix Endres on 2012-11-27 02:28:38 UTC