# local costmap empty using move_base_node

Hi,

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.

EDIT 1:

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.

EDIT 2:

If I change

local_costmap:
observation_sources: base_scan
base_scan: {
topic: /car_0/base_scan
...


for

local_costmap:
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.

EDIT 3:

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.

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 http://www.ros.org/wiki/costmap_2d

#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]]

#Cost function parameters
# included in both global and local costmaps params
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 http://www.ros.org/wiki/costmap_2d

global_costmap:
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 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?

( 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]]'

( 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).

( 2014-01-17 14:01:58 -0500 )edit

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

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

( 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

( 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?

( 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 https://www.github.com/gustavovelascoh/vintersim and https://www.github.com/gustavovelascoh/vinter_sim

( 2014-02-12 06:25:23 -0500 )edit

Sort by » oldest newest most voted

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

more

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

( 2016-01-27 08:52:58 -0500 )edit