Navigation - Bad Initial Localization

Ask
1

Hi,
I was wondering if I am the only one having difficulties to reliably run the navigation stack. Mapping an environment works very well. However, when running the navigation stack, the robot is not localizing itself properly in the prerecorded map, although I give it a good initial estimate. For me it looks like that the robot just takes my initial estimate (2d pose marker) and does not fit anything to the recorded environment.

Thanks for your help!

IMG_9779
IMG_97791920Ă—1440 212 KB

1 Like
2

Hey @Pascalsutter, as I understand it, the localizer doesn’t make updates to the robot’s estimated pose until it receives a “motion update” (i.e. the robot starts moving). In effect, the location estimate only gets improved if you send a navigation goal or if you ask the robot to perform a “localization dance”, which is where the robot performs some hard-coded motions, such as turning in place. Have you tried sending a Nav goal yet?

3

Hi @Pascalsutter Can you confirm how you set the initial pose? Was it through rviz or did you set the parameter in the AMCL params? As @bshah said that motion will update the robot’s estimated pose so you could rotate the robot in place to update the location.

4

Hi, yes moving the robot around improves the initial estimate, but it takes some time until there is a good match. Directly sending the Nav goal is not optimal, as the robot moves in the wrong direction depending on the initial estimate. I set the initial pose through rviz. Thanks!

5

If the initial estimate is close enough, it should take only a few updates (a few seconds) for AMCL to find a good match. You can trigger updates using a “localization dance”, like I mentioned above, or you can request “no motion” updates:

ros2 service call /request_nomotion_update std_srvs/srv/Empty {}

For example, in this video, I set an initial estimate using Rviz and then call /request_nomotion_update repeatedly until AMCL converges.

This works well when the initial estimate is close and the map has unique features for AMCL to match between the map and the laser scan. If the initial estimate was wrong and the room had repeating patterns (e.g. a perfect square room with 4 identical corners), AMCL would converge to the wrong pose estimate.

You could automate this with a node that listens to the /initialpose topic and calls the /request_nomotion_update service a handful of times in response.

1 Like