EXPLORING INTERFACES IN A DISTRIBUTED
COMPONENT-BASED PROGRAMMING FRAMEWORK FOR
ROBOTICS
A. C. Domínguez-Brito, F. J. Santana-Jorge, J. Cabrera-Gámez, J. D. Hernández-Sosa,
J. Isern-González and E. Fernández-Perdomo
Instituto Universitario SIANI, Dpto. de Informática y Sistemas
Universidad de Las Palmas de Gran Canaria, Las Palmas de Gran Canaria, Spain
Keywords:
Robot programming environments and languages, Component-based software engineering.
Abstract:
CoolBOT is a C++ distributed component-based programming framework for robotics. A system can be seen
as a distributed network of software components interconnected by port connections where system behavior
emerges from the interaction and independent execution of the components integrating the system. Recently
we have endowed CoolBOT with two new types of software components: views and probes. On one side, in
order to separate and decouple robot control from graphical displays, we have introduced the concept of view
as an integrable, composite and reusable graphical interface available for CoolBOT system integrators and
developers. On the other side, probes have been devised as interfaces for interoperability with non CoolBOT
software.
1 INTRODUCTION
Some of the significant approaches within the
robotics community based on the CBSE (Compo-
nent Based Software Engineering) (George T. Heine-
man and William T. Councill, 2001) paradigm are
G
en
oM/BIP from LAAS Openrobots project (Mal-
let et al., 2010)(Basu et al., 2006)(Bensalem et al.,
2009)(Openrobots, 2011), Smartsoft (Schlegel et al.,
2009)(SmartSoft, 2011), OROCOS (Orocos, 2011),
ORCA (Brooks et al., 2005), OpenRTM-aist (Ando
et al., 2008) and ROS (ROS, 2011).
In this paper we want initially to focus our at-
tention on system graphical interfaces which consti-
tute a specific kind of software component on their
own, that we normally find in robotic CBSE devel-
oping software approaches. Thence, in ROS (ROS,
2011) we can find the following tools: rviz for
3D visualization, rxbag for showing “off-line” sen-
sory data collected during runtime, rxplot for scalar
data visualization in runtime and rxgraph to show a
system graph also in runtime. Similarly, in ORCA
This work has been partially supported by: research
project TIN2008-06068 funded by the Ministerio de In-
novación y Ciencia, Gobierno de España, Spain; research
project ProID20100062 funded by the ACIISI, Gobierno de
Canarias, Spain; and by European Union’s FEDER funds.
(Orca, 2011) the following utilities are available:
RegistryView to show a graphical representation
of the structure of a component, and OrcaView2d
and OrcaView3d which are respectively 2D and 3D
graphical interfaces for sensory data. Equally the
Openrobots project (Openrobots, 2011) provides the
powerful tool gdhe for system 3D visualization.
Recently we have made freely available a dis-
tributed CBSE C++ framework for programming
robotic systems developed at our laboratory, as an
open source initiative we have called The CoolBOT
Project (Domínguez-Brito et al., 2007; CoolBOT,
2011). In CoolBOT, graphical interfaces are software
components on their own called views. On the other
side and considering the problem of interoperability
of CoolBOT-based systems with non-CoolBOT soft-
ware, we have also introduced the concept of probe.
The rest of this document is organized as follows.
In section 2 we will introduce briefly an overview
about CoolBOT. Next, we will pass to focus on the
support for views and probes provided by the frame-
work respectively in sections 3 and 4. Finally, last
section is devoted to present briefly the conclusions
we have drawn from the work presented in this paper.
667
C. Domínguez-Brito A., J. Santana-Jorge F., Cabrera-Gámez J., D. Hernández-Sosa J., Isern-González J. and Fernández-Perdomo E..
EXPLORING INTERFACES IN A DISTRIBUTED COMPONENT-BASED PROGRAMMING FRAMEWORK FOR ROBOTICS.
DOI: 10.5220/0003881706670672
In Proceedings of the 4th International Conference on Agents and Artificial Intelligence (SSIR-2012), pages 667-672
ISBN: 978-989-8425-95-9
Copyright
c
2012 SCITEPRESS (Science and Technology Publications, Lda.)
2 CoolBOT OVERVIEW
CoolBOT (Domínguez-Brito et al., 2007) is a C++
distributed component oriented programming frame-
work aimed to robotics developed at our laboratory
which follows the CBSE paradigm for software de-
velopment.
integration
machine
integration
machine
machine
network
web browser
view
Robot
view
Map
java
applet
probe
ND
Navigation
GridMap
TCP/IP
connections
port
connection
input
port
output
port
commands
sensory
info
commands
map
virtual
scan
commands
commands
planner
map
sensory
info
MbICP
view
MbICP
view
MbICP
view
Pla-
nner
Player
Robot
Short
Term
Planner
commands
Figure 1: CoolBOT. Secure Navigation System.
Fig. 1 gives a global view of a a real system de-
veloped using CoolBOT. The example shows a se-
cure navigation system for an indoor mobile robot
based on the ND+ algorithm for obstacle avoidance
(Minguez et al., 2004). It has been implemented at-
tending to (Montesano et al., 2006).
The system is organized using two CoolBOT in-
tegrations, one only formed by CoolBOT compo-
nent instances, and the other one containing CoolBOT
view instances. The former one is really the integra-
tion which implements the navigation system. As we
can observe, it consists of five component instances,
namely: PlayerRobot (this is a wrapper compo-
nent for hardware abstraction using the Player/Stage
project framework (Vaughan et al., 2003)), MbICP
(this is a component which implements the MbICP
laser-based scan matching algorithm (Minguez et al.,
2006)), GridMap (this component maintains a grid
map of the surroundings of the robot built using
robot range laser scans, it also generates periodi-
cally a 360
o
virtual scan for the ND+ algorithm),
NDNavigation (implements the ND+ algorithm) and
ShortTermPlanner (a planner which uses the grid
map for planning paths in the robot surroundings). On
other machine another integration is shown hosting
four view instances through which we can control and
monitor the system remotely. In addition, in another
machine, a web browser hosting a Java applet using
a CoolBOT probe to connect to some of the compo-
nents of the system.
As we can observe in Fig. 1, CoolBOT pro-
vides means for distributed computation. A Cool-
BOT integration is an application (a process) which
integrates instances of CoolBOT components and
views. As mentioned previously, port connections are
multiplexed using TCP/IP connections between soft-
ware components in different integrations, but in the
same integration, port connections are supported us-
ing thread synchronization resources (locks, condi-
tional variables, mutexes and shared memory). Inte-
grations can be instantiated in any machine and port
connections can be established dynamically at any
moment, whether local or remote.
In general, in CoolBOT we can find three types
of software components in terms of integration, de-
ployment and composition: components, views and
probes. All these three types are software components
in the whole sense, since we can compose them indis-
tinctly and arbitrarily without changing their imple-
mentation to build up a given system. Fig. 2 depicts
the software abstraction layers involved when using
CoolBOT.
GNULinux/Windows
OS API
ACE
(threads, mutexes, cond. variables, time, etc.)
(sockets & data marshalling)
CoolBOT threads,
ICC mechanisms & time
DC3 Protocol
input &
output
ports
controllable
&
observable
variables
port
packets
component
exceptions
port
connections
timers &
port
watchdogs
utility
classes
CoolBOT components, views, probes, integrations & services
Operating
System
OS APIs &
Utility Libraries
CoolBOT C++
framework
infraestructure
CoolBOT C++
API
probe
component
component
component
view
view
component
component
view
probe
System
Level
Figure 2: Abstraction layers in CoolBOT.
CoolBOT Components have been devised to im-
plement any kind of functionality. When connected,
they form port connections, as depicted on Fig. 1.
Through them, they interchange discrete units of in-
formation termed port packets. Port connections
are established dynamically in runtime, are unidirec-
tional, and follow a publish/subscribe paradigm of
communication (Brugali and Shakhimardanov, 2010).
Output and input ports may be defined out of a set
of available typologies (more details in (Domínguez-
Brito et al., 2007)).
CoolBOT components are distributed active ob-
jects (Ellis and Gibbs, 1989), in fact they can be seen
as “data-flow machines”. More formally, CoolBOT
ICAART 2012 - International Conference on Agents and Artificial Intelligence
668
<<component>>
control
port
monitoring
port
user
input
ports
user
output
ports
time, timers, watchdogs, component
exceptions, internal events, controllable
and observable variables, threads
synchronization, priorities
component
threads
network
threads
end
starting
ready
suspended
error
error
recovery
running
error
error
recovery
component
automaton
Figure 3: CoolBOT. Component structure.
components are modeled as port automata (Stewart
et al., 1997). Fig. 3 provides a view of the struc-
ture of a component in CoolBOT. Its external inter-
face comprises all its input and output ports, its types,
and the port packets it accepts through them. There
are two special ports (control and monitoring ports)
in any component, the rest are user defined. Inter-
nally a component is organized as an automaton, as
illustrated in Fig. 3. The part of this automaton which
is common to all components is called the default au-
tomaton, which allows for an external supervisor to
control a component’s execution using an standard
procedure. Depicted by meta-state running in Fig.
3 (the dotted circle) each component defines its user
automaton which is specific for each component and
implements its functionality. Transitions among com-
ponent’s automaton states are triggered by incoming
port packets, and also by internal events. The user
can associate C++ callbacks to transitions. As active
objects, CoolBOT components can organize its exe-
cution using multiple threads of execution as depicted
on Fig. 3. All components are endowed at least with
one thread of execution; the rest, if any, are user de-
fined.
We have postponed deliberately the presentation
of views and probes to the following sections, sections
3 and 4 respectively, so we elaborate on them next.
3 VIEWS
CoolBOT views are decoupled, integrable, composite
and reusable graphical interfaces (GUIs) available for
CoolBOT system integrators and developers, which,
as software components, may be interconnected with
any other component, view or probe.
In Fig. 4 we can observe the structure of a view
in CoolBOT. As we can see views are also endowed
with an external interface of input and output ports.
<<view>>
user
input
ports
user
output
ports
time, timers, threads
synchronization
network
threads
graphical
interface
Figure 4: CoolBOT. View structure.
Although, contrarily to components, views internally
are not modeled using an automaton, as we can ob-
serve on the figure.
In fact, views use the same infrastructure provided
by the framework to intercommunicate with other
components, views and probes, residing them either
locally in the same integration, or remotely in another
one. Contrarily to CoolBOT components, views have
been devised to implement no functionality, except
the implementation of a GUI in a typical window-
based graphical library, in fact, the current views al-
ready developed and operational which are available
in CoolBOT have been implemented using the GTK
graphical library (GTK, 2010).
Thence, to develop a CoolBOT view, we ini-
tially create a workspace (using a specific tool termed
coolbot-ske). This workspace is a directory con-
taining a template for generating our future view us-
ing coolbot-c (a .coolbot-view file), CMake tem-
plate files needed to compile the view, and a pkg-
config file (pkg-config, 2011) necessary to include
and link the view in whatever application we would
like to integrate our views (usually a CoolBOT inte-
gration), once completely developed.
Once created the workspace, using the description
language accepted and using another tool, the Cool-
BOT compiler, coolbot-c, we describe the structure
our component will have, mainly its external interface
of input and output ports. Then, using coolbot-c the
view is mapped into a C++ class, in particular Cool-
BOT generates the GTK skeleton of this C++ class, in
the sense that the class is not completely functional,
the functionality should be completed by the devel-
oper/user. Concretely, the part which should be com-
pleted by the user is precisely its specific graphical
implementation, which it is done using GTK directly
or using a GTK GUI graphical programming soft-
ware like Glade (Glade, 2010). Mind that, the view’s
external interface of input and output ports is pro-
vided transparently by the framework and generated
EXPLORING INTERFACES IN A DISTRIBUTED COMPONENT-BASED PROGRAMMING FRAMEWORK FOR
ROBOTICS
669
Figure 5: Map view’s snapshot.
/*
* File : gri d - gt k. coolbot - view
* D e s cri p tio n : d esc r ipt i on f i l e for G ridG t k view
* Date : ...
* G e n era t e d by c o o l b o t - ske
*/
view G ridG t k
{
header
{
author " ... ";
description " G ridG t k View ";
institution " .. . ";
version " .. . "
};
constants
{
private D EF A ULT _ RE F RE S HIN G _P E RIO D =50 0 ; // mil l ise c ond s
...
};
input port R OBO T _CO N FIG
type poster
port packet P lay e rRo b o t :: Co n fig P ack e t ;
input port G RID_ M AP
type poster
port packet G ridM a p : : G ri d M ap P a ck e t ;
input port P LAN N ER_ P ATH
type l a s t
port packet S ho r t Te r mPl a nne r :: Pla n ne r Pat h Pac k et ;
output port P LA N N ER _ COM M AND S
type generic
port packet S ho r t Te r mPl a nne r :: Com m and P ack e t ;
output port N D_C O MMA N DS
type generic
port packet N DNa v iga t ion :: C o mma n dPa c ket ;
};
Figure 6: grid-gtk.coolbot-view: GridGtks descrip-
tion file.
by coolbot-c, so views use the same infrastructure
than component to communicate with other views, or
components (and probes) whether remote or not.
As already mentioned, Fig. 1 illustrates a real sys-
tem developed using CoolBOT. In Fig.5 we can see a
runtime snapshot of one of the views of Fig. 1, con-
/*
* F i l e : m b i c p - i n teg r ati o n . c o olbot - int e gra t io n
* D esc r ipt i on : d esc r ipt i on file fo r
* mbicp - i nte g ra t ion in t egr a ti o n .
* D a t e : . ..
* G ene r ated by co o l b ot - ske
*/
in t egr a ti o n mbi c p_i nte g ra t io n
{
header
{
author " ... ";
description " MbICP s v i e ws inte gra t ion " ;
institution " ... ";
version " ... "
};
ma c h ine ad d res s es
{
loc a l m y _ma c hi n e : " 1 2 7.0 . 0.1 " ;
th e _o t he r _ma c hi n e : " . . . " ;
};
li s ten i ng ports // TCP /IP ports
{
RO B OT_ P ORT : 1 950;
MB I CP_ P ORT : 1 965;
NA V IG A TI O N_ M AP_ POR T : 1970;
ND _ P ORT : 1 9 80;
NA V IG A TI O N_ P LA N NE R _P O RT : 1 9 90;
RO B OT _ VIE W _P O RT : 1 9 55;
MB I CP _ VIE W _P O RT : 1 9 85;
NA VIG A TI O N_ M AP _ VI E W_ P OR T : 1975;
NA VIG A TI O N_ P LA N NE R _V I EW _ PO R T : 1 9 9 5;
};
loc a l i n sta n ces
{
view rob o tVi e w : P la y erR o bo t Gtk
li s ten i ng on R OB O T_V I EW _ POR T
with description " R o bot ";
view mbi c pVi e w : M bIC P Gtk
li s ten i ng on M BI C P_V I EW _ POR T
with description " M b ICP ";
view mapV i ew : Grid G tk
li s ten i ng on N AV I GA T IO N _M A P_ V IE W _P O RT
with description " Ma p " ;
view na v ig a tio nPl a nn e rV i ew : Pl a nne r Gtk
li s ten i ng on N AV I GA T IO N _P L AN N ER _ VI E W_ P OR T
with description " P lann e r " ;
};
rem o te ins t anc e s on t h e_ o the r_m a ch i ne ;
{
component robot : Pl a yer Rob o t
li s ten i ng on R OB O T_V I EW _ POR T ;
component mbi cpI n sta n ce : Mb ICP C orr ect o r
li s ten i ng on M BIC P _PO R T ;
component nav iga t ion M ap : Gr i d Map
li s ten i ng on N AV I GA T ION _MA P _P O RT ;
component n d : ND N avi g at i on
li s ten i ng on N D_PO R T ;
component na v iga t io n Pl a nne r : S ho r tT e rmP l an n er
li s ten i ng on N AV I GA T IO N _P L AN N ER _ VI E W_ P OR T ;
};
port con n ec t ion s // s tati c c o nne c tio n s
{
co n n ect rob o t : O D OME T R Y t o ro b otV i e w : ODOM E TRY ;
...
};
};
Figure 7: The integration containing Robot. MbICP, Map
and Planner views of Fig. 1.
cretely view Map, which shows the map the mobile
indoor robot is building based on laser scans. In order
to illustrate how C++ skeletons for views are gener-
ated, we can observe in Fig. 6, the description file for
this view.
Once developed CoolBOT views are graphical
components we can integrate in a window-based ap-
plication. In fact, a CoolBOT integration which in-
ICAART 2012 - International Conference on Agents and Artificial Intelligence
670
cludes views is a GUI application, whose C++ skele-
ton has been generated using also coolbot-c from
a description file. In Fig. 7 we can see and ex-
ample, the four-view integration of Fig. 1. Notice
that coolbot-c generates C++ skeletons for integra-
tions where the static instantiation and interconnec-
tion among components and views are generated au-
tomatically. If we want to build a dynamic integra-
tion, we must complete the dynamic part of the skele-
ton generated by coolbot-c using the C++ runtime
services provided by the framework (Fig. 2).
4 PROBES
As depicted in Fig. 8 a CoolBOT probe is provided
with an external interface of input and output ports,
and likewise component and views, as software com-
ponents. Equally they implement the same network
decoupled support of threads for transparent network
communications. In CoolBOT, probes are devised
as interfaces for interoperability with non CoolBOT
software, as illustrated graphically in Fig. 1.
<<probe>>
network
threads
user
input
ports
user
output
ports
Figure 8: CoolBOT. Probe structure.
A complete functional C++ class implementing
a probe is generated when a component is compiled
by coolbot-c. The probe implements the comple-
mentary external interface of its corresponding com-
ponent, and provides and API (Application Program-
ming Interface) to use the probe to connect and com-
municate with instances of its corresponding compo-
nent. Thus, a given probe instance provides means
to access a component instance. Those probes gener-
ated automatically can be seen as automatic refactor-
ings of external component interfaces in order to sup-
port interoperability of CoolBOT components with
non CoolBOT software.
As of now we have used CoolBOT probes to inter-
operate with Java applets inserted in a web browser or
used independently, as shown in Fig. 1. More specif-
ically we have used SWIG (SWIG, 2011) in order to
have access to the probe C++ classes in Java with the
aim of implementing several Java GUI interfaces in
Java equivalent to some of the CoolBOT views we
have already developed. In Fig. 9 we can see a snap-
shot of the Java equivalent of a robot view to represent
the range sensor information of the mobile robot.
Figure 9: Snapshot of a Java view implemented using a
probe.
5 CONCLUSIONS
In this paper we have explored the concept of in-
terface in a distributed CBSE framework specifically
aimed to build robotic control software. In fact we
have put into practice the concept of interface as a
software component on its own with its own structure
and functionality, in opposition to a more wide con-
cept of generic software component. Thus, we have
presented the framework, CoolBOT, where we have
available three types of software components to in-
tegrate systems: components, views and probes; be-
ing the last two, interfaces for two clear purposes, re-
spectively: the implementation of graphical user in-
terfaces in a component-based software system, and
the interoperability of components with other differ-
ent software (whether component-based or not).
GUIs implementing graphical views of a given
system are a clear demand in distributed component
based robotic software, and it is because of that, that
we have integrated in our framework infrastructure,
facilities and tools to facilitate its development. In
this manner, GUIs can also be seen as integrable parts
like any other software component, and at the same
time, means are provided to systematize its develop-
ment, in opposition to other approaches present in the
EXPLORING INTERFACES IN A DISTRIBUTED COMPONENT-BASED PROGRAMMING FRAMEWORK FOR
ROBOTICS
671
area. In addition we have also specifically put into
practice another kind of software component which
is a deployable interface allowing interoperation with
other CBSE approaches, or just not CBSE software,
this is a problem present in the area, as other authors
have also indicated (Makarenko et al., 2007)(Geof-
frey Biggs and Kotoku, 2010).
The framework we have presented in this docu-
ment, CoolBOT, constitutes the work around which
we have started recently an open source initiative
called The CoolBOT Project (CoolBOT, 2011), where
the framework itself, its developing tools, and the
components, views and probes composing the system
presented in this paper are freely available.
REFERENCES
Ando, N., Suehiro, T., and Kotoku, T. (2008). A Software
Platform for Component Based RT-System Develop-
ment: OpenRTM-Aist. In Carpin, S., Noda, I., Pag-
ello, E., Reggiani, M., and von Stryk, O., editors, Sim-
ulation, Modeling, and Programming for Autonomous
Robots, volume 5325 of Lecture Notes in Computer
Science, pages 87–98. Springer Berlin / Heidelberg.
Basu, A., Bozga, M., and Sifakis, J. (2006). Modeling het-
erogeneous real-time components in BIP. In Fourth
IEEE International Conference on Software Engineer-
ing and Formal Methods, pages 3-12, Pune (India).
Bensalem, S., Gallien, M., Ingrand, F., Kahloul, I., and
Thanh-Hung, N. (2009). Designing autonomous
robots. IEEE Robotics and Automation Magazine,
16(1):67–77.
Brooks, A., Kaupp, T., Makarenko, A., S.Williams, and
Oreback, A. (2005). Towards component-based
robotics. In In IEEE International Conference
on Intelligent Robots and Systems, pages 163–168,
Tsukuba, Japan.
Brugali, D. and Shakhimardanov, A. (2010). Component-
based robotic engineering (part ii). Robotics Automa-
tion Magazine, IEEE, 17(1):100 –112.
CoolBOT (2011). The CoolBOT Project.
www.coolbotproject.org.
Domínguez-Brito, A. C., Hernández-Sosa, D., Isern-
González, J., and Cabrera-Gámez, J. (2007). Software
Engineering for Experimental Robotics, volume 30 of
Springer Tracts in Advanced Robotics Series, chapter
CoolBOT: a Component Model and Software Infras-
tructure for Robotics, pages 143–168. Springer.
Ellis, C. and Gibbs, S. (1989). Object-Oriented Concepts,
Databases, and Applications, chapter Active Objects:
Realities and Possibilities. ACM Press, Addison-
Wesley.
Geoffrey Biggs, N. A. and Kotoku, T. (2010). Native
robot software framework inter-operation. 2010 In-
ternational Conference on Simulation, Modeling, and
Programming for Autonomous Robots (SIMPAR),
November 15-18, Darmstadt, Germany.
George T. Heineman and William T. Councill (2001).
Component-Based Software Engineering. Addison-
Wesley.
Glade (2010). Glade - A User Interface Designer.
glade.gnome.org.
GTK (2010). The GTK+ Project. www.gtk.org.
Makarenko, A., Brooks, A., and Kaupp, T. (2007). On the
benefits of making robotic software frameworks thin.
IEEE/RSJ Int. Conf. on Intelligent Robots and Sys-
tems (IROS’07), San Diego CA, USA.
Mallet, A., Pasteur, C., Herrb, M., Lemaignan, S., and In-
grand, F. (2010). GenoM3: Building middleware-
independent robotic components. IEEE International
Conference on Robotics and Automation.
Minguez, J., Montesano, L., and Lamiraux, F. (2006).
Metric-based iterative closest point scan matching
for sensor displacement estimation. Robotics, IEEE
Transactions on, 22(5):1047 –1054.
Minguez, J., Osuna, J., and Montano, L. (2004). A “Divide
and Conquer” Strategy based on Situations to achieve
Reactive Collision Avoidance in Troublesome Scenar-
ios. IEEE International Conference on Robotics and
Automation, New Orleans, USA.
Montesano, L., Minguez, J., and Montano, L. (2006).
Lessons Learned in Integration for Sensor-Based
Robot Navigation Systems. International Journal of
Advanced Robotic Systems, 3(1):85–91.
Openrobots (2011). LAAS Openrobots.
http://softs.laas.fr/openrobots/wiki.
Orca (2011). Orca: Components for Robotics. http://orca-
robotics.sourceforge.net.
Orocos (2011). The Orocos Project. http://www.orocos.org.
pkg-config (2011). pkg-config Wiki. http://pkg-
config.freedesktop.org.
ROS (2011). ROS: Robot Operating System.
http://www.ros.org.
Schlegel, C., Haßler, T., Lotz, A., and Steck, A. (2009).
Robotic Software Systems: From Code-Driven to
Model-Driven Designs. In Proc. 14th Int. Conf. on
Advanced Robotics (ICAR), Munich.
SmartSoft (2011). SmartSoft. http://smart-
robotics.sourceforge.net.
Stewart, D. B., Volpe, R. A., and Khosla, P. (1997). De-
sign of Dynamically Reconfigurable Real-Time Soft-
ware Using Port-Based Objects. IEEE Transactions
on Software Engineering, 23(12):759–776.
SWIG (2011). SWIG. http://www.swig.org/.
Vaughan, R. T., Gerkey, B., and Howard, A. (2003). On De-
vice Abstractions For Portable, Reusable Robot Code.
In IEEE/RSJ International Conference on Intelligent
Robot Systems (IROS 2003), Las Vegas, USA, Octo-
ber 2003, pages 2121–2427.
ICAART 2012 - International Conference on Agents and Artificial Intelligence
672