reusable robotics software collection
TRANSCRIPT
Reusable Robotics Software Collection
Anthony Mallet1, Fumio Kanehiro2, Sara Fleury1 and Matthieu Herrb1
1 LAAS/CNRS7, avenue du Colonel RocheF-31077 Toulouse Cedex 4
2 Intelligent Systems Research Institute, AISTCentral 2, 1-1-1 Umezono
TsukubaIbaraki 305-8568, [email protected]
Abstract—Integrating software on board realrobots requires to be able to share, distributeand reuse robotics software components among therobotics community. Many projects and frameworkshave contributed to this problem. However, most ofthe frameworks concentrate on providing a particulararchitecture. This actually leads to a reduced reusabil-ity.
We present ideas on what integration tools shoulddo and how robotic software should be developedin order to improve reusability. This work is accom-plished in the context of the Joint Japanese-FrenchRobotics Laboratory where the distributed struc-ture of the lab and the necessary need for softwareexchanges make the software reusability problem acrucial one.
I. INTRODUCTION
During the last few years, there has been a con-stantly growing amount of contributions addressing therobotics software integration and architecture theme.For instance, Robotics DTF[15] of Object Manage-ment Group[11] has recently standardized the RT-Middleware[9] and famous software editors [8] have alsorecently started to consider this theme as a business-attractive one.
Such a profusion of different frameworks and contribu-tions probably reveals that there is a high demand fromend-users. What are they expecting from these frame-works? From a researcher point-of-view, the probablymost salient usage of integration tools is to be able to userobotics hardware for demonstration purposes. Indeed,frameworks must make possible to evaluate, study andcompare different approaches. This calls for softwarereusability not only within teams, but also amongst therobotics community.
As software engineers, the emergence of commercialproducts shall also direct us toward comparing and eval-uating integration tools. This also calls for reusabilitybecause we will need to integrate the same software indifferent frameworks.
The main objective of the paper is to present ideas onrobotics software development techniques to maximizereusability. These ideas are based on the experience we
have gained at LAAS in this domain and on the re-cent collaborations started in the Joint Japanese-FrenchRobotics Laboratory [4] context. The first point wehighlight is the necessary distinction between two aspectsof reusability inducted by different abstract levels ofarchitecture we have to define in robotics. This is detailedin section II. In section III we then expose some consid-erations that we have taken into account for achievinga good reusability at the algorithmic level. Sections IVto V should be considered as an experimental validationof the previous ideas. Section IV presents the Openrobotsproject that is a collection of reusable software developedwith reusability in mind. The OpenRobots project doesnot put a particular control architecture forward. Theuse of the OpenRobots software is showed in section V,throught the presentation of three different integrationtools that integrate the Openrobot’s software at JRL-France [4] and JRL-Japan [5].
II. SOFTWARE ARCHITECTURE vs.CONTROL ARCHITECTURE
We introduce the two concepts of software architec-ture and control architecture in order to highlight twomajor aspects involved in the robotics software design.These concepts are intended to demonstrate how highersoftware reusability can be achieved when these steps areclearly decoupled.
First, we name “the software architecture aspect” theart of developing source code and arrange it in a generic,extensible and readable manner. This step typically usestraditional and well-known object-oriented programmingtechniques. It does not especially call for robotics specifictools for its design — but of course the algorithms arespecific to robotics.
Second, we name “the control architecture aspect”the process of combining source code into executablecomponents, connecting them together and setting up thenecessary tools so that components eventually run on realhardware. This aspect requires specific tools for roboticssystems (and more generally autonomous systems).
In many contributions proposing software frameworksfor robotics, these two aspects are mixed together, im-
peding the actual reusability of software amongst dif-ferent systems. In fact, control architecture should beseen as what an operating system does for a standardcomputer. Operating systems do not define data struc-tures nor a predefined set of components. They offer themeans to develop software, exchange components andglue applications together, by taking care of the hardwaremanagement and resources allocation, such as time ormemory. Robotics control architecture should achieve thesame goal for robots. In that sense it is decoupled fromthe development of robotics algorithms and does notnecessarily aim at being reusable itself.
Indeed, the robotics software integration tools willprovide sets of binary components (i.e. algorithmslinked with communication middleware and integratedin threads and processes). Although the idea of reusingcomponents is challenging, there are several limitationsthat impede components reusability. First, this wouldrequire users to stick to a particular framework, which isobviously not a good idea, especially since there are moreand more different frameworks. Second, the granularityneeded for components is not well defined today, and thisgranularity seems to be highly application-dependent.Finally, the structure of components is also an openproblem and there is no clear consensus on what struc-ture the components should have (or shouldn’t have).CORBA components model might be a good startingpoint, though.
To summarize, we feel that there is a lot more urgentwork to be done before we can efficiently tackle theproblem of components reusability in a generic way.On the other hand, a powerful set of integration toolscan overcome this problem by making the componentdefinition phase simple enough so that it does not requiremuch work.
More precisely, robotics integration software shouldfocus on providing tools that should be able to integrate(ideally) any existing software developed by other means.The software that we shall make reusable in the shortterm is the algorithms, developed in the software archi-tecture aspect. Next section details some important ideason how to achieve this.
III. ALGORITHM REUSABILITY
High level of algorithm reusability can be achievedby making no hypothesis on the control architecturethat will be used to integrate the software. This simple,consensual, sentence hides more complexity than it wouldappear at the first glance. Some arguments are detailedin the following sections.
A. Avoid all-in-one approaches
The most obvious pitfall to avoid is to release soft-ware that aims at performing all the tasks involved ina robotic application. For instance, communication orcomponents connections are aspects that belong to the
control architecture aspect and thus should be providedby the integration tools.
Moreover, execution control or behavior supervisionmust be separated from the algorithmic parts. Con-necting different algorithms together or sequencing theirexecution also belong to the control architecture software.
Thus, software should be released as a set of libraries,each of them implementing one, single and well definedalgorithm. In charge to the integration tools to providethe necessary means to glue the algorithms together.
B. Avoid static design
Static design means hard-wiring different componentstogether, in terms of their interface or for the data flow.For instance the CORBA framework, if used incorrectly,will lead to static design because it provides an easyway to invoke requests of remote components. Often,a mix between communication, execution control andalgorithms also lead to such static design.
In distributed frameworks, this could be workedaround by using name services and some layer on top, butas of today there is no tool that provides the necessaryguidelines to develop components in such a way. In thisdomain, the SmartSoft framework [16] in interesting as itexplicitly address this issue by the use of communicationpatterns.
Algorithms should be developed with no hypothesis ondata sources nor on the destination of computed data,and structured by a clear, generic, API. Then differentframeworks can propose different components structuresthat make use of the same underlying software.
C. Components are tied with framework
By construction, software components are tied withthe tools that built them. To mention only one example,CORBA components will require an ORB to run. Thisexample is interesting because the CORBA specificationhas achieved a great modularity and reusability levelamong different implementations of ORBs. However, itis still not possible to use CORBA components in otherframeworks that do not implement these specifications.
Furthermore, it is now well known that roboticscomponents are more than sole CORBA servers. RT-middleware or GenoM (see section V) are an illustrationof what is missing in such components. Although RT-middleware got a standardization from the OMG, thisis fairly new and must be accepted by the communitybefore we can rely on it.
So for the question of being independent of particularspecifications and in order to be able to compare differentinstances of frameworks and architectures, algorithmsshould be developed independently. This approach isvery well illustrated by famous projects like OpenCVfor image processing or boost in the software engineeringworld.
D. Data structures and API standardizationProviding algorithms that are intended to abstract
classical robotic tasks raises the problem of exchangingdata structure between components. This is for instancediscussed in [10] and a conclusion is to use abstract,generic interfaces provided by object-oriented program-ming. However, no one has ever found any methodologythat can define how generic an API is.
The standardization of data structures or API hasoften been a kind of “emerging” phenomenon wherethe well known and used libraries tend to become defacto standards which are progressively accepted by thecommunity.
An on-going effort in the Humanoid Path PlannerProject [17], conducted in the JRL context, is to definea series of abstract interface classes. The idea is that:i) developers of a software tool provide their implemen-tation through derived classes of the specified abstractinterface classes and ii) users call the abstract interfacesignoring the implementation they will eventually use.This organization allows the development of concurrentapproaches and let anyone switch from one implemen-tation to another. This is a necessary effort in order toshare code between people, but this is also necessarilylimited to a small community or a particular domain.
Thus, since the algorithms are to be embedded intocomponents, the standardization can also be made atthis level. By doing so, the component becomes a kindof “abstract interface” to the actual data structures usedin the underlying algorithms.
IV. OPENROBOTS PROJECT
The OpenRobots project is a project started at LAAS.It aims at providing an off-the-shelf, reusable roboticssoftware collection (Figure 1). Following the guidelinespresented in this paper, the software is organized as aset of independent libraries, each implementing somewell known algorithms. Most of the software do notfocus on specific control architecture and the libraries arereusable in any context. In that sense it differs from manyexisting projects that are intended to provide completesolutions. We also put in this collection the integrationtools GenoM et al. that we have developed (see nextsection), but this is done independently: eventually, otherintegration tools might also be incorporated, such asthe OpenRTM [9] framework. A great majority of thesoftware is released under a BSD open-source license,granting people with a free access to this project.
Developed in the context of the JRL lab, the recentHPP (Humanoid Path Planning) [17] project will alsointensively focus on reusability since we will develop andshare software between three laboratories (LAAS, IN-RIA Rhone-Alpes, and the Intelligent Systems ResearchInstitute in Tsukuba). This software will be integratedinto different architectures, either based on GenoM orCORBA components.
Besides the reusable libraries, we also propose an archi-tecture of software components based on the GenoM tool.Components are essentially wrappers around librariesand instantiate them into a control architecture. This haslead, in particular, to a successful integration of mixedcomponents between ASL at EPFL and LAAS.
Finally, we are currently working on the integrationof a packaging system, based on NetBSD’s pkgsrc [14]framework in order to provide users with a user-friendlybuild system. Packages will be organized in categories(e.g image processing, vision, motion planning, ...) andavailable in binary and source form.
V. INTEGRATION TOOLS
In this section we present three integration tools thatare able to integrate OpenRobots software on boardrobots. The tools are quickly described in order todemonstrate that they implement very different compo-nent architectures as well as very different control ar-chitectures, while integrating the very same algorithmicsoftware.
We do not claim any new contribution on the toolsthemselves, for which references are given in the text.Rather, we put forward the work that was required inthe OpenRobots project to develop algorithmics librariesthat were actually integrated into different architectures.
A. OpenHRPOpenHRP(Open architecture Humanoid Robotics
Platform)[6], [12] belongs to the category of integrationtools. It was designed to be a software developmentplatform of humanoid robots under HRP(HumanoidRobotics Project) in Japan[3]. It is a package of asimulator and a controller framework.
The controller framework helps to build modules called“plug-in” by wrapping Algorithms and hard real-timeexecution of them. Figure 2 shows structure of the wholecontrol system. A low-level behavior controller is a hardreal-time execution part. It includes several plug-insand execute them sequentially in a single thread. Thisis a very strong limitation, but it makes the systemdeterministic and predictable. Plug-ins can be added andremoved dynamically while the system is running. Eachplug-in includes a state machine which is similar to thatof GenoM module and calls APIs of an embedded librarycorresponding to the internal state. External interfaces ofplug-ins can be defined by IDL. High-level behavior con-trollers can be written in order to control the executionof the plug-in, read/write parameters and send requeststhrough those interfaces.
Figure 3 shows an example system composition fora walking experiment. In this case, four plug-ins areused. They are (A)Walking Pattern Generator plug-in,(B)Kalman Filter plug-in, (C)ZMP calculator plug-inand (D)Stabilizer plug-in. They are executed in turn from(A) to (D)((A),(B) and (C) can be reordered) in 5[ms]cycle.
function h2, h2bis Super Scouts XR400 (diligent) B21 ATRV Marsokhod (Lama) Blimp (Karma)
basic locomotion X X X X X Xposition structures X x X X X
sensors camera X X X x X X XsonyCam X X xus X . . . .sick X X x XPTU directed perception X X X x X Xgps X X
Trajectory m2d X X xgeneration vstp x x x
p3d X Xnav X X
motion nd X X X X Xelastic band X Xtraj. execution Xditto, with trailer X Xtarget following X Xgoal tracking X X X Xobstacle avoidance X X X x X
modeling occupancy grid X X X& dtm X Xlocalization segment loc. X X x X
visual odometry X Xipm X xstereo-correl. X X xpanoramic loc. Xfeature loc. X X xposition fusion X X
Fig. 1. Salient list of reusable algorithms and associated components provided by the OpenRobots project. The columns lists someof the robots on which the components has been run. Component names are sometimes cumbersome and refer to particular algorithmsimplemented: the dynamic wiring of components allows supervision procedures to switch between algorithms at run-time. There areapproximately 120 components developed (not listed all here).
High-level BehaviorController
(Python, C++, Java, …)
Plugin
Plugin
Plugin
Plugin
Adaptor
Virtual or Real Robot
SensoryInformation
MotorCommand
Shared Data
Low-level Behavior Controller
Fig. 2. Structure of OpenHRP controller
Reference ofJoint angles
WalkCommand(x,y,th)
Kalmanfilter
Body inclination
USER
Gyro
Accelerometer
Force/torquesensor
Joint servoStabilizer
References of Joint angles, body inclination and ZMP
encoder
ZMPZMPcalculator
PatternGenerator
Fig. 3. Composition of a walking experiment system
B. GenoM COMPONENT BUILDER
This section describes the GenoM tool. GenoM [2],[1] is a software component builder and thus also be-longs to the category of integration tools that can helpin developing programmable control architectures. It isavailable under an open-source BSD license [13]. We havebeen using this tools to integrate robotics demonstrationson numerous platforms since 1996 and we are effectively
functionalpposters
controlposter
(to sensor or effector or other module)
activities
controller
requests replies
clients
controldatabase
functionaldatabase
requests / replies library interface
dataflow
execution engines
post
er a
cces
s lib
rary
inte
rface
Fig. 4. Structure of a module.
reusing a lot of software developed since then.GenoM components are technically implemented as
independent multi-threaded processes. The core of thecomponents is an execution engine that provides ageneric and common execution model for all components.The execution engine is able to receive requests thattrigger the execution of a finite state machine in chargeof the execution of a particular step of an algorithm.Components can define several requests, correspondingto different embedded algorithms.
A real-time communication library is used to handlecontrol and data flow aspects.
The generic structure of the component has two parts(Figure 4): the module logical control part and the pro-cessing and activities management part. They interact bythe mean of typed asynchronous events.
The logical control part of the execution engineis a reactive thread which manages the state of thecomponent: it receives requests for service execution,checks and records parameters, checks if requests are not
ETHER
INIT
ZOMBIE
exec/−init/−
abort/−
abort/−
EXEC
INTER−/ended
−/failed
−/failed
abort/−
−/ended
− / execution
control / −events
Fig. 5. Control graph of an activity: events associated to transi-tions between states are generated by the control thread (event/-)or signaled by the processing layer (-/event).
conflicting with current state (e.g. activities in progress),starts and stops activities and sends back replies to theclients. The state of the component is exported into thecontrol data structure.
Execution of a service creates an activity which ismanaged according to a control graph composed of fivestates and nine transitions (Figure 5).
A nominal execution follows the external cycle shownon Figure 5: the activity is initially in the fictitiousstate ETHER. When a service is started, it goes to theINIT state, in which parameters are checked and possibleincompatible activities interrupted. The activity is thenprocessed (state EXEC). Its termination (event -/ended)brings it back to the ETHER state. The event abort/-brings the activity into the INTER state during which ithas to finish its processing (e.g., interruption of childrenactivities, stabilization of controlled processes, memoryrelease) before going back to ETHER.
The client is informed of the effective start of theprocessing (exec/-) by an intermediate reply. A finalreply is sent, with the specific execution report (OK,ZOMBIE, interrupted, or other), when the activitycomes back to ETHER or ends up into ZOMBIE.
The activities management part of the executionengine manages the activities requested by the controlthread. It is technically implemented with one or severalperiodic or aperiodic threads and represents the execu-tion context of the actual processing.
The EXEC state of activities is handled by the threadsof the processing layer. In order to offer interruption andrecovery capacities, this state is in turn split into differentstates (Figure 6). Each step corresponds to the executionof a user-supplied function.
Activities are executed in the context of one executionthread and it inherits its characteristics in terms ofperiod, priority and so forth. An execution thread mayprocess several activities, provided they share the sametemporal characteristics.
GenoM components are an instantiation of a genericcomponent template. A formal description (a text filedescribing some parameters of the component) and thelibraries to be integrated are fed into a parser whichbuilds the final component.
EXEC−/exec
−/end
abort/−−/ended
exec/−
−/fail
−/fail
−/fail
−/failed
−/execfail
start
exec
end
INTER *
ETHER
INIT
ZOMBIE
EXEC *
inter
control graph
execution graph
Fig. 6. Execution states of an activity.
InterfaceLibraries
TestProgram
ModuleCo
mp
ilat
ion
+
L
ink
sC
om
pil
atio
nGenoM
FormalDescription
GenericModuleSkeleton
Parser
12
3
4
Codels
Algorithmsincluding
+Makefiles
code files
Fig. 7. Automatic component generation.
The generated code performs no dynamic memory allo-cation (constant size in memory), and the complexity ofthe control algorithms is in O(1) (constant time cycles):memory or computing time uncertainties depends onlyon the content of the user-provided libraries. GenoM doesnot validate a priori the logical and temporal constraintsof components, which are of course dependent of thealgorithms and the host CPU capacities. But it offersa systematic methodology and a set of tools to verify theon-board system.
C. RT-Middleware
RT-Middleware [9] (RT means “Robot Technology”)is a set of interface and its component model of dis-tributed object middleware for RT functional element.RT-Middleware defines RT-Component as a basic func-tional unit. Figure 8 shows the structure of an RT-Component. Each RT-Component has its own activityto execute its main task and InPorts and OutPorts forexchanging data with other RT-Components. The stan-dardization of the RT-Component specification had beenproposed to OMG [11] and was adopted in September2006 [7].
OpenRTM-aist is an open-source implementation ofRT-Middleware. It provides RT-Component framework(class library), a template generator “rtc-template” andan integration tool “rtc-link”. “rtc-template” generatescodes from given component profile (type of activity, thenumber of InPort/OutPort and so on). A developer canbuild a RT-Component by adding implementation codesto those files. “rtc-link” is a GUI which helps to defineconnections between RT-Components.
Architecture of RT component
Activity
RTComponent
RTComponent Service
SDO Interfaces RTC Interfaces RTCEx Interfaces
OutPortInPort
RTCS Consumer
InPort 0
InPort n OutPort n
OutPort0
Service
Service
reply
pushput
get, subscribe
Buffer Buffer
BufferBuffer
Consumer
Proxy
Consumer
Proxy
reply
getput
useprovideprovide
State Machine
Fig. 8. RT-Component
D. Summary: Greatest Common Divisor
This survey of different tools reveals that in order tobe able to integrate the same software, these tools mustshare some common characteristics.
The most salient common characteristic must be theability, for robotics components, to control and sequencethe execution of algorithms as well as feeding them withdata.
As a consequence, reusable algorithms should be writ-ten with that philosophy in mind. At the very least, theymust provide an API in which each step is elementary.
VI. CONCLUSIONS
In this paper we have presented ideas on how todevelop reusable software in robotics. The reusabilityoccur at two levels: the software algorithmic level and thecomponent level. Given the variety of components modelsand contexts of integration, the reusability must be firstachieved at the algorithmic level. By doing so, severalcomponents model and control architecture definitionscan be developed and eventually compared in terms ofperformance, ease of integration and so on. Also, thesame software can be reused in different integrationcontexts that require different components model.
We have presented the recent OpenRobots project thatis a collection of robotics algorithms and integrationtools. Users can pick-up software at the level that matchtheir needs (i.e. algorithmic, component, ...). This projectwill serve as a basis for effective software exchangesbetween JRL-Japan, LAAS and INRIA Rhone-Alpes,and also among the robotics community.
References
[1] R. Alami, R. Chatila, S. Fleury, M. Ghallab, and F. In-grand. An architecture for autonomy. International Journalof Robotics Research, 17(4):315–337, April 1998.
[2] S. Fleury, M. Herrb, and R. Chatila. Genom: A tool for thespecification and the implementation of operating modules ina distributed robot architecture. In International Conferenceon Intelligent Robots and Systems, volume 2, pages 842–848,Grenoble (France), September 1997. IEEE.
[3] Hirochika Inoue, Susumu Tachi, Yoshihiko Nakamura,N.Ohyu, Shigeoki Hirai, Kazuo Tanie, Kazuhito Yokoi, andHirohisa Hirukawa. Overview of Humanoid Robotics Projectof METI. In Proc. of the 32nd ISR, 2001.
[4] AIST-CNRS Joint Japanese-French Robotics Laboratory.http://www.laas.fr/JRL-France/jrl-index-en.htm.
[5] AIST-CNRS Joint Japanese-French Robotics Laboratory.http://www.is.aist.go.jp/jrl/.
[6] Fumio Kanehiro, Hirohisa Hirukawa, and Shuuji Kajita.OpenHRP: Open Architecture Humanoid Robotics Platform.The International Journal of Robotics Research, 23(2):155–165, 2004.
[7] T. Kotoku. Robot middleware and its standardization inOMG - Report on OMG technical meetings in St. Louisand Boston. In SICE-ICCAS2006, pages 2028–2031, Busan(Korea), October 2006.
[8] Microsoft Robotics Studio. http://www.microsoft.com/robotics.
[9] N.Ando, T.Suehiro, K.Kitagaki, T.Kotoku, and W.-K.Yoon.RT-Middleware: Distributed Component Middleware forRT(Robot Technology). In Proc. of the IEEE/RSJ In-ternational Conference on Intelligent Robotics and Systems(IROS’05), 2005.
[10] I. Nesnas, R. Simmons, D. Gaines, C. Kunz, A. Diaz-Calderon,T. Estlin, R. Madison, J. Guineau, M. McHenry, I-H. Shu,and D. Apfelbaum. CLARAty: Challenges and Steps TowardReusable Robotic Software. International Journal of AdvancedRobotic Systems, 3(1):23–30, 2006.
[11] Object Management Group. http://www.omg.org.[12] OpenHRP: Open architecture Humanoid Robotics Platform.
http://www.is.aist.go.jp/humanoid/openhrp/.[13] OpenRobots: Software for Autonomous Systems. http://
softs.laas.fr/openrobots.[14] pkgsrc: The NetBSD Packages Collection. http://www.
pkgsrc.org.[15] Robotics Domain Task Force. http://robotics.omg.org.[16] C. Schlegel. Communication Patterns as Key Towards
Component-Based robotics. International Journal of Ad-vanced Robotic Systems, 3(1):49–54, 2006.
[17] E. Yoshida, I. Belousov, C. Esteves, and J-P. Laumond. Hu-manoid motion planning for dynamic tasks. In InternationalConference on Intelligent Robotics and Systems, Tsukuba(Japan), 2005. IEEE.