Playing with the Player Project

The Player Project is a robot-control software framework for interfacing with PC-based robots. Learn how to use it to interface with sensors, actuators and even full research robots.

Playing with Player

So far, our robot is awake, alert and ready to be told to do something
interesting. Let's give it something to do. The CoroBot robot comes with
a number of sensors and actuators—probably the easiest of which to
interface with are the front- and rear-facing infrared ranging sensors and
the mobility base's drive motors. Thus, we can write a small C program
to talk to the Player server, read the IR sensors and drive the robot
until it is 10cm away from an obstacle in front of the robot.

The first thing we have to do to interface with the Player server is
open up a connection to it. For the sake of brevity, we will skip a lot
of error checking, but you can download the full version of the code
from the LJ FTP server (see Resources).

This code defines the variables we will use to talk to the Player
server and the device interfaces in which we are interested:

The clientHandle is used for talking to the Player server
itself. The second position2d interface talks to the position2d interface,
providing us with encoder information about how the wheels are moving
and allowing us to send motor commands to the robot. We'll ignore the
encoder information for this example. Lastly, the IR interface gives us
information about the distances that the robot's IR sensors are reporting.

The next code snippet uses these proxies to interface with the server
and these devices:

We start off by connecting to the Player server and configuring our
connection. We want to get new messages from the server only when we
are ready for them, so we configure the connection for a pull-type
arrangement. And, because we want only the most recent information (we
don't care what the IR sensors were indicating a second ago, we care
about what they are saying right now), we tell the server to report
only the most recent data. If we really wanted, we could let Player ensure
that every IR message was delivered, but that might result in getting
less-than-fresh data and possibly driving into a wall.

After our connection is configured, we open up the position2d interface
on the Player server and subscribe to it. Then, we do the same with the
IR interface. So far, so good. Now we need to get the state of the IRs
from the robot and tell it how to move the motors:

Each time through the loop, we try to read the newest data from the
robot. After a little sanity checking, we take the ranges reported by the
IR sensors and feed them into a controller function. This controller
does some magic processing (we'll talk about that later) and returns
information on how we should drive the robot. Finally, we pass these
driving commands back to the Player server and start it all over again.

All that's left now is to provide a runController function
that maps from IR sensor readings to drive commands. The CoroBot driver
accepts numbers in the range of –1.0 to +1.0 to tell how to drive the
robot forward and backward: +1.0 means 100% power forward, –1.0 means
100% power in reverse, and 0.0 means stop. It accepts the same range
for telling the robot how to turn: –1.0 means turn full power left, +1.0
means turn full power right, and 0.0 means drive straight ahead. Noting
that the IR readings are provided in meters, we can use the following
P-controller to drive our robot forward until we are 10cm away from a
front obstacle. We even get a bonus for free—if we are closer than
10cm away, the robot will back up a bit until it is at the proper distance:

Building on the design we showed earlier, we can see how our drive-by-IR
program interacts with the Player infrastructure. The CoroBot
configuration file loads the phidgetIFK driver, which exposes an aio:0
device. This device allows the CoroBot driver to read the robot's onboard
infrared sensors. The CoroBot driver also exposes the position2d and
IR interfaces, which the drive-by-IR program reads with the help of the
libplayerc library (Figure 5).

Figure 5. The Relationship between
Several Devices and Interfaces When Using the Drive-by-IR Program

The Player Project offers a lot of functionality that there just isn't
room to get into in one article. This includes robot simulation, support
for numerous commercial robots of many different prices and qualities,
and support for a whole slew of readily available devices. Its plugin
system even allows you to build your own drivers for new devices, either
to support new hardware or to implement new experimental algorithms. Give
it a try, and give your computer a chance to stretch its legs.