Rosanswers logo


I'm running a Turtlebot 2 on ROS Groovy, Ubuntu 12.04.

I have a robot where I'm running the Gmapping demo, and I've been trying to observe the local costmap belonging to move_base. I have read that for local costmaps with rolling_window = true, that the robot should always be centered in the costmap. However, my observations so far indicate to me that this may not always be the case.

What I have been doing is starting gmapping_demo.launch and then starting my own node that basically does this:

  1. Move forward a meter, then stop.

  2. Subscribe to move_base/local_costmap/obstacles long enough to get a single callback, then unsubscribe.

  3. Check the observed obstacles. If moving a meter forward in a straight line would interfere with any of them, then stop. Otherwise, repeat from Step 1.

In Step 3, the program assumes that the robot is always 0,0 (centered) with reference to the local rolling costmap. So essentially it checks all points on a straight line from 0,0 to 1,0 (a meter forward) against all obstacle cells.

(I know that move_base can do advanced obstacle navigation without my help, but I very much want this simplistic straight-line behavior for my application.)

If I start up my program with the robot facing a wall within a meter's distance, it correctly reports that the wall would interfere with moving forward. But if I have a wall that's a few meters away, it will take the first few meter steps and fail to recognize the wall as being in the way.

I think what is happening is that the robot is not centered in the costmap in the distance it takes from the starting point of the application to the maximum local costmap size, i.e, the point at which the costmap window starts actually rolling.

I can confirm this by starting gmapping with the robot facing a wall, doing a rostopic echo -n 1 on the obstacles, moving forward a few feet, and doing another rostopic echo -n 1. If I compare the two echos, they are the same, which means the robot position in the costmap must not be 0,0 during the second echo.

As far as I know, there is no way to get the robot position inside the local costmap without initializing my own local costmap in my application and calling the GetRobotPose() member function. Or maybe looking up the odom->base_link transform (I'm not sure about this one -- not very experienced).

Am I right in thinking the robot is not centered in the costmap during the start of the run only? Am I doing something wrong or poor practice? Any input is appreciated. Thanks!

Here's my local_costmap_params.yaml, if that helps:

  map_type: voxel
  global_frame: /odom
  robot_base_frame: /base_footprint
  update_frequency: 5.0
  publish_frequency: 5.0
  static_map: false
  rolling_window: true
  width: 4.0
  height: 4.0
  resolution: 0.1
  transform_tolerance: 0.5

Originally posted by BlitherPants on ROS Answers with karma: 504 on 2014-03-03

Post score: 1

Original comments

Comment by ahendrix on 2014-03-03:
I don't see anything obviously wrong, but it may be worth visualizing the robot pose and the local costmap in rviz.

Comment by BlitherPants on 2014-03-03:
I've already done that. Everything looks lined up OK, it's just that the robot doesn't seem to be at point 0,0 with reference to the local costmap. If there were a way to get the robot's coordinates with respect to the local costmap that'd be great...


1 Answer 1


Rosanswers logo

After having looked at it for a while, I came to the conclusion that yes, the robot is more or less centered in the costmap, but I believe the obstacles are being published with reference to the global frame, which explains why they do not move when my robot does. I eventually settled on upgrading my ROS to Hydro. Then, I subscribe to local_costmap/costmap, which gives me the costmap origin and resolution.

Originally posted by BlitherPants with karma: 504 on 2014-03-12

This answer was ACCEPTED on the original site

Post score: 0


Your Answer

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