ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question
3

Why AMCL requires to subscribe to /initialpose topic?

asked 2016-04-17 09:46:40 -0600

murdock gravatar image

updated 2016-04-19 11:26:50 -0600

AMCL is supposed to solve global localization problem, which means that the robot doesnt know its initial pose. I found this answer in this forum, but I did not understand it. Does it mean that I am providing it initial pose if its subscribing to it?

initialpose (geometry_msgs/PoseWithCovarianceStamped)
Mean and covariance with which to (re-)initialize the particle filter.

EDIT Alright, so apparently it is a violation of global localization problem. Thank you, Martin.

How does one avoid giving initial pose? I need to solve a global localization problem but this is cheating now if I say I use AMCL and provide everything robot needs.

edit retag flag offensive close merge delete

Comments

1

AMCL does not solve the kidnapped robot problem.

ahendrix gravatar image ahendrix  ( 2016-04-17 14:18:13 -0600 )edit

2 Answers

Sort by » oldest newest most voted
5

answered 2016-04-18 04:33:44 -0600

updated 2016-04-19 15:00:43 -0600

Edit: You don't have to publish an initial pose, you can simply call the global_localization service.


Original answer:

Yes, you have to publish the initial pose once (without that, the robot could be literally anywhere, like 1,000,000 km away from the map origin). Even if you don't have a very good idea where the robot is, it's usually somewhere on the map you provided to amcl (otherwise amcl is useless anyway). The "initial pose" is actually an initial gaussian distribution, and you can set a very high covariance in the initial pose message to make the particles spread to a wide area of the map, which of course makes AMCL's job much harder. In that sense, "global localization problem" translates to "somewhere on the map".

The answer by @dornhege that you linked to means that

  1. you shouldn't publish the initial pose all the time (otherwise it would reset AMCL all the time), but only once, in the beginning
  2. ...except when the robot becomes delocalized (i.e. none of the amcl particles is near where the robot actually is).

Perhaps it would be nice if instead of requiring an initial gaussian distribution, AMCL would randomly spread particles all over the free areas of the map, but the ROS implementation doesn't do that.

One more thing: instead of publishing a message to the initialpose topic, you can also set some parameters to achieve the same effect. The initialpose topic is there so that you can reset the pose while amcl is running (for example using RViz).

edit flag offensive delete link more

Comments

Thank you a lot!

murdock gravatar image murdock  ( 2016-04-18 05:03:27 -0600 )edit
1

You don't have to publish anything to the initialpose topic. If you leave it empty it defaults to the origin of the map (0.0.0,0,0,0)

Icehawk101 gravatar image Icehawk101  ( 2016-04-18 10:54:04 -0600 )edit

That is correct, but the default covariance is very small (meaning amcl is pretty certain the robot is at the map origin). So unless your robot is within 1 m of the map origin, facing in x direction (+/- 30°), you do need to set the initial pose.

Martin Günther gravatar image Martin Günther  ( 2016-04-19 03:24:17 -0600 )edit

Martin, could you explain your above answer (not comment) in other words? Does it mean that I give robot a pose that is not fully correct? For example, http://tinyurl.com/gtg69hw , does it mean that I give initial pose that is 99.7% sure that it is the correct one?

murdock gravatar image murdock  ( 2016-04-19 05:01:05 -0600 )edit

Or does it mean that I give robot something like this http://tinyurl.com/gwk8g3e ? It still seems to me that im violating the global localization definition by giving it initial pose.

murdock gravatar image murdock  ( 2016-04-19 05:02:58 -0600 )edit

Have a look at this tutorial. It includes a video that shows (among other things) the particle cloud by AMCL, perhaps that makes things clearer.

Martin Günther gravatar image Martin Günther  ( 2016-04-19 09:03:58 -0600 )edit

What you set in the initialpose topic is a PoseWithCovariance. The pose part defines the center of the particle cloud, and the covariance part controls how wide the particles are spread. And yes, you are right, strictly speaking this does violate the global localization definition.

Martin Günther gravatar image Martin Günther  ( 2016-04-19 09:06:00 -0600 )edit
1

Actually, I was wrong. I just re-checked, and all you need to do is call the global_localization service: "Initiate global localization, wherein all particles are dispersed randomly through the free space in the map."

Martin Günther gravatar image Martin Günther  ( 2016-04-19 14:33:22 -0600 )edit
2

answered 2019-01-25 04:40:17 -0600

Roberto Z. gravatar image

From Programming Robots with ROS: A Practical Introduction to the Robot Operating By Morgan Quigley, Brian Gerkey, William D. Smart:

Instead of using a normally distributed initial pose, you can get amcl to use a uniform set of candidate poses, scattered all over the map. You might do this if you really dont have a good idea of where the robot is. However, this makes it (much) harder for the algorithm to converge on a good pose estimate, so you should only do this if you really dont know where the robot is starting. you can enable this behaivoir by asking a service call to the global_localization service, using an empty request of type std_srvs(Empty).

To call that service from the command line:

$ rosservice call /global_localization "{}"

Then the robot can be positioned by rotating it. Of course, you can move around too, but the method of rotation will allow the particles to converge quickly.

Next, it's best to clear the cost map because they may contain incorrect information due to the initial wrong location.

$ rosservice call /move_base/clear_costmaps "{}"
edit flag offensive delete link more

Question Tools

1 follower

Stats

Asked: 2016-04-17 09:46:40 -0600

Seen: 6,374 times

Last updated: Jan 25 '19