Rosanswers logo

I am trying to wrap my head around the navigation stack, and how to run it.

My objective is to get my simple, differential-drive robot to navigate using the nav stack. I want to set a simple goal in rviz, and let my robot navigate to that position.

My robot is publishing tf frames: "base_laser" to "base_link", and "base_link" to "odom". It also sends odometry data (I use stepper motors), and laser scan data from a sonar sensor. I have been following the ROS navigation tutorials to get this far.

My robot currently shows this rqt graph shown below:

Nodes only image description

Nodes and topics image description

Right now, it seems that everything is in order, except that I get the tf error "Timed out waiting for transform from base_link to map to become available before running costmap . . . "

isn't the move_base node in charge of publishing the "base_link" to "map" transform?

Screen shot of tf tree: image description

  <master auto="start"/>

  <!-- Run the map server -->
  <node name="map_server" pkg="map_server" type="map_server" args="$(find tf_test)/myTestMap.pgm 0.02"/>

  <!--- Run AMCL -->
  <include file="$(find amcl)/examples/amcl_diff.launch" />

  <node pkg="move_base" type="move_base" respawn="false" name="move_base" output="screen">
    <rosparam file="$(find tf_test)/costmap_common_params.yaml" command="load" ns="global_costmap" />
    <rosparam file="$(find tf_test)/costmap_common_params.yaml" command="load" ns="local_costmap" />
    <rosparam file="$(find tf_test)/local_costmap_params.yaml" command="load" />
    <rosparam file="$(find tf_test)/global_costmap_params.yaml" command="load" />
    <rosparam file="$(find tf_test)/base_local_planner_params.yaml" command="load" />

obstacle_range: 2.5
raytrace_range: 3.0
footprint: [[-0.10, 0.10], [-0.10, -0.10], [0.10, -0.10], [0.10, 0.10]]
#robot_radius: ir_of_robot
inflation_radius: 0.15

observation_sources: laser_scan_sensor

laser_scan_sensor: {sensor_frame: base_laser, data_type: LaserScan, topic: scan, marking: true, clearing: true}

  global_frame: odom
  robot_base_frame: base_link
  update_frequency: 10.0
  publish_frequency: 10.0
  static_map: false
  rolling_window: true
  width: 2.0
  height: 2.0
  resolution: 0.02

  global_frame: /map
  robot_base_frame: base_link
  update_frequency: 0.5
  static_map: true

  max_vel_x: 0.1409946783
  min_vel_x: 0.0007049734
  max_vel_theta: 2.311388169
  min_in_place_vel_theta: 0.01155694

  acc_lim_theta: 2.311388169
  acc_lim_x: 0.1409946783
  acc_lim_y: 0

  holonomic_robot: true


<node pkg="amcl" type="amcl" name="amcl" output="screen">
  <!-- Publish scans from best pose at a max of 10 Hz -->
  <param name="odom_model_type" value="diff"/>
  <param name="odom_alpha5" value="0.1"/>
  <param name="transform_tolerance" value="0.2" />
  <param name="gui_publish_rate" value="10.0"/>
  <param name="laser_max_beams" value="30"/>
  <param name="min_particles" value="500"/>
  <param name="max_particles" value="5000"/>
  <param name="kld_err" value="0.05"/>
  <param name="kld_z" value="0.99"/>
  <param name="odom_alpha1" value="0.2"/>
  <param name="odom_alpha2" value="0.2"/>
  <!-- translation std dev, m -->
  <param name="odom_alpha3" value="0.8"/>
  <param name="odom_alpha4" value="0.2"/>
  <param name="laser_z_hit" value="0.5"/>
  <param name="laser_z_short" value="0.05"/>
  <param name="laser_z_max" value="0.05"/>
  <param name="laser_z_rand" value="0.5"/>
  <param name="laser_sigma_hit" value="0.2"/>
  <param name="laser_lambda_short" value="0.1"/>
  <param name="laser_lambda_short" value="0.1"/>
  <param name="laser_model_type" value="likelihood_field"/>
  <!-- <param name="laser_model_type" value="beam"/> -->
  <param name="laser_likelihood_max_dist" value="2.0"/>
  <param name="update_min_d" value="0.2"/>
  <param name="update_min_a" value="0.5"/>
  <param name="odom_frame_id" value="odom"/>
  <param name="resample_interval" value="1"/>
  <param name="transform_tolerance" value="0.1"/>
  <param name="recovery_alpha_slow" value="0.0"/>
  <param name="recovery_alpha_fast" value="0.0"/>

rostopic list when everything is running:

derek@derek-G74Sx:~$ rostopic list

move_base and amcl errors:

[ WARN] [1502606686.483551591]: Timed out waiting for transform from base_link to map to become available before running costmap, tf error: . canTransform returned after 0.102372 timeout was 0.1.
[ WARN] [1502606687.766040187]: No laser scan received (and thus no pose updates have been published) for 1502606687.765959 seconds.  Verify that data is being published on the /scan topic.
[ WARN] [1502606687.766627339]: MessageFilter [target=odom ]: Dropped 100.00% of messages so far. Please turn the [ros.amcl.message_notifier] rosconsole logger to DEBUG for more information.

Originally posted by Raisintoe on ROS Answers with karma: 51 on 2017-08-11

Post score: 0

Original comments

Comment by jayess on 2017-08-11:
Can you post screenshot of your tf tree?

Comment by billy on 2017-08-11:
Can you include the parameter files the Navigation stack? Please also include information from the terminal that is running the Nav Stack. I'm guessing that AMCL isn't running due to perhaps a slow update of laser scan. How often do you publish a new laser scan?

Comment by Raisintoe on 2017-08-12:
It might be because of a slow laser scan update. I get an output warning, telling me that it hasn't received scan messages, but scan messages are sent about every second. Odom also is only sent while the robot is moving. I have sent cmd_vel messages to my robot to force it to move.

Comment by Raisintoe on 2017-08-12:
[ WARN]: Timed out waiting for transform from base_link to map to become available before running costmap, tf error: . canTransform returned after 0.100641 timeout was 0.1. [ WARN]: No laser scan received (and thus no pose updates have been published) for . . . verify that data is being published...

Comment by Raisintoe on 2017-08-12:
Also, I get: [ WARN] [1502524814.408269556]: MessageFilter [target=odom ]: Dropped 100.00% of messages so far. Please turn the [ros.amcl.message_notifier] rosconsole logger to DEBUG for more information.

Comment by Raisintoe on 2017-08-12:
I get this from roswtf: WARNING The following node subscriptions are unconnected:

  • /amcl:
    • /tf_static
  • /move_base:
    • /tf_static
  • /rviz_1502523805001460332:
    • /tf_static

Comment by gvdhoorn on 2017-08-12:
@Raisintoe: please always just edit your original question if you have new info, want to add screenshots or logging output. The comments are not suited for that.

And please also use the Preformatted Text button (the one with 101010 on it) to format console copy-pastes, or xml or yaml. Thanks.

Comment by Humpelstilzchen on 2017-08-12:
I see no scan message in the rqt-graph, do you have a laser scanner or something simulating (e.g. 3d camera) one?

Comment by billy on 2017-08-12:
I've seen where AMCL/MoveBase will set VEL_CMD to 0,0 if there is a delay(500ms) in laser scan. If this happens and your robot then also stops providing ODOM, you'll have two issues compounded. Can you modify the SW to issue both more frequently, even if you're just re-issuing same data twice.

Comment by Raisintoe on 2017-08-13:
I set up fake scan and odom publishers and tf_broadcasters that published at 10Hz, it didn't change anything.

Comment by Humpelstilzchen on 2017-08-13:
Feeding scans from sonar to amcl defeats its purpose. Because of the high field of view of the sensor I don't think amcl will be able to do anything useful.

Comment by Humpelstilzchen on 2017-08-13:
I recommend to 1. drop the amcl node, 2. Use odom in local and global costmap as global_frame and switch the obstacle layer against the the range layer.

Comment by Raisintoe on 2017-08-13:
I know that the sonar sensor will not work well, I am just using it to learn the ROS system. I have done as you suggested though, and dropped the amcl node . . .etc, and now I only get the error " . . . Dropped 100.00% of messages so far . . ."

Comment by Humpelstilzchen on 2017-08-13:
To learn: Get a simulation running, Turtlebot should do. So you get a working system you can compare yours to. About the error: AMCLs job is to provide the map->odom tf. Without amcl (or e.g. gmapping...) there is no map frame so you use odom as global frame everywhere (rviz, costmap,...)

Comment by Raisintoe on 2017-08-13:
Oooh! Something a little exciting happened, my robot will spin around, trying to locate itself when I set a goal in rviz. This might be all it will ever do with a sonar sensor, huh? I will try the Turtlebot_simulator as you suggest.

Comment by Raisintoe on 2017-08-14:
I am running ROS kinetic, do I need to install an earlier ROS distribution in order to run the turtlesim? I am having trouble installing it as usual. Maybe I am not finding decent instructions on installation.

Comment by jayess on 2017-08-14:
What instructions were you using? The installation instructions in the wiki are pretty comprehensive.


1 Answer 1


Rosanswers logo

Just to make things clear, move_base is "only" in charge of taking all the info it can get to generate a "cmd_vel" topic for the robot to follow. it is the one utilizing the parameter yamls and operating the planners, costmaps, etc.

The amcl node is the one publishing the Tf between /odom and /map, and it is the one giving you the trouble. It will not publish the needed info nor tell you what's missing until you get it all. I've had similar trouble and I can possibly help if you post the amcl launch-file (amcl_diff) content and a rostopic list while everything is running (in addition to the thorough info you've already posted). As a side-note, if you have a differential drive robot, you might want to turn false the "holonomic" part in the local planner, because it cannot move sideways. I also used dwa_local_planner, don't really know whats the difference except for the amount of parameters that need tuning and what I could google.

EDIT: Well, I'm actually not sure now with the extra details. usually its about an inconsistency between some topics and/or link names. I would suggest 2 things:

  1. when all is running, type rostopic echo scan and check that you get incoming data. If not, then the problem is in the publishing.
  2. you seem to be missing parameters, such as:
and perhaps a few more... I'm just not sure what would be the effect in case you haven't added those - I guess some defaults should appear.

Originally posted by StevenCoral with karma: 167 on 2017-08-12

This answer was ACCEPTED on the original site

Post score: 1

Original comments

Comment by Raisintoe on 2017-08-12:
Thanks, I added the information that you asked for. Also, I have wondered if I should be using dwa_local_planner, but am still learning what that is, and how to use it.

Comment by Raisintoe on 2017-08-12:
Upon trying to run dwa_local_planner dwa_planner, it appears that my navigation stack is not fully built. I have had trouble building my nav_stack once installed. Isn't there a straightforward tutorial for installing the nav_stack? I swear I found one once, but I can't find it again.

Comment by billy on 2017-08-12:
Regarding your question about straightforward tutorials, I started here (sections 3 and 6.1) and went through all subpages. It wasn't quick, but it was pretty straightforward. I was learning Ubuntu at the same time so it took a long time. I had many questions though.


Comment by Raisintoe on 2017-08-12:
I have tried following that tutorial, but when it comes to installing the nav stack, I get a boat-load of errors when I try building it from a github clone. Isn't there an alternative way to install the nav stack, and other ros packages? Cloning from github just isn't a happy time for me.

Comment by jayess on 2017-08-13:
How did you install ROS? Did you not do the full desktop install? Also, are you compiling the correct branch for your version of ROS?

Comment by Raisintoe on 2017-08-13:
I did the full ROS kinetic desktop installation. It did not include the nav stack; I installed that later. I don't know if all of the packages where built properly when I ran catkin_make.


Your Answer

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