Big odom error when moving forward with plain environment
I have a simulated autonomous base running in ROS1, Melodic, Gazebo with movebase, gmapping and robotpose_ekf for the odom. When I move my robot straight forward, with the environment remaining unchanged for the entire path, then I get a bad map > odom transformation, making the robot perceive the straight path much shorter than how it actually is in reality.
I suppose this won't be a problem with a good wheel odom encoder on a real robot, but the simulation is problematic. This is similar to this question, however the answers didn't really help.
I checked the launch files of many autonomous robots (pr2, turtlebot, husky, jackal etc) to compare, but I couldn't identify the culprit. Below I post the rviz image with the map - odom error.
I tried with hector mapping but it doesn't work neither with pubmapodom_transform = true or false since it mostly relies on lidar (not odom), and since the environment is unchanged.
I also tried changing the
I also upload some important files for your reference:
global_costmap.yaml
global_costmap:
global_frame: map #map
robot_base_frame: base_link
update_frequency: 5 # Set this as high as the cpu resources allow
publish_frequency: 5 #2.5
static_map: true
rolling_window: false
track_unknown_space: true
width: 1024
height: 1024
origin_x: -51.25
origin_y: -51.25
resolution: 0.1
transform_tolerance: 1.0
plugins:
- {name: static_layer, type: "costmap_2d::StaticLayer"}
local_costmap.yaml
local_costmap:
global_frame: odom # odom_combined
robot_base_frame: base_link
update_frequency: 10 # 5.0
publish_frequency: 10 # 5.0
static_map: false
rolling_window: true
width: 4.0
height: 4.0
resolution: 0.05
transform_tolerance: 1.0
plugins:
- {name: static_layer, type: "costmap_2d::StaticLayer"}
- {name: obstacle_layer, type: "costmap_2d::VoxelLayer"}
- {name: inflation_layer, type: "costmap_2d::InflationLayer"}
gmapping.launch
<launch>
<arg name="scan_topic" default="scan"/> <!--scan_filtered-->
<node pkg="gmapping" type="slam_gmapping" name="slam_gmapping" output="screen">
<param name="odom_frame" value="odom"/>
<param name="base_frame" value="base_link"/>
<param name="map_frame" value="map"/>
<param name="throttle_scans" value="1"/>
<param name="map_update_interval" value="0.1"/> <!-- default: 5.0 -->
<param name="maxUrange" value="10.0"/>
<param name="maxRange" value="10.0"/>
<param name="sigma" value="0.05"/>
<param name="kernelSize" value="1"/>
<param name="lstep" value="0.05"/>
<param name="astep" value="0.05"/>
<param name="iterations" value="5"/>
<param name="lsigma" value="0.075"/>
<param name="ogain" value="3.0"/>
<param name="minimumScore" value="150.0"/>
<param name="lskip" value="0"/>
<param name="srr" value="0.01"/>
<param name="srt" value="0.02"/>
<param name="str" value="0.01"/>
<param name="stt" value="0.02"/>
<param name="linearUpdate" value="0.1"/>
<param name="angularUpdate" value="0.05"/>
<param name="temporalUpdate" value="-1.0"/>
<param name="resampleThreshold" value="0.5"/>
<param name="particles" value="20"/>
<param name="xmin" value="-10.0"/>
<param name="ymin" value="-10.0"/>
<param name="xmax" value="10.0"/>
<param name="ymax" value="10.0"/>
<param name="delta" value="0.03"/>
<param name="occ_thresh" value="0.5"/> -->
<param name="llsamplerange" value="0.01"/>
<param name="llsamplestep" value="0.01"/>
<param name="lasamplerange" value="0.005"/>
<param name="lasamplestep" value="0.005"/>
<remap from="scan" to="$(arg scan_topic)"/>
</node>
</launch>
robotposeekf:
<node pkg="robot_pose_ekf" type="robot_pose_ekf" name="robot_pose_ekf">
<param name="output_frame" value="odom"/> <!-- odom_combined -->
<param name="base_footprint_frame" value="base_link"/>
<param name="freq" value="10.0"/>
<param name="sensor_timeout" value="1.0"/>
<param name="odom_used" value="true"/>
<param name="imu_used" value="true"/>
<param name="vo_used" value="false"/>
<param name="debug" value="false"/>
<param name="self_diagnose" value="false"/>
<remap from="imu_data" to="imu"/>
</node>
Also the alternative hector_slam:
<launch>
<arg name="tf_map_scanmatch_transform_frame_name" default="scanmatcher_frame"/>
<arg name="base_frame" default="base_link"/>
<arg name="odom_frame" default="odom"/>
<arg name="pub_map_odom_transform" default="true"/>
<arg name="scan_subscriber_queue_size" default="5"/>
<arg name="scan_topic" default="scan"/> <!--scan_filtered-->
<arg name="map_size" default="1024"/>
<node pkg="hector_mapping" type="hector_mapping" name="hector_mapping" output="screen">
<!-- Frame names -->
<param name="map_frame" value="map" />
<param name="base_frame" value="$(arg base_frame)" />
<param name="odom_frame" value="$(arg odom_frame)" />
<param name="use_tf_scan_transformation" value="true"/>
<param name="use_tf_pose_start_estimate" value="false"/>
<param name="pub_map_odom_transform" value="$(arg pub_map_odom_transform)"/>
<param name="map_resolution" value="0.1"/>
<param name="map_size" value="$(arg map_size)"/>
<param name="map_start_x" value="0.5"/>
<param name="map_start_y" value="0.5" />
<param name="map_multi_res_levels" value="2" />
<param name="update_factor_free" value="0.4"/>
<param name="update_factor_occupied" value="0.9" />
<param name="map_update_distance_thresh" value="0.05"/>
<param name="map_update_angle_thresh" value="0.06" />
<param name="laser_z_min_value" value = "-1.0" />
<param name="laser_z_max_value" value = "1.0" />
<param name="map_pub_period" value="1.0"/>
<param name="advertise_map_service" value="true"/>
<param name="scan_subscriber_queue_size" value="$(arg scan_subscriber_queue_size)"/>
<param name="scan_topic" value="$(arg scan_topic)"/>
<param name="tf_map_scanmatch_transform_frame_name" value="$(arg tf_map_scanmatch_transform_frame_name)" />
</node>
</launch>
Any help is highly appreciated!
Asked by AlexandrosNic on 2021-05-27 05:12:57 UTC
Comments
Have you added any features to the map? If every frame of the laserscan looks the same (since it measures perfectly), it is quite possible the slam algorithm is interpreting it as a drift in odometry (since scan matching is usually quite reliable). To confirm this, try adding a few random objects in the room so that the lasers can see the robot is moving forward.
Asked by allenh1 on 2021-05-28 10:08:50 UTC
Thank you for your reply. Unfortunately I cannot add features in my environment because in the real-world scenario the robot will operate in a big empty building (with a wall at the side of the robot being the only "feature"). Thus I would like gmapping or hector to rely more on the odometry values.
For your reference if I add features in the environment then the problem disappears
Asked by AlexandrosNic on 2021-05-31 09:38:38 UTC