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 signiﬁcant 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

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 speciﬁc kind of software component on their

own, that we normally ﬁnd in robotic CBSE devel-

oping software approaches. Thence, in ROS (ROS,

2011) we can ﬁnd 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 brieﬂy 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 brieﬂy 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 Artiﬁcial Intelligence (SSIR-2012), pages 667-672

ISBN: 978-989-8425-95-9

 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

network

web browser

view

Robot

view

Map

java

applet

probe

Navigation

GridMap

TCP/IP

connections

port

connection

input

port

output

port

commands

sensory

info

commands

map

virtual

scan

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 ﬁve 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

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 ﬁnd 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

view

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 deﬁned 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-ﬂow 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

recovery

running

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 deﬁned. 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 deﬁnes its user

automaton which is speciﬁc 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-

ﬁned.

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 ﬁgure.

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 speciﬁc 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 ﬁle), CMake tem-

plate ﬁles needed to compile the view, and a pkg-

conﬁg ﬁle (pkg-conﬁg, 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 speciﬁc 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: GridGtk’s descrip-

tion ﬁle.

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 ﬁle 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 ﬁle. 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 speciﬁcally

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 speciﬁcally 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

beneﬁts 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-conﬁg (2011). pkg-conﬁg Wiki. http://pkg-

conﬁg.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 Reconﬁgurable 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