# how to configure the map to put its origin as in stage

Part 1: Hi, I already posted nearly same question but I ended up with sth new. I am using gmapping (localization and map) to run the navigation by move_base node and I have this famous error :

[ WARN] [1350293255.494001686]: The origin for the sensor at (-0.16, 0.68) is out of map bounds. So, the costmap cannot raytrace for it.


I am running a simple differential robot, gmapping node, laser node, and move_base.

As I found from some discussions, it seems that I didn’t realise that I had to configure the map to put its origin as in stage; so can it be the reason? if yes then the question is that how can I configure that?

Part 2: Thanks for your answers. Now I am putting the global costmap static_map parameter to true. and the local costmap static_map parameter to false. and rolling_window to false as well and I set no map parameter in the yaml files. So it should take all from map_server. In my saved map file, the origin is [-10, -10] for a 20X20 map. but again I am receiving the out of map bound error!

The map is from map server (including map parameters of course). the laser data is going from the laser. the localization from gmapping. it is putting the robot foot print on origin so my laser will be out bound. How can I get rid of it then? Well generally how this map updating should go now? I want to have a implementation like the implementation in the link: http://www.ros.org/wiki/navigation/Tutorials/Using%20rviz%20with%20the%20Navigation%20Stack

I mean to have the general map and also have the online updating of the obstacles (not an updated map though).

edit retag close merge delete

I added a 2nd part to my question.

( 2012-10-18 06:40:32 -0500 )edit

you might want to set the local costmap rolling_window to true (since static_map is false). Then look at RViz to see your map, and show your laser link and see where it is with reference to the map.

( 2012-10-18 16:10:21 -0500 )edit

Sort by » oldest newest most voted

This problem arises from your global costmap parameters. In your other question, you set the global costmap to NOT use static map ("static_map: false"). This means you have to give the costmap some data (height/width/resolution/origin), or it will default to a 10m by 10m costmap with origin at (0,0). This default costmap does not have any negative x, y cells since origin is at (0,0), so if your sensor is placed "behind" the robot centre, you get the "out-of-bounds" message.

Setting the costmap origin to some negative value would solve this problem (as mentioned in the other post). Usually this value is set such that your robot is in the centre of the costmap (so if using default 10m by 10m map, origin would be at -5,-5)

The other way is to set global costmap "static_map: true". This means you will need a map obtained from the map server. In this case, since you are using gmapping, the global costmap will take the initial map created when gmapping starts. You will not need to set any costmap data (height/width etc) and you should not get any out-of-bound message. However, this means you will not be able to set a goal beyond the size of the initial map obtained (but that's a problem in the path planner).

EDIT 19 Oct 2012:

These are good places to look when there are navigation problems:

more

Hi there,

I met the same problem today, and I solved this problem.

1. Open global_costmap_params.yaml

rolling_window: true

Example in my global_costmap_params.yaml:

global_costmap: global_frame: /map robot_base_frame: /base_footprint
update_frequency: 1.0
publish_frequency: 0.5 static_map: true transform_tolerance: 0.5
rolling_window: true plugins: - {name: static_layer, type: "costmap_2d::StaticLayer"} - {name: obstacle_layer, type: "costmap_2d::VoxelLayer"} - {name: inflation_layer, type: "costmap_2d::InflationLayer"}

I hope this way also effective in your project!

more

According to the move_base configuration in your previous question, the map generated by gmapping should not be used at all by move_base (the static_map parameter is false for both maps). I don't really think that gmapping or the position of a map has anything to do with the above error.

more