The site is read-only. Please transition to use Robotics Stack Exchange
| ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange |
 | 1 | initial version |
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 all implementations would have errors so similar to each other. In any case, I'd love to hear about more about your setup. There might be something we can do/recommend even if the driver isn't to blame.
And to answer your implied question: in general the Create's odometry as exposed by the open interface (on which most drivers are built) is... not the best... when compared to other differential drive bots. It can be fine for tasks that pose immediate feedback but it is not in general accurate enough for any kind of dead reckoning situation on its own.
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.
