IEEE Robotics & Automation Magazine - September 2013 - 85

Device-Specific
Connection
(Serial, Etc.)

Shared Global Address Space

Device D0
Thread
Physical
Device D0

Curre

Client C0
Reader Thread

Device D0
Data
Buffer

Client C0
Writer Thread

Device Dn
ent Command
r
r
u
C
and Buffer
Comm

Client Cx
Reader Thread

Data

Device Dn
Thread
Physical
Device Dn

Device D0
ent
Curr nd Command
a
Buffer
Comm

TCP
Connection

Curre
Data

Device Dn
Data
Buffer

Comm

ands
to
All De
vices

Client C0

from
Data
vices
All De

Comm

ands
to
All De
vices

Client Cx

from
Data
vices
All De

Client Cx
Writer Thread

Figure 3. Architecture of Player for versions prior to 2.0.

interface and that developers would be happy managing their
own socket themselves. Over time, it was realized that the client API was just as important to end users.
One of the most important features of Player has always
been that it makes no assumptions about the structure of
robot control programs. This was a conscious design decision from the beginning. It is perhaps the feature that most
contributed to its early popularity. Having struggled with
the limitations imposed by Ayllu, the Player developers
decided that an open approach using a library-style API,
rather than structured controllers, would give researchers
more flexibility. Player therefore took a minimalist
approach when compared with other architectures of the
time, and even most architectures of today. In Player, the
researcher is free to create controllers of any complexity
and style they choose, from highly concurrent controllers
to simple read-think-act loops.
The design of the Player architecture, shown in Figure 3,
was asynchronous, allowing clients and devices to operate at
their own speed. The server at this point used a large number
of threads: two for each client (one reader, one writer) and one
for each active device, as well as the thread listening for new
clients.
Communication between clients and devices was via
buffers in the server. Each device had two buffers, which
stored the latest command and data. If new data or a new
command arrived before the old was read, it overwrote the
previous contents. This design decoupled devices from clients, allowing all entities to operate at their own rate. Internally, devices communicated by global shared memory.
The design did have its drawbacks. The fixed rate
meant that clients could not determine whether the data it
had just received was new or a repeat of old data (a "pull"

mode was later added to give clients control over receiving data). The laser scanner operated at 5 Hz, for example,
meaning laser data was out of date half the time. However,
Player was intentionally designed this way for simplicity;
it allowed clients to perform blocking reads.
By 2001, the internal server design had changed little.
The authors of [4] formally defined Player as the protocol,
not the server, and introduced the motivation for Player's
use of a socket abstraction:
● Distribution-Clients and servers could exist anywhere
and in any number.
● Independence-Clients could be written in any language on any operating system supporting sockets.
● Convenience-Clients just had to connect and ask for
access to the devices they were interested in to start
receiving data.
The concept of virtual devices was first explicitly mentioned in 2001. A device could be pure software, taking
data from a hardware device and transforming it, before
presenting it to clients. This concept allowed algorithms
to be widely shared.
In 2001, Player was beginning to grow in popularity. Compared with the state of the art at the time, Player took a radically different approach. Architectures focused on creating a
development environment that suited a particular control philosophy. For example, Ayllu enforced a concurrent behaviorbased control structure [1]. COLBERT/Saphira similarly
focused on behavior-based control, using fuzzy blending [5].
Architectures at this time often restricted the programmer to a
specific language designed for the architecture, such as Ayllu's
C-like language. It was also still common for research robots to
come with an unmodifiable library for control, with researchers working within the constraints of this library.
september 2013

IEEE ROBOTICS & AUTOMATION MAGAZINE

Table of Contents for the Digital Edition of IEEE Robotics & Automation Magazine - September 2013