0
$\begingroup$

Rosanswers logo

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.


Originally posted by 130s on ROS Answers with karma: 10937 on 2011-11-22

Post score: 1

$\endgroup$

1 Answer 1

0
$\begingroup$

Rosanswers logo

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.


Originally posted by fergs with karma: 13902 on 2011-11-23

This answer was ACCEPTED on the original site

Post score: 2


Original comments

Comment by tfoote on 2011-11-23:
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.

Comment by 130s on 2011-11-23:
@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).

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.