Ask Your Question

Odometry drift and how to fix

asked 2020-12-28 03:57:39 -0500

yanaing gravatar image

Asking for advice on how should I fix the odometry drifting of the wheel. I detail of my problems are described below.

I have a differential-drive robot using RaspberryPi-4 and Oriental motor and motor-driver. The motor driver and the RaspberryPi are connect using RS-485 communication and python minimalmodbus library is used to drive and read speed of the motor.

The Kinematics model using is:

# inverse kinematics
velocity_left_wheel = (linear_velocity - angular_velocity*wheel_distance/2)/wheel_radius
velocity_right_wheel = (linear_velocity + angular_velocity*wheel_distance/2)/wheel_radius

# forward kinematics
robot_linear_velocity = (wheel_radius*(velocity_right_wheel + velocity_left_wheel)/2 )
robot_angular_velocity = (wheel_radius*(velocity_right_wheel - velocity_left_wheel)/wheel_distance )

In this way, I can drive and read the speed properly. When calculating the odometry, the robot location in real-world and RVIZ did not match(mostly during rotation). The odometry equation using is:

    delta_x = (robot_linear_velocity*np.cos(robot_th)) * dt
    delta_y = (robot_linear_velocity*np.sin(robot_th)) * dt
    delta_th = robot_angular_velocity * dt

    robot_x += delta_x
    robot_y += delta_y
    robot_th += delta_th

To read and write the speed of the motor, multi-callback functions are used:

    rospy.Timer(rospy.Duration(0.1), self.read_callback)
    rospy.Timer(rospy.Duration(0.1), self.write_callback)

Is there any suggestion to fix my problems. I already upload the complete code in github. If you are interested, feel free to check and advise me. Thank you to all contributors.

Tried ways:

  • using single callback and publish robot_velocity to Odometry node to calculate odometry and publish tf
  • using single callback and odometry is calculated in the same node
  • using multiple callback and odometry is calculated in the same node (already linked to github)
edit retag flag offensive close merge delete



I say stop calculating your odom and measure it instead. Rotate the robot exactly 10 times to the left and record exactly how many encoder counts on each wheel. Then exactly 10 in the other direction. Exactly 5 meters forward, how many counts? You get the point. Measuring the constants will help. Then ditch those kinematic calculations and use real world values. Of course you know that there will always be some drift in ODOM and the lowest hassle way to deal with that drift on an indoor robot is to slap on a laser scanner and run AMCL. Laser scanners have come way down in price($70US) and ROS/AMCL is absolutely rock solid.

billy gravatar image billy  ( 2021-01-01 00:29:17 -0500 )edit

1 Answer

Sort by ยป oldest newest most voted

answered 2020-12-29 16:37:48 -0500

SmallJoeMan gravatar image

Could you use an additional sensor such as the RealSense T265?

edit flag offensive delete link more


This might be one of the solutions, and also using IMU. The problem also having is that the robot itself could not go straightly, meaning there is a little deviation during moving. The reading back data is showing that they are rotating in the same RPM. That's why I am confusing that should I try to get the correct odometry or should I add sensors.

yanaing gravatar image yanaing  ( 2020-12-29 20:54:48 -0500 )edit

@yanaing odometry error is a fact of life, it is especially bad while turning. I would be very surprised if a cheap IMU would actually help you solve your problem. I don't understand exactly the context of your project but I would say that adding a simple range sensor like @billy said or a Realsense like @SmallJoeMan said would be the quickest and most robust way to eliminate all state estimate drift.

JackB gravatar image JackB  ( 2021-01-06 09:28:18 -0500 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools



Asked: 2020-12-28 03:57:39 -0500

Seen: 338 times

Last updated: Dec 29 '20