Player does not properly get odometry data for Create in multithreaded application

Question

I am using Player (Player/Stage) on the iRobot Create. The interface for getting odometry data from the robot is fairly simple: call playerc_client_read, and then if you've properly subscribed a playerc_position2d proxy, you should be able to access the proxy's members px, py, pa for distance traveled in x and y (in meters); and rotation (in radians).

I have no issue with doing this in a single threaded application -- all the odometry data is perfectly where I need it to be.

However, when I try to move the robot controller to its own thread (with pthreads), I run into some issues. The issue is that only px seems to be updated. py and pa always remain 0.

Here's the gist of the robot thread

//declare everything (including the playerc_client_t* object and playerc_position2d_t* object)
//connect to server (in pull mode or push mode, it doesn't seem to matter)
//subscribe to position2d proxy

while(!should_quit) {
playerc_client_read(client)
double xPosition = position2d->px;
double yPosition = position2d->py;
double radians = position2d->pa;

//do some stuff
sleep(10 milliseconds)
}
cleanup and unsubscribe

and sure enough, only xPosition is ever set while yPosition and radians remain 0 no matter how the robot moves.

I couldn't find anything else online, is this a known bug? Has anybody else had this issue? Can someone provide insight as to why this may be happening? Thank you.

Full disclosure: I'm a graduate student and this is for a class project.

Answer 1

The issue here is not necessarily with threading.

What we found is that the Create's internal odometry is very inconsistent, especially when a netbook is sitting atop it.

To get any semblance of an accurate reading, one has to set the angular velocity high enough (higher than 0.11 rads/s in our case).

This site helped explain a few things -- namely that the Creates use motor power to determine odometry, and not wheel counters or any kind of analog.

To get accurate odometry for dead reckoning tasks, one either needs to build their own accurate estimator, or use some external sensors that give better information about positional changes.

Our specific problem was caused by a thresholding in the multithreaded case that set angular velocity to low to register a change, whereas the sequential code did not have such thresholding.