[AMCL] Robot pose's covariance on turns

[jesusramondovale]

Behaviour report

Required Info:

• Operating System:
  • Ubuntu 22.04
• ROS2 Version:
  • Humble binaies
• DDS implementation:
  • Fast-RTPS

Steps to reproduce issue

1. Setup a differential robot with a 180º LiDAR.
2. Configure Nav2 and AMCL for localization.
3. Monitor the amcl_pose while the robot moves.

Expected behavior

AMCL maintains a stable covariation in amcl_pose, indicating consistent confidence in the robot's estimated position.

Actual behavior

The covariation in amcl_pose increases over time when robot turns on itself, suggesting a growing uncertainty in the robot's position.

Is it possible to configure the number of degrees used by the LiDAR in AMCL to improve the accuracy and reduce the covariation? If so, how can this be achieved? Additionally, are there any recommended parameters or configurations for using AMCL with a 180º LiDAR to mitigate this issue?

[SteveMacenski]

I don't understand. If the robot rotates and triggers and update, that can definitely adjust the confidence in the positioning. Who's to know how well you were localized before, or if your rotation resulted in slippage that didn't achieve the odometric rotation intended, or how well the environment matches the map, or .... There's many good reasons for AMCL's confidence to adjust when updating during rotations.

Is it possible to configure the number of degrees used by the LiDAR in AMCL

I don't understand what this means.

[jesusramondovale]

The robot is almost perfectly located on the map with amcl_pose's covariance matrix (all values) <0.004 before turning on itself.

I'm using a Realsense Camera IMU and EKF node to get the exact rotation so no odometry from wheels is "needed" on turns with zero linear_x component.

I turn the camera on itself a random degrees amount (the same as if I'd turn the robot with the camera on it)

The /tf published by EKF node is perfect, the base_link axis turns the exact way on rviz as I do with my hand (with the camera or the physical robot) and without any lag.

Also, the points of laser scan topic (after rotating with the robot) are positioned over the map walls almost perfectly.

Covariance of the amcl_pose grows significally on this process (when I turn the camera ot the robot with the camera on it). From <0.004 to >0.02

QUESTION:

Is there any AMCL parameter that has something to do with the /scan topic angle used by this module? If there is, which one?

[SteveMacenski]

Can you provide a video? Do you see that the particle cloud is meaningfully diverging? 0.004 - 0.02 might still be so low its not statistically changing much. If that keeps growing to something substantive and that doesn't reflect in the particle cloud's distribution diverging as well, then that's a problem potentially.

Admittedly, AMCL is pretty old and really doesn't receive much changes, so I'd be highly suspicious about any new changes to that package. Not to say that its perfect, just that its really finnicky and I'd rather not touch it unless there's a clear and good reason to and someone can point to something in the code that they can identify as a bug which can be fixed.

Is there any AMCL parameter that has something to do with the /scan topic angle used by this module?

The AMCL lidar sample are evenly sampled from the entire laser scan depending on the number of beams selected. You may want to increase that parameter. Admittedly our defaults for AMCL are not well thought out.

[SteveMacenski]

@jesusramondovale any updates?

[jesusramondovale]

We're thinking about using two 270° LiDARs on each corner to cover the full 360 degrees.

[SteveMacenski]

Is there anything more we should address in this ticket?

[jesusramondovale]

No, you can close this ticket and I'll come back to you if I make any progress.

Thank you