# Local costmap has large drift, why?

I want to test out an exploration node and want to avoid errors in mapping and localization. Therefore I have replaced gmapping by the fake_localization node and a modified version of the map_server node. In the map_server I publish only the parts of the map where the robot has been. This computation is based on the localization of the fake_localization node and implements ray tracing to emulate a laser scanner.

EDIT: I did not experience the drift of the local map with gmapping!

Now I'm experiencing a large drift in the local costmap (see images). The first image was taken right after the start, the second just a minute later. Any Ideas what could be wrong here?

The costmap setup is as follows:

Common costmap parameters:

transform_tolerance: 10
obstacle_range: 2.5
raytrace_range: 4.0
footprint: [[-0.4, -0.4], [-0.4, 0.4], [0.4, 0.4],[0.4, -0.4]]
track_unknown_space: true


Global costmap parameters:

global_costmap:
update_frequency: 5
publish_frequency: 0
static_map: true
rolling_window: false
width: 150.0
height: 150.0


Local costmap parameters:

local_costmap:
update_frequency: 1
publish_frequency: 0
static_map: false
rolling_window: true
width: 8.0
height: 8.0
global_frame: /map


The TF transforms in RVIZ look completely wrong, maybe its just a displaying issue. It is static all the time, not moving together with the robot. At the lower end of the transform axis there is map and odom, on the upper end there is base_link, base_laser_link and base_footprint.

The frames look like this:

UPDATE: Using roswtf I figured out that the message types of the robot footprint publisher and subscriber in the costmap did not match. I fixed this in the costmap_2d_ros.cpp in the costmap_2d node. Luckily the tf transforms are now correctly displayed in rviz but I get strange errors now. All the frontier points are now way off and I don't know why.

edit retag close merge delete

Connecting the costmap with itself over the footprint topic was just wrong. Thats why it messed up so much.

( 2015-08-24 08:12:37 -0500 )edit

Sort by » oldest newest most voted

It was just a problem with the map_server/resolution parameter. It did not match the resolution of the stage simulator. So basically I had to change the size in the world file for stage so it matches the resolution of the map server (I guess the other way around it would have also been possible). Thanks for the help anyways!

EDIT: In the stage world file you specify the underlying bitmap like this:

floorplan
(
name "my_bitmap"
bitmap "my_bitmap.png"
size [100.0 200.0 0.4]
pose [ 0 0.0 0 0.0 ]
)


where the size is given in meters (e.g. width 100 m, height 200 m). The corresponding bitmap file should have a number of pixels that results in a resolution you specify in the map server.

For example, if your bitmap is 2000 pixel wide and 4000 pixel high, the resolution parameter of the map server must be 0.05 (i.e. 1 m = 20 px).

more

How did you fix this please?

I have the same issue

( 2020-06-06 13:07:07 -0500 )edit

@femitof: Se my updated answer.

( 2020-06-07 07:46:32 -0500 )edit

Thanks for your response @aau Not sure I totally understand..

Are you saying that the local cost map and the static map Should have the same resolution? If yes, mine already has the same resolution.. Looking forward to your response..

( 2020-06-12 22:05:46 -0500 )edit

This looks very much like your local costmap uses the odometry origin as global frame. To keep local costmap and global map aligned, you should set your map frame as the costmap's global_frame.

more

I tried that, see the parameter settings that I added to my question.

( 2015-08-21 03:11:52 -0500 )edit

It might help to visualize the TF-transforms in RVIZ. Maybe your localizer is drifting away?

( 2015-08-21 04:46:57 -0500 )edit

In RVIZ the transformes look completely wrong, see updated post.

( 2015-08-21 08:08:21 -0500 )edit

Use "rosrun tf view_frames" to see what transformations are published by which node. Maybe some node is publishing the same transformation as your localizer.

( 2015-08-21 08:24:50 -0500 )edit

I put the output of view_frames in my question. They look alright to me though...

( 2015-08-21 08:58:10 -0500 )edit