IEEE Robotics & Automation Magazine - September 2018 - 51

described in [5], Playful relies on a light robotic architecture
implementing a simple shared memory and resource management system. It also supports runtime instantiation and
deletion of modules via the trigger mechanism [6]. The platform is inspired by TDM and implements a similar declarative programming paradigm, one improved with an original
scripting language as well as support for state machines and
tree structures.
In many respects, Playful is similar to cognitive robot
abstract machine (CRAM) plan language (CPL), with
which it shares some core features: a dedicated language
and a synchronizing of parallel behaviors, with support for
reactive execution targeting real, physical robots [7]. The
two software items nevertheless rely on fundamentally different approaches. CPL is a plan language that is explicitly
goal oriented. On the other hand, Playful does not rely on
planning, as it is based on a mixture of logic, with no explicit declaration of goals. In CRAM, CPL has also been
tightly integrated into knowledge processing for robots,
which provides first-order knowledge representation and
reasoning. In the "Future Work" section, we discuss the
possibility of interfacing Playful with reasoning-enabled
software via evaluation.
Playful encodes behaviors using tree structures, similar to
some frameworks used for robot soccer [8]. Our platform differs from these by the mixture of logic it implements: a combination of conditional ruling, dynamic prioritization based
on resource management, and finite state machines.
Playful's scripting language is used to encapsulate subbehaviors as branches of a behavior tree. Because of the
reactive programming paradigm applied, these branches
may run in parallel, and Playful's syntax is particularly
suitable for specifying parallel actions. The work in [9]
introduced scripting commands for parallel execution as
nonblocking commands in URBI and have since been
implemented in robotic operating systems as post commands (Softbank Robotics NaoQi) or via monitoring
libraries, such as actionLib (the ROS monitoring library).
But in those, parallel commands are created in the context of imperative scripts, where sequential executions are
monitored by classic statements. In contrast, Playful uses
parallel commands in the context of reactive programming. Our platform does not use any of the statements
used by imperative programming languages, such as
while, if, or for. It is based on novel statements that
are suitable for reactive programming: w h e n e v e r ,
targeting, priority of, and switch to. If is
also a keyword used by Playful, but is adapted to reactive programming.
At runtime, the Playful engine reevaluates the behavior
tree at a fixed frequency, leading to activation and/or deactivation of its branches. This differs from the approaches in
which logic is encoded in edges, and module activation relies
on traversing the tree during operation [10].
The leaf nodes of Playful's tree are Python modules that
run their own thread, control access to resources, and manage

start and stop calls. Our software platform provides an application programming interface (API) for the creation of new
modules, and is in this respect similar to PyRobot [11].
Reactive Programming
The reactive programming paradigm, as implemented by
Playful, declares the conditional activation of a
a whenever e

This declarative statement calls for the activation of a
whenever e is evaluated to true, independently of the execution status of the rest of the program. When using reactive
programming, e is continuously reevaluated, and the activation status of a is updated accordingly. By contrast, using an
imperative programming paradigm, conditional activation of
a routine a is monitored via instructions such as
if(e){
a;
}

Based on such an instruction, a will be activated if e is
true at the moment the expression is evaluated. The difference
between imperative programming and reactive programming
is striking. Typically, imperative scripts focus on sequential
execution, monitored via classic statements such as while,
for, and if. In the following imperative example, a2 may
activate only after a1:
if(e1){
a1;
}
if(e2){
a2;
}

In contrast, reactive programming results in a purely
declarative approach in which the commands in the script do
not presume any execution order. Activations of a and b are
asynchronously monitored, and the order of these two statements has no importance:
a1 whenever e1
a2 whenever e2

As the evaluation status of e1 and e2 change, the program above results in four activation patterns: 1) neither a1
nor a2 is activated, 2) only a1 is activated, 3) only a2 is activated, and 4) both a1 and a2 are activated. If a1 and a2 are
modules communicating with a robotic middleware, these
changes in activation patterns will shape the behavior of the
robot. Reactive programming therefore naturally supports
mapping from the world state to patterns of module activation. In addition, it allows the natural expression of behaviors
that may overlap in time.
september 2018

IEEE ROBOTICS & AUTOMATION MAGAZINE

IEEE Robotics & Automation Magazine - September 2018

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