Ask Your Question

local costmap empty using move_base_node

asked 2014-01-17 06:34:41 -0500

updated 2014-02-12 04:00:49 -0500


I'm using move_base_node in stage, and I've found that local costmap is empty. In this picture from rviz I can see that global costmap is fine but local costmap (the small square) is empty. The red dots are the laser scans from robot (green footprint) with which the local costmap should be generated. Is something wrong with this? Because although of this I can set goals and the robot can reach them.


Although the robot can reach the goals, it does it at a very low speed, even if I increase the value of max_vel_x parameter of local_planner. I don't know if this happens due to the lack of local_costmap.


If I change

      observation_sources: base_scan
      base_scan: {
        topic: /car_0/base_scan


          observation_sources: base_scan
          base_scan: {
            topic: /base_0/base_scan

where /base_0/base_scan is another LaserScan topic, some black areas start to appear in local_costmap until origin of sensor its outside it.


This is my TF tree; base_* are "robots" on each corner of the intersection; I say "robots" because I use them as static lasers. And car_* are robots navigating as vehicles, in this case car_0 is the green polygon.

image description

Here are the parameters I use:

costmap_common file:

#This file contains common configuration options for the two costmaps used in the navigation stack for more details on the parameters in this file, and a full list of the parameters used by the costmaps, please see

#For this example we'll configure the costmap in voxel-grid mode
map_type: voxel

#Voxel grid specific parameters
origin_z: 0.0
z_resolution: 0.2
z_voxels: 10
unknown_threshold: 9
mark_threshold: 0

#Set the tolerance we're willing to have for tf transforms
transform_tolerance: 0.3

#Obstacle marking parameters
obstacle_range: 2.5
max_obstacle_height: 2.0
raytrace_range: 3.0

#The footprint of the robot and associated padding
# included in both global and local costmaps params
#footprint: [[-0.25, -0.25], [-0.25, 0.25], [0.25, 0.25], [0.3, 0.0], [0.25, -0.25]]
footprint: [[-0.25, -0.25], [-0.25, 0.25], [0.25, 0.25], [0.3, 0.0], [0.25, -0.25]]
footprint_padding: 0.05

#Cost function parameters
# included in both global and local costmaps params
inflation_radius: 0.35
cost_scaling_factor: 10.0

#The cost at which a cell is considered an obstacle when a map is read from the map_server
lethal_cost_threshold: 100

#Configuration for the sensors that the costmap will use to update a map
# included in both global and local costmaps params
#observation_sources: base_scan
#base_scan: {data_type: LaserScan, expected_update_rate: 0.4,
#  observation_persistence: 0.0, marking: true, clearing: true, max_obstacle_height: 0.4, min_obstacle_height: 0.08}

global_costmap file:

#Independent settings for the global planner's costmap. Detailed descriptions of these parameters can be found at

  observation_sources: "base_0 base_1 base_2 base_3"
  base_0: {
    topic: /base_0/base_scan,
    data_type: LaserScan, 
    expected_update_rate: 0.4,
    observation_persistence: 0.0, 
    marking: true, 
    clearing: true, 
    max_obstacle_height: 0.4, 
    min_obstacle_height: 0.08

  base_1: {
    topic ...
edit retag flag offensive close merge delete


What is the output of move_base? Any errors? Also, I'm not sure what the defined behavior is when you don't have a footprint defined (it's commented out in your file). Is it possible that your robot has no footprint, hence it can go anywhere?

Tim Sweet gravatar imageTim Sweet ( 2014-01-17 11:23:51 -0500 )edit

Hi @Tim-sweet, parameter in costmap_common file are common to global and local costmaps, there is the footprint: 'footprint: [[-0.25, -0.25], [-0.25, 0.25], [0.25, 0.25], [0.3, 0.0], [0.25, -0.25]]'

gustavo.velascoh gravatar imagegustavo.velascoh ( 2014-01-17 13:01:17 -0500 )edit

Oh I missed that, my bad. Does move_base produce any errors? It might be helpful to set the logger level to debug (you can do that in rqt_console).

Tim Sweet gravatar imageTim Sweet ( 2014-01-17 14:01:58 -0500 )edit

move_base doesn't produce errors, just warnings about control rate.

gustavo.velascoh gravatar imagegustavo.velascoh ( 2014-01-30 07:54:32 -0500 )edit

What does your TF tree look like? Also are the /base_*/base_scan lasers not on the robot? I'm confused to your setup.

David Lu gravatar imageDavid Lu ( 2014-02-11 10:50:00 -0500 )edit

HI @David_lu, I updated my question with a link to my TF tree and a brief explanation about my setup. Thanks

gustavo.velascoh gravatar imagegustavo.velascoh ( 2014-02-12 04:04:38 -0500 )edit

When you run the non-working configuration, rostopic info /car_0/base_scan show the proper connections?

David Lu gravatar imageDavid Lu ( 2014-02-12 05:30:50 -0500 )edit

Yes, /car_0/base_scan is connected to /car_0/move_base_node. If you need to test the code is on and

gustavo.velascoh gravatar imagegustavo.velascoh ( 2014-02-12 06:25:23 -0500 )edit

1 Answer

Sort by ยป oldest newest most voted

answered 2014-10-02 08:37:51 -0500

Mani gravatar image

I faced a similar issue in a much simpler setup. I found out ObstacleLayer of Costmap2D will not put any obstacles from a sensor in the costmap, if there is negative z-offset between the sensor_frame plane and map plane (assuming a planar lidar as sensor). I could get around this by setting a negative value for min_obstacle_height (less than the z offset between two planes).

edit flag offensive delete link more


You saved me! Ran into similar problems and it was exactly this negative z-offset! Thx

Karsten gravatar imageKarsten ( 2016-01-27 08:52:58 -0500 )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



Asked: 2014-01-17 06:34:41 -0500

Seen: 3,223 times

Last updated: Oct 02 '14