From The Player Project
Player is a network server for robot control. Running on your robot, Player provides a clean and simple interface to the robot's sensors and actuators over the IP network. Your client program talks to Player over a TCP socket, reading data from sensors, writing commands to actuators, and configuring devices on the fly.
Player supports a variety of robot hardware. The original Player platform is the ActivMedia Pioneer 2 family, but several other robots and many common sensors are supported. Player's modular architecture makes it easy to add support for new hardware, and an active user/developer community contributes new drivers.
Where does Player run?
Player runs on pretty much any POSIX platform, including embedded systems (Player has been cross-compiled to run on several ARM- and PPC-based Linux systems). Specifically, Player's requirements are:
- POSIX development environment, with threads (pthreads)
- TCP stack
- A compiler with both C and C++ (we have only tested gcc and Visual Studio 2008/2010, but other compilers may work)
- CMake to generate the build scripts. With the shift to CMake and some extra cross-platform compatibility work, Player can now build natively on Windows.
Features of Player
- Player is designed to be language and platform independent.
Your client program can run on any machine that has a network connection to your robot, and it can be written in any language that supports TCP sockets. We currently have client-side utilities available in C, C++, Python and Ruby. Third party client-side libraries are available for Tcl, Java, and others.
- Player makes no assumptions about how you might want to structure your robot control programs.
In this way, it is much more "minimal" than other robot interfaces. If you want your client to be a highly concurrent multi-threaded program, write it like that. If you like a simple read-think-act loop, do that. If you
- Player allows multiple devices to present the same interface.
For example the Pioneer 2 and RWI drivers both use Player's 'position' interface to allow control of the robot's movement. Thus the same control code could drive both kinds of robot. This feature is very useful when combined with the Stage simulator; control programs written for Stage's simulated robots will often work unchanged on real hardware.
- Player is designed to support virtually any number of clients.
Have you ever wanted your robots to "see" through each others' eyes? Now they can. Any client can connect to and read sensor data from (and even write motor commands to) any instance of Player on any robot. Aside from distributed sensing for control, you can also use Player for monitoring of experiments. For example, while your C++ client controls a robot, you can run a graphical visualization tool elsewhere that shows you current sensor data and a logger program to save data for later analysis. On-the-fly device requests allow your clients to gain access to different sensors and actuators as needed for the task at hand.
- The behavior of the server itself can be configured on the fly.
See the user manual for details on changing sensor data rate and other features.
- Player is free software.
Released under the GNU Public License. If you don't like some part of how it works, change it. And please send us your patch! : This is not possible in other proprietary robotics suites, as Microsoft Robotics Studio.
How Player works
The Player server provides an abstract interface to robotic devices, including mobile robot bases, sensors, etc. Player communicates with these specific devices using device drivers, but provides to its clients standard device interface. For example, Player may use SICK LMS-200 and Pioneer drivers, but simply provides to clients "laser" and "position" ("position" is a movable mobile robot base), "sonar", etc. interfaces. This allows clients to be portable to other robots. The same client could work with a Player server running the "rflex" robot driver on, say, a RWI B21R or even a Roomba and a Hokuyu URG laser. Or, custom drivers you write for your own robot and devices. Player drivers are kept as plug-in modules. The Player config file determines which drivers to load and any parameters they may require.
Stage and Gazebo, on the other hand, do not simulate specific devices (such as a SICK LMS-200 or Pioneer robot), instead they have configurable abstract device models (such as "laser" and "position"). These models are defined and configured in the world file. Though often a model that imitates a specific device is used -- for example a "laser" model with a 180 degree field of view and angle resolution approximates a typically configured SICK LMS-200 -- Player device drivers are never used with Stage or Gazebo. Currently, Stage and Gazebo models are built-in to their respective simulators; new models (for a completely new kind of device) can be added by modifying Stage. To use Stage with a Player server instead of real devices, you load the Stage's plugin driver into Player. The Stage simulator can then provide any of a number of standard interfaces ("position", "laser", etc.) that it supports.
Stage and Gazebo are different simulators. They have different configuration (world) files and implement different (though overlapping) sets of simulated devices in different ways.
The next diagram shows how simply player works:
User programs are usually linked with client libraries, the client libraries manage the communication with the player server and provides a clear interface to the programs. The same programs can be used for the simulators and for the real robot. The configuration file of the Player server defines how the server talks with the robot hardware (in which ports are the devices attached, etc.) or the simulator. The simulator configuration file defines how to simulate the robot, how the worlds looks like, etc.
Since Player provides standard interfaces to the client, the client operates the same no matter what driver is loaded into Player, so long as those drivers provide the required device interfaces.