ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

irobot create odometry package

asked 2011-12-17 16:14:21 -0500

searchrescue gravatar image

Hi Everyone, I want to provide odometry information for my approach. I use irobot_create_2_1 brown driver. There is the topic /odom that i check. I recognized that the x value is in the pose is absolute . i mean that it just gives the traveled distance along x axis, it does not give - values for moving backward. Angle value is also irrational. Do you know any successful implementation of this. Or has any of you used odometry package for the irobot. Thank you all. Best

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted

answered 2011-12-26 15:47:40 -0500

tjay gravatar image

I just tested the (Brown) driver on a model 4400 Create paired via bluetooth to a Fedora ROS install and wasn't able to reproduce the problem. Moving forward increased X and moving back caused a decrease. Can you give a bit more information about your configuration? I have heard of Creates that simply never report either forwards or backwards movements. Do you have another Create you can try?

As for other known issues that might cause similar symptoms, I can think of a few:

1) You can't rely on the Create's "unpowered" odometry. The on-board controller uses motor power information when determining the distance and direction traveled. Movement information from, for example, turning a Create over and manipulating the wheels will be inaccurate. This also applies to pushing the robot forward or back. The most common behavior in these cases is that the robot will report uniform movement in its last direction regardless of which wheels are turned and in what direction.

2) The odom topic attempts to track the robot's absolute---not relative---position. As a result it is very sensitive to angular error (and the best of the Creates still don't have great angular tracking). Often times the numbers for X will look like nonsense but a visualization will reveal they are relatively (in time and space) accurate and that the reference frame (i.e. what forward is) has-drifted/is-drifting. This is why combining the onboard dead reckoning with a compass or gyro is so popular. rviz or some other way of visualizing the odom information should help you determine if this is your problem. If it is and it doesn't seem due to hardware (see known problem 3 below), you can try attaching the back caster and running the robot on different surfaces and otherwise varying how the Create carries it's load (especially if it is notebook laden). This can sometimes improve things.

3) The Create's odometry seems to be either calibrated at the factory or somehow tuned to the individual Create's motors. Occasionally, you will have a right or left motor (or both) that either from the get-go or as the Create ages simply will not accurately report information. To make matters worse this problem seems to have speeds at which it will occur or not occur on a given motor. Combined with 1 and 2 above, this can lead to frustratingly complicated failures. Some people have a fleet of Creates for this reason, others find the speed at which their robot reports the most accurate information.

I noticed that it's not just our implementation that's causing you trouble. Since many of the other drivers take very different approaches to working around the foibles of the Create platform and you're getting identical behavior, I would try another Create if at all possible. I don't normally lean towards hardware failure and I'm not eliminating the possibility of a subtle bug but it seems unlikely that ... (more)

edit flag offensive delete link more


I forgot to mention a cause of odometry problems specific to your driver: you cannot mix topic-based and service-based control of the bot in a single session because of the way it effects the distance counter used internally by the bot.
tjay gravatar image tjay  ( 2011-12-26 15:51:10 -0500 )edit

i recognized somehing. When the battery is not full, it gives erroneous measurements. If the battery is very close to full, it gives usable data.

searchrescue gravatar image searchrescue  ( 2012-04-01 19:00:33 -0500 )edit

Question Tools


Asked: 2011-12-17 16:14:21 -0500

Seen: 1,521 times

Last updated: Dec 26 '11