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

What are the causes of AMCL jumping around in its localization?

asked 2020-07-12 16:32:45 -0500

pitosalas gravatar image

Using a GoPiGo3 robot running melodic. I've built a map of my office (which is a bit cluttered admittedly.) The map looks reasonable but there are gaps and also not so fine grained.

Now when I launch AMCL it does put the robot approximately in the right place, but it jumps around quickly without receiving any commands.

I also see some confusing messages in the console:

Done checking log file disk usage. Usage is <1GB.

started roslaunch server http://u.local:37977/

SUMMARY
========

PARAMETERS
 * /amcl/base_frame_id: base_link
 * /amcl/global_frame_id: map
 * /amcl/gui_publish_rate: 50.0
 * /amcl/initial_pose_a: 0.0
 * /amcl/initial_pose_x: 0.0
 * /amcl/initial_pose_y: 0.0
 * /amcl/kld_err: 0.02
 * /amcl/laser_lambda_short: 0.1
 * /amcl/laser_likelihood_max_dist: 2.0
 * /amcl/laser_max_beams: 180
 * /amcl/laser_max_range: 3.5
 * /amcl/laser_model_type: likelihood_field
 * /amcl/laser_sigma_hit: 0.2
 * /amcl/laser_z_hit: 0.5
 * /amcl/laser_z_max: 0.05
 * /amcl/laser_z_rand: 0.5
 * /amcl/laser_z_short: 0.05
 * /amcl/max_particles: 3000
 * /amcl/min_particles: 500
 * /amcl/odom_alpha1: 0.1
 * /amcl/odom_alpha2: 0.1
 * /amcl/odom_alpha3: 0.1
 * /amcl/odom_alpha4: 0.1
 * /amcl/odom_frame_id: odom
 * /amcl/odom_model_type: diff
 * /amcl/recovery_alpha_fast: 0.0
 * /amcl/recovery_alpha_slow: 0.0
 * /amcl/resample_interval: 1
 * /amcl/transform_tolerance: 0.5
 * /amcl/update_min_a: 0.2
 * /amcl/update_min_d: 0.2
 * /joint_state_publisher/use_gui: False
 * /move_base/DWAPlannerROS/acc_lim_theta: 3.2
 * /move_base/DWAPlannerROS/acc_lim_x: 2.5
 * /move_base/DWAPlannerROS/acc_lim_y: 0.0
 * /move_base/DWAPlannerROS/controller_frequency: 10.0
 * /move_base/DWAPlannerROS/forward_point_distance: 0.325
 * /move_base/DWAPlannerROS/goal_distance_bias: 20.0
 * /move_base/DWAPlannerROS/latch_xy_goal_tolerance: False
 * /move_base/DWAPlannerROS/max_rot_vel: 2.75
 * /move_base/DWAPlannerROS/max_scaling_factor: 0.2
 * /move_base/DWAPlannerROS/max_trans_vel: 0.22
 * /move_base/DWAPlannerROS/max_vel_x: 0.22
 * /move_base/DWAPlannerROS/max_vel_y: 0.0
 * /move_base/DWAPlannerROS/min_rot_vel: 1.37
 * /move_base/DWAPlannerROS/min_trans_vel: 0.11
 * /move_base/DWAPlannerROS/min_vel_x: -0.22
 * /move_base/DWAPlannerROS/min_vel_y: 0.0
 * /move_base/DWAPlannerROS/occdist_scale: 0.02
 * /move_base/DWAPlannerROS/oscillation_reset_dist: 0.05
 * /move_base/DWAPlannerROS/path_distance_bias: 32.0
 * /move_base/DWAPlannerROS/publish_cost_grid_pc: True
 * /move_base/DWAPlannerROS/publish_traj_pc: True
 * /move_base/DWAPlannerROS/scaling_speed: 0.25
 * /move_base/DWAPlannerROS/sim_time: 1.5
 * /move_base/DWAPlannerROS/stop_time_buffer: 0.2
 * /move_base/DWAPlannerROS/vth_samples: 40
 * /move_base/DWAPlannerROS/vx_samples: 20
 * /move_base/DWAPlannerROS/vy_samples: 0
 * /move_base/DWAPlannerROS/xy_goal_tolerance: 0.05
 * /move_base/DWAPlannerROS/yaw_goal_tolerance: 0.17
 * /move_base/base_local_planner: dwa_local_planner...
 * /move_base/conservative_reset_dist: 3.0
 * /move_base/controller_frequency: 10.0
 * /move_base/controller_patience: 15.0
 * /move_base/global_costmap/cost_scaling_factor: 3.0
 * /move_base/global_costmap/footprint: [[-0.105, -0.105]...
 * /move_base/global_costmap/global_frame: map
 * /move_base/global_costmap/inflation_radius: 1.0
 * /move_base/global_costmap/map_type: costmap
 * /move_base/global_costmap/observation_sources: scan
 * /move_base/global_costmap/obstacle_range: 3.0
 * /move_base/global_costmap/publish_frequency: 10.0
 * /move_base/global_costmap/raytrace_range: 3.5
 * /move_base/global_costmap/robot_base_frame: base_link
 * /move_base/global_costmap/scan/clearing: True
 * /move_base/global_costmap/scan/data_type: LaserScan
 * /move_base/global_costmap/scan/marking: True
 * /move_base/global_costmap/scan/sensor_frame: base_scan
 * /move_base/global_costmap/scan/topic: scan
 * /move_base/global_costmap/static_map: True
 * /move_base/global_costmap/transform_tolerance: 0.5
 * /move_base/global_costmap/update_frequency: 10.0
 * /move_base/local_costmap/cost_scaling_factor: 3.0
 * /move_base/local_costmap/footprint: [[-0.105, -0.105]...
 * /move_base/local_costmap/global_frame: odom
 * /move_base/local_costmap/height: 3
 * /move_base/local_costmap/inflation_radius: 1.0
 * /move_base/local_costmap/map_type: costmap
 * /move_base/local_costmap/observation_sources: scan
 * /move_base/local_costmap/obstacle_range: 3.0
 * /move_base/local_costmap/publish_frequency: 10.0
 * /move_base/local_costmap/raytrace_range: 3.5
 * /move_base/local_costmap/resolution: 0.05
 * /move_base/local_costmap/robot_base_frame ...
(more)
edit retag flag offensive close merge delete

Comments

1

AMCL will not update unless the robot has moved or rotated a certain amount since the previous update. So if you're saying it's updating "without receiving any commands" meaning robot is not being commanded to move, then AMCL is updating because ODOM is changing enough to cause AMCL to think it's time to re-update localization.

When you say it's jumping around, you mean the robot is visually moving around in RVIZ? What is ODOM doing this time? If AMCL is updating, the MAP <-- ODOM TF will be getting updated so watch that and see if it really is. I'm asking about this because I'm not convinced this is an AMCL issue.

billy gravatar image billy  ( 2020-07-12 18:59:15 -0500 )edit

Thanks @billy... See my own answer below but I doubt it would be useful to others because its pretty specific.

pitosalas gravatar image pitosalas  ( 2020-07-13 20:22:02 -0500 )edit

1 Answer

Sort by ยป oldest newest most voted
0

answered 2020-07-13 20:24:54 -0500

pitosalas gravatar image

I found two problems which together made this particular problem go away:

  1. I had not specified either ROS_HOSTNAME or ROS_IP and as a result apparently ROS takes the hostname (from hostnames) and treats it as a local domain name. This is not reliable in my case (and I understand its not reliable in general.) So I put in specific ip addresses as ROS_IP= on both the robot (running roscore) and the remote computer.
  2. I found that the URDF had the orientation of the LIDAR off by 90 degrees. The urdf had it mounted sideways but actually it is mounted straight (i.e. pointing forward.

FIxing these two things made the jumpy AMCL go away. Now I can do SLAM and AMCL and it works. Thanks!

edit flag offensive delete link more

Question Tools

1 follower

Stats

Asked: 2020-07-12 16:32:45 -0500

Seen: 787 times

Last updated: Jul 13 '20