IEEE Robotics & Automation Magazine - September 2013 - 83

Work Begins on Arena Simulator
"On Device Abstractions" Published
Proposals for a More UNIX-Like
RETF Discusses Player as a "Defacto Standard"
Approach to Robot Software
Socket Interface to Arena
ArenaServer Written to Run Arena
Controllers on Pioneer Robots
Basic Concepts of Golem Laid Out
Work Begins on What Will Become Player 2.0
Golem Created to Replace Ayullu
and ArenaServer
Dynamically-Sized Arrays Support
Golem/Arena Interface Created
ArenaServer Obseleted
Property Bag Support
Golem/Arena Renamed Player/Stage
Pluggable Interfaces Support
Player/Stage Announced to the World
"Player 2.0: Toward a
Blug Reports from Outside Start Arriving Practical Robot
Player Gains Windows Support
First Outside Contribution
Player 3.0 Released
Programming
Project Hosting Moved to SourceForge Framework"
"Most Valuable
Published
Player" published
Passthrough Driver Developed
Player Summer School on Cognitive
First Direct Funding for Player.Stage
Robots
Gazebo Started
Microsoft Robotics Studio (MSRS) 1.0
RADISH Established
Released
ORCA 2
Released
Japanese RT Middleware
Project Begins
Orocos Proposed
Orocos Development Begins
First Orocos Release
1998

1999

2000

2001

2002

2003

2004

2005

MSRS 2008
goes free
OpenRTM-Aist OpenRTM-Aist
0.4.2
1.0
Korean National OPRos
Project Begins
ROS Begins Development ROS 1.0
Released
2007
2008
2009
2010
2011

ORCA 2 Switches to ICE
OpenRTM-Aist
0.4.0

2006

Figure 1. Timeline showing major points in the development of Player, contrasted with other events in robot software.

An Evolving Design
The design of Player has evolved and changed considerably over the years. However, the core principles of the
architecture remain the same. It can still perform its original task, acting as a device server, but it can also compete,
featurewise, with the latest component-based architectures. In this section, we discuss the evolution of Player's
design from its humble origins as a side project to make
one lab's robots easier to use.
Origins of a Robot Architecture
In 1998, the Interaction Lab at the University of Southern
California (USC) used Pioneer robots from ActivMedia
(now known as MobileRobots). These robots ran on the
Ayllu middleware [1]. Ayllu is a behavior-based architecture
targeted at distributed multirobot systems. It builds on the
design of single-robot behavior-based control architectures,
in particular the Subsumption [2] style of controller. However, programming robots using it required following its controller design. This was quite limiting for researchers who
wanted to try different controller styles. It also required the
use of its own C-like custom language, adding another
hurdle for developers.
What became Player was developed both to replace
this somewhat restrictive control architecture and to
allow controllers written for the new simulator developed
in the lab, named "Arena," to be executed on real robots
without changes.

At first, controllers written for Arena were compiled indirectly, but it soon gained a socket interface. This allowed a
separation between the simulator and robot controllers. It also
led to Arena's developers writing large pieces of robot controller code for use in Arena, which they also wanted to try on
the lab's Pioneer robots. Rather than porting their controllers
to Ayllu, they developed ArenaServer.
ArenaServer ran on a Pioneer robot and presented the
same socket interface as the Arena simulator. It was tied to
both Ayllu and ActivMedia software but allowed robot
control code designed for Arena to run, unchanged, on the
lab's real robots.
This experience led the developers of Arena and Arena
Server to design the generic robot interface of their
dreams, based on some simple ideas and UNIX concepts of
abstraction:
● be as unprescriptive as possible
● present a socket interface to the robot
● hide all the details of dealing with the hardware
● be free and open
● work well with a simulator.
A new server for the Pioneer robots was developed on the
basis of these ideas. This time, however, a custom driver was
written for interacting with the robot's controller. The new
server was named "Golem." An interface between Golem and
Arena was created, allowing controllers written for one to
work with the other. Golem was soon renamed as Player and
Arena as Stage.
september 2013

IEEE ROBOTICS & AUTOMATION MAGAZINE

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