ROS navigation stack with AMCL, odometry and localization issues

asked 2020-10-05 18:04:07 -0500

NiamhD gravatar image

updated 2020-10-06 04:49:18 -0500

I am using the ROS navigation stack with amcl on a custom built robot base with a 2D hokuyo lidar. The goal is to navigate from a start position/ home base navigate to a number of waypoints in a room and then return to the start position and then repeat. To find the waypoints, I set an initial pose and then move the robot to to different points in the room and record what is published to /amcl_pose. I also run amcl_pose at the initial point and set that as the last waypoint.

The issue is that the robot never goes exactly to the waypoint, it always stops somewhere nearby. I suspect there is some issues with the rotational odometry after running the odometry tests listed here: http://wiki.ros.org/navigation/Troubl... - In particular after running  'Test 1'  the lasers scans seem to be quite displaced  by about 45 degrees when rotating on the spot. This seems to effect the navigation accuracy and stops the robot from stopping at the  waypoints correctly.

A bag file, rviz images and a video of the test in rviz can be viewed here: https://drive.google.com/drive/folder...

I am looking to confirm id the odometry is the issue and I am looking for suggestions on how to best to proceed. Should I try to use an alternative to amcl (like hector slam) or can I try to improve amcl to accommodate for the drift. These are the parameters I have set for amcl are here:

<launch>

<arg name="use_map_topic" default="false"/> <arg name="scan_topic" default="scan"/> <arg name="initial_pose_x" default="0.0"/> <arg name="initial_pose_y" default="0.0"/> <arg name="initial_pose_a" default="0.0"/> <arg name="odom_frame_id" default="odom"/> <arg name="base_frame_id" default="base_footprint"/> <arg name="global_frame_id" default="map"/>

<node pkg="amcl" type="amcl" name="amcl">

<param name="odom_model_type"           value="diff"/>
<param name="odom_alpha1"               value="0.2"/>
<param name="odom_alpha2"               value="0.2"/>
<!-- translation std dev, m -->
<param name="odom_alpha3"               value="0.2"/>
<param name="odom_alpha4"               value="0.2"/>
<param name="odom_alpha5"               value="0.1"/>


<!-- Laser model parameters -->
<param name="laser_max_beams" value="30"/>
<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_model_type" value="likelihood_field"/>
<param name="laser_likelihood_max_dist" value="2.0"/>

<!-- <param name="laser_model_type" value="beam"/> -->
<param name="laser_likelihood_max_dist" value="2.0"/>
<param name="update_min_d"              value="0.2"/>
<param name="update_min_a"              value="0.5"/>
<param name="odom_frame_id"             value="$(arg odom_frame_id)"/>
<param name="base_frame_id"             value="$(arg base_frame_id)"/>
<param name="global_frame_id"           value="$(arg global_frame_id)"/>
<param name="resample_interval"         value="1"/>
<!-- Increase tolerance because the computer can get quite busy -->
<param name="transform_tolerance"       value=".1"/> ...
(more)
edit retag flag offensive close merge delete

Comments

Two quick suggestions, visualize the particle set in RVIZ using the /particlecloud topic which AMCL publishes. Try to observe when/where/during what motion the particles stop representing the true motion of the platform. That can provide a lot of insight in how to handle the problem. Second, I would increase odom_alpha1 and odom_alpha4 which model the noise in the rotation, or decrease update_min_a which will force the filter to update more quickly when turning. Updating after a rotation of 0.5 rad (your current setting) may not be often enough.

JackB gravatar image JackB  ( 2020-10-06 08:48:58 -0500 )edit