ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | Q&A
Ask Your Question

2D Pose estimate

asked 2016-02-23 03:28:38 -0600

Sietse gravatar image

updated 2016-02-26 04:40:04 -0600

Hello All,

Using amcl as described in Ros By Example volume 1, section 8.5.2, I am confused. There are 2 maps in Rviz, one using topic /map, and showing the map I use, and one called Inflated Obstacles using topic /move_base/local_costmap/costmap. And it shows the inflated map include inflated data from the laser. Initially both maps are overlapping.

But if I do a "2D Pose Estimate", the inflated map moves with the setting of the pose. So if I only turn the robot 90 degrees, the inflated map also turns 90 degrees with respect to the other map. I can see that the laser data now is correct with respect to the robot, but not with respect to the inflated map. And navigation does not work.

I am confused, the only difference with the setup in the book is our own simple controller that does dead reckoning for odometry. And it works perfectly with move_base.


Initially both the global map and the (inflated) local (incl. laser) map are overlapping, as it should be. The robot is at some position. When setting the pose correctly, the laser is set to align with the global map. The inflated map now is completely wrong because it moved with the robot.

For example a wall in the local map now is standing in the middle of the room in the global map.

I would assume the because of the laser data the local map will be updated, but it isn't. And navigation through that part of the room is not possible. On a side note: If I stand in front of the laser for a moment, the obstable is often not disappearing altogether. Most of the time a remnant wil stay in the local map and can block the path.

Here some screenshots of rviz.

First the initial situation, then after setting the correct pose. The last one is while trying a goal in the "top" of the room, where you can see that it gets stuck because of the local costmap that is (incorrectly I think) in the way.

Initial situation

After setting pose

Getting stuck

Finally note that the laser does not has a complete free view, it cannot see to the back of the robot. The front of the robot is the black dot, which actually is the laser. Hopefully this helps

edit retag flag offensive close merge delete


I don't really understand the situation you're describing. Can you add screenshots of rviz before and after setting the position of the robot?

ahendrix gravatar image ahendrix  ( 2016-02-25 13:24:28 -0600 )edit

See the edit above.

Sietse gravatar image Sietse  ( 2016-02-26 04:34:03 -0600 )edit

It looks like your local costmap is including obstacles from the static map. Most users don't configure the local map that way.

ahendrix gravatar image ahendrix  ( 2016-02-26 12:01:25 -0600 )edit

2 Answers

Sort by ยป oldest newest most voted

answered 2016-02-29 09:06:13 -0600

Sietse gravatar image

Arrrg!! Somehow at some point I did set the value of static_map to true in local_costmap_params.yaml, while it should be false.

Now it is working as advertised, thanks for the help.

I still have the problem that some remnants of temporary objects sometimes remain in the inflated map, but I probably leave that for a next question. I can however remove them using the clear_costmap service.

edit flag offensive delete link more

answered 2016-02-23 03:38:39 -0600

ahendrix gravatar image

The laser data and the inflated obstacle map are relative to the robot; not to the global map. This is why the laser data and the inflated obstacle map move when you update the position of the robot.

AMCL is a particle filter which tracks the position of the robot relative to the global map. "2D Pose Estimate" tells AMCL to reinitialize the position of the robot with the pose you give it. Updating the pose in AMCL only updates the robot's position with respect to the global map (the laser scans and inflated obstacles remain relative to the robot).

By giving the robot a pose that is offset from the real world, you're giving AMCL incorrect input, and making your robot "lost". AMCL may eventually (by random sampling) figure out the correct position of the robot, but until then it will be rather lost.

edit flag offensive delete link more


Thanks. I think I understand this. See my edit above.

Sietse gravatar image Sietse  ( 2016-02-25 07:47:05 -0600 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower


Asked: 2016-02-23 03:28:38 -0600

Seen: 3,106 times

Last updated: Feb 29 '16