0
$\begingroup$

Rosanswers logo

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 http://i66.tinypic.com/2ela93l.png

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.

Map:

image description http://i68.tinypic.com/20jsd4l.png

Costmap:

image description http://i68.tinypic.com/2gvtt75.png

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

My tf-tree: https://drive.google.com/open?id=0B8AXM-B3TVZ_MUF6TEtkdjhFblk

The laser-scan and costmaps seem OK:

image description http://i65.tinypic.com/1zez9z4.png

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.

https://drive.google.com/open?id=0B8AXM-B3TVZ_cGFXRktia0JqYU0

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.

https://drive.google.com/open?id=0B8AXM-B3TVZ_ZW9JUl9VZnVqMDg

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.

https://drive.google.com/open?id=0B8AXM-B3TVZ_NU9BcUo5c2RCa2M

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> 

      <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)"/>
      </include>


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

      <!-- 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"/>
      </node> 

<!-- 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" />
</node>

<!-- 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/mapper.yaml"/>
</node>

<!-- Start the Navigator to move the robot autonomously -->
<node name="Navigator" pkg="nav2d_navigator" type="navigator">
    <rosparam file="$(find nav2d_tutorials)/param/navigator.yaml"/>
</node>

<node name="GetMap" pkg="nav2d_navigator" type="get_map_client" />
<node name="Explore" pkg="nav2d_navigator" type="explore_client" />
<node name="SetGoal" pkg="nav2d_navigator" type="set_goal_client" />


<!-- RVIZ to view the visualization -->
<node name="RVIZ" pkg="rviz" type="rviz" args=" -d $(find nav2d_tutorials)/param/tutorial3.rviz" />

Can you see what's wrong?

Thank you all!


Originally posted by Gonzalo Hernández R on ROS Answers with karma: 3 on 2016-01-18

Post score: 0


Original comments

Comment by zzzZuo on 2016-05-09:
Has your problem solved? I also have a similar problems that I couldn't receive a map after it roslaunch.

Comment by Gonzalo Hernández R on 2016-05-27:
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.

$\endgroup$

1 Answer 1

0
$\begingroup$

Rosanswers logo

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".

Update:

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?


Originally posted by Sebastian Kasperski with karma: 1658 on 2016-01-18

This answer was ACCEPTED on the original site

Post score: 1


Original comments

Comment by Gonzalo Hernández R on 2016-01-18:
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.

Comment by Sebastian Kasperski on 2016-01-19:
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?

Comment by Sebastian Kasperski on 2016-01-19:
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.

Comment by Gonzalo Hernández R on 2016-01-19:
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).

Comment by Gonzalo Hernández R on 2016-01-19:
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.

Comment by Sebastian Kasperski on 2016-01-20:
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.

Comment by Gonzalo Hernández R on 2016-01-20:
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

Comment by Sebastian Kasperski on 2016-01-20:
Changes at the code should not be necessary. All frame names are set in "ros.yaml". What changes do you need to do?

Comment by Gonzalo Hernández R on 2016-01-21:
I don't have a problem with the name of the frames since I have the same names in the tf-tree and my robot. It seems to be a problem in the conections between the frames and I don't know how to change that configuration. I've updated the original questions with a few videos so you can see it.

Comment by Gonzalo Hernández R on 2016-01-21:
Thank you so much, it was that. The problem is that the laser was upside down in the Gazebo simulation, check that if you have the same problem. Now I have other issues but I won't bother you anymore (for the moment =D).

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.