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

NAV2 AMCL Fails to Localize my Custom Ackermann Robot

asked 2023-05-16 00:27:57 -0600

Vini71 gravatar image

updated 2023-05-16 01:07:03 -0600

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:

  1. AMCL Configuration: Currently the robot_model_type 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.

  2. 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 scan_buffer_maximum_scan_distance, link_scan_maximum_distance, and loop_search_maximum_distance in the mapper_params_online_sync.yaml file. You can also refer to my nav2_params.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/configurat... save_pose_rate: 0.5 sigma_hit: 0.2 tf_broadcast: true transform_tolerance: 1.0 update_min_a: 0.2 update_min_d: 0.25 z_hit: 0.5 z_max: 0.05 z_rand: 0.5 z_short: 0.05 scan_topic: scan

Here is my nav2_params.yaml and mapper_params_online_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.

edit retag flag offensive close merge delete

Comments

1

You should probably use omni models instead of differential drive models if you don't have a diff drive set of kinematics. Omni at least allows for anything, so ackermann is a subset of that (even if imperfect). Adding an ackermann motion model plugin is definitely something that could be done!

stevemacenski gravatar image stevemacenski  ( 2023-05-16 12:44:41 -0600 )edit
1

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

Yes.

stevemacenski gravatar image stevemacenski  ( 2023-05-16 12:45:29 -0600 )edit

Thank you for your advice, Steve. I tilted the Lidar to aid mapping, but in the real application, it must face downwards to detect lower obstacles due to the truck's height, some suggestion?

Regarding the Omni models suggestion, I see the merit considering my robot's kinematics. Customizing an Ackermann motion model plugin seems promising. Do you have tips on where to start, or know of similar existing plugins?

I'm probing whether this could be the root cause of my planning issue. Further guidance would be much appreciated. More details are in this new thread: AMCL Small particles don't allow Planning

Thanks for your help!

Vini71 gravatar image Vini71  ( 2023-05-18 22:34:28 -0600 )edit

In addition, is there some update for this request:? Nav2-Reference for Ackermann Robot Simulation

I would highly appreciate it, considering I am struggling to enable the path planner module (despite having significant progress)

Vini71 gravatar image Vini71  ( 2023-05-18 22:44:25 -0600 )edit

1 Answer

Sort by ยป oldest newest most voted
0

answered 2023-05-18 22:26:17 -0600

Vini71 gravatar image

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.

edit flag offensive delete link more

Question Tools

2 followers

Stats

Asked: 2023-05-16 00:27:57 -0600

Seen: 654 times

Last updated: May 18 '23