Rosanswers logo

Dear fellow ROS-Devs,

I have recently upgraded from Groovy to Hydro. My launch config, which uses the move_base package, worked fine under Groovy but fails under Hydro.

Under Groovy, move_base used to publish a correct local costmap as 'nav_msgs/GridCells' on the topics:


Under Hydro, move_base now publishes the local maps as message type 'nav_msgs/OccupancyGrid' on the topic:


(as described here). I have experimented with adding the 'plugins' parameter to the move_base config files, but I get the same result as without it ('Loading from pre-hydro parameter style').

In rviz, I can add a map and choose '/move_base/local_costmap/costmap' as topic, and all status indicators show green. However, no map is shown. If I do the same for '/move_base/global_costmap/costmap', I can see the global costmap that resembles the one served by mapserver.

When debugging on the command line, 'rostopic list' shows all topics as expected. But 'rostopic echo /move_base/local_costmap/costmap' only shows an empty map:

ros@Base:~$ rostopic echo /move_base/local_costmap/costmap
  seq: 0
    secs: 1381741501
    nsecs: 967703624
  frame_id: map
    secs: 0
    nsecs: 0
  resolution: 0.0500000007451
  width: 119
  height: 119
      x: -2.95
      y: -2.95
      z: 0.0
      x: 0.0
      y: 0.0
      z: 0.0
      w: 1.0
data: [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, ... 0 ]

Note: Data abbreviated here, but there are only 0's in the data field.

Any ideas why I cannot see obstacles in the local costmap any more?

Update 1

As requested by David, here is the output of 'rosparam get /move_base/local_costmap':

ros@Base:~$ rosparam get  /move_base/local_costmap
footprint: '[[-0.4,-0.2],[0.4,-0.2],[0.4,0.2],[-0.4,0.2]]'
footprint_layer: {enabled: true}
footprint_padding: 0.01
global_frame: /odom_combined
height: 6
inflation_layer: {cost_scaling_factor: 10.0, enabled: true, inflation_radius: 0.5,
  robot_radius: 0.46}
laser_scan_sensor: {clearing: true, data_type: LaserScan, marking: true, sensor_frame: /base_laser,
  topic: /scan}
obstacle_layer: {enabled: true, max_obstacle_height: 2.0, obstacle_range: 2.5, raytrace_range: 3.0}
obstacle_layer_footprint: {enabled: true}
obstacles: {observation_sources: laser_scan_sensor}
origin_x: 0.0
origin_y: 0.0
- {name: obstacle_layer, type: 'costmap_2d::ObstacleLayer'}
- {name: footprint_layer, type: 'costmap_2d::FootprintLayer'}
- {name: inflation_layer, type: 'costmap_2d::InflationLayer'}
publish_frequency: 2.0
publish_voxel_map: false
resolution: 0.05
robot_base_frame: /base_frame
robot_radius: 0.46
rolling_window: true
static_map: false
transform_tolerance: 1.0
update_frequency: 5.0
width: 6

Note: This is without specifing any plugins for costmap_2d layers, hence using pre-hydro parameter style.

Originally posted by Huibuh on ROS Answers with karma: 399 on 2013-10-14

Post score: 1

Original comments

Comment by David Lu on 2013-10-14:
Can you please post the output of rosparam get /move_base/local_costmap

Comment by Huibuh on 2013-10-15:
@David: Please see my updated post above

Comment by David Lu on 2013-10-15:
Two possibly dumb questions: 1) Are you using RViz from Hydro? 2) Do you have obstacles from your laser within 2.5 m of your robot?

Comment by Huibuh on 2013-10-15:
Here are my answers:

  1. Yes, I used RViz from Hydro
  2. There are plenty obstacles <2.5m around the robot, I can see them as dots in the RViz laser scan visualization

Comment by David Lu on 2013-10-15:
If you rostopic echo /move_base/local_costmap/costmap_updates, are there any non-zero values? I'm trying to tell if your costmap isn't being updated properly, or something is wrong with the visualization side of things.


1 Answer 1


Rosanswers logo

After more debugging I found out why move_base stoped publishing costmaps: During the migration to Hydro I tried to configure plugins for layered costmaps myself. Because I was having trouble with the name space of the laser scan sensor, I added the "obstales" namespace specifier in the "common_costmap_params.yaml" file:

  observation_sources: laser_scan_sensor

When I later removed the "plugins" from the local and global costmap configuration (going back to pre-hydro compatibility mode) I forgot to remove the "obstacles:" namespace specification. D'oh!

Originally posted by Huibuh with karma: 399 on 2013-10-16

This answer was ACCEPTED on the original site

Post score: 1

Original comments

Comment by David Lu on 2013-10-16:
Ah, that's annoying. My apologies for not reading the parameters more carefully.


Your Answer

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