-
Notifications
You must be signed in to change notification settings - Fork 32
Home
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.
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.
- Player is designed to be language and platform independent.
- Player makes no assumptions about how you might want to structure your robot control programs.
- Player allows multiple devices to present the same interface.
- Player is designed to support virtually any number of clients.
- The behavior of the server itself can be configured on the fly.
- Player is free software.
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.