Question

I'm experiencing issues with the AMCL localization of my custom Ackermann robot using Nav2. In RViz, the localization fails, and I'm unsure about the root cause. I've identified several potential factors:

AMCL Configuration: Currently the robotmodeltype parameter in the AMCL configuration is set to "differential", as I couldn't find an Ackermann option available in the documentation: AMCL configuration. Here is my current AMCL configuration.
Parameter Misconfiguration : I've tried to adjust the parameters to match my robot's real-world characteristics as closely as possible, but I may have misconfigured something. My robot has a higher laser range and larger size than a TurtleBot, and it operates in a larger environment. I'm unsure about the correct settings for parameters like scanbuffermaximumscandistance, linkscanmaximumdistance, and loopsearchmaximumdistance in the mapperparamsonlinesync.yaml file. You can also refer to my nav2params.yaml file for other settings:

amcl:
  ros__parameters:
    use_sim_time: True
    alpha1: 0.2
    alpha2: 0.2
    alpha3: 0.2
    alpha4: 0.2
    alpha5: 0.2
    base_frame_id: "base_footprint"
    beam_skip_distance: 0.5
    beam_skip_error_threshold: 0.9
    beam_skip_threshold: 0.3
    do_beamskip: false
    global_frame_id: "map"
    lambda_short: 0.1
    laser_likelihood_max_dist: 2.0
    laser_max_range: 100.0
    laser_min_range: -1.0
    laser_model_type: "likelihood_field"
    max_beams: 60
    max_particles: 2000
    min_particles: 500
    odom_frame_id: "odom"
    pf_err: 0.05
    pf_z: 0.99
    recovery_alpha_fast: 0.0
    recovery_alpha_slow: 0.0
    resample_interval: 1
    robot_model_type: "differential" #Need to customize
later an Ackermman plugin for this according to the documentation: https://navigation.ros.org/configuration/packages/configuring-amcl.html saveposerate: 0.5 sigmahit: 0.2 tfbroadcast: true transformtolerance: 1.0 updatemina: 0.2 updatemind: 0.25 zhit: 0.5 zmax: 0.05 zrand: 0.5 zshort: 0.05 scantopic: scan

Here is my nav2_params.yaml and mapperparamsonline_sync.yaml) files.

3- Z-axis Offset During Mapping: While creating the map, I observed an unexpected "jump" in the Z-axis, resulting in the map appearing to be generated above the robot's origin. After this sudden shift, the map creation stabilizes. I'm concerned this behavior may be affecting the AMCL localization.

4- Other factors: Could the slight 10-degree downward tilt of my lidar sensor be influencing this behavior?

Tutorial Visualization image description

My robot Visualization: image description

Here is a YouTube video demonstrating the problem. I would appreciate any guidance or suggestions for resolving this issue.

Asked by Vini71 on 2023-05-16 00:27:57 UTC

Answer 1

Steps Taken to Resolve Localization with a Scaled Ackermann Robot:

I've made a number of adjustments to address my original problem:

1- Robot Structure & World Simplification: I altered my robot's structure to have a lidar positioned at a 90-degree angle (i.e., no tilt) and simplified my world, scaling the standard turtlebot world by 7-12 times.

2- Launch and World Files: I noticed that the tb3_simulation_launch.py file depends on the waffle.model world to publish joint_states and consequently the odom to base_footprint TF. Essentially, an SDF model is created instead of launching the robot URDF.

When I tried to modify the launch file truck_simulation_launch.py to remove the SDF world creation, the robot's planning performance suffered, as shown in this video: Poor Planning.

3- Mapping Improvement: My original mapping process was inconsistent, with the robot floating in Z, and the odom and map frames shifting along with the map. This was due to the simultaneous publication of information by SLAM and AMCL, as discussed here: robot jumps while mapping.

My solution was to connect the joint state publisher to my Ackermann model, removing the localization robot node in my launch file: mapping_world.launch.py, to avoid redundancy in the odom to base_footprint TF.

Among these, the second approach was critical for resolving the localization issue. Since AMCL requires the odom and map to publish particles if the TF tree doesn't contain the odom to base_footprint (or base_link) Transform, AMCL won't function. This can be achieved by properly configuring joint_states in the SDF file (alongside spawning the robot model and world), or by loading the joint_state publisher and robot_localization node (ekf) in the launch file, although the latter seems to negatively impact planning performance.

Now, I'm working on getting the path planner to operate correctly. I'm still trying to determine whether further localization fixes are needed or if the root cause lies elsewhere. I'm continuing this discussion in a new post: AMCL Small particles don't allow Planning. Any assistance would be appreciated.

Asked by Vini71 on 2023-05-18 22:26:17 UTC

NAV2 AMCL Fails to Localize my Custom Ackermann Robot

Comments

Answers

Comments