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

AMCL losting problem

asked 2015-09-04 02:14:38 -0500

osmancns gravatar image

updated 2016-02-10 07:07:51 -0500

hello... I work on AMCL. if I work in little area AMCL work very well. But if I work in corridor AMCL always is losting in the middle of corridor. My AMCL parameters are good so amcl pose estimation (pose arrays) doesnt spread. why it get lost always same area ??? problem is about LIDAR MAX RANGE or gound type ?

lidar hokuyo : 5.4 m max range type of floor : tile The length of the corridor :

image description

VIDEO ABOUT PROBLEM :

VIDEO INFO :

video timing (03:08) : robot is actually in front of the first door, but amcl estimation is still in front of the first floor video timing (04:07) : robot is actually in front of the third door, but amcl estimation is still in front of the second floor

    <!-- amcl.XML-->
<launch>
  <arg name="use_map_topic"   default="true"/>
  <arg name="initial_pose_x"  default="0.0"/>
  <arg name="initial_pose_y"  default="0.0"/>
  <arg name="initial_pose_a"  default="0.0"/>

<node pkg="amcl" type="amcl" name="amcl" args="scan:=scan2" output="screen">
<!-- Publish scans from best pose at a max of 10 Hz -->

<param name="odom_frame_id" value="odom_combined"/>
<param name="base_frame_id" value="base_footprint"/>
<param name="global_frame_id" value="map"/>
<param name="odom_model_type" value="diff"/>

<param name="transform_tolerance" value="0.5" />
<param name="gui_publish_rate" value="10.0"/> <!-- 5 -->
<param name="laser_max_beams" value="80"/>  <!-- 30 -->
<param name="min_particles" value="100"/>
<param name="max_particles" value="4000"/>
<param name="kld_err" value="0.05"/>
<param name="kld_z" value="0.99"/>
<param name="odom_alpha1" value="0.02"/> <!-- 0.2 -->
<param name="odom_alpha2" value="0.07"/> <!-- 0.2 -->
<!-- translation std dev, m -->
<param name="odom_alpha3" value="0.08"/> <!-- 0.8 -->
<param name="odom_alpha4" value="0.02"/> <!-- 0.2 -->
<param name="laser_max_range" value="5.6"/>
<param name="laser_z_hit" value="0.95"/>
<param name="laser_z_short" value="0.1"/>
<param name="laser_z_max" value="0.05"/>
<param name="laser_z_rand" value="0.05"/>
<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_model_type" value="beam"/> -->
<param name="laser_likelihood_max_dist" value="2.0"/>
<param name="update_min_d" value="0.08"/>  <!-- 0.2 **0.15-->
<param name="update_min_a" value="0.18"/>  <!-- 0.5 **0.12-->

<param name="resample_interval" value="1"/>
<param name="transform_tolerance" value="0.1"/> <!-- 0.1 -->
<param name="recovery_alpha_slow" value="0.0"/>
<param name="recovery_alpha_fast" value="0.0"/>

<param name="initial_pose_x" value="$(arg initial_pose_x)"/>
<param name="initial_pose_y" value="$(arg initial_pose_y)"/>
<param name="initial_pose_a" value="$(arg initial_pose_a)"/>
<param name="use_map_topic" value="$(arg use_map_topic)"/>

</node>
</launch>
edit retag flag offensive close merge delete

Comments

This cannot be debugged without more information.

Please provide at least your configuration (min. amcl), maybe a video (from rviz) how this happens, or a bagfile.

mgruhler gravatar image mgruhler  ( 2015-09-04 06:47:46 -0500 )edit

thanks... I edited my question @mig

osmancns gravatar image osmancns  ( 2015-09-04 09:27:42 -0500 )edit

can you help me @mig please ?

osmancns gravatar image osmancns  ( 2015-09-07 01:25:52 -0500 )edit

It's rather difficult to tell what's happening, though I would be concerned that the particles are staying so bundled. Particles are supposed to spread out. This means that the algorithm is resampling, so check your odometry/laser rangefinders/map scale? One of those is likely the problem.

allenh1 gravatar image allenh1  ( 2015-09-07 08:19:30 -0500 )edit

thank you @allenh1. I placed boxes center of the corridor. and I mapped again. and now AMCL doesnt loss . so work well. ı cant understand ? And I learned that" if particles doesnt spread out , AMCL work so good ", doesnt it ???? I changed always amcl parameters and fixed that spread out particles.

osmancns gravatar image osmancns  ( 2015-09-07 08:46:49 -0500 )edit

I'm really not sure what is happening there. To me, it seems, that you don't have proper odometry measurements. Could you create a bagfile and upload this somewhere?

Particles need to spread out to some extent. To me, it seems you are overestimating the (faulty) odometry. but this is just a guess

mgruhler gravatar image mgruhler  ( 2015-09-10 02:31:05 -0500 )edit

. I placed boxes center of the corridor. and I mapped again. and now AMCL doesnt loss. corridor length is longer then my lidar max range. is it a problem you think ? and if particles dont spread out , Does that amcl parameters are very good . ı know so ??? you think my parameters are bad @mig ??

osmancns gravatar image osmancns  ( 2015-09-10 04:25:57 -0500 )edit

I'd say that you're odometry parameters are too low. On our robots, they are considerably higher and work fine.

But as I don't know your robot, I cannot say.

mgruhler gravatar image mgruhler  ( 2015-09-12 11:11:30 -0500 )edit

1 Answer

Sort by » oldest newest most voted
1

answered 2016-02-10 08:30:33 -0500

Orhan gravatar image

updated 2016-02-10 10:04:11 -0500

Gmapping is locating robot via laser. Even if odometry is poor, gmapping is correcting position of robot with scan matching. But in corridor, your laser's range isn't enough for this.

Test your odometry first:

...

The first test checks how reasonable the odometry is for rotation. I open up rviz, set the frame to "odom," display the laser scan the robot provides, set the decay time on that topic high (something like 20 seconds), and perform an in-place rotation. Then, I look at how closely the scans match each other on subsequent rotations. Ideally, the scans will fall right on top of each other, but some rotational drift is expected, so I just make sure that the scans aren't off by more than a degree or two.

...

For more, look at this navigation tuning guide.

edit flag offensive delete link more

Comments

I control my robot with a joystick so path is no problem. If I do odometry tests in a room (5x5 m) , odometry result is very good and no problem. But when I drive my robot in corridor ( about pic. above), amcl get lost position of robot.

osmancns gravatar image osmancns  ( 2016-02-10 09:09:31 -0500 )edit

I'm editing my answer because my comment is long,

Orhan gravatar image Orhan  ( 2016-02-10 09:49:11 -0500 )edit

is there a way or parameter to compensate this drifting ? (except a new lidar )

osmancns gravatar image osmancns  ( 2016-02-10 09:58:26 -0500 )edit

No, If This problem about your odometry settings, You must correct them first. Try editing your urdf file by looking other open source robot's urdfs.

Orhan gravatar image Orhan  ( 2016-02-10 10:03:00 -0500 )edit

I use a real robot and urdf model is same with robot. And I use laser_scan_matcher to produce odometry.

osmancns gravatar image osmancns  ( 2016-02-11 02:37:10 -0500 )edit

I used real informations about my robot before too. But sometimes navigation needs some tricks like this.

Orhan gravatar image Orhan  ( 2016-02-11 02:48:20 -0500 )edit

Question Tools

1 follower

Stats

Asked: 2015-09-04 02:14:38 -0500

Seen: 1,821 times

Last updated: Feb 10 '16