FIELD TESTED SERVICE ORIENTED ROBOTIC ARCHITECTURE: CASE STUDY

Lorenzo Flückiger and Hans Utz

Carnegie Mellon University, NASA Ames Research Center, Mail Stop 269-3, Moffett Field, CA-94035, USA.
{Lorenzo.Fluckiger,Hans.Utz}@nasa.gov

ABSTRACT

This paper presents the lessons learned from six years of

experiments with planetary rover prototypes running the
Service Oriented Robotic Architecture (SORA) devel-
oped by the Intelligent Robotics Group (IRG) at NASA
Ames Research Center. SORA relies on proven software
methods and technologies applied to the robotic world.
Based on a Service Oriented Architecture and robust mid-
dleware, SORA extends its reach beyond the on-board
robot controller and supports the full suite of software
tools used during mission scenarios from ground control
to remote robotic sites. SORA has been field tested in
numerous scenarios of robotic lunar and planetary explo-
ration. The results of these high fidelity experiments are
illustrated through concrete examples that have shown the
Figure 1: K10 Red Rover in the Arctic, running SORA
benefits of using SORA as well as its limitations.
during the 2007 Haughton Crater Field Test (Canada).

Key words: Service Oriented Architecture, Space

Robotics, Field Tests Experiments.
This applied research involves numerous robotics field
test experiments conducted to validate the proposed ap-
proaches. Most of these field tests take place in remote
1. INTRODUCTION locations that are good Mars or Moon analogs like shown
in Fig. 1. Some of the key requirements for the soft-
ware system running on IRG’s robotic platforms are: 1)
Advanced software methodologies are necessary to cope
enable complex autonomous systems, 2) support a wide
efficiently with the complexity of the software powering
range of robots and instruments, 3) permit a variety of
any modern robotics system. This need is even amplified
exploration scenarios, 4) facilitate the integration with a
for robots designed for the exploration of uncharted envi-
whole suite of mission tools and 5) allow a dynamic re-
ronments since the tasks involved require a high level of
search by a small team. To address these challenging re-
autonomy combined with a rich set of interactions with
quirements, in 2005 IRG began developing the Service
a control team. The Intelligent Robotics Group (IRG) at
Oriented Robotic Architecture (SORA) which is detailed
the NASA Ames Research Center developed a Service
in [1]. SORA embraces the typical concepts of service
Oriented Robotic Architecture (SORA) to control its ex-
oriented systems: encapsulation, communication patterns
ploration robot prototypes. SORA has enabled complex
based on stable interfaces, and reliance on robust middle-
exploration scenarios in realistic environments to be con-
ware. This builds a loosely coupled and highly cohesive
ducted while allowing IRG’s research in human-robot ex-
system.
ploration to smoothly evolve. This paper reports on the
lessons learned from over six years of experiments with
the SORA software system. The research on software methods and systems for
robotics has increased considerably over the past six to
eight years. The application of good software practices
to handle the complexity of robot systems has lead natu-
1.1. Context
rally to the adoption of software architectures well estab-
lished in computer science. Three of those architectural
Human-robot exploration of remote locations has been paradigms are classified in [2]: Distributed Object Ar-
one of IRG’s key research topics for more than a decade. chitecture (DOA), Component Based Architecture (CBA)
and Service Oriented Architecture (SOA). This is how- 2. SORA CONCEPTS
ever still a very young domain and despite standardiza-
tion efforts such as RTC [3] and RoSta [4], the land-
scape of solutions is still extremely fragmented. Some It is first important to emphasis that SORA is a software
approaches are focused on constructing a new type of architecture supporting robotic systems, and does not de-
middleware specifically for robotics like OROCOS [5] or fine a particular robot control architecture 1 . Fig. 3 illus-
the ROS [6], increasingly adopted in the robotic research trates a simplified controller constructed with SORA. The
community. Other approaches are building component details of the services internal structure, and unified ser-
frameworks using an existing middleware like [7] or [8] vices communication modes are described in [1]. The key
or are designed to be middleware independent [9]. points concept of SORA are briefly highlighted in this
section, starting with the common characteristics shared
SORA shares several characteristics common to CBAs by SOAs and finishing with the SORA specificities.
and SOAs in robotics and adds the following specificities:
1) SORA extends well beyond the robot controller and is
used across the whole mission tool suite and 2) SORA 2.1. Essential SOA aspects of SORA
has been used extensively in high fidelity robotic mission
simulations.
This section describes what properties make SORA a typ-
ical SOA.

1.2. Experience with Exploration Robots

2.1.1. Services

In [1] we have shown how SORA has supported a Lu- SORA services encapsulate a set of interconnected
nar analog robotic field test during the summer 2007 classes to offer high level functionalities to the system.
at Haughton Crater, Devon Island (Canada). This first Each service is self contained and is dynamically load-
full deployment of SORA involved two K10 rovers per- able. In addition, a service manages its own control-flow
forming systematic site surveys on a site above the Arc- requirements (message loops, threads etc). A service can
tic circle [10]. Since then, SORA has been used dur- be passive, just waiting for events, or active with one or
ing the summer periods of 2008 at Moses Lake (WA), multiple threads of execution.
2009 at Black Point Lava Flow (AZ) [11] and 2010 at
the Haughton Crater site again [12], as well as in a cou-
ple of small-scale mission experiments conducted at sites 2.1.2. Interfaces
closer to the NASA Ames Research Center. These unique
opportunities allowed IRG to test SORA robustness in
applied scenarios involving full teams depending on the Strongly typed, network transparent interfaces, specified
robotic resource availability (mobility and data gather- with the Interface Definition Language (IDL) [13], allow
ing). Field experiments also put SORA services inter- connecting to the services. Implementation of the inter-
actions (within the robot and to the ground control) in faces in different languages allows heterogeneous sys-
real situations with non homogeneous networks includ- tems to interact. The same control interfaces are accessed
ing satellite links with variable Quality of Service (QoS). using Remote Method Invocation (RMI) for interactions
between services on the robot as well as by applications
running at ground control.

1.3. SORA as Mission Backbone

2.1.3. Data Distribution

Fig. 2 illustrates a typical field test where SORA is used

across the full system deployment: within rovers, by the In addition to RMI, SORA uses a Publish/Subscribe
field team supporting the robots, by the control team ex- scheme to distribute data across services, within a sin-
ecuting remote operations and by the science team using gle controller, and to the ground control systems. SORA
analysis and mission planning tools. Whenever SORA initially used the CORBA Notification Service [14] to im-
services are collocated or distributed across a network, plement a publish/subscribe mechanism. This implemen-
their interactions are based on unified interfaces and are tation still remains active while SORA transitions to the
transparently optimized by the supporting middleware. Data Distribution System (DDS) [15]. DDS is a recent
standard by the Object Management Group (OMG) on
the publish-subscribe paradigm. At publication, most of
The following Section 2 describes the high level concepts
the rover telemetry will be also distributed using DDS.
of SORA. Then, using specific examples the paper high-
lights the benefits of the SORA in Section 3 and the short- 1 The current control architecture of IRG robots is constructed as a
comings of SORA in Section 4. Finally the paper con- two tiered system combined with some services acting like behaviors,
cludes with future extensions to the current research. thus it should be probably characterized as a mixed control architecture.
Figure 2: Typical use of SORA across a full field deployment. Common unified interfaces are shared at each node. Data
distribution appears identical at all nodes.

2.1.4. Middleware 2. Software: an average of 19 software services are in

charge of data processing and high level algorithms
for autonomy and control.
SORA relies heavily on middleware, specifically the
ACE/TAO implementation [16] of the CORBA [14] stan- 3. Infrastructure: an average of 12 services are per-
dard. In addition to CORBA, SORA uses the MIddle- forming infrastructure tasks ranging from audible
ware for RObots (Miro) [17]. Miro facilitates the use of notifications to bandwidth management.
CORBA in the robotics context, without introducing an
extra layer of indirection, but by providing a configura-
tion of the middleware tailored to the robotics domain. In 2.2.2. Loose coupling
addition to CORBA that will continue to be used for com-
manding, SORA relies on the RTI [18] DDS implemen-
tation for data distribution. DDS offers numerous new Services of a SOA are not subject to the same level of
Quality of Service (QoS) compared to CORBA for data coupling as the components of a CBA. SORA services
distribution across heterogeneous, non-reliable networks. need to respect some rules, like resource usage to play
For example, building on DDS QoS, IRG was able to nice in the overall system. However, these rules are
conduct a field test where a 50s transmission delay was not enforced by a formalism or a compiler. In addition,
introduced. the loose coupling between services allows freedom on
the implementation method of each service. In contrast
CBAs can offer facilities for architecture analysis, sys-
2.2. Specific aspects of SORA tem composition, and individual components building.
IRG is considering using the CORBA Component Model
(CCM) [19] in the future to gain some structured CBA
This section describes some characteristics that are benefits, however CCM was not mature enough when
unique to SORA. SORA was initiated.

2.2.1. Services Assembly

2.2.3. Standard messaging between NASA robots

A robot controller is constructed from a set of services.

From its inception, SORA exposed a set of messages for
These services are started according to a configuration
data distribution within the robot and to external sub-
file crafted for a particular scenario. The same config-
scribers. Building on the expertise gained using this
uration mechanism is used also for services not running
system during several years, a collaboration with other
on the robot, like simulated components. A robot con-
NASA centers started an effort to create standard mes-
troller assembled for a typical exploration scenario with
sages for exploration robots across NASA. This effort led
autonomous navigation and a few science instruments av-
to the RAPID project [20]. RAPID defines a set of stan-
erage 45 services. These services could be grouped into
dard data structures that are shared between the robots
three categories:
of already three NASA centers: NASA Ames (K10s and
K-REX rovers), Johnson Space Center (LER, Centaur-
1. Hardware: an average of 14 hardware services are in 2 rovers) and the Jet Propulsion Laboratory (Athlete 6-
charge of communication with physical sensors and legged robot). RAPID is Open-Source Software and es-
actuators. sentially consists of a set of IDLs plus utilities classes.
 are derived from Service Oriented Architecture specific
concepts like encapsulation, communication pattern, and
exposition of stable interfaces. In addition, the use of
a component configurator pattern and reliance on robust
middleware increases the flexibility and reliability of the
system.

Figure 3: A minimal robot controller built with only a

(a) HMP 2007 Controller
few services. Data distribution is unified across the full
deployment. Provided interfaces are transparently acces-
sible within a robot or remotely.

These IDLs are processed to generate code supporting

messages that are distributed using DDS.

2.2.4. Validation with field tests

As mentioned above, SORA was deployed in multiple

field tests on various rovers. In addition to power the K10 (b) HMP 2010 Controller
series rovers, SORA has also been tested on a smaller
scale rover, K10-mini (footprint of 40cmx30cm), as well Figure 4: Two successive versions of the K10 controller
as the much larger new IRG rover K-REX (footprint (only few services shown).
2mx1.6m). Outside of IRG rovers, SORA also currently
supports a navigation system based on a LIDAR for the
Centaur-2 rover [21]. The range of situations encoun-
tered across these field tests is summarized in Tab. 1. 3.1. Encapsulation
SORA’s exposure to these real world situations confirms
that SORA meets three key characteristics of robotic Encapsulation of robotics capabilities into services ex-
space systems: flexibility, scalability and reliability. The posing well defined interfaces is effectively shielding the
unified interfaces across the system, for both collocated overall system from any code modification within ser-
and distributed scenarios, provide a great flexibility. Sim- vices. As long as the IDLs for the interfaces and mes-
ilarly, the facility to create specific robot controllers for sages for data distribution remain the same, any change
particular scenarios by easily assembling different sets of to the internals of a service will not affect other ser-
services brings a great flexibility. Scalability is obtained vices. This is illustrated in Fig. 4 with the evolution of
by the service encapsulation, the loose coupling between the Navigator service. The navigator service allows
services, and the interchangeability of services providing the rover to reach a given goal while avoiding obstacles
identical interfaces. Finally, insulation of each service by building a dynamic map of the environment. While
and reliance on robust middleware promote a high level ignoring the mapping services dependencies for the sim-
of reliability. plicity of the discussion, we can see that the Navigator
service has strong dependency on the Locomotor ser-
vice and PoseEstimator service. In addition the
3. SORA BENEFITS Navigator service is used by the Executive ser-
vice. The navigator has undergone major re-structuring
over the years to gain performance and obtain more flexi-
This section describes the benefits of SORA during the bility. In particular the initial navigator heavily relied the
IRG robotics field tests. Each of these benefits are gener- Navigation classes from the CLARAty [22] framework,
ated by architectural concepts and illustrated with a con- state of the art at the time. The current navigator replaces
crete example. Most of the advantages reported below the previously sequential model with a newly developed,
 Table 1: Range of key parameters during field tests using SORA

Parameter Minimal/Unfavorable configuration Full-blown/Optimal configuration

Configuration 1 robot + field team of 5 2 robots + field team of 6 + ground team of
9 + science team of 12
Local wireless network 10Mbps (degraded 802.11b) to no comms 50Mbps (Meshed Tropos network with
(robot out of range for extended periods 802.11n)
and navigating fully autonomously)
Link to ground 2Mbps (satellite link) to no comms (link 15Mbps (microwave link) with optional
loss or no ground team) 50s delay introduced
Number of services on the Simple navigation: 12 [Hardware (HW)=2, Autonomous navigation and science in-
robot Sofware (SW)=6, IN (Infrastructure)=4] struments: 55 [HW=19, SW=22, IN=14]
Distributed services (not on 1-2 (”mission manager” to start an au- > 5 multiple control panels and 3D visual-
the robot) tonomous plan and monitor robot health) ization plus data collection system
Data collected on the robot 80MB/h (no science and exclude stereo im- 1GB/h (LIDAR data + stereo images in-
ages) cluded)

concurrent framework: sensor reading, map building and consumer, that can subscribe to any message type and se-
action selection are asynchronous and the robot drives rialize it to file, including a trace of the request/reply pairs
continuously. New terrain analysis and path evaluation of commands. With the Miro LogPlayer tool, the log files
algorithms were incorporated into the navigation system. created can be replayed at one’s convenience to analyze
This extensive development effort has been transparent to a particular situation. The LogPlayer also permits data to
the many users of the navigator interface. be fed back to the data-bus, where it can be consumed in
the same manner as the original data.

3.2. Communication Patterns

3.3. Stable Interfaces
SORA services are interconnected with a dual communi-
cation pattern: RMI and Data Publish/Subscribe. These All SORA interfaces (allowing remote method invoca-
two modes are complementary. RMI is especially conve- tion), and all data structures (participating in the pub-
nient for commanding individual services and querying lish/subscribe mechanism) are defined with the IDL lan-
their state while the Publish/Subscribe mechanism is bet- guage. Each IDL specification is carefully designed to
ter suited for distributing data to multiple services. Even be as generic as possible while allowing access to spe-
though it is possible to implement a request/reply pat- cific capabilities of the sub-system. These interfaces and
tern using a data distribution model, the stricter RMI ap- data structures have certainly evolved from the initial
proach enables greater static checking and code genera- SORA conception to today’s system. However, changes
tion. Thus RMI makes the implementation of transaction- are mostly extensions of existing interfaces or addition of
oriented interfaces, such as robot commanding, more ef- new data structures to address a new domain. Keeping
ficient and less error prone. In addition to the regular these interfaces stable and their specification in a unique
RMI concept, SORA uses the Asynchronous Method In- repository (shared by all the parties contributing to soft-
vocation (AMI) [23] pattern which augments the service ware for robotic field tests) permits to easily swap a ser-
decoupling and simplifies services implementation. For vice for an equivalent one and enables to maintain all the
example, a service can take minutes to complete an op- tools around the robot controller up to date.
eration; however, it can be impractical for the caller of
this operation to block its thread of execution while wait- An example of this evolution is shown in Fig. 4. A new
ing for completion. Using AMI, the call will immediately version of the PoseEstimator has been written for
return and the caller will be notified by a callback when the second HMP field test. The PoseEstimator com-
the completion actually occurred. All the complexity of putes the best estimate of the rover position and orienta-
AMI, thread safety, and exception handling is handled by tion using a Kalman Filter to process various sensor in-
the middleware. puts (not all included in this figure). The second version
of the PoseEstimator relies on an additional sensor,
Despite the advantages of RMI and AMI, data distribu- and computes poses using a new algorithm. Thanks to the
tion is preferable when multiple consumers are interested SORA architecture, the previously existing sensor data is
in the same type of data or when data needs to be trans- consumed the same way and the services depending on
mitted periodically. In addition, the Publish/Subscribe the PoseEstimator did not have to be modified at all.
mechanism decouples the services further as producers
of data are totally unaware of the consumers. SORA con- CORBA interfaces support inheritance. SORA uses this
tains a key service exploiting fully the Publish/Subscribe feature extensively to define the services interfaces. In
mechanism: the data logger. This service is a generic data addition SORA extend this polymorphism to the imple-
mentation of the interfaces. Class polymorphism is a 3.5. Robust Middleware
powerful concept of any object-oriented language. This
is exemplified when used at the service level with in-
terface polymorphism. The best example in SORA are The architectural paradigms implemented in SORA
the interfaces to the services encapsulating science in- would not have achieved such a reliable and extensive
struments functionalities. For each field test IRG rovers set of features without adopting a robust middleware.
carry a new set of science instruments to achieve some As mentioned in the Section 2, SORA heavily relies on
particular science goal. Of course, each instrument has CORBA coupled Miro, and increasingly on DDS. These
a particular set of characteristics that require some spe- dependencies obviously are imposing some constraints
cific methods to access its functionalities. However, all due to the choice of a specific middleware (see Section 4
these instruments’ interfaces inherit from the same base for the drawbacks). Middleware is pervasive, so replac-
Instrument interface. This allows a range of services ing any middleware for another one would require sub-
to control and access any instrument in a transparent man- stantial code changes. However, this commitment to a set
ner at a high level. This is particularly the case for the of well-established libraries enables rapid progress with
Executive service that executes plans defined by the a finite (and usually limited) amount of resources. The
scientist. A plan contains instructions when instruments ACE/TAO CORBA implementation went though several
need to be activated/deactivated, or when to acquire a release cycles, so about once a year SORA updates to use
sample. The Executive is only aware of the base type the latest revision. Each new revision of ACE/TAO re-
of Instrument and thus will command any instrument solves some issues and bring new improvements. SORA
which inherits and implements that base-interface. directly benefited from these new versions representing a
considerable amount of work from outside parties. At the
The abstract interfaces in combination with the easy re- same time, CORBA being a standard, new revisions of
configurability of the controller is also used to replace the implementation only requires minor changes on the
some (or all) services of the controller for the physical user side. The same stability argument can be made for
robot with simulated components. The Locomotor ser- Miro. The few changes in the Miro source code over the
vice on Fig. 3 is responsible for translating high level years is a praise to its reliability and SORA has been very
locomotion commands (translate, drive arc) to individ- well supported by Miro’s initial set of features.
ual motor commands regarding the rover kinematics and
actuation capabilities. These low level commands are Finally, appropriate usage of middleware frees the devel-
passed to the WheelGroup service that abstracts the ac- opers of the robotic software from issues or changes of
tual robot hardware. A simulated WheelGroupSim ser- the lower layers. For example, as shown in Fig. 2, the
vice which simulates the robot wheels motion has been Field Site and Ground Operations are connected using an
developed. It can simply be started in place of the orig- unreliable satellite link. To cope with lower and intermit-
inal service to obtain a simulation of the rover motion. tent data rates, the robot telemetry is transferred using a
Applications like the 3D visualization tool which is used specific method developed as part of Miro. However, this
to monitor the rover progress, do not need to be modified extension of the data distribution method is completely
at all and it is a matter of switching configuration files to transparent to the services running either on the Field Site
start a real rover controller or a simulated rover controller. or Ground Operations. The exact same applications are
running on each site, not cognizant if the connection is
supported by a direct optical fiber link (situation for the
local test site at NASA Ames) or by a satellite link.
3.4. Component Configurator Pattern

SORA uses the “Component Configurator” pattern [24]

4. SORA SHORTCOMINGS
to combine the services in a full system. A configuration
file specifies which services should be started to create
a particular controller. Despite the fact that these con-
The long-term use, continuous development and inten-
troller configuration files are currently crafted manually,
sive field testing of SORA provided a good stress-test un-
they have been a tremendous tool to develop and test our
covering weaknesses in the design and implementation
robotic software. Configurations are created for each in-
choices as well as the deployed software technologies of
dividual scenario. Scenarios are ranging from a minimal
the SORA architecture. In this section we want to dis-
controller containing only the locomotion service to a full
cuss some of those: scalability of the publish/subscribe
blown field test controller requiring a suite of science in-
mechanism, re-use of data structures, synchronization of
struments, passing by controllers containing simulated
services and middleware acceptance by external parties.
components. In addition to facilitate developers task,
the simplicity and rapidity of creating a new controller
configuration also allows tuning controllers regarding re-
source usage or memory footprint. The flexibility and ro- 4.1. Publish/Subscribe Scalability
bustness of the SORA services assembled with the com-
ponent configurator pattern can be measured by the num-
ber of services (range 30 to 50) running in concert on a The CORBA Notification service is designed as a cen-
robot, while sharing the ressources harmoniously. tral monolithic data-relay. This obviously makes it a
single-point of failure and is not scalable to complex dis- 4.3. Synchronization of Services
tributed applications. Also, the QoS options do not sup-
port bandwidth-management very well, which is a major
scalability concern in heterogeneous networks. Further- In a loosely coupled architecture tight synchronization
more the Notification service has other short-comings, of services is generally not envisioned. This is gener-
such as a very inefficient transfer of type-code informa- ally true for most of our services, too. Triggering activity
tion, that are of concern especially on low-bandwidth in one service on an event emitted by another service is
network-links. We overcame these problems by deploy- straight forward, but other synchronization primitives do
ing a customized extension that allows to create a feder- not exist.
ation of notification service instances exchanging events
between instances on a separate data-channel [25]. We This becomes more of an issue, with simulation, when
also added a time-based filter, implementing message- single-stepping and faster-than-real-time execution be-
frequency limits between nodes of the federation. come of interest. Synchronization of the systems real-
time clock is usually provided by network services. But a
While this system provides a solution for our specific re- uniform, synchronized time-step is difficult to provide ef-
quirements it is obviously not a generalized system aimed ficiently in a large-scale distributed system and generally
at addressing all design deficiencies of the Notification not provided by any middleware or object model infras-
service. SORA transition to DDS allows to overcome tructure.
these limitations regarding data distribution. DDS ex-
tensive QoS capabilities permits its deployment in very
difficult network environments. Furthermore it supports 4.4. Middleware Acceptance
different modes of data-dissemination that allow imple-
mentation of a wider set of communication patterns over
a data-bus. On the down-side, adding a second middle- Objective criteria generally state a clear benefit of mid-
ware package neither helps the footprint nor the complex- dleware over ad-hoc solutions for distributed systems de-
ity of the software architecture. velopment. Nevertheless, the acceptance of middleware,
especially of CORBA is often an issue. The major issues
reported usually are footprint and complexity.

4.2. Rigidity of Data Structures Both those arguments are only partially true. Middle-
ware packages usually have similar foot-print as other
frameworks and libraries that are regularly used in the
The publish-subscribe model of data-distribution is cen-
development of large-scale systems (GUI toolkits, data-
tral to many SORA like distributed systems. Unfor-
bases, JIT-compiler etc). It is difficult to over-come es-
tunately this model violates some of the abstraction
tablished misconceptions regarding the complexity and
concepts of the object-oriented paradigm. The data-
performance of middleware In our experience, the com-
structures used for distributing information through the
plexity of middleware can be managed by a small number
system become the public interface to write applications
of domain experts, though. The other developers then do
against. This is a necessary caveat in a data-centric
not have to be concerned about the details of the distribut-
distributed applications such as robotics, but can affect
edness of their applications.
maintainability and code re-use.
One factor which stays true is, that most middle-
In addition, the data-distribution systems used by SORA ware packages (especially open-source packages like
do not efficiently support type-polymorphism. A data- ACE/TAO) are not trivial to install and to integrate into
bus supporting single-inheritance in the disseminated the build-process. ACE/TAO now provides packages for
data-structures would allow generic data-consumers sub- most Linux distributions, but an installer for Windows is
scribing to a generalized concept (i.e. position), to ig- still missing. Also, the poor readability of the generated
nore the specific sensor information (i.e. additional GPS code also makes it difficult for the non-domain expert to
data fields). However, the CORBA Notification service directly look up the method signatures in the code gener-
as well as DDS only allow retrieval of the payload-type ated by the IDL-compiler.
of an event that was put in on the publisher side.

In consequence, SORA data producers (like a pose sen-

sor) are less interchangeable than if type-polymorphism 5. CONCLUSION AND FUTURE WORK
was available. In a similar way, code re-use is limited
when writing data consumers since they cannot share a
common high level data type. Finally, this limitation also This paper describes the Service Oriented Robotic Ar-
affects the maintainability of data collected during field chitecture (SORA) design concepts, the benefits brought
tests. The logged data is used extensively after the field by this approach and the difficulties encountered. SORA
tests for analysis and development purpose. So any exten- has been deployed to multiple high fidelity mission sim-
sion of previously defined data-types requires additional ulations of remote rovers controlled from ground opera-
effort to convert the logged data to match the new type- tions. These experiments have demonstrated the advan-
signatures. tages of SORA in term of flexibility, scalability and re-
liability. At the same time, these experiments helped to [9] Mallet, A., Pasteur, C., Herrb, M., Lemaignan, S., & In-
identify SORA limitations in those areas. grand, F. Genom3: Building middleware-independent
robotic components. In Robotics and Automation (ICRA),
Future work on SORA includes refining some of the SOA 2010 IEEE International Conference on, pages 4627 –
concepts, fully replacing the CORBA publish/subscribe 4632, May 2010.
mechanism with the DDS standard, and continuing to [10] Fong, T., Allan, M., Bouyssounouse, X., et al. Robotic site
standardize the robotic interfaces with other NASA cen- survey at haughton crater. In International Symposium on
ters. In addition, the SORA source code has been cleared Artificial Intelligence, Robotics, and Automation in Space
for release under the NASA Open Source Agreement li- (iSAIRAS), 2008.
censing and thus will be available to a larger community
for evaluation and contributions. [11] Deans, M. C., Fong, T., Allan, M., et al. Robotic scouting
for human exploration. In AIAA Space 2009, Pasadena,
The advantages of SORA extend beyond the domain of California, September 2009.
the robot controller architecture. SORA is the backbone [12] Fong, T. W., Bualat, M., Deans, M., et al. Robotic follow-
supporting IRG field test scenarios by connecting the var- up for human exploration. In Space 2010, pages AIAA–
ious robotic mission tools with a powerful distributed sys- 2010–8605. AIAA, September 2010.
tem infrastructure. The SORA design and implementa- [13] Object Management Group. OMG IDL. http://
tion has enabled a full eco-system of robotic capabilities, www.omg.org/gettingstarted/omg_idl.htm,
and will continue to smoothly support their evolution in 2012.
the future.
[14] Object Management Group. CORBA/IIOP specification.
Technical report, OMG, Framingham, MA, April 2004.

ACKNOWLEDGMENTS [15] Object Management Group. Data distribution service

(DDS). http://www.omg.org/spec/DDS, 2012.
[16] ACE/TAO. ACE, TAO, and CIAO sucess sto-
This work was supported by the NASA Exploration Technology ries. http://www.cs.wustl.edu/˜schmidt/
Development Program and the NASA Enabling Technology TAO-users.html, 2012.
Development and Demonstration Program The authors would [17] Utz, H., Sablatnög, S., Enderle, S., & Kraetzschmar, G. K.
like to thanks all the individuals who contributed to SORA: Miro – middleware for mobile robot applications. IEEE
Mark B. Allan, Xavier Bouyssounouse, Matthew Deans, Susan Transactions on Robotics and Automation, Special Is-
Lee, Mike Lundy, Eric Park, Liam Pedersen and Vinh To. sue on Object-Oriented Distributed Control Architectures,
18(4):493–497, August 2002.
[18] RTI. RTI DDS. http://www.rti.com/products/
REFERENCES dds/, 2012.
[1] Flückiger, L., To, V., & Utz, H. Service-oriented robotic [19] Schmidt, D. C. & Vinoski, S. Object interconnections:
architecture supporting a lunar analog test. In Interna- The CORBA component model: Part 1, evolving towards
tional Symposium on Artificial Intelligence, Robotics, and component middleware. C/C++ Users Journal, February
Automation in Space (iSAIRAS), 2008. 2004.

[2] Amoretti, M. & Reggiani, M. Architectural paradigms for [20] Torres, R., Allan, M., Hirsh, R., & Wallick, M. RAPID:
robotics applications. Advanced Engineering Informatics, Collaboration results from three NASA centers in com-
24(1):4 – 13, 2010. Informatics for cognitive robots. manding/monitoring lunar assets. In Aerospace confer-
ence, 2009 IEEE, pages 1 –11, march 2009.
[3] Object Management Group. Robotic Technology Com-
[21] Pedersen, L., Utz, H., Allan, M., et al. Tele-operated lunar
ponent (RTC). http://www.omg.org/spec/RTC,
rover navigation using LIDAR. In International Sympo-
2012.
sium on Artificial Intelligence, Robotics, and Automation
[4] RoSta. Robot standards and references architectures. in Space (iSAIRAS), 2012.
http://www.robot-standards.org/, 2009.
[22] Nesnas, I., Wright, A., Bajracharya, M., et al. CLARAty:
[5] Orocos. OROCOS: open robot control software. http: An architecture for reusable robotic software. In Proceed-
//www.orocos.org/, 2012. ings SPIE Aerosense Conference, Orlando, Florida, April
[6] Willow Garage. Robot Operating System (RoS). 2003.
http://www.willowgarage.com/pages/ [23] Schmidt, D. C. & Vinoski, S. Programming asynchronous
software/ros-platform, 2012. method invocations with CORBA messaging. C++ Re-
[7] Makarenko, A., Brooks, A., & Kaupp, T. Orca: Compo- port, 11(2), February 1999.
nents for robotics. In 2006 IEEE/RSJ International Con- [24] Schmidt, D. C., Stal, M., Rohnert, H., & Buschmann,
ference on Intelligent Robots and Systems (IROS’06), De- F. Pattern-Oriented Software Architecture: Patterns for
cember 2006. Concurrent and Networked Objects. Wiley & Sons, 2000.
[8] Jackson, J. Microsoft robotics studio: A technical intro- [25] Hirsh, R. L., Simon, C. L., Tyree, K. S., et al. Astronaut
duction. Robotics Automation Magazine, IEEE, 14(4):82 Interface Device (AID). In Proceedings of AIAA Space
–87, December 2007. 2008, San Diego, CA, September 2008. AIAA.