Ask Your Question

Turtlebot/Create doesn't move straight

asked 2011-11-22 10:51:14 -0500

130s gravatar image

updated 2011-11-23 17:43:56 -0500

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 Probably due to this, SLAM mapping is terrible.


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

2 Answers

Sort by ยป oldest newest most voted

answered 2011-11-23 07:47:41 -0500

fergs gravatar image

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.

edit flag offensive delete link 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).
130s gravatar image 130s  ( 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.
tfoote gravatar image tfoote  ( 2011-11-23 14:16:06 -0500 )edit

answered 2011-11-23 17:49:35 -0500

130s gravatar image

updated 2011-11-28 04:25:56 -0500

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.

edit flag offensive delete link more


In that case, it may be that one of your motors cannot achieve 0.35m/s and so you curve in that direction.
fergs gravatar image fergs  ( 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.
130s gravatar image 130s  ( 2011-11-27 04:18:48 -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

1 follower


Asked: 2011-11-22 10:51:14 -0500

Seen: 2,270 times

Last updated: Nov 28 '11