Code Reusability Tools for Programming Mobile

Robots
Carle Côté, Dominic Létourneau, François Michaud,
Jean-Marc Valin, Yannick Brosseau, Clément Raı̈evsky, Mathieu Lemay, Victor Tran
LABORIUS – Department of Electrical Engineering and Computer Engineering
Université de Sherbrooke, Sherbrooke (Québec) CANADA, J1K 2R1
Email: Carle.Cote, Dominic.Letourneau, Francois.Michaud
@USherbrooke.ca

Abstract— This paper describes two initiatives aiming at some of their efforts in the 2003 AAAI Mobile Robot
improving code reusability for programming mobile robots: Challenge [2]. We had observed the same difficulties with
RobotFlow/FlowDesigner, a data-flow programming environ- our robot entry in 2000 [3], making the robot going through
ment; MARIE (Mobile and Autonomous Robotics Integration
Environment), a programming environment allowing multiple the entire steps of the challenge using symbol recognition, a
applications, programs and tools, to operate on one or touch screen interface, emotional expression, autonomous
multiple machines/OS and work together on a mobile robot recharging and HTML reports. From this experience we
implementation. RobotFlow/FlowDesigner’s objective is to identified two critical issues: programming tools to manage
provide a modular, graphical programming environment that the complexity in programming sophisticated decision-
will help visualize and understand what is really happening in
the robot’s control loops, sensors, actuators, by using graph- making algorithms for robots, and programming environ-
ical probes. MARIE aims at avoiding making an exclusive ments that facilitate code reuse. Note that we make a
choice on particular programming tools, making it possible distinction between a software architectural methodology
to reuse code and applications. for decision-making of an autonomous agent (such as [1],
[4], [5]), and programming environments which are used
I. I NTRODUCTION to implement architectural methodologies (such as Saphira,
The intelligence of a system depends on its sensing, Mobility, etc.). Our focus in this paper is on the latter.
acting and processing capabilities, not taken individually The mobile robotic community recognizes the need for
but as a whole. Over the last two decades, we have seen the evolution of standards in the field, to allow the industry
the field of autonomous mobile robotics progress rapidly to re-exploit what have been shown to work and to make
with the technological evolutions of computers, sensors and progress using these elements. Currently a great variety
actuators, allowing the elaboration of various algorithms of programming environments and tools for robotics exist
and approaches for sophisticated decision-making process- (see http://www.orocos.org/related.html for a list). Initia-
ing applicable to such systems. Obstacle avoidance, navi- tives also exist to produce a functional basis for robotic
gation, localization, mapping, planning, modeling, recogni- software system (project OROCOS), device abstractions for
tion, searching, tracking, interaction, cooperation, decision- robotic programming (Player/Stage [6]), navigation toolkits
making, just to name a few, are good examples of such (CARMEN [7]), or low-level robotics building blocks [8].
algorithms developed on different robotic platforms, to val- Most of these initiatives are developed independently of
idate research hypothesis and to learn about the challenges the others, driven by specific applications and objectives
to overcome in making a mobile robot act as an intelligent in mind. One solution is to choose the one with the most
and useful agent in the real world. diverse capabilities and the biggest community of users,
While good progress has been made, a lot remains to guaranteeing somewhat that support will be provided over
be discovered about how to accomplish such goal. A key the years. But it may still be too soon to make such
obstacle to overcome is the issue of integration. When the choice, with the field having to explore a great variety of
Behavior-Based Subsumption Architecture was introduced ideas, application areas (each one having its own set of
in 1986 [1], one of the most fundamental contribution was constraints, e.g., space, military, human-robot interaction,
to demonstrate the importance of integration in mobile etc.) and to cope with continuously evolving computing
robotics. Yes it is critical to work on specific capabilities technologies.
such as SLAM, vision, planning, speech, etc., but making So we asked ourselves the following question: how can
them work as a whole is a necessary step for increased we come up with an efficient way not to reinvent the wheel
intelligence manifested by autonomous machines in real every time we have to program a robot, without imposing
life settings. Without a doubt, the task is certainly a difficult tools that would have to suit the needs of the very broad
one: no standards in mobile robotics exist, with everybody robotic community? The challenge is to come up with a
developing capabilities on their own (on different robots, solution that helps the science in mobile robotics progress,
using different operating systems and programming envi- allowing everybody to benefit from the works of others.
ronments) and trying afterward to combine it with others. Our answers to this question led to two initiatives related
This is where the design team of the robot GRACE put to programming mobile robots. RobotFlow/FlowDesigner
is a modular data-flow programming environment that that tells when a block has to process its input data. This
facilitates visualization and understanding what is really simple implicit scheduling mechanism makes it possible
happening in the robot’s control loops, sensors, actuators. to build networks from smaller functional blocks without
MARIE (Mobile and Autonomous Robotics Integration En- running into efficiency problems caused by scheduling
vironment), a programming environment allowing multiple overhead.
applications, programs and tools, to operate on one or
multiple machines/OS and work together on a mobile robot
implementation. RobotFlow/FlowDesigner and MARIE are
described in the following sections, along with the justifi-
cation behind the design choices made for these tools.
II. ROBOTFLOW/FLOWDESIGNER
A programming environment, designed to visualize de-
cision blocks, reusable buildings blocks and their inter-
connections, surely helps to structure systems and to un-
derstand mechanisms. This idea has been used for many
years now with scientific and engineering software like
Matlab/Simulink, LabView and the LEGO Mindstorm pro-
gramming environment. These environments, however, do
not fulfill all of the needs associated with the programming
of sophisticated intelligent decision-making algorithms for
autonomous mobile robots. With the great variety of mobile
robotics platforms and their programming environments
(proprietary or not), code reusability is limited by not Fig. 1. Color extraction using FlowDesigner and RobotFlow
being able to easily import code from one platform to
another. Debugging is a critical part of robot programming, FlowDesigner allows to create reusable software blocks,
and having the platform move in the world makes it and to link them together using a standardized mechanism
difficult to see what works and what does not in various in order to create a network of blocks. The blocks are
dynamic situations. Tools that facilitate debugging and data connected dynamically at run time. A network composed
inspection are therefore very important. At the same time of multiple blocks can be inserted as a super-block into
though, with limited processing power onboard robots, other networks. The composition mechanism is inspired
computational overhead has to be limited to a minimum in by the Composite object pattern [13]. Blocks and super-
order to allow good response time when running complex blocks can then be treated the same way, which help
algorithms. preserve uniformity of the blocks interface (inputs, outputs,
In order to address these challenges, the FlowDesigner parameters, scheduling). Super-blocks allow the creation
(http://flowdesigner.sourceforge.net) project was initiated of user-defined processing blocks that can be reused and
in 1999. FlowDesigner is a C++ data-flow processing li- modified easily with the GUI. This makes the global
brary coupled with a graphical programming environment. system easier to maintain since everything is grouped into
The graphical interface is shown in Figure 1. With data- smaller functional blocks. Once the blocks are properly
flow networks, two interaction mechanisms can be imple- connected, the user can execute the program directly from
mented: push and pull [9]. Pushing is when an interaction the GUI interface or from a shell terminal, which parses the
between processing elements is initiated by the data sender textual description of the network. Allowing FlowDesigner
(producer); pulling occurs when an interaction is initiated programs to run in a shell terminal provides flexibility and
by the data receiver (consumer). Push connections are requires less ressources.
appropriate for communication triggered by asynchronous FlowDesigner’s buffering mechanism allows blocks to
events, while a pull network instructs the source element compute their outputs only once per iteration for better
to send data only when the destination element is ready to efficiency. During a given iteration, if block A has calcu-
process. FlowDesigner was originally designed for image lated its outputs which are requested by block B, block
and audio signal processing (DSP), having to deal with A just returns the results stored in its output buffers,
synchronous data processing. That explains why we chose without propagating the request recursively to its input
a pull mode architecture. The pull mechanism also provides blocks. Buffer size is managed by the system, enabling
the simplicity of designing processing elements that do not blocks to request outputs over the N previous iterations,
have to be aware of the others and where everything is self- enabling the creation of feedback blocks. FlowDesigner
scheduled. Self-scheduling happens when blocks are asked also defines standard data types and operators that can be
to output their results: each output block (sink blocks) call used by blocks. Creating new C++ blocks does not require
their input blocks to compute recursively in order to be able knowledge of FlowDesigner’s internal processes, but only
to obtain the input data required for calculation. This kind the procedure to define inputs, outputs, parameters, and the
of computation does not require to have a specific scheduler desired processing function for calculation by the block.
Automatic type checking and type conversion are provided low level operating system (OS) interfaces and hardware
by the data-flow library. Objects creation and destruction interfaces. The BEL provides mechanisms for creating
are handled by the system, avoiding dealing with memory behaviors, which are basic building blocks on which
allocation. Using standardized data types and conversion software applications are built. Behaviors coordination
operators reduces complexity of the C++ blocks, improves is performed automatically by the system. The Behavior
code readability and helps uniformize blocks. When linking Composer GUI helps connecting behaviors inputs and
blocks together with the GUI, users are automatically outputs. The TEL provides infrastructure for creating goal-
notified when a link between two blocks is invalid, which oriented tasks, enabled by an event-driven mechanism.
prevents errors and misuses of a block. User-defined data With RobotFlow, our goal is to let programmers decide
types and operators can easily be added in new toolkits. how behaviors are connected, selected and arbitrated,
Multiple toolkits are already available, e.g., for audio what kind of software architecture and intelligence
processing, artificial neural networks, fuzzy logic, visu- mechanisms to use, and which data types to exploit. A lot
alization probes, vector quantization (VQ), and Gaussian remains to be discovered about how to program intelligent
Mixture Models (GMM). Visual and textual debugging autonomous mobile robots, and in our opinion flexibility
probes are available in these toolkits, providing a flexible is more important than user-friendliness or automatic
and useful way to visualize the information transiting in and hardcoded mechanisms at this point. RobotFlow’s
the data-flow network. Probes can be inserted as standard graphical user interface, mostly incorporated into probes,
blocks in the network, without modifying the data content. is somewhat minimal, but programmers have all the liberty
For instance, built-in probes can show data either on the of building much better GUIs that are suited for their
terminal or on the screen. More complex graphical probes needs.
can plot the data (2D) in real time. Interactive probes can Overall, FlowDesigner and RobotFlow are mostly use-
also be created with buttons, text areas, graphics, keypad, ful when dealing with sequential (synchronous data-flow)
etc. They can interrupt the processing of a block, allowing processing. Processing with mobile robots are often syn-
step-by-step debugging. Once everything works as planned, chronous: it starts with sensing, perception, deciding what
probes can be removed without recompiling, an useful to do and taking action using the effectors. RobotFlow also
capability while debugging mobile robots. allows reuse of networks of blocks, or parts of networks
RobotFlow (http://robotflow.sourceforge.net) is the mo- of blocks, for multiple mobile robotics projects. However,
bile robotics toolkit based on FlowDesigner. Using the the pull scheduling used in FlowDesigner policy is not
RobotFlow toolkit, programmers do not have to worry well suited for asynchronous processing. Other scheduling
about low level drivers for robots and devices and are able policies could be developed with FlowDesigner (push,
to build programs with sufficient hardware abstraction. The events) to better fit robotics needs and are to be addressed
system also provides enough flexibility to create higher in the future. With asynchronous processing, finite state
level intelligence modules without forcing the programmer machines and petri nets become easier to do because
to use a pre-determined mechanism for behavior arbitration each block in a network can switch to different state
and selection. Behavior blocks, Pioneer2 robots interface according to events. Nevertheless, RobotFlow allows to
blocks and vision processing blocks are already available create finite state machines that are incorporated into one
for programmers to create complex systems. For instance, block controlling every state, and outputing commands
as shown in Figure 1, extracting color components from to other blocks. Processing threads can be created within
an image and displaying it in a graphical image probe blocks or networks of blocks, allowing parallel calculations
require the use of just a few building blocks and links. A using different update rates and events. The GUI also
color training probe makes it possible to select membership runs in a different thread, making GUI events possible.
to color channels directly on the image. RobotFlow also Being able to make parallel computation (distributed com-
has Player/Stage [6] client interface blocks which allows puting) would probably require to run multiple instances
the control of all Player supported platforms and devices, of FlowDesigner/RobotFlow using different update rates.
along with interface to Stage and Gazebo simulators. Such issues in system communication are addressed by
Using these links, RobotFlow provides a convivial interface MARIE.
for creating higher level programs using a powerful and
flexible client/server robot and device interface like Player. III. MARIE
Blocks in RobotFlow could be made to make it compatible Reusability in robotics can be seen at a functional level
with Mobility, Saphira, etc. where small reusable blocks of functionalities are created
For comparison, Evolution Robotics and linked together to build a robotics system, as done
(http://www.evolution.com) offers a similar programming by RobotFlow/FlowDesigner. It can also be seen at a
environment based on a Graphical User Interface (GUI) system level where applications, tools and programming
to connect software components. The layered software environments are created and linked together. Those two
architecture provides higher level modules for vision, levels can be used concurrently in the same system as they
navigation and interaction on top of a Task Execution offer different integration possibilities. As indicated in [10],
Layer (TEL), a Behavior Execution Layer (BEL) and a many programming environments based on one or both
Hardware Abstraction Layer (HAL). The HAL provides levels exist, proposing different approaches for robotics
system development and integration. Unfortunately, many knowing how to coordinates global interactions between
of these programming environments are not compatible colleagues to realize the desired system. Here are the five
with each other and cannot be easily integrated together. consequences identified for the mediator design pattern,
MARIE’s first goal is to create a programming environment adapted to the distributed mobile robotics context:
at a system level, facilitating reusability of applications,
1) It limits subclassing. Changing overall system behav-
tools and programming environments in an integrated and
ior following the mediator pattern means having to
coherent system.
only change mediator’s interactions between appli-
Distributed system must integrate many applications
cations, leaving applications intact. This is a good
that communicate with each other either locally or on
consequence because otherwise it would probably
separate processing nodes. Creating direct application-to-
be necessary to modify application source code to
application communication links is not always possible
change behaviors, reducing application reusability.
since applications do not necessarily share the same com-
2) It decouples colleagues. Having all applications
munication protocols (TCP, UDP, shared memory, etc.)
linked to the mediator only promotes loose cou-
or communication mechanisms (push, pull, event-based,
pling between them. Applications do not need to
etc.). Many programming environment, such as Player
be aware of others applications, limiting interactions
[6], CARMEN [7], MIRO [11] and CLARaty [12], have
only through the mediator. Using better decoupling
solved this problem by choosing specific communication
between colleagues also allow to reuse mediator
protocols and/or mechanisms that need to be implemented
configurations and applications independently, and to
by all applications to be linked together. This solution has
easily switch applications offering the same services.
some limitations knowing that it might not be possible or
3) It simplifies object protocols. A mediator replaces
desirable to modify the source code for an application.
many-to-many interactions with one-to-many inter-
Furthermore, it limits coexistence of multiple commu-
actions between mediator and its colleagues. In a
nication protocols and mechanisms interacting together.
distributed context, it means that each application
Another solution is to import the functionalities of vari-
can use its own communication interface as long as
ous applications by re-implementing them in a common
the mediator knows how to communicate with each
framework, and then adding what is required for com-
communication interface. Application reusability is
munication. This solution typically involves an error-prone
enhanced by being not limited to specific communi-
work that requires time, effort and knowledge to assure that
cation interface, and by getting compatibility issues
functionalities are not deteriorated or modified during the
handled by a centralized control unit instead of being
migration process. Unless for compatibility, optimization
the responsibility of each application to integrate.
or performance issues, re-implementing functionalities in
4) It abstracts how objects cooperate. It can be easier
a common programming environment should probably be
to create an abstraction level over each application,
avoided whenever possible.
with each seen as a service provider. This abstraction
level can use robotic domain representation without
influencing the functional level of each application.
5) It centralizes control. However, by centralizing con-
trol, the complexity of the mediator increases in
order to manage adequately all interactions between
applications and implement all of the system func-
tionalities. This can lead to specific implementations
that can be hard to understand, maintain and extend.
According to these consequences, we have identified
four functional components (control and logic) necessary
for the interaction of heterogeneous applications together
via a centralized control unit based on the mediator design
pattern. Figure 3 illustrates these functional components
allowing the integration of distributed applications. They
form the main elements composing the base of MARIE’s
communication framework. Application Adapters are res-
ponsible for sending service requests and communications
Fig. 2. MARIE’s adaptation of the mediator pattern for distributed system from the centralized control unit to the applications, and
vice versa, using an application proxy. Each application to
MARIE proposes another solution, illustrated in Fig- be integrated must have its own Application Adapter that
ure 2, by adapting the mediator design pattern [13] for encapsulates communication mechanisms, the services it
distributed systems. The mediator design pattern primarily provides and the specific configurations it needs. The cen-
creates a centralized control unit (named mediator) which tralized control unit then communicates directly with the
interacts with each colleague (application) independently, Application Adapters to interact with the applications, and
vice versa. Communication Adapters are responsible for neous communication interfaces and applications increase
translating information between different communication the complexity of making MARIE a stable and coherent
protocols and mechanisms. For example, they can provide system. Third, each application must have a clear method
an interaction mechanism that lets two applications using of interactions (through an API or communication links
a pull communication mechanism exchange data correctly. for example) that MARIE can use for integration. Finally,
They can also be responsible for creating a certain level a more subtle but critical issue is in the way applications
of communication abstraction by providing communication access system resources (drivers, memory, hardware, etc):
tap points that hide data source from data sink. Communi- if two independent applications tries to access the same
cation Managers are responsible of creating and managing resources at the same time or in an incoherent way, it can
communication links between Application Adapters that result in an unstable and unpredictable system. Controlling
need to be connected together. This means that they can be system stability can be difficult if integrated applications
used to interconnect Communication Adapters. One Com- do not give access to how they manage system resources.
munication Manager must be available for each processing
node present in the distributed system. Application Man- A. Prototypes
agers manage and control the entire system by coordinating MARIE’s implementation is done through implementa-
system states, achieving system coherence and stability, tions of prototypes with increasing levels of complexity and
and configuring and controlling all components available sophistication, with the objective in mind of not reinventing
in the system. One Application Manager must be available the wheel and study how different software elements can
for each processing node present in the distributed system. be used and integrated in MARIE.

Fig. 3. Example of a distributed system with a detailed view of MARIE

centralized control unit Fig. 4. MARIE’s first prototype system

Explicitly decoupling functionalities using functional The first implementation of MARIE

components enhances modularity and reusability of those (http://marie.sourceforge.net/) was developed for proof of
components in different integrated systems. By using a concept. It allows to change at run-time the robotic entity
solid and generic communication framework, MARIE aims that is controlled using the same decision modules, as
to create a very flexible system that will support a wide illustrated in Figure 4. Three entities are available, each
variety of applications, and let robotics developers build one running on a different computer: a simulated robot
on top of MARIE’s higher level of abstraction to design using Stage on Linux, a simulated robot using Webots
systems based on their own integration needs. In order to (http://www.cyberbotics.com/) on Windows, and a real
reduce development complexity associated with implemen- Pioneer 2 robot running Player server on Linux. The
tation of the centralized control unit, MARIE’s solution is decision modules consist of a behavior-based architecture
to have many development and debugging tools that will using sonars to wander around while avoiding obstacles
help create a stable and coherent system. MARIE’s design in the environment. The behavior-based architecture is
also follows standardized software engineering methodolo- divided in two independent applications: one for the
gies to ensure good software design practices according to behaviors, and the other for arbitration (subsumption).
requirements in mobile robotics [14]. Both applications are implemented using RobotFlow.
These advantages come with a cost. First, system per- The Behaviors application receives sensors information
formance can be affected by the overhead caused by from MARIE’s centralized control unit without knowing
the additional software for the functional components. what entity provides them. It then provides commands to
Second, allowing to create systems using many heteroge- MARIE’s centralized control unit, which sends them to the
Arbitration application. The Arbitration application, like workshops, the tools will make these exchanges through
the behaviors application, does not know which module working code (source code under open source license,
provides behaviors commands, since it receives them another way of communication, or through executable)
from centralized control unit. Once arbitration is done, and common working practices. It will also allow the
the Arbitration application provides actuator commands realization of innovative scientific contributions, by making
back to MARIE’s centralized control unit, which sends possible to integrate interesting capabilities on mobile
them to the selected entity. All these interactions are done robots in novel ways. In that regard creating these tools are
asynchronously. Using this prototype, it is possible to more than just an engineering effort: it must be part of the
change on the fly the entity controlled by the decision scientific process of studying intelligence in autonomous
modules. The same implementation of decision modules systems. Our most fundamental hope is that tools such as
can be validated on different entities, without having to RobotFlow and MARIE become interesting enough that
re-implement it in multiple programming environments. others will join the initiatives in an effort that shows great
Adding on-line a module to teleoperate the robot would potential in addressing the integration issues facing the
be very easy: it would require just to add a new module emerging industry of mobile robotics.
implementing a virtual joystick that sends directly
ACKNOWLEDGMENT
actuators commands, leaving everything else untouched.
Although it is a simple implementation, MARIE’s first F. Michaud holds the Canada Research Chair (CRC)
prototype demonstrates many promising possibilities. in Mobile Robotics and Autonomous Intelligent Systems.
A second implementation integrating more of MARIE’s This research is supported financially by CRC, the Natural
concepts has been completed June 2004. It contains Sciences and Engineering Research Council of Canada
Application Adapters for Player, CARMEN and (NSERC), AUTO21st Network of Centre of Excellence and
RobotFlow/FlowDesigner, which are used to build a the Canadian Foundation for Innovation (CFI).
semi-autonomous tele-operated mobile robot application. R EFERENCES
Navigation and localization are done with CARMEN;
[1] R. A. Brooks, “A robust layered control system for a mobile robot,”
remote control and behavior control are done with IEEE Journal of Robotics and Automation, vol. RA-2, no. 1, pp.
RobotFlow/FlowDesigner; Player device abstraction 14–23, March 1986.
allows to use the same system configuration to run in [2] S. Hedberg, “IJCAI-03 conference highlights,” AI Magazine, vol. 24,
no. 4, pp. 9–12, 2003.
simulation (with Stage and Gazebo) and on a real robot [3] F. Michaud, J. Audet, D. Létourneau, L. Lussier, C. Théberge-
(Magellan Pro). MARIE’s functional components and Turmel, and S. Caron, “Experiences with an autonomous robot
communication layer are programmed in C++ using ACE attending the AAAI conference,” IEEE Intelligent Systems, vol. 16,
no. 5, pp. 23–29, 2001.
(http://www.cs.wustl.edu/˜schmidt/ACE.html) as a generic [4] J. S. Albus, “Outline for a theory of intelligence,” IEEE Trans.
communication framework. By using ACE instead of on Systems, Man, and Cybernetics, vol. 21, no. 3, pp. 473–509,
more specialized communication systems, it is possible May/June 1991.
[5] F. Michaud, “EMIB – Computational architecture based on emo-
to implement multiple communication mechanisms tion and motivation for intentional selection and configuration of
and protocols, and support many communication behaviour-producing modules,” Cognitive Science Quaterly, Special
systems used in robotic such as IPC (http://www- Issue on Desires, Goals, Intentions, and Values: Computational
Architectures, vol. 3-4, pp. 340–361, 2002.
2.cs.cmu.edu/afs/cs/project/TCA/www/ipc/ipc.html), [6] R. T. Vaughan, B. P. Gerkey, and A. Howard, “On device abstrac-
NIST/RCS (http://www.isd.mel.nist.gov/projects/rcslib/) tions for portable, reusable robot code,” in Proc. IEEE/RSJ Int. Conf.
and CORBA (http://www.corba.org/). A detailed on Intelligent Robots and Systems, 2003, pp. 2421–2427.
[7] M. Montemerlo, N. Roy, and S. Thrun, “Perspectives on standardiza-
description of this implementation is available at tion in mobile robot programming: The Carnegie Mellon navigation
http://marie.sourceforge.net. (CARMEN) toolkit,” in Proc. IEEE/RSJ Int. Conf. on Intelligent
Robots and Systems, 2003, pp. 2436–2441.
IV. C ONCLUSION [8] M. Hattig, I. Horswill, and J. Butler, “Roadmap for mobile robot
specifications,” in Proc. IEEE/RSJ Int. Conf. on Intelligent Robots
In this document we have described two software de- and Systems, 2003, pp. 2410–2414.
velopment initiatives currently underway, aiming at facil- [9] Y. Zhao, “A model of computation with push and pull processing,”
Master’s thesis, University of California at Berkeley, Department of
itating code reusability for programming of autonomous Electrical Engineering and Computer Sciences, December 2003.
mobile robots. Our goal is to make such tools robust, [10] E. Woo, B. A. MacDonald, and F. Trépanier, “Distributed mobile
efficient, well-documented, and to share them with others robot application infrastructure,” in Proc. IEEE/RSJ Int. Conf. on
Intelligent Robots and Systems, 2003, pp. 1475–1480.
to make the field progress. They are all available for free, [11] H. Utz, S. Sablatnög, S. Enderle, and G. Kraetzschmar, “MIRO –
under an open-source license. Middleware for mobile robot applications,” IEEE Trans. on Robotics
In our view, programming tools for code reusability and Automation, vol. 18, no. 4, pp. 493–497, 2002.
[12] I. A. D. Nesnas, A. Wright, M. Bajracharya, R. Simmons, and
in mobile robotics are fundamental elements to optimize T. Estlin, “CLARaty and challenges of developing interoperable
scientific breakthroughs in the field. They become a mean robotic software,” in Proc. IEEE/RSJ Int. Conf. on Intelligent Robots
to communicate knowledge and implementation results and Systems, 2003, pp. 2428–2435.
[13] E. Gamma, R. Helm, R. Johnson, and J. Vlissides, Design Patterns :
through readable, reusable and well-documented code. Elements of Reusable Object-Oriented Software. Addison-Wesley,
They allow exchange of ideas, sharing of approaches, and 1994.
communication of implementation results. In addition of [14] A. Orebäck and H. I. Christensen, “Evaluation of architectures for
mobile robotics,” Autonomous Robots, vol. 14, pp. 33–49, 2003.
having these exchanges through articles, conferences and