# Odometry drift and how to fix

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

# 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)
rospy.spin()


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 close merge delete

1

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.

Sort by » oldest newest most voted

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

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 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.