# Using robot_pose_ekf and RGBDslam for path planning with Octomaps

I wanted to use Robot_pose_ekf and RGB-D slam for path planning with Octomaps. I have tried to integrate the robot_pose_ekf with the rgbdslam package. I have added the following to the launch file.

  <node pkg="rgbdslam" type="rgbdslam" name="rgbdslam" cwd="node" required="true" output="screen">
<param name="config/fixed_frame_name"      value="/map"/>
<param name="config/base_frame_name"       value="/odom_combined"/>
<param name="config/fixed_camera"          value="false"/>
</node>
<node pkg="robot_pose_ekf" type="robot_pose_ekf" name="robot_pose_ekf">
<param name="output_frame" value="/odom_combined"/>
<param name="freq" value="300.0"/>
<param name="sensor_timeout" value="1.0"/>
<param name="odom_used" value="false"/>
<param name="imu_used" value="true"/>
<param name="vo_used" value="true"/>
<remap from="imu_data" to="Imu" />
</node>


The above launch file gives out the following tf tree

Also the output of the rgbdslam node at the console is

[ WARN] [1360005388.569379127, 1359982581.866228234]: Frame id /odom does not exist! Frames (10): Frame /camera_link exists with parent /base_footprint.
Frame /base_footprint exists with parent /odom_combined.
Frame /camera_rgb_optical_frame exists with parent /camera_rgb_frame.
Frame /camera_rgb_frame exists with parent /camera_link.
Frame /camera_depth_optical_frame exists with parent /camera_depth_frame.
Frame /camera_depth_frame exists with parent /camera_link.
Frame /odom_combined exists with parent /map.
Frame /map exists with parent /odom_combined.
Frame /where_mocap_should_be exists with parent /map.
- No odometry available


How should I correct this problem ?

Further whenever I send the model to the octomap server only then the /tf between /map to /odom_combined is available. How can I make it online so that i dont have to use the service provided by the rgbdslam resulting in a fixed publishing rate of the /tf. ?? This should also be realtime in the sense that it should not slow down as the time passes. Any suggestions on what could be a solution to this particular problem?

--------------Edit--------------

I just checked the configuration of the RGBdslam in the gui where all the params were set. I saw there were 3 frames which we could specify.

1. Base frame

2. Fixed frame

3. Odom frame.

Could I initialize these frames with /base_footprint , /map and /odom_combined respectively to get a consistent tf tree and a good map estimated from the input images..?

edit retag close merge delete

1

I think your problem might be that you have the "odom_combined" frame instead of "odom", which is a result of robot_pose_ekf. Can you change its frame to "odom"?

( 2013-02-04 21:26:39 -0600 )edit

Sort by » oldest newest most voted

Hi Karan, this is not a way to incorporate odometry into rgbdslam. This way, you may get a transformation between odom_combined and the map, but the transformation from odometry will just be "subtracted" from the found transformation.

The bad news is, that rgbdslam currently doesn't really support odometry (there are only some experimental hacks). I think someone has merged the output from rgbdslam and odometry in a filter, but I don't know with what success, though.

Edit: Rgbdslam now repeatedly sends the latest tf transform between the frames given in parameters base_frame_name and fixed_frame_name at 10 Hz.

more

I tried the approach that A Hornung suggested, which is setting the frame to be /odom. This solved the problem of No odometry found. But now as you said this is not the way. What can i do to add odometry to slam?The /tf published would be between the current pose and the starting positon of Kinect.?

( 2013-02-05 01:11:22 -0600 )edit

So somehow if I add odometry to rgbdslam would it help the localization procedure of the rgbdslam or the adding of new node in the existing graph of the map built..?? What i mean to say that could it help in any way ie. speed up things a little bit??

( 2013-02-05 01:18:30 -0600 )edit

There are several ways one could use odometry. My guess is, that it is not as important as for laser based systems, since feature matches are (comparatively) unambiguous, which reduces the small errors due to misassociations. This is only a guess, if you wish, we can discuss this by email.

( 2013-02-06 03:17:52 -0600 )edit

I have left a mail at the email id given at your site. Thanks for the help..

( 2013-02-06 04:57:37 -0600 )edit

Hi @Karan wore you able to get robot_pose_ekf working with rgbdslam /tf? Can you please tell me how? Thanks!

( 2014-07-07 11:11:38 -0600 )edit