# Turtlebot/Create doesn't move straight

When I keyboard-teleop my Turtlebot, it often shifts toward left, say a few degrees. Although this doesn't always happen, once it starts happening I have no idea how to correct that (e.g. rebooting both PC & iRobot Create didn't take effect). Calibration of odom & gyro was successful enough (but I think calibration doesn't matter since this happens even with teleop which I believe doesn't use IMU). I see neither significant amount of stuff stuck at wheels nor related info in the owner's manual available at irobot.com. Probably due to this, SLAM mapping is terrible.

Thanks.

Update) /odom returns some values, so I was wrong saying that odometry & gyro weren't used in teleop. And the value returned only shows displacement in x-direction which I interpret as the robot doesn't know at ROS level that it's shifting left. Now 3 out of 4 Turtlebots in our office show the same phenomenon.

Update-2) We found Create itself moves fairly straight by the embedded demo programs, with and without the toppings (= Turtlebot's structure). And Create even deviates when the Turtlebot's structure is removed but laptop still connected and controlled via teleop. These indicate that the root cause might lie somewhere in ROS software, its configuration or their combination.

edit retag close merge delete

Sort by » oldest newest most voted

The short answer is that most low-cost robots don't drive exactly straight when told to. When you have so few encoder ticks per rotation, small differences in wheel speed cause the robot to turn as it drives forward.

The odometry messages published by the turtlebot_node are generated from wheel encoders alone, and the Create is notorious for having bad angular feedback. If you look at the base_link->odom transform generated by the ekf_filter, it should reflect that the robot is not going exactly straight, however, this transform (which comes from both wheel encoders and the gyro) is not used in the control loop which converts geometry_msgs/Twist messages into actual movement. Even so, with the control loop not adjusting, the positional information sent to gmapping (in the form of tf transforms) should reflect the rotation.

more

@fergs thanks. Then how can gmapping still reflect the unwanted rotation without using tf data that knows the exact movement? And I'm curious to see tf with frame /base_link and child-frame /odom but I don't find it in "rostopic echo /tf" while I run teleop (noticed /odom is always a parent).
( 2011-11-23 09:41:10 -0500 )edit
Gmapping detects the errors in the odometry by comparing laser scans over time in the same way the AMCL does. It also updates the map at the same time.
( 2011-11-23 14:16:06 -0500 )edit

After lots of troubleshoots, we've figured out a workaround that the linear velocity matters when either teleop_keyboard or teleop_joystick is used. In our case, 0.3 (or probably slower. We haven't tested all possible velocity values) is good enough for the Turtlebot to keep straight, but 0.35 and 0.4 are NG. We still don't know what's the root cause though.

more

1
In that case, it may be that one of your motors cannot achieve 0.35m/s and so you curve in that direction.
( 2011-11-24 03:05:35 -0500 )edit
@fergs thx, your comment gives me another insight for the next time we troubleshoot. I just corrected my answer and basically what we've been seeing is slower is better when it comes to moving straight.
( 2011-11-27 04:18:48 -0500 )edit