Ask Your Question

Nav2d with Turtlebot failing to create map

asked 2016-01-18 04:42:32 -0600

Gonzalo Hernández R gravatar image

updated 2016-01-21 03:50:34 -0600

Hello everyone!

Im trying to use nav2d package with turtlebot and hokuyo laser to map an unknown room. I think I've all well conected, as you can see on my rqt_graph:

image description

I can use the /StartMapping service but it seems to fail at this point. These are the /map and the /Operator/local_map/costmap in RVIZ.


image description


image description

Obviously, Exploration doesn't work well with these maps.

My tf-tree:

The laser-scan and costmaps seem OK:

image description

Some videos of the problem:

This is a video of the first Tutorial1 (Nav2d). I'm showing you odom and the base_footprint frames. As you can see, all the conections between the frames seem OK.

The next two videos are from Tutorial3 (Nav2d). The point of view is from map in the RVIZ, as you can see this frame is upside down, I don't know why. It seems to be an issue at this point, since odom and offset frame make aparently random jumps.

The last one is from the perspective of base_link of the robot. I show you both, the map and the costmap. The map frame seems to maintain the reference with the map.

I hope these videos help you to understand the problem.

This is my launch file:


<!-- Some general parameters -->
<param name="use_sim_time" value="true" />
<rosparam file="$(find nav2d_tutorials)/param/ros.yaml"/>
     <arg name="world_file"  default="$(env TURTLEBOT_GAZEBO_WORLD_FILE)"/>
 <arg name="base"      value="$(optenv TURTLEBOT_BASE kobuki)"/>  <!--create, roomba -->
     <arg name="battery"   value="$(optenv TURTLEBOT_BATTERY /proc/acpi/battery/BAT0)"/>   <!--/proc/acpi/battery/BAT0 --> 
      <arg name="gui" default="true"/> 
      <arg name="stacks"    value="$(optenv TURTLEBOT_STACKS hexagons)"/>  <!-- circles, hexagons --> 
      <arg name="3d_sensor" value="$(optenv TURTLEBOT_3D_SENSOR kinect)"/>  <!-- kinect, asus_xtion_pro --> 

      <include file="$(find gazebo_ros)/launch/empty_world.launch">
      <arg name="use_sim_time" value="true"/>
      <arg name="debug" value="false"/>
      <arg name="gui" value="$(arg gui)" />
      <arg name="world_name" value="$(arg world_file)"/>

      <include file="$(find turtlebot_gazebo)/launch/includes/$(arg base).launch.xml">
      <arg name="base" value="$(arg base)"/>
      <arg name="stacks" value="$(arg stacks)"/>
      <arg name="3d_sensor" value="$(arg 3d_sensor)"/>

     <node pkg="robot_state_publisher" type="robot_state_publisher" name="robot_state_publisher">
           <param name="publish_frequency" type="double" value="30.0" />

      <!-- Fake laser -->

      <node pkg="nodelet" type="nodelet" name="laserscan_nodelet_manager" args="manager"/>
      <node pkg="nodelet" type="nodelet" name="depthimage_to_laserscan"
               args="load depthimage_to_laserscan/DepthImageToLaserScanNodelet laserscan_nodelet_manager">
      <param name="scan_height" value="10"/>
      <param name="output_frame_id" value="/camera_depth_frame"/>
      <param name="range_min" value="0.45"/>
      <remap from="image" to="/camera/depth/image_raw"/>
      <remap from="scan" to="/kinect_scan"/>

<!-- Start the Operator to control the simulated robot -->
<node name="Operator" pkg="nav2d_operator" type="operator" >
    <remap from="scan" to="base_scan"/>
    <remap from="cmd_vel" to="cmd_vel_mux/input/teleop" />
    <rosparam file="$(find nav2d_tutorials)/param/operator.yaml"/>
    <rosparam file="$(find nav2d_tutorials)/param/costmap.yaml" ns="local_map" />

<!-- Start Mapper to genreate map from laser scans -->
<node name="Mapper" pkg="nav2d_karto" type="mapper">
    <remap from="scan" to="base_scan"/>
    <rosparam file="$(find nav2d_tutorials)/param ...
edit retag flag offensive close merge delete


Has your problem solved? I also have a similar problems that I couldn't receive a map after it roslaunch.

zzzZuo gravatar image zzzZuo  ( 2016-05-09 03:04:18 -0600 )edit

Yes, the problem was with the hokuyo description in the urdf. The hokuyo in gazebo was upside down but the base_laser_link frame was not, so the mapper didn't know how to manage that measures.

Gonzalo Hernández R gravatar image Gonzalo Hernández R  ( 2016-05-27 03:00:06 -0600 )edit

1 Answer

Sort by » oldest newest most voted

answered 2016-01-18 06:22:36 -0600

Sebastian Kasperski gravatar image

updated 2016-01-21 04:13:35 -0600

Are you running a real robot or simulation? Your scans seem to come from gazebo, but "cmd_vel" doesn't seem to go into gazebo.

Your global map looks somewhat distorted like from some error in the transformation tree. You should check the tf-tree with "rosrun tf view_frames".


An inverted scan-frame would explain the weird behavior when the robot is turning. In your video 2 it also looks like the scan is under the map, can you verify this? Can you check which coordinate frame the laser-scan is defined in (likely it is base_laser_link) and visualize this in RVIZ?

And have you checked the ROS-Console (rqt_console) if any warnings or errors show up there?

edit flag offensive delete link more


Im working in Gazebo for the moment. cmd_vel go into Gazebo since the Operator is able to move the robot. What should I look for in the tf-tree? I've checked it before to see if "laser_frame", "robot_frame" and "odom_frame" were OK, and they seem so. Tf-tree in the question. Thanks for your answer.

Gonzalo Hernández R gravatar image Gonzalo Hernández R  ( 2016-01-18 13:03:28 -0600 )edit

In the tf-tree, check that no transforms are outdated compared to the rest. You can also view the transformations in RVIZ, to see if anything weird happens (e.g. jumping transforms). Is the local costmap ok, or is it also corrupted, when the robot moves?

Sebastian Kasperski gravatar image Sebastian Kasperski  ( 2016-01-19 03:14:04 -0600 )edit

And I don't see the laser-scan in the images. although it seems to be selected in RVIZ. Check if there is some problem too.

Sebastian Kasperski gravatar image Sebastian Kasperski  ( 2016-01-19 03:17:12 -0600 )edit

I've checked the transforms and the only one with a different time is the odometry one. Actually, Gazebo publish in the topic odom but no one is subscribed.

I've updated the question with an image so you can see that the laser is received and the costmap is not corrupt (at least i think).

Gonzalo Hernández R gravatar image Gonzalo Hernández R  ( 2016-01-19 04:14:38 -0600 )edit

Ok Sebastian, I've checked the tfs in RVIZ, especifically: base_laser_link, odom, base_footprint, offset and map. All work fine except for map, which jump when the robot spins. That's why the map is not created right, Isn't it?

Thanks in advance.

Gonzalo Hernández R gravatar image Gonzalo Hernández R  ( 2016-01-19 05:09:01 -0600 )edit

Yes, it pretty much looks like it. But it's difficult to figure it out just from the pictures. Maybe try to check the map right after start, without moving the robot. Does it look okay with only one scan in the map? Then you have to figure out, where these jumps come from.

Sebastian Kasperski gravatar image Sebastian Kasperski  ( 2016-01-20 03:32:52 -0600 )edit

Thanks for yout time one more time. I launched the tutorial1 with Turtlebot and Gazebo and the TFs looks fine in RVIZ. The problem comes with tutorial3 and the configuration of the TFs that mapper does. Should I change the mapper.cpp to fix this? Otherwise I dont know how to change tf configuration

Gonzalo Hernández R gravatar image Gonzalo Hernández R  ( 2016-01-20 05:31:15 -0600 )edit

Changes at the code should not be necessary. All frame names are set in "ros.yaml". What changes do you need to do?

Sebastian Kasperski gravatar image Sebastian Kasperski  ( 2016-01-20 06:41:01 -0600 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower


Asked: 2016-01-18 04:42:32 -0600

Seen: 3,143 times

Last updated: Jan 21 '16