Rosanswers logo


I have a problem in using AMCL package , The output position is totally random. When feeding the /initial_pose topic with current output of robot localization , the car is on the right position on the map. As shown in the next pic: image description

As soon as the car moves , Particles start to vastly spread out and randomly jump and the car never localize itself in a proper way again as shown in the video: amcl

I didn't investigate much at amcl parameters . But I suspect that I have a fundamental issue. Am I missing something? Here is my setup:

robot localization ( 1 local node): inputs: imu , wheel_odometry ( I put odometry child_frame_id as base_footprint and imu as i mu_link "fixed transfor to base_footprint" )

Sample Msgs:


  seq: 25
    secs: 1538665174
    nsecs: 779748916
  frame_id: "imu_link"
  x: -0.021728795831
  y: 0.0629217740198
  z: 0.934970575289
  w: 0.348423209804
orientation_covariance: [0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.01]
  x: 0.0010685628315
  y: 0.00427425132599
  z: 0.00747993982048
angular_velocity_covariance: [0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0]
  x: 1.45088620605
  y: 1.59932670898
  z: 10.4099888184
linear_acceleration_covariance: [0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0]


  seq: 1
    secs: 1538665300
    nsecs: 997972965
  frame_id: "odom"
child_frame_id: "base_footprint"
      x: 0.0
      y: 0.0
      z: 0.0
      x: 0.0
      y: 0.0
      z: 0.0
      w: 0.0
  covariance: [0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0]
      x: 0.0
      y: 0.0
      z: 0.0
      x: 9.0
      y: 0.0
      z: 0.0
  covariance: [1e-05, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1e-06, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.01]

Launch File:

    <node pkg="robot_localization" type="ekf_localization_node" name="ekf_loc" clear_params="true" output="screen">      
      <remap from="odometry/filtered" to="/odometry/filtered1" />
      <param name="frequency" value="5"/>
      <param name="sensor_timeout" value="0.3"/>
      <param name="map_frame" value="map"/>
      <param name="two_d_mode" value="true"/>
      <param name="odom_frame" value="odom"/>
      <param name="base_link_frame" value="base_footprint"/>
      <param name="world_frame" value="odom"/>
     <param name="use_control"       value="false"/>
      <param name="odom0" value="/rdwheel_odometry_new"/>
      <param name="imu0" value="/imu_bbb_new"/>   

      <rosparam param="odom0_config">[false, false, false,
                                      false, false, false,
                                      true, true, false,
                                      false, false, true,
                                      false, false, false]</rosparam>
      <rosparam param="imu0_config">[false, false, false,
                                      false, false, true,
                                     false, false, false,
                                     false, false, false,
                                     false, false, false]</rosparam>
      <param name="imu0_queue_size"   value="2"/>
      <param name="odom0_queue_size"   value="10"/>
      <param name="imu0_remove_gravitational_acceleration" value="true"/>  

amcl : inputs: map , laser_scan , initial_pose " from robot localization" at first

<launch> <node pkg="amcl" type="amcl" name="amcl" output="screen">

  <remap from="map" to="map" />   
  <remap from="scan" to="lidarsS" />
  <remap from="amcl_pose" to="lidarRoof_pose" /> <!--best particle-->   
  <remap from="particlecloud" to="particlecloud" /> <!--all particle-->

 <!--Odometry model parameters-->
 <param name="odom_model_type" value="diff-corrected"/>

  <param name="odom_alpha1" value="0.2"/>
  <param name="odom_alpha2" value="0.2"/>   <!-- translation std dev, m -->   
  <param name="odom_alpha3" value="0.8"/>   
  <param name="odom_alpha4" value="0.2"/>   
  <param name="odom_alpha5" value="0.1"/>   
  <param name="odom_frame_id" value="odom"/>   
  <param name="base_frame_id" value="base_footprint"/>  
  <param name="global_frame_id" value="map"/>   
  <param name="tf_broadcast" value="true"/>

 <!--Overall filter parameters-->   
 <param name="min_particles" value="500"/>   
 <param name="max_particles" value="5000"/>

  <param name="kld_err" value="0.05"/> 
 <param name="kld_z" value="0.99"/>   
 <param name="update_min_d" value="0.2"/>   
 <param name="update_min_a" value="0.5"/>

  <param name="resample_interval" value="1"/>
  <param name="transform_tolerance" value="0.1"/>

  <param name="recovery_alpha_slow" value="0.0"/>
  <param name="recovery_alpha_fast" value="0.0"/>

  <param name="gui_publish_rate" value="2.0"/>
  <param name="save_pose_rate" value="0.5"/>
  <param name="use_map_topic" value="true"/>
  <param name="first_map_only" value="true"/>

 <!--Laser model parameters-->
 <param name="laser_min_range" value="-1"/><!---1 uses reproted range-->
 <param name="laser_max_range" value="-1"/>
 <param name="laser_max_beams" value="30"/> <!--How many evenly-spaced beams in each scan to be used when updating the filter. -->

<!--Note that whichever mixture weights "laser_z_*" are in use should sum to 1-->
<param name="laser_z_hit" value="0.5"/>
<param name="laser_z_short" value="0.05"/>
<param name="laser_z_max" value="0.05"/>
<param name="laser_z_rand" value="0.5"/>
<param name="laser_sigma_hit" value="0.2"/>
<param name="laser_lambda_short" value="0.1"/>
<param name="laser_lambda_short" value="0.1"/>
<param name="laser_model_type" value="likelihood_field"/>
<param name="laser_likelihood_max_dist" value="2.0"/>
</node> </launch>


  • static tf from imu_link , lidar_link to base_footprint

  • robot localization publishes tf (base_footprint -> odom )

  • amcl publishes tf (odom -> map)

image description

Thank you

EDIT1: IN response to Delb :

I do have a bigger tf_tree. But ,for debugging amcl problem , I had to simplify everything .

I don't use a urdf file . I use two_d_mode so I think I don't need base_link base_footprint transform

I just use static transform this way:

<node pkg="tf" type="static_transform_publisher" name="imu" args="1.57 -0.4 1.065 0 0 0 1  /base_footprint /imu_link  100"

The tf is OK in Rviz and I can see car polygon and can navigate the car and reach goals if I use my ordinary setup :

Everything is OK .

The problem starts only when using Amcl with one instance of robot localization or if i published the odom-basefootprint transform myself

Originally posted by Mahmoud Kamel on ROS Answers with karma: 103 on 2018-10-04

Post score: 0

Original comments

Comment by Delb on 2018-10-05:
You should have the wheels in your tf tree. Also you can see that the buffer length between map and odom is 0.0 which means no data is sent. Can you tell us which robot you are using ?

Comment by Delb on 2018-10-05:
Also I'd recommend two things :

  • Check if the odom output when moving straight forward is correct.
  • Try running your project without the ekf_localization_node and see what happen

Comment by Mahmoud Kamel on 2018-10-05:
My robot is an ackerman golf cart. I use wheel odometry twist messege in base_footprint frame which is in the middle of the 2 rear wheels. I didn't notice the buffer lenght . I think that's why there is insane output position. But why amcl node (the publisher of this tf) did that?

Comment by Mahmoud Kamel on 2018-10-05:
If I didn't use robot localization . I think I have to publish a transform (base_footprint -> odom ) myself. I already tried that . I published this transform using imu and wheel_odometry data . And The same thing happened.

Comment by Delb on 2018-10-05:
I've looked the urdf of the ackerman golf cart and you should definitly have a bigger tf_tree. You don't even have the tf base_link->base_footprint. Can you load correctly your urdf in rviz ? (if yes can you show us the tf_tree only when visualizing the robot and using nothing else please ?)

Comment by Mahmoud Kamel on 2018-10-05:
Thank you for your time. Please check the question. I updated it.

Comment by Delb on 2018-10-05:
Using two_d_mode only specify if you are operating in a planar envirronment to facilitate the calculations so it's not related to tf. Does using the full urdf create errors ? Also have you checked that odom has coherent values when moving straight forward ?

Comment by Mahmoud Kamel on 2018-10-05:
No , using the full urdf doesn't create errors. I 'll revise odom values again to check that , and I'll return with a bag file. Until that what do you suspect? Is there something wrong in robot localization configuration that may outputs coherent values ?

Comment by Delb on 2018-10-05:
I really suspect not using the urdf is the mistake. For the robot localization configuration it might be an issue as stated here in "The differential and relative Parameters".

Comment by Mahmoud Kamel on 2018-10-05:
In reality there are 2 ways of communication between car and ROS:

Comment by Mahmoud Kamel on 2018-10-05:
a-The car sensor(like imu ,wheel-odometry and gps ) should send their data in a specific frame which is the sensor is really settled on . ROS needs to know the transform between this frame and the base. I do that with static_transform_publisher instead of urdf . Is there a problem in that?

Comment by Mahmoud Kamel on 2018-10-05:
b- Navigation "move_base" should send actuators command to the car and doesn't need a direct feedback of where is each wheel right now . That is implicitly sent using localization message (odom). So why i need a urdf if i don'r use simulation?

Comment by Mahmoud Kamel on 2018-10-05:
Sound like I misunderstand something . I wrote my understanding in the last comments. Please correct me if I'm wrong. I do use urdf when i use simulation. Thank you.

Comment by Delb on 2018-10-08:
The urdf directly tells how the frames are moving between each others so maybe your static_transform_publisher is the thing that create the jumps. Even if you are not in simulation you need the urdf file. Have you ever tried with the full urdf ? Does it create the same issue ?


1 Answer 1


Rosanswers logo

My problem was laserScan frequency . My lidar frequency is too low (0.8 Hz) .

I used this low frequency in simulation and it generated the same problem.

When I reduced car speed to a very low speed with the same lidar frequency , Things worked.

Originally posted by Mahmoud Kamel with karma: 103 on 2018-10-22

This answer was ACCEPTED on the original site

Post score: 0


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.