Barriers to Adopting Robotics Solutions
Gregory Broten and David Mackay
Defence Research and Development Canada – Suffield
{firstname.lastname}@drdc-rddc.gc.ca
Abstract— Building upon it’s wealth of experience in the
development of tele-operated vehicles, Defense R&D Canada
(DRDC) has recently embarked on a program to develop co-
operating autonomous robotic vehicles. This new focus required
a multi-disciplinary approach in which a number of researchers,
with a broad range of knowledge and experience in robotics,
collaborated to construct an autonomous vehicle. The assembled
team recognized early on that the software, required to imple-
ment autonomous capabilities, would dominate the development
process. This paper discusses DRDC’s experiences in adopting
readily available robotics solutions, including the benefits accrued
and the barriers encountered.
I. I NTRODUCTION
In 2003, DRDC embarked on a program, the Autonomous
Land Systems (ALS) project, whose goal was the demonstra-
tion of cooperating autonomous vehicles operating within a
military context. To meet this goal, DRDC assembled a multi-
disciplinary research team that included experienced roboti-
cists, controls and control software experts, and a significant
number of inexperienced newcomers.
Early work reviewed the state-of-the-art in the field of
mobile robotics, followed by an assessment of DRDC’s tele-
operated vehicle program. This assessment revealed that while
tele-operated vehicles were still of interest, the software sys-
tem / architecture employed in these vehicles was unsuit-
able for more complex, autonomous robotic implementations.
Thus, working with a clean slate, researchers were free to
chart the course that best suited the program’s requirements.
Given DRDC’s “research and development” imperatives, its
interests in autonomous robotics extend beyond pure research
into development and product delivery. With this long term
view, the team understood that the software underpinning the
robotics program must evolve with the program, hence it must
be modular, flexible and extensible.
To achieve these goals, DRDC adopted a Component Based
Software Engineering (CBSE) approach using frameworks and
middleware. Frameworks define commonly used design pat-
terns that yield generic component implementations [1], while
middleware provides the mechanisms that allow components
to share information and data. Additonally, DRDC required
a software development environment, and an architecture that
was applicable to unmanned ground vehicles. Finally, rejecting
the “not invented here” mindset, DRDC actively sought open
source implementations of both frameworks and middleware
toolkits as a means of jump starting their research program.
This paper reviews DRDC’s quest for a software develop-
ment environment, framework, middleware and architecture
and is divided into six sections. Section II describes DRDC’s
envisioned requirements for architectures and supporting soft-
ware tools. The steps taken to meet the requirements are given
in Section III. DRDC’s experiences with robotics solutions are
detailed in Section IV. In Section V the barriers and difficulties
experienced, as well as the successes, are highlighted. Finally,
conclusions are given in Section VI.
II. S OFTWARE D EVELOPMENT E NVIRONMENT AND
A RCHITECTURAL R EQUIREMENTS
DRDC researchers recognized that the development of
autonomous systems, with its emphasis on implementing au-
tonomous capabilities, was dominated by the software devel-
opment process. This viewpoint is held by others, including
S. Thrun the team leader of the Stanley vehicle that won
the DARPA Grand Challenge who states “Treat Autonomous
Navigation as a software problem” [2]. Hence, DRDC created
an extensive list of desirable software properties [3], which
are summarized below:
1) Programming language(s), compiler, and operating sys-
tem feature longevity.
2) Compatibility with other major robotics research insti-
tutions.
3) Based upon a strong middleware toolkit.
4) Flexible, modular, scalable and extensible implementa-
tion that is built upon components.
5) Based upon a framework approach that allows an archi-
tecture to emerge from the system requirements.
III. ACHIEVING THE R EQUIREMENTS
A. Software Development Environment
Based upon group experience, research, and subjective
comparisons [4], it was concluded that open source software
and tools, executing under the Linux operating system, using
the C/C++ programming languages and the GCC tool chain,
would best suit DRDC’s software development requirements.
B. Networking Middleware
Following a preliminary examination, DRDC subjectively
ranked a number of networking middleware toolkits, including
ACE [5], TAO [6], RTC [7], NDDS [8], NML [9] and IPT/IPC
[10], [11]. This investigation highlights two trends in the
robotics community; the development and use of specialized,
robotics-specific middleware (IPC/IPT/RTC) and the adoption
of generic middleware (ACE/TAO/NDDS) to robotics applica-
tions. Generic middleware, especially CORBA, allows for the
most flexible, modular and extensible implementation, but at
the cost of resource consumption and complexity.
 Solution Self Contained Difficulty
C. Robotics Architectures
Miro/ACE/TAO No 3
Numerous robotics architectures and/or framework based Carmen/IPC Yes 1
architectures were reviewed [1], including Player/Stage [12], Player Yes 1
CLARAty [13], Marie [14], Carmen [15], Miro [16] and
TABLE II
Orca [17]. Table I provides more details on a selected list of
E ASE OF INSTALLATION OF THE CANDIDATE SOLUTIONS RANKED ON A
architectures. The rating given to each category ranges from
SCALE OF 1 ( LEAST DIFFICULT ) TO 3 ( MOST DIFFICULT )
a 1 (low), to a 3 (high), and are subjective values from the
authors’ view points.

Open Tools Frame Middle Modular Usage

works ware arise in situations like this involving multiple packages with
Player 3 3 3 1 2 2 uncoordinated release/update schedules.
Carmen 3 3 2 2 2 1
MARIE 3 3 2 2 3 1 B. Introductory Usage
Miro 3 3 3 3 3 1
Orca 3 3 3 3 3 1
Each solution was exercised from a high level perspective.
CLARAty 1 ? ? ? ? 2 These investigations were conducted in the 2004 time frame
when Player was available as version 1.x, Miro was only
TABLE I available as a beta version, and Carmen was a 2002 release.
A SUBJECTIVE COMPARISON OF SELECTED ATTRIBUTES OF THE Each solution was evaluated with respect to the following
CANDIDATE ARCHITECTURE, ADAPTED FROM [1] features:
• available documentation,
• useful tutorials and code examples,
From the list of candidates only three architectures, Player,
• support for multiple robot platforms,
Carmen and Miro, were freely available and of sufficient
• availability of sensor drivers,
maturity to merit further investigation.
• capabilities such as localization and mapping, and
IV. E XPERIENCES WITH ROBOTICS S OLUTIONS • simulation capabilities.

DRDC researchers examined, in detail, three open source Each solution is subjectively ranked with respect to these
solutions, where a solution is the combination of an architec- features in Table III.
ture and the middleware toolkit(s) upon which it was built. Solution Miro/ACE/TAO Player Carmen/IPC
These solutions included: Documentation 2 3 1
• the Miro (Middleware for Moblie Robot Applications) Code Examples 1 2 1
framework, based upon the ACE and TAO middleware, Platforms 2 3 1
Drivers 2 3 1
• the Player toolkit and Stage simulation package,
Applications 2 3 1
• Carmen (The C.M.U. Robot Navigation Toolkit), based Simulation 1 3 2
upon IPC middleware.
TABLE III
The evaluation of these solutions was, by necessity, a
I NITIAL ACCEPTANCE CRITERIA FOR THE CANDIDATE SOLUTION RANKED
subjective procress that involved numerous researchers and
ON A SCALE FROM 1 ( POOR ) TO 3 ( GOOD ).
the views given are the overall group’s collective impressions.
The follow sections evaluate each solution with respect to: the
installation process, including configuration and compilation;
the ease of use; and the overall capabilities. With reference to Table III, clearly Player contains the
most user-friendly features. Miro was second in terms of
A. Installation friendliness and Carmen trailed in last place. The following
Each solution is provided as source code. The source code is sections provide specific feedback on each of the three candi-
extracted (if required), configured, and compiled. All solutions date solutions.
used similar installation procedures with TAO and ACE being 1) Player: Player was subjectively judged as the easiest
the exception, as it used mwc instead of the Gnu autotools. solution to use. Player’s documentation, example code and
Table II subjectively rates each solution with respect to ease close ties with the Stage simulator make its potential easily
of installation. apparent to even the most casual user. Though, this conclusion
Player and Carmen/IPC are self-contained solutions that may simply be a reflection of the simple client/server model
do not require other source code modules. Miro is not self- employed.
contained, depending upon the ACE/TAO toolkits, both of 2) Carmen/IPC: Carmen suffered from a lack of doc-
which must be compiled from source. In addition, Miro umentation where the only available documentation was a
requires cvs access to the Miro repository in order to acquire small README file in the source code directory. Additionally,
the most recent version. Thus, the user is further burdened the source files were thin on embedded documentation; they
with handling the version incompatibilities that inevitably included neither useful file headers describing a file’s purpose
nor, for the most part, descriptive function headers. Simply put,
the user was forced to read the source code in order to under-
stand Carmen’s implementation and capabilities. Conversely,
the IPC middleware, upon which Carmen is built, included a
detail usage manual.
3) Miro/ACE/TAO: Both ACE and TAO are mature middle-
ware toolkits and have an abundance of documentation avail-
able. The TAO version of CORBA is a very large and complex
software suite, which makes it difficult to comprehend its
capabilities by simply reading a book or manual. Fortunately,
the Miro framework hides many of the CORBA and ACE
details; thus, reducing the requirement to understand CORBA’s
complexity. The Miro website doesn’t provide a large amount
of information, but the Miro manual gives the user an adequate
overview of Miro’s implementation and capabilities. Although
the manual covers a large number of topics, it does not include
tutorials or examples with which the user can explore Miro’s
capabilities.
C. Capabilities
Each solution was also evaluated for its capabilities, as given
in the following list:
• the use of middleware,
• the capabilities of the middleware,
• availability of multiple message passing paradigms,
• the use of a framework based approach,
• the encouragement of a component based implementa-
tion, and
• the suitability to multi-process implementations.
TableIV ranks each of the candidate solutions with respect
to these capabilities.
Solution Miro Player Carmen
Middleware Yes No Yes
Middleware Capabilities 3 1 2
Messaging Paradigms 3 1 1 considered adopting Player and Miro.
Components 3 2 1 Player was the clear leader in terms of ease of installation
Frameworks 3 2 2 and use. With a relatively modest effort, users were able to
Multi-Process 3 1 2
TABLE IV
R ELATIVE CAPABILITIES OF THE CANDIDATE SOLUTIONS RANKED ON A
SCALE FROM 1 ( POOR ) TO 3 ( GOOD ).
As can be seen in Table IV, Miro is the most capable
solution. Specific comments on each individual solution are
given in the following sections.
1) Player: Quoting the Player FAQ, “Player is a device
server that provides a powerful, flexible interface to a variety
of sensors and actuators”. Thus, at its core, Player uses a
client/server model to provide a defined, uniform and con-
sistent interface to devices. This uniformity encourages the
development of components, since device drivers following
the Player standard are portable and reusable. Although Player
has many admirable features, its lack of middleware and its
client/server focus limit its flexibility. Additionally, it is not
not well suited for multi-process implementation since there is
no simple facility for distributing intermediate results between
independent processes.
2) Carmen: Unfortunately, the lack of documentation made
it difficult to assess Carmen’s capabilities since any in-
depth exploration required a significant expenditure of time
and effort. This being noted, DRDC researchers were able
to achieve a reasonable understanding of Carmen’s imple-
mentation philosophy and its usage. Unlike Player/Stage,
Carmen does not follow the client/server analogy, rather it
implements a publish-subscribe paradigm where individual
services exchange data using IPC. This allows modules to
run as individual processes, calling upon IPC as a means of
synchronization and data exchange. Under this paradigm, the
structure of these data exchanges is crucial to understanding
the systems operation, but, unfortunately, IPC contains no
formal mechanisms for defining these messages.
3) Miro: Miro was the most the powerful, complex
and flexible of all the architectures reviewed. Miro, us-
ing ACE/TAO middleware, supports multiple messaging
paradigms, allowing data to flow in a client/server manner, as
the publication of and the subscription to events, or both. The
development of components is encouraged by Miro via the
CORBA Interface Description Language, which defines the
data and methods associated with message objects. Finally,
Miro’s framework implementation allows the user to evolve
an architecture to meet his particular needs. Not surprisingly,
constructing these impressive capabilities requires complex
software. Although Miro shields the user from a significant
portion of this complexity, by hiding many implementation
details, the overall implementation is still complex and can be
difficult to understand.
D. Discussion
Of the three solutions investigated in detail, DRDC only
install and run Player examples under the Stage simulation
environment. Additonally, DRDC researchers controlled the
Segway RMP robot using the available Segway driver and
the SICK laser device driver. Trials demonstrated the Segway
avoiding obstacles while navigating to a target waypoint using
the provided VFH obstacle avoidance software, a GPS, and
waypoint following.
Although Player has many positive attributes, its limited ca-
pabilities prompted DRDC researchers to examine other pos-
sibilities. Despite the significant effort involved, researchers
installed and investigated the Miro framework. These inves-
tigations revealed that Miro’s capabilities were significantly
more extensive than Player’s and it was concluded that Miro
would better meet DRDC’s requirements.
DRDC adapted and extended Miro to support the Kyoker
Industries Raptor, hydrostatic all wheel drive utility vehicle,
as shown in Figure 1. The Raptor vehicle is capable of fully
autonomous operations and hosts a complete suite autonomy
applications. Overall, the Raptor vehicle development totalled
 Robotics Controls Linux Windows Software Skills
1 5 3 1 5 1 1
2 5 5 1 5 5 4
5 1 5 5 5 5 5
4 1 5 0 5 0 0
5 5 5 5 5 5 4
6 5 1 0 5 5 2
7 5 5 0 5 1 0
8 5 1 5 5 5 4
9 0 0 5 5 5 5
10 0 0 0 5 0 4
11 0 1 0 5 0 1
12 0 1 0 5 0 0

TABLE V
Fig. 1. The Raptor Vehicle Unmanned Ground Vehicle. I NITIAL AND SUBSEQUENT SKILL SETS OF DRDC TEAM MEMBERS,
RANKED ON A SCALE OF 0 (N ONE ) TO 5 (E XPERT ).

over 60,800 source lines of code that corresponds to an

estimated 13 person-years of development effort.
V. BARRIERS TO A DOPTION
Given DRDC’s recent experiences with reviewing numer-
ous robotics solutions, its observations should provide useful
feedback to researchers in the Programming Environments
in Robotics and Automation community. In a retrospective
review of its program, DRDC concluded that four barriers
hamper the adoption of available solutions. These barriers are
as follows:
• the skill level of the personnel involved,
• the software complexity and required learning curves,
• the level of documentation, and
• restrictive implementations.
Each of these barriers are discussed, in further detail, in the
following sections.
A. Personnel Skills
Hand in hand with the recognition that robotics requires a
multi-disciplinary approach, is a belief that roboticists have
varied backgrounds that include significant software skills.
In an ideal world, all researchers would have the requisite
software skills, but real robotics teams include disparate mem-
bers with a variety of backgrounds. The DRDC research team
included members who had in-depth software experience, but
some members did not have a formal software background;
thus, were unfamiliar or uncomfortable with complicated soft-
ware development and integration environments. TableV lists
the skill sets of the DRDC team members; the column at the
far right indicates whether or not the team member eventually
mastered the software skills required to independently develop
software under Miro/ACE/TAO.
This table highlights the correlation between existing soft-
ware skills and the successful mastery of the Miro framework
and the ACE/TAO middleware toolkits. Plainly stated, the team
members who did not already possess software experience,
regardless of their other skills, did not easily acquire the
software skills required. This split in capabilities posed a
dilemma, since members without the required software skills
found it difficult to integrate and test their algorithms on an
operational robot. Although there are various underlying issues
that could have influenced this split, it is believed that software
complexity was the most significant contributing factor.
B. Software Complexity and Learning Curves
A major issue confronted by the DRDC team was the sheer
complexity of the available solutions. Robotics researchers
have recognized the advantages of software reusability and
have achieved progress towards with goal. A consequence of
this push for reusable, portable, modular and extensible soft-
ware is robotic systems with sophisticated implementations.
Fortunately, frameworks, design patterns, and components
can shield the researcher from many of the implementation
details. This reduces the complexity but robotics solutions
have used such techniques with varying degrees of success.
To illustrate the effects of complexity, two code snippets, one
taken from Player and the other for Miro, are shown below.
The Player code snippet requires only three lines of code to
instantiate a robot as a PlayerClient, grab a Position2dProxy
and get the LaserProxy. With this setup completed, the client
can acquire laser range data and pass positional commands to
the robot.
int main(int argc, char **argv)
{
parse_args(argc,argv);
using namespace PlayerCc;
PlayerClient robot(gHostname, gPort);
Position2dProxy pp(&robot, gIndex);
LaserProxy lp(&robot, gIndex);
pp.SetMotorEnable (true);
for(;;)
robot.Read();
}
The next code snippet uses Miro and CORBA to implement
a similar capability, except that instead of acquiring laser range
data the software acquires a generic ExampleEvent from an
event channel. From the code snippets shown below, it is
abundantly obvious that the Miro implementation is signifi-
cantly more complex and requires a greater understanding of
the underlying software.
int main(int argc, char *argv[])
{ // Create a server orb to find the events
Miro::Server server(argc, argv);
EventChannel_var ec(
server.resolveName<EventChannel>
("ExampleEventChannel"));
NotifyConsumer pushConsumer(ec.in(),
server.namingContextName, delay);
server.run(); // Enter CORBA event loop.
} domain has unique requirements and a “one size fits all”
NotifyConsumer::NotifyConsumer(
EventChannel_ptr _ec,
const string& domainName) :
StructuredPushConsumer(_ec),
{ barriers to adoption, but their continuing existence implies that
EventTypeSeq added, removed;
added.length(1);
added[0].domain_name = domainName.c_str();
added[0].type_name = "ExampleEvent";
setSubscriptions(added);
} complex software that is accompanied by useful, and pertinent
void NotifyConsumer::push_structured_event(
const StructuredEvent& notification
ACE_ENV_ARG_DECL_WITH_DEFAULTS)
throw(SystemException, Disconnected)
{ only 2 researchers conducted the original assessment of Miro,
const ExampleIDL *pEvent;
if (notification.remainder_of_body >>= pEvent)
cout << "Received event" << endl;
} independent manner. It is clear that Player has made the most
Although the Miro software is more complex, it also a more
sophisticated and flexible implementation. The single threaded
Player code executes tasks in a serial manner and blocks all
execution until new data is available. In contrast, the event
driven Miro implementation can be multi-threaded, receiving
multiple asynchronous event types and processing them in a
parallel manner.
C. Documentation
Documentation plays a crucial role, enabling researchers to
easily adopt existing code and build upon the expertise of other
researchers to create ever more capable robots.
During its review of architectures and middleware toolkits,
DRDC noted that the available documentation was, at best,
adequate and at worst, nonexistent. Given the complexity that
this software encompasses, expecting the user to learn from the
source code is not reasonable, especially when considering the
undisciplined documentation practices of many programmers.
Mature tools such as ACE/TAO and CORBA provided the best
level of documentation, including published textbooks. IPC,
which has been available for almost a decade, also provides
a good user’s manual. The documentation available for Player
was above average, which when coupled with its simple usage,
helped it become a favorite of many DRDC researchers. Miro’s
documentation while adequate for the expert programmer with
Linux experience, did not provide those with less experience
enough background material and information. Finally, the
early versions of Carmen provided very little documentation,
which greatly magnified the difficulty associated with under-
standing and using it.
D. Restrictive Implementations
While promoting reuse, modularity, portability, and exten-
sibility, solutions should not impose a rigid, fixed architec-
ture. Instead they must provide the flexibility that allows an
appropriate architecture to emerge. Even in DRDC’s field
of unmanned vehicles there is a wide spectrum of domains,
ranging from land, to air and marine environments. Each
architecture may not be appropriate.
E. Discussion
Obviously DRDC is not the first group to encounter these
the Programming Environments in Robotics and Automation
community must do more to address these issues.
The community should acknowledge that many robotics
researchers are not software wizards and, hence, require less
documentation. Up to 12 DRDC researchers contributed to
the development of the Raptor vehicle, but only 6 researchers
became proficient at using Miro. Of these 6 Miro users,
and they assisted others in acquiring Miro, ACE and TAO
skills. Conversely, 5 researchers acquired Player skills in a
progress towards the ease of use goal and, not coincidentally,
has become quite popular in robotics community.
Although less complex software is desirable, researchers
still need solutions that provide extensive capabilities. It would
have been easier for DRDC to adopt Player, but in the final
analysis, Miro’s capabilities more than offset Player’s ease of
use. To encourage researchers to adopt powerful frameworks,
such as Miro, more effort must be directed towards shielding
users from the implementation details and making the software
more user-friendly. This would give less skilled roboticists
access to the Miro framework, thus enhancing its adoption by
the robotics community. At the same time, Miro would retain
its extensive capabilities and allow a power user to adapt or
change it as required.
Progress towards lowering these barriers has been observed
over the past 2 to 3 years. When DRDC first reviewed Carmen,
the dearth of documentation was a significant problem. Today,
Carmen has SourceForge website that includes significantly
more documentation than was previously available.
Whether or not robotics solutions have gained much traction
is an open question. In an attempt to shed light on this
question, the software used by competitors in DARPA’s Grand
Challenge 2 was examined. The Journal of Field Robotics
(Aug. and Sept. 2006) profiled the 14 finalists in this offroad
UGV race and detailed each contestant’s vehicle, software,
algorithms and performance. Each paper was reviewed for
references to robotics solutions, namely architectures and
middleware toolkits. Of these 14 race contestants, only a
single contestant, CIMAR using JAUS [18], was based upon
an existing architectural solution. Conversely, five contestants
built upon some type of middleware toolkit, including High-
lander/Sandstorm under IPT [10]; Stanley using IPC [11]; Al-
ice built on Skynet [19]; and Propsect Eleven using Microsoft
.NET.
Unfortunately, there was little commonality in the middle-
ware toolkits , as each vehicle used a unique implementation
(Note: IPT and IPC different, but related). Although it appears
that solutions are gaining a foothold in the robotics field, there
is still a long way to go.
VI. C ONCLUSIONS
DRDC’s experience in adopting an open source framework
and middleware toolkit shows that researchers can build upon
the work of others. DRDC believes that the adoption of
Miro/ACE/TAO significantly reduced the time required to
construct an operational autonomous vehicle.
Although DRDC’s experiences with adopting Miro was
positive, a survey of DARPA Grand Challenge competitor
reveals that the robotics community at large (or at least the
unmanned vehicles field) still prefers to scratch develop their
own systems since only six of the fourteen entries built upon
existing tools and solutions. Given this low adoption rate,
researchers in the Programming Environments in Robotics and
Automation need to address this issue.
DRDC reviewed its experience in adopting robotics solu-
tions and identified four factors that complicated the process.
These factors were: the skill sets of DRDC personnel, software
complexity, poor or lacking documentation, and restrictive
implementations. The first three barriers are interrelated, as
they affect the effort required to adopt a solution. A solution
that demands significant existing expertise and requires a
significant effort, will probably be passed over. To facilitate the
acceptance of existing solutions, researchers must low the en-
try barriers and make the solutions accessible to all roboticists.
Solutions must also be provide informative documentation and
tutorials that exemplify its usage. Most roboticists have neither
the time nor the motivation to read the source code. It is the
solution developer’s best interest to lower barriers to entry and,
thus potentially increase his solution’s user/test/contributor
base. By creating a user community the solution will grow
and mature, and this will have a snowball effect, thus creating
an even large user community.
Player is a good example of solution that is making progress
on this front. Its entry barriers are low and it has a growing
community of users and contributors. Unfortunately Player’s
restrictive implementation currently limits its applicability to
complex, real-time implementation. The robotics’ community
needs solutions that are user-friendly like Player, which also
incorporate the capabilities provided by Miro. Until this hap-
pens, researchers will still be tempted to create unique one of
a kind solutions to their individual problems.
R EFERENCES
[1] G. Broten, S. Monckton, J. Giesbrecht, and J. Collier, “Software sysetms
for robotics, an applied research perspective,” International Journal of
Advanced Robotic Systems, vol. Volune 3, 1, no. 2005-204, pp. 11–17,
March 2006.
[2] S. Thrun, M. Montemerlo, H. Dahlkamp, D. Stavens, A. Aron, J. Diebel,
P. Fong, J. Gale, M. Halpenny, G. Hoffmann, K. Lau, C. Oakley,
M. Palatucci, V. Pratt, P. Stang, S. Strohband, C. Dupont, L.-E. Jen-
drossek, C. Koelen, C. Markey, C. Rummel, J. van Niekerk, E. Jensen,
P. Alessandrini, G. Bradski, B. Davies, S. Ettinger, A. Kaehler, A. Ne-
fian, and P. Mahoney, “Stanley: The robot tha won the darpa grand
challenge,” Journal of Field Robotics, vol. 23, no. 9, pp. 661–692,
September 2006, accepted for publication.
[3] G. Broten, S. Monckton, J. Giesbrecht, and J. Collier, Software Engineer-
ing for Experimental Robotics. Springer Tracts in Advanced Robotics,
2006, no. DRDC Suffield SL 2005-227, ch. UxV Software Systems, An
Applied Research Perspective.
[4] G. Broten, S. Verret, and B. Digney, “Unmanned ground vehicle software
development environment,” Defence R&D Canada – Suffield, DRDC
Suffield TM 2004-060, June 2004.
[5] S. Huston, J. Johnson, and U. Syyid, The ACE Programmer’s Guide.
Addison-Wesley, 2004.
[6] TAO Developer’s Guide, Oci tao version 1.3a ed. 12140 Woodcrest
Executive Drive, Suite 250, St. Louis, MO, 63141: Object Computing
Inc., 2003, vol. 1 and 2.
[7] J. . Pedersen, “Robust communications for high bandwidth real-time
systems,” Carnegie Mellon University, Tech. Rep. CMU-RI-TR-98-13,
1998.
[8] G. Pardo-Castellote, S. Schneider, and M. Hamilton, “Ndds: The real-
time publish-subscribe middleware,” Real-Time Innovations, Inc., 1999.
[9] W. S. J. Michaloski, F. Proctor, “The neutral message language: A model
and method for message passing in heterogeneous environments,” in
Proceedings of the World Automation Conference, Maui, Hawaii, June
2000.
[10] J. Gowdy, “Ipt: An object oriented toolkit for interprocess communi-
cation,” Robotics Institute, Carnegie Mellon University, Pittsburgh, PA,
Tech. Rep. CMU-RI-TR-96-07, March 1996.
[11] D. J. Reid Simmons, IPC - A Reference Manual, Carnegie Mellon
University - School of Computer Science / Robotics Institute, February
2001, iPC Version 3.4.
[12] B. Gerkey, R. T. Vaughan, and A. Howard, “The player/stage project:
Tools for multi-robot and distributed sensor systems,” Proceedings of
the 11th International Conference on Advanced Robotics, pp. 317–323,
2003.
[13] The CLARAty Architecture for Robotic Autonomy. Big Sky, MT:
IEEE, March 2001. [Online]. Available: http://robotics.jpl.nasa.gov/
tasks/claraty/overview/publications/index.html
[14] C. Cote, D. Letourneau, F. M. J.-M. Valin, Y. Brosseau, C. Raievsky,
M. Lemay, and V. Tran, “Code reusability tools for programming mobile
robots,” in Proceedings of the IEEE/RSJ International Conference on
Intelligent Robots and Systems, 2004.
[15] M. M. N. Roy and S. Thrun, “Perspectives on standardization
in mobile robot programming: The carnegie mellon navigation
(CARMEN) toolkit,” in Proceedings of the IEEE/RSJ Conference
on Intelligent Robots and Systems, 2003. [Online]. Available:
http://robots.stanford.edu/papers/Montemerlo03b.html
[16] H. Utz, S. Sablatnog, S. Enderle, and G. Kraetzschmar, “Miro - mid-
dleware for mobile robot applications,” IEEE Transactions on Robotics
and Automation, June 2002.
[17] A. Brooks, T. Kaupp, A. Makarenko, A. Oreback, and S. Williams,
“Towards component-based robotics,” in IEEE/RSJ International Con-
ference on Intelligent Robots and Systems, August 2005.
[18] “The joint architecture for unmanned systems, ref-
erence architecture specification ra v3.2 parts 1-3,”
http://www.jauswg.org/baseline/refach.html, August 2004.
[19] Y. Amir, C. Danilov, M. Miskin-Amir, J. Schultz, and J. Stanton, “The
spread toolkit: Architecture and performance,” John Hopkins University,
Baltimore, MD., CNDS 2004-1, 2004.