GenoM: A Tool for the Specication and the Implementation of

Operating Modules in a Distributed Robot Architecture

Sara Fleury, Matthieu Herrb, Ra ja Chatila

LAAS-CNRS, 7 Avenue du Colonel Roche, 31077 Toulouse, France

e-mail : fsara, matthieu, rajag@laas.fr

Abstract complex systems is not trivial as they deal with vari-

This paper presents a general methodology for the spec- ous specic real-time coordinated processes involving
ication and the integration of functional modules in many people, each experiment generally remains a spe-
a distributed reactive robot architecture. The approach
is based on a hybrid architecture basically composed
of two levels: a lower distributed functional level con-
trolled by a centralized decisional level.
cic instance of the guideline architecture.
More recently, these robotics systems have con-
ducted to another approach focused on distributed
real-time software engineering considering real-time
constraints, parallelism, synchronization, communica-
Thanks to this methodology, synchronous or asyn- tion protocols, concurrent tasks specication, and so
chronous operating capabilities (servo-control, data on.
processing, event monitoring) can be easily added to The \versatility" of robotic systems (additions and
the functional level. They are encapsulated into mod- modications of functions, context-dependent process-
ules, built according a generic model, that are seen by ing selection) has favored modular and incremental de-
the decisional level as homogeneous, programmable, re- signs (Chimera [5], ControlShell [6]) at the expense
active and robust communicant services. of a more classical, but not adapted, top-down ap-
Each module is simply described with a specic lan- proach1 . As a consequence these approaches can not
guage and is automatically produced by a generator of
modules (GenoM) according to the generic model. GenoM
also produces an interactive test program and interface
libraries to control the module and to read the resulting
data, which allow to directly integrate the module into
the architecture.
1 Introduction
take advantage of the formal verications brought up
by the formalization methods of concurrent systems
(Petrinets, SART, Statecharts, ...). A noticeable ex-
ception concerns the ORCCAD system [7] based on
the ESTEREL synchronous language which permits
to demonstrate some logical and temporal properties.
However these methods, initially dedicated to robot
manipulators2 present two limitations for autonomous
The conception of autonomous robotic systems has
been essentially studied from an architectural view-
point focused on the organization of the decisional
and reactive capacities. Three main approaches are
frequently considered: the distributed reactive archi-
tectures (e.g. behavioral [1]), the centralized architec-
robots: (i) specically designed to manage high fre-
quency periodic servo-control processes (crucial to dy-
namically control six or more axes) they hardly in-
tegrate the asynchronous processes required for au-
tonomous robots; (ii) they have left aside architec-
tural concepts: each task is programmed by the user
tures (e.g. blackboards, TCA [2]), and the hierarchical
architectures (e.g. NASREM [3]). However it is now
generally admitted that, as both a decisional and reac-
tive system, an autonomous robot needs to merge sev-
eral architectural paradigms. This report has lead to
\hybrid" architectures, such as the LAAS architecture
[4], characterized by a hierarchical decomposition con-
sisting in at least of two levels: a reactive distributed
functional level controlled by a decisional centralized
as a specic sequence of servo-control processes. The
poorness of the quantitative and semantics exchanges
with the functional level (for observation and control
purposes) complicates the integration of a decisional
level.
We consider that architectural paradigms and real-
time systems design are complementary: our objective
is to design and integrate real-time modules into a hy-
brid architecture. To satisfy the various constraints,
level. The presented system ts within these architec- we propose here a fully operational development envi-
tures. ronment called GenoM. It relies on a \generic" module
Nevertheless these architectural designs do not con- 1 Specication ! design ! validation ! integration.
sider integration aspects. Yet the integration of such 2 ORCCAD is also used in mobile and submarine robotics.
that can integrate synchronous and asynchronous pro-
cesses. Each robot module is an instance of this com-
mon template and has a predictable behavior and stan-
dard communication interfaces. A module description
language associated with an automatic module gener-
ator allow to easily specify and insert a module in the
architecture.
2 A Network of Modules
A robot functional level must satisfy very strong con-
straints related to three aspects:
 A real-time distributed system: the func-
the whole system is increased.
2.2 Control of the Services
The services are parameterized and activated asyn-
chronously through requests sent to the modules. A
relevant request, that may include input parameters,
applies to every service. The reception of a request
starts a client/server relationship that ends with the
termination of the service, marked by a reply returned
by the server to its client. The reply includes an exe-
cution report and possibly data results.
tional level embeds all the processes that control The execution report qualies how the service
the interactions between the robot and the environ- was executed (e.g., no trajectory found, target not -
ment through sensors and eectors. Some of them identied, important drift, invalid inputs, .. .). These
have strong real-time constraints (servo-controls, event predened reports allow the client to anticipate the re-
monitoring, re
ex actions). Thus this level should sults and to install adequate recoveries (e.g., another
oer basic real-time procedures (parallelization, syn- attempt with new parameters, use of another service,
chronization, inter-task communication, multiproces- passing the information on a higher level).
sors support), and should permit time-bounded exe- The requests that trigger on a processing are called
cution and reactivity to asynchronous events. execution requests. Control requests are dedicated to
 A controlled system: the functional level does the control of the execution: they allow to read or to
not include reasoning capacities nor predened behav- dynamically modify execution parameters of the mod-
iors (i.e., prewired and xed interactions between its ule, or to interrupt an execution. Execution and con-
functions). It can be considered as a library of reac- trol requests compose the control
ow of the system.
tive services dynamically parameterized and selected
by a higher controller. This selection will depend on
the task but also on the current execution context in-
2.3 Dynamic Hierarchical Relation-
ferred from the informations returned by the services. ships
In other words, the services must be observable and A module does not a priori know its clients. Relations
programmable in a coherent and predictable way. between modules are dynamically established, which
 An open system: the robot system should be oers a very
exible architecture: the modules are in-
evolvable and modiable. The services should be eas- cluded or removed from the system according to the
ily integrated, modied or suppressed according to the application requirements, and services may be used or
considered application and algorithmic development. not according to the context.
This requires an incrementally designed system with
common integration methodology and validation pro- Moreover, the services of a module can be used by
cedures for the involved people. another module. This allows to dene hierarchies of
These issues claim for a modular architecture of the processes, i.e. to elaborate more sophisticated ser-
functional level, standard structure, behavior and in- vices by combining primitive - but general and thus
terfaces of the modules (section 3) and a precise de-
velopment methodology (section 4).
2.1 The Modules Dividing-Up
A module is a software entity that oers services re-
lated to a physical (sensors, eectors) or a logical
(data) resource. More precisely, a module is responsi-
ble of the resource: it embeds all the required process-
ings to control the resource, but also failure detections
reusable - processings3 . In gure 1, the service \vi-
sual tracking with local obstacles avoidance" uses
six other servers.
A processing under way is called an activity. An ac-
tivity that starts another activity4 is a mother activity :
it is responsible of its children activities. In particular,
the interruption of an activity will cause the interrup-
tion of its children activities. This hierarchical control
simplify the global control of the system which can be
and recovery procedures to ensure its integrity.
This decentralized control relieves the central con-
troller: the required services are managed by the mod-
ex actions: actions trig-
ules, hiding the complexity and the dynamics of the
low levels processings. Thanks to the control and re-
covery procedures at the lower level, the robustness of
represented by a dynamic activity tree (gure 1).
3 This allows for instance to build re
gered by an event monitoring action.
4 Thus, a client/server relationship is established between
their modules.
 Module poster_ P poster_ P poster_P
tracking + 1 2 3
avoidance activity
path visual wall
poster tracking tracking following

local visual
avoidance tracking possible
tracking_request ( poster_Pn )
input
reference
position
sonar position video platform control
control control acquisition control

odometer driving−wheels

Figure 2: Data ow redirection example: either P 1,

P 2 or P 3 poster reference can be transmitted to the
sonars odometer driving−wheels camera platform

Figure 1: Activity tree example: local obstacles avoid- tracking request.

ance during visual tracking
2.4 Access to the Data
During their execution, activities may have to read
and/or produce data5 . These exchanges are done via
posters: structured shared memories readable by any
element of the architecture, but only writable by its
owner (the module in charge of the exported data).
Thanks to the posters continuously updated data
icting.
are public. They enable data transfer between ac-
icts
tivities with dierent temporal constraints6 , and syn-
chronous data transfer between periodic activities.
ict-
situations must then be managed in a systematic pre-
dictable manner, and above all, a clear information
must be returned to the client.
First of all, a module must check the relevance of its
inputs: validity of the request parameters and applica-
bility of the required actions. Indeed, due to resource
sharing, the services oered by a module are generally
(but not systematically) con
To satisfy the reactivity requirement, the con
are resolved according to the following rule: the
last request is always preemptive on current con
Each poster is unequivocally identied in the sys- ing activities. Therefore, all the activities must be
tem. This permits to easily redirect the data
ow: interruptible with a delay compatible with the dy-
the poster to be read by an activity is specied as namics of the \subsystem" controlled by the mod-
an input parameter of its execution request. For in- ule. Hence, despite the large diversity of the process-
stance, if we consider a service to servo-control the ings (periodic/aperiodic, synchronous/asynchronous,
robot position on a given reference, (activity position self/controlled termination), the activities must be in-
servo-control at the bottom of the gure 2), this
reference could be computed and exported by a path
tracking activity, a visual tracking activity or a
wall following activity.
This data
ow protocol contributes to the observ-
ability of the functional level. In particular, besides
processing dependent functional posters, each module
maintains a control poster which contains informations
relative to its state and its current activities.
3 Anatomy of a Generic Module
A module must manage the processings and ensure its
own working order. Indeed, a malfunction may have
catastrophic consequences on the whole system (failure
of the application or even robot damage). However, a
module has no informationon the purpose of the global
task: it cannot take any \decision". The non-nominal
5 The data transfer by requests/replies can only occur at the
tegrated in such a way that:
 they are interruptible,
 they terminate properly to insure the stabilization
of the controlled process or the coherence of the
produced data, but also to get back into condi-
tions for a new start,
 they detect the failures (algorithm limitations, re-
source absence, memory limitation) and inform
the client about them.
These constraints, unlike the previous control as-
pects, are closely linked to the processing algorithms:
the execution context should oer a framework to
structure the programs, and mechanisms to manage
non-nominal execution modes (interruptions and fail-
ures).
beginning and the end of a service. All these considerations have lead to the denition
6 Any consumer has a direct access to the data at its own of a \generic" module [8, 9] that clearly distinguishes
pace, independently of the producer. control and execution aspects.
3.1 Structure of the Generic Module 3.2 Module Logical Control
The structure of the generic module has two parts (g- The reception of an execution request creates an ac-
ure 3): tivity which is managed according to a control graph
The control level is a reactive level which man- composed of 5 states and 9 transitions (gure 4).
ages the module: it receives the requests, checks and The transition events are imposed by the control
records their parameters, veries if they are not in con- level (event/-) or signaled by the execution level

ict with processings in progress, ends and starts activ- (-/event).
ities, and sends back replies to the clients. It maintains
a representation of the module state which is exported control / −
to the control poster . init/− INIT
events
exec/− − / execution

The execution level carries out the activities re-

abort/−

quired by the control level. This level is composed of

ZOMBIE
abort/− −/failed

one or several periodic or aperiodic execution tasks: −/failed

the execution context of the processings.
ETHER EXEC

−/ended abort/−
INTER

requests / replies library interface

control −/ended
control poster
level control
task Figure 4: Control graph of an activity
control
poster access library interface

functional
data data

A nominal execution follows the external cycle of

control functional gure 4: the activity is initially in the ctitious state
database database ETHER. The reception of an execution request brings it
to the INIT state, in which its parameters are checked,
execution and possible incompatible activities are interrupted.
level
execution tasks
functional
posters The activity is then started (state EXEC). Its termina-
activities tion (event -/ended) brings it back to ETHER.
In case of a serious error during the execution that
requires a specic intervention or a re-synchronization,
the execution may return a -/failed event bringing
(to sensor or effector or other module) the activity to ZOMBIE. A ZOMBIE state forbids all new
activity. This state is also used for debugging pur-
Figure 3: Structure of a module poses: it allows to freeze and analyze the module. A
specic recovery request will bring it back to ETHER.
These two levels interact by means of typed asyn- During its execution, the activity may be inter-
chronous events (described further) and two databases: rupted by the control level. The event abort/- takes
the activity to the INTER state during which it has to
 the functional database includes all the data re-
lated to the controlled system: default settings,
parameters updated through requests, and pro-
cessing results (exported within the replies or the
functional posters).
nish its processing (e.g., interruption of children ac-
tivities, stabilization of controlled processes, memory
release) before going back to ETHER.
The client is informed of the eective start of the
processing (exec/-) by an intermediate reply. The
 the control database, which has the same structure
for all the modules, contains the states of the ac-
tivities, the commands from the control level and
the reports issued by the execution level.
nal reply is sent, with the specic execution report
(OK, zombie, interrupted, or other), when the ac-
tivity comes back to ETHER or ends to ZOMBIE.
The control level is made of one asynchronous task
which wakes up on external or internal events (request
Moreover, the specication of the generic module or execution events) and goes through the graphs of
includes two standard interface libraries to have access activities. Its reduced computation time (this task is
to the services (emission of requests and reception of sleeping most of the time) is the guarantee of a good
replies) and to the content of the posters. reactivity.
3.3 Processings and Activities a precise denition of a system is not the guarantee
The execution of the processing (EXEC) is supported of a correct implementation, especially when various
by the execution level. To permit the integration of people are involved (not to mention the tedious sides
a large variety of algorithms while oering interrup- of such a systematic and complex construction). With
tion and recovery capacities, the processings are split GenoM this instantiation is formalized: only the specic
up into steps (gure 5). Each step is associated with parts have to be expressed, and the new module is
an non interruptible code part named codel. The codels automatically generated.
are the smallest processing element known by the mod-
ule.
4.1 Formal Description of a Module
As suggested in gure 5, a processing may generally A module is described using a \C" like declarative lan-
be split into three main steps, each being associated guage. This description contains ve parts:
with a codel: an initializing start step, the main exec
step - possibly iterated - and an end step to conclude.
The fail step is linked to a recovery codel.
control graph
INIT
1. The identication of the module (its name).
2. The declaration of the data types used by the
module and the functional database.
3. The declaration of the requests with their types
(control or execution), their input and output pa-

ZOMBIE exec/− rameters, the list of all the possible execution

ETHER EXEC *
reports, the list of the con icting services, and,
INTER *
start for execution requests, the codels associated with
each execution step and the name of the execution
task that handles them.
−/fail

EXEC
−/exec
−/fail
inter 4. The declaration of the posters: name, structure,
updating modalities.
fail exec
−/exec
−/fail
−/end 5. The declaration of the execution tasks: period,
delay, priority, and other attributes related to the
execution graph
end
operating system.
−/failed abort/−
−/ended 4.2 Automatic Generation
This description is processed by the C-preprocessor in
Figure 5: Execution graph of an activity order to be able to include standard C header les that
will be shared with the codels and the clients for all
The end of each codel is associated with an event data type denitions.
-/x that species the next phase (x): an activity is a The output of the C preprocessor is fed to a parser
succession of predened codels sequenced dynamically which builds an internal representation of the module.
according to the results of the previous one. This representation is used to produce the code of the
This allows to structure and monitor the program module, by substituting keywords in a generic skeleton
execution, to exhibit the possible interruption points (gure 6).
(i.e. the transitions between the codels) and to install
adequate termination procedures: the control event 4
abort/- preempts the execution events and brings to GenoM
Compilation

Test
INTER which is associated with an inter codel. Inci-
Generic
Module Program
2
dentally, one can note the codel reusability. 1 Skeleton
Interface
The execution contexts of the codels are the execu- code files
+ Libraries
Compilation

tion tasks: an activity inherits of the characteristics of Formal

Parser Makefiles
Links

Description
its execution task. Providing similar dynamics (same
+

Module
period or equivalent execution time) and priority, one Codels
execution task may be in charge of several activities. including

It is the case in particular if these activities are several 3 Algorithms

instances of a same processing (e.g. a monitoring).
4 Automatic Module Produc-
tion
Every module of the functional level is an instance of
the generic module. However it is well known that
Figure 6: The generator of module
In addition to the module itself, an empty shell for
the codels, the interfaces libraries and an interactive
test program are produced, along with all the building
scripts (Makefiles) to compile and link the module.
 The code produced by GenoM is ready to run (be-
fore the developer integrates its algorithms) either on
a Unix workstation (for simulation purposes) or on a
real-time embedded target (running the VxWorks real-
time OS).
4.3 Development Methodology
A typical development cycle includes the four following
The execution reports provide information on the
service success or failure. These reports are helpful for
an operator and above all they are quite necessary to
envisage automatic execution control.
In a robot, the functional level can be directly un-
der the control of the user (e.g., in teleoperation) or
embedded in an autonomous system. The interfaces
provided by GenoM permit various kinds of control pro-
steps (gure 6): cedures according to the objectives.
1. Formal description: the input le for GenoM.
2. Building of the module: code generation and
compilation.
3. Coding of the codels guided by the shells pro-
duced at step 2, and link editing with the module.
4. Execution of the module on UNIX or VxWorks.
5.1 Teleoperation
This system is adapted to a teleoperation control for
the following reasons:
 the control and recovery procedures included in
the modules give the minimum security required
From the formal description (1), a rst module can to lter out some human control errors,
be generated (2) and integrated in the functional level  thanks to the communication protocols, the func-
(4). The algorithms of the codels are incrementally tions of the module interface libraries can be
included and nalized by iterating on steps 3 and 4. called from a distant Unix workstation,
Any service modication or addition is simply achieved  the execution reports and the accessibility of all
by editing the formal description le.
In the frame of an integration with other modules,
the formal descriptions of the modules handled by
GenoM form a very powerful data sheet to summarize
the awaited services, the behavior and the data struc-
tures of the modules.
The GenoM environment does not validate a pri-
ori the logical and temporal constraints of a module,
which are dependent of the algorithms and the host
CPU capacities, but it oers a systematic methodol-
ogy and a set of tools to verify the on-board system.
The interactive test program allows to start and to
interrupt individually or in parallel all the services,
and to read the produced data. A tool to measure the
computing time of the codels and to build the chrono-
grams of one or several modules is also provided with
GenoM. This permits to determine the number of re-
quired processors and to decide of the distribution of
the module on these processors.
The generated codes include no dynamic memory al-
the produced data (position, map, ...) allow to
supervise the remote execution.
For simple tests, a user may directly utilize the inter-
active test programs generated by GenoM. However, a
more ergonomic human/machine interface for teleop-
eration applications can be built upon the available
interfaces.
5.2 Autonomous Robots
The autonomy of the robot requires a decisional (sym-
bolic) level to interpret the mission and select the ad-
equate actions that will be executed by the functional
level. In the hybrid architecture we built, the inter-
face between the symbolic reasoning level and the set
of real-time data-processing functions is an execution
controller or executive.
The executive translates the \symbolic" required ac-
tions to parameterized requests and returns the results
of execution in terms of interpretable symbolic infor-
location (no memory consumption during execution),
and the complexity of the control algorithms is null
(constant time cycles): memory or computing time
ict management), establishes the data
ow by rerout-
uncertainties may only come from the codels.
ex actions and some system-
5 System Integration
Thanks to the standardization, a module can be eas-
ily integrated in a functional level. Each new module
extends the set of on-board services and increases the
robot capabilities.
icts), but also the constraints between the modules
The functions of the interface libraries of the mod-
ules generated by GenoM enable control and observ-
ability of the functional level from higher levels. An
application will then consist in parameterizing and se-
quencing the services through the set of requests.
mations (execution reports classication).
It insures a coherent execution of the activities (con-
ing the data among the modules, and reacts to their
replies. It also installs re
atic recovery procedures.
The executive must react in bounded time and ac-
cording to a determinist logical behavior: it must in-
tegrate the constraints of each module (resource con-
and the constraints imposed by the application (e.g.
do not start manipulations while the mobile platform
is moving) [10]. This system has been implemented in
Kheops [11], a 0+ rule based system. The executive
behavior and constraints are expressed by rules. Once
compilated, they produce an optimal and determinis-
tic decision tree.
5.3 Experiments
The usage of GenoM is now generalized for both our
indoor and outdoor robots. For instance a library of
about 20 modules has been developed for the Hilare
robots. About half of them are basic sensor or eector
controllers and are used in all the experiments.
This functional level has been used in various appli-
cations. The most demonstrative one is the European
Esprit project MARTHA (coordination of a robot
eet [3] J. S. Albus, H. G. McCain, and R. Lumia.
for transshipment in harbors, airports and railway sta-
tion yards [12]): eight modules have been designed ac-
cording to the generic model by the dierent partners
and successfully integrated on two industrial demon-
strators.
Moreover, in order to test the multi-robot coordina-
tion protocol, we have run up to 30 simulated robots
on 30 Unix workstations connected by Ethernet. This
complex system has ran for hours validating the mod-
ules and their integration.
Finally, to validate the complete system on real
robots, the \MARTHA architecture" (the 8 modules
and the decisional level) have been added up to the
\basic" functional levels of three of our Hilare robots.
The coordination experiment has ran for hours in
a very constrained environment with an intensively
prompted functional level (thousands of requests per
hour).
6 Conclusion
GenoM oers a structured development context that al-
lows the programmer to focus on its algorithms, with-
out caring about real-time process development and
architecture design. The automatic production of the
modules guarantees a standard behavior and avoids
tedious logical tests. The standardization associated
to the formal description allows to easily develop a
Architectural design: automatic generation of the
executive using the formal description of the set of used
modules (a prototype has been already designed).
References
[1] R. A. Brooks. A robust layered control system for a
mobile robot. IEEE Journal of Robotics and Automa-
tion, April 1986.
[2] R. G. Simmons. Structured control for autonomous
robots. IEEE Transactions on Robotics and Automa-
tion, 10(1):p. 34{43, February 1994.
NASA/NBS standard reference model for telerobot
control system architecture (NASREM). Technical
Report 1235, NBS, 1987.
[4] R. Chatila. Deliberation and reactivity in autonomous
mobile robots. In Robotics and Autonomous Systems,
Vol.16, 2-4, pp.197-211, November 1995.
[5] D. Stewart and P. Khosla. Rapid development of
robotic applications using component-based real-time
software. In IEEE Int. Workshop on Intelligent Robots
and Systems (IROS '95), Pittsburg, (USA), 1995.
[6] S. Schneider, V. Chen, and G. Pardo-Catellote. The
ControlShell components-based real-time program-
ming system. In IEEE Int. Conf. on Robotics and
Automation (ICRA'95), Nagoya (Japan), 1995.
[7] D. Simon, B. Espiau, E. Castillo, and K. Kapel-
los. Computed-aided design of a generic robot con-
troller handling reactivity and real-time control is-
sues. IEEE Transaction on Control Systems Technol-
ogy, 1(4), 1993.
[8] R.F.Camargo, R.Chatila, and R.Alami. Hardware and
software architecture for execution control of an au-
tonomous mobile robot. In International Conference
on Industrial Electronics, Control, and Instrumenta-
tion (IECON'92), San Diego (USA), 1992.
[9] S. Fleury, M. Herrb, and R. Chatila. Design of a mod-
ular architecture for autonomous robot. In IEEE In-
ternational Conference on Robotics and Automation,
San Diego California, (USA), 1994.
complex functional level. This system is now system- [10] A. Medeiros, R. Chatila, and S. Fleury. Speci-
atically used for all our robots and has been validated cation and validation of a control architecture for
in large scale projects. autonomous mobile robots. In IROS - IEEE In-
Beyond these software engineering aspects, the au- ternational Conference on Intelligent Robots, Osaka,
tomated generation according to a predened template Japan, November 1996.
oers many perspectives: any extension of the generic [11] M. Ghallab and H. Philippe. A compiler for real-time
model is pass on to the modules. Some ongoing exten- Knowledge-based Systems. In International Work-
sions of this system are related to the following aspects:
Validations: logical and temporal validation of the
modules through the generic model.
Software engineering: generation of a general
user-interface to control all the modules of a given
functional level (inter-module relations), and to inter-
shop on Articial Intelligence for Industrial Applica-
tions,Hitachi City, Japan, May 1988.
[12] R. Alami, L. Aguilar, H. Bullata, S. Fleury, M. Herrb,
F. Ingrand, M. Khatib, and F. Robert. A general
framework for multi-robot cooperation and its imple-
mentation on a set of three hilare robots. In 4th
International Symposium on Experimental Robotics
actively dene sequences of actions for test purpose (ISER'95), Stanford, California, 1995.
(GenoM manages only one module at a time).