Ask Your Question

the odom of irobot create is not right when move backward

asked 2011-12-13 18:20:52 -0500

clark gravatar image

As stated in the title, when the create robot is moving backwards, the odom value reported for x position is increasing rather than reducing.

I tested both irobot_create_2_1 and turtlebot_node, and the same results observed.

Is this because of the onboard encoder limitation?

edit retag flag offensive close merge delete

4 Answers

Sort by ยป oldest newest most voted

answered 2011-12-26 16:01:18 -0500

tjay gravatar image

In general, dead reckoning style odometry on the Create is... definitely not good. Implementations do of course vary. For the most part this seems to have to do with both hardware limitations and the limitations of building a driver that doesn't run directly on the bot but on top of a serial connection to the Open Interface. I posted a few thoughts that might help in this thread. This is not to knock the Create because it is cheap and tough and pretty much my favorite platform. That said, it only really comes into its own with some kind of navigational aid like a laser scanner, Kinect, or just a web-cam.

You aren't alone in reporting problems with X being absolute across multiple drivers. Can you provide a few more details about your setup? Do you have more than one Create for which this seems to be a problem?

edit flag offensive delete link more

answered 2011-12-31 15:04:18 -0500

clark gravatar image

You are right. I also observed that when the create moves backward by hand push/pull, the odometry is wrong (which is the case I reported in the 1st post), but if the same motion is issued by publishing cmd_vel in ROS program, then negative odom value is reported correctly. And I guess this is due to the fact that the brown driver has considered the movement sign internally.

I also fully agree that the the dometry on the Create is not that good. When I command it to go from staring point to another position(x,y) only based on its odometry, the create moves forward but always deviate away from the target...

edit flag offensive delete link more


Deviation might be coming from the noise in the velocity measurements or slippery. However, you are so right about the odometry problem. It should be a internal problem for the brown driver .

searchrescue gravatar image searchrescue  ( 2012-07-10 18:55:36 -0500 )edit

answered 2011-12-18 04:46:03 -0500

searchrescue gravatar image

In fact, we recognized that almost everything with the odometry package is wrong in icreate. I could not find any successful implementation either. For example if you move only one wheel by keeping the irobot upside down on your knees, you will see both left and right wheel encoders will be non-zero. We made some assumptions for this. We assumed at least some parameters are correct and derived multiple solutions but it did not help either. I believe, the odometry package for icreate robot and the encoder values are unusable. Best.

edit flag offensive delete link more


that's bad; wondering how the odometry is handled when turtlebot_node is used for navigation, according to the related youtube video; whether the calibration procedure can solve it?
clark gravatar image clark  ( 2011-12-19 19:31:44 -0500 )edit
file a ticket for the turtlebot_node and I'll look into it. Typically the nav stack doesn't have the TurtleBot drive backwards so we may have not noticed the problem. But if there is a bug we'll try to fix it
mmwise gravatar image mmwise  ( 2011-12-29 09:53:59 -0500 )edit

answered 2011-12-25 16:58:32 -0500

clark gravatar image

For your reference, I think one old post in ros-users forum explains the odometry issue clearly:

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools


Asked: 2011-12-13 18:20:52 -0500

Seen: 732 times

Last updated: Dec 31 '11