Replacing gmapping with rgbdslam

I am experimenting with replacing gmapping with rgbdslam on a turtlebot-like robot. Gmapping provides localization data through map->odom transform, and the mapping data through the published topic map.

How should I get these 2 pieces of information with rgbdslam?

I am trying this:

roslaunch rgbdslam rgbdslam_headless.launch
roslaunch rgbdslam octomap_server.launch
rosservice call /rgbdslam/ros_ui_b pause false
rosservice call /rgbdslam/ros_ui send_all


Every time I need an updated map, I call the send_all service, but this also gives the tf for each of the pointcloud, resulting in multiple map->odom transform being broadcast.

<param name="config/fixed_frame_name"              value="/map"/>
<param name="config/ground_truth_frame_name"       value=""/><!--empty string if no ground truth-->
<param name="config/base_frame_name"               value="/odom"/> <!-- /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)-->


The param "base_frame_name" ought to be something like "base_link", but this will not work (frames can only have one parent) since I have robot_pose_ekf broadcasting odom->base_footprint and robot_state_publisher broadcasting base_footprint->base_link

Also, I had to change line 1306 in graph_manager.cpp to broadcast fixed_frame->[base_frame_name] instead of the current "/openni_camera". I'm still not sure what the "where_mocap_should_be" means.

Am I on the right track? Or is there something already available to produce "map->odom" and publish "map" at regular intervals?

I see a void GraphManager::broadcastTransform(const ros::TimerEvent& ) function commented out. Should I be using this to get localization info instead? How then can I get the map published?

edit retag close merge delete

Sort by » oldest newest most voted

Hi weiin. Good thinking there. I am currently a little swamped and removed from the rgbdslam code, but here are my quick thoughts:

• When setting the base_frame_name to /odom you need to unset fixed_camera, because the transformation between odom and openni_rgb_optical_frame is not static.
• Letting the octomap server periodically listen to the model sent from RGBDSLAM is probably not a good idea, as you need to store the clouds and therefore need huge amounts of memory. Also the timestamps of the transforms match the point clouds, but not the odom transforms. I am not sure whether this works, but in principle you should be able to let the octomap server listen to the camera driver and have RGBDSLAM send out the transformation online. I have the latter working on my machine, but I am not sure if it is upstream already. Maybe for performance reasons you need to use "throttle" from pkg "topic_tools" on the point cloud topic and have rgbdslam and the octomap server listen to that.
• The commented out broadcast is probably what you need. As mentioned I fixed this, and I could make the current state available, but I am not sure about the overall stability of my current code base as many things have been added and some testing would be necessary to find out if that broke existing functionality
more