|
===Player Project===
The [[Player Project]] (formerly the '''Player/Stage Project''') is a project to create [[free software]] for research into [[robotics]] and [[sensor]] systems.<ref>Gerkey, B., Vaughan, R., and Howard, A. (2003) The Player/Stage Project: Tools for Multi-Robot and Distributed Sensor Systems. ''Proceedings of the International Conference on Advanced Robotics
{| class="wikitable" style="border:1px solid lightblue" align="justify" valign="center"
'' 317-323</ref> Its components include the ''Player'' network server and the ''Stage'' robot platform simulators. Although accurate statistics are hard to obtain, Player is one of the most popular open-source robot interfaces in research and post-secondary education.<ref>Collet, T. H. J., MacDonald, B. A., and Gerkey, B. (2005) Player 2.0: Toward a practical robot programming framework. ''Proceedings of the Australasian Conference on Robotics and Automation (ACRA)''</ref> Most of the major intelligent robotics journals and conferences regularly publish papers featuring real and simulated robot experiments using Player and Stage.
|-
| style=" border:1px solid lightblue" align="justify" valign="center" |
* <u>System organization/decomposition</u> - Player is a device server (application server) with the collection of dynamically loadable device shared libraries. The main portion of this server is custom communication protocol which enables client-server communication model. Player is implemented in C++ and uses POSIX compliant pthread interface for multithreaded applications. Player can be viewed as a multithreaded application server providing applications/services to client programs. Here application/services are devices which are used by client programs. Since devices (applications/services that is) can be loaded dynamically, Player can be considered as "some way in between monolithic application and modular middleware+services" approach. A main Player server thread listens to client side connections and spawns threads whenever the client program asks a service from some specific device. Each device (device program) has its own thread of execution. As can be seen from the figure 1, the threads communicate via a shared global address space. Each device has an associated command and data buffer. Whenever the client needs to access some specific device, it sends a command which is queued in a command buffer and then read by the device. The same applies to the data buffer: The device writes the data to the buffer and the client side program reads it. Since Player does not implement any device locking mechanism whenever multiple clients are connected to a Player server, one can overwrite the commands of other clients. This applies to commands and data (it is noteworthy to mention that data and commands are implemented as asynchronous one-way continuous streams) but not to configuration requests which can be used to access specific hardware features (this mechanism is implemented as a two-way synchronous request-reply interaction). One can also define the frequencies at which a particular device provides data to the client, by default this value is 10 Hz. Depending on the needs of a client data can be served in PUSH or PULL modes, by default the mode is PUSH, so server/devices send all data available to the client.
|-
| style="border:1px solid lightblue" align="justify" valign="center" |
* <u>Communication approach</u> - Player, of current version, decomposed into two main parts: Player core, which is the core Player API, device drivers, driver loading code, configuration parsing code and driver registry. Transport layer, this part is independent of device drivers and can be any type of transport system, of current version it is implemented as two libraries, libplayertcp and libplayerxdr, and is based on TCP communication protocol using sockets (and message queues). Other transport types which can be used are JINI and CORBA based (means there is support for RMI and RPC).
|-
| style="border:1px solid lightblue" align="justify" valign="center" |
* <u>Platform/language support and other system features</u> - Support for plugin drivers and simulation environments Stage and Gazebo. No device locking mechanism, client side data is always older than server side data because of the "buffer sit" times. Devices are treated as files with read/write access. Most of the devices adopt character device model. On the client side, programs communicate with server/devices through their respective local proxycies. There is no considerable support for fault tolerant capabilities. One of the features which can be accounted for is the “libplayererror” library, which can be used to perform error reporting. Also, there are some procedures to perform thread locking in order to avoid conflicts. Player is supported on most of the UNIX flavors and under Windows using Cygwin. Client programs can be written in any language providing socket mechanism, e.i. TCL, Python, C, C++, Java etc.
|-
| style="border:1px solid lightblue" align="justify" valign="center" |
* <u>Fault tolerance and robustness aspects:</u> Though the Player project has been active for quite a long time, there have been no considerable developments to improve its fault tolerant capabilities. One of the features which can be accounted for is the libplayererror library, which can be used to perform error reporting. Also, there are some procedures to perform thread locking in order to avoid conflicts. From the perspective of robustness, it should be possible to implement planning, learning, state estimation or similar functionalities for an application based on Player. In the future the authors want to implement a resource awareness attribute, i.e. enable the programs to perform resource discovery and change their behavior according to the availability of resources.
|}
=== RT-middleware Projects ===
|
