Copyright Brian Gerkey and contributors 1999-2011, and beyond.
Part of the Player Project (http://playerstage.org)
Player is a robot device interface. What does that mean? If you're familiar with operating systems (OS) terminology, Player is a hardware abstraction layer (HAL) for robotic devices. Your OS (Linux, Mac OS X, etc.) hides the details of your computer's hardware by defining generic concepts such as "mouse" and "printer," with each having a standard interface. Programs such as word processors can (to a great extent) avoid knowing the details about your particular mouse or printer, as long each adheres to the appropriate interface. The details of making a particular mouse, say, support the standard "mouse" interface are handled by a driver.
Player serves the same purpose for robotic devices, making it a kind of robot OS. Player defines a set of standard interfaces (Interface specifications), each of which is a specification of the ways that you can interact with some class of devices. For example the position2d interface covers ground-based mobile robots, allowing them to accept commands to make them move (either velocity or position targets) and to report their state (current velocity and position). Many drivers support the position2d interface, including p2os, obot, and rflex, each of which controls a different kind of robot. The job of the driver is to make the robot support the standard interface. This way, Player control code that works with one robot will work (within reason) on another robot.
Player also provides transport mechanisms that allow data to be exchanged among drivers and control programs that are executing on different machines. By far the most common transport in use now is a client/server TCP sokcet-based transport (see Quick start for an example of this usage). In this setup, the player server is executed with a configuration file (Writing configuration files) that defines which drivers to instantiate and how to bind them to hardware. The drivers run inside the player server (often in multiple threads), and the user's control program runs as a client to that server. Client Libraries are available in various languages to facilitate the development of such control programs. Other transports can be used instead; an experimental JINI-based transport is also available.
Though most Player drivers directly control hardware, recently a number of abstract drivers have been developed. An abstract driver uses other drivers, instead of hardware, as sources for data and sinks for commands. The main use of abstract drivers is to encapsulate useful algorithms in a way that they can be easily reused. For example, the amcl driver is an implementation of adaptive Monte Carlo localization, a well-known algorithm for probabalistic localization of a mobile robot. This driver supports both the position2d interface (so it can be used directly in place of odometry) and the more sophisticated localize interface (which allows for multiple pose hypotheses to be considered). In addition to providing this incredibly useful implementation of a particular localization algorithm, by defining such standard interfaces we build up an environment in which alternative algorithms and implementations can be developed and tested. Other abstract drivers include vfh, wavefront, and laserbarcode. Ideally, Player will become a common development platform and community code respository for such algorithms.
This document describes Player version 3.1.x, which represents minor changes from the 3.0.x line, and significant changes from the 2.x line. The information contained herein does not apply to earlier versions of Player.
All Player source code is distributed under the terms of the GNU General Public License v2 ("GPL"). A copy of this license is included with the sourcecode in the files COPYING.
With the exception of the libplayerdrivers library, all Player source is simultaneously distributed under the terms of the GNU Lesser General Public License v2.1 ("LGPL"). A copy of this license is included with the sourcecode in the files COPYING.lib. Users may use dual-licensed portions of Player under the GPL or the LGPL, at their choosing.
Player documentation is distributed under the GNU Free Documentation License ("FDL").