Player is designed to be language and platform independent. Your client program can run on any machine that has network connectivity to your robot, and it can be written in any language that can open and control a TCP socket. Client-side utilities are currently available in C, C++, Tcl, LISP, Java, and Python. Further, 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 like to control your robot interactively, try our Tcl client (or write your own client utilities in your favorite interactive language).
Player is also 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 Tk GUI client elsewhere that shows you current sensor data, and a Python client that logs data for later analysis. Also, on-the-fly device requests allow your clients to gain access to different sensors and actuators as needed for the task at hand.
In addition to controlling the physical hardware, Player can be used to interface to the robot simulators Stage and Gazebo.
Last but not least, Player is Free Software. If you don't like how something works, change it. And please send us your patch!
As a simple example of the use of Player, consider Figure 1.1 (note that for clarity, we leave out several protocol-level interactions). The server is executing locally on the computer to which the devices of interest are connected. In many cases, this computer is the robot itself, but it could also be, for example, a desktop machine attached to a SICK laser range-finder. The client can execute anywhere that has network connectivity to the machine hosting the server.
First, the client establishes a TCP socket connection to the server. The client next sends some messages to the server to open the devices in which the client is interested. After that, the server continuously feeds data from those devices to the client, and the client exerts control by sending appropriate commands back to the server. Very simple.
