Big odom error when moving forward with plain environment

asked 2021-05-27 05:12:57 -0600

AlexandrosNic gravatar image

I have a simulated autonomous base running in ROS1, Melodic, Gazebo with move_base, gmapping and robot_pose_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.

image description

I tried with hector mapping but it doesn't work neither with pub_map_odom_transform = true or false since it mostly relies on lidar (not odom), and since the environment is unchanged.

I also tried changing the <publishodomtf>false</publishodomtf> of my gazebo plugin: differential_drive_controller ( to true, but it doesn't work (I think because it has many broadcasters of odom tf).

I also upload some important files for your reference:


  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

    - {name: static_layer,            type: "costmap_2d::StaticLayer"}


  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

   - {name: static_layer,        type: "costmap_2d::StaticLayer"}
   - {name: obstacle_layer,      type: "costmap_2d::VoxelLayer"}
   - {name: inflation_layer,         type: "costmap_2d::InflationLayer"}


  <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 ...
edit retag flag offensive close merge delete


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.

allenh1 gravatar image allenh1  ( 2021-05-28 10:08:50 -0600 )edit

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

AlexandrosNic gravatar image AlexandrosNic  ( 2021-05-31 09:38:38 -0600 )edit