| ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange |
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?
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?
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.
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...
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 .
For your reference, I think one old post in ros-users forum explains the odometry issue clearly:
http://ros-users.122217.n3.nabble.com/iRobot-Roomba-vs-Create-td2019380.html
Asked: 2011-12-13 18:20:52 -0600
Seen: 944 times
Last updated: Dec 31 '11
ROS Answers is licensed under Creative Commons Attribution 3.0 Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.
