Abstract
Over the past 20 years, Defence Research and Development Canada has developed numerous tele-operated unmanned ground vehicles (UGV), many founded on the ANCÆUS command and control system. This paper relates how long experience with tele-operated UGVs influenced DRDC's shift in focus from tele-operated to autonomous unmanned vehicles (UV), the forces that guided DRDC's development approach and DRDC's experience adapting a specific tool set, MIRO, to a UGV implementation.
Introduction
Over the past 20 years, Defence Research and Development Canada has developed numerous tele-operated unmanned ground vehicles (UGV), many founded on the ANCÆUS [Broten et al, 2003] command and control system. First fielded in 1990, ANCÆUS solved difficult wireless networking and vehicle control problems five years or more before similar military systems appeared internationally. With remarkable foresight, ANCÆUS decoupled the vehicle platform from both the commands and communications interface and proved adaptable to other platforms such as the combat CAT, the tele-operated Bobcat with a backhoe and the ILDP landmine detection vehicle depicted in Figure 1.

Improved Landmine Detection Project (ILDP) Vehicle
Hardware and software development eventually overtook ANCÆUS, however. Substituting today's networking technology; ANCÆUS is analogous to the Joint Architecture for Unmanned Systems (JAUS) [JAUS-WG, 2004] command set. Through ANCÆUS, DRDC learned that systems integration becomes more expensive, error prone, and time consuming with:
the need to port, extend and maintain customized software across platforms and payloads, platforms and payloads that must evolve continuously to avoid obsolescence, platforms and payloads that are task dependent.
This paper describes DRDC's entry into autonomous systems research and adoption of a methodology and tool chain for managing complex software development. Section 2 explains the hazards of complex software system development and how rapidly evolving technology drove DRDC's decisions. Section 3 reviews current trends in robot architectures, detailing the forces that have guided DRDC's development. Section 4 overviews DRDC's successful application of a specific tool set, MIRO, to an outdoor UGV implementation while Section 5 summarizes DRDCs experiences and current progress.
The relentless increase in circuit density and efficiency is matched only by the growing size, complexity, and pervasiveness of software in personal, industrial, and military affairs. Driven by complexity, programming has evolved from CPU assembly language to network-aware Java and C#, proof that “the increasing complexity of programs has driven the need for better ways to manage that complexity” [Schildt, 1994].
Military robotics are particularly susceptible to these forces. With sufficient sensors, distributed signal processing, world representation, and control algorithms, UVs can navigate modestly complex environments in real-time. In a military context, such systems challenge development teams to manage the complexity, size, diversity, and future evolution of software and hardware components – a role for Middleware toolkits.
Networking Middleware
Middleware toolkits have been identified as a key ingredient in managing software complexity [Gowdy, 2000b]. DRDC further realized that open source software and collaborative research are crucial to capturing and communicating science, the ultimate product of DRDC's UGV research. Therefore, DRDC evaluated all toolkits for open source availability, support and use of open tools and operating systems; support for modular, extensible, flexible and scalable software systems; support for multiple messaging paradigms; usage and maturity; and applicability to robotic architectures. The following overviews some interprocess communication middleware packages and discusses some of their relative advantages and disadvantages.
CMU Toolkits: IPT, IPC and RTC
IPT [Gowdy, 1996], IPC [Simmons, 1991] and RTC [Pedersen, 1998] are related middleware toolkits emerging from the C.M.U.'s robotic research programs.
NML - Neutral Messaging Language
Used in NIST's NASREM and 4D/RCS architectures, NML is a uniform application interface (API) to communications functions [J. Michaloski, 2000].
NDDS - Network Data Distribution System
NDDS is a commercial middleware product by RealTime Innovations that implements the publish-subscribe model [G. Pardo-Castellote and Hamilton, 1999].
ACE - Adaptive Communications Environment
ACE is a widely-used, open-source, object-oriented middleware that implements core concurrency and networking patterns [Schmidt and Huston, 2002] for communications software [Huston et al., 2004].
CORBA
CORBA is an open communications standard for developing portable distributed applications on heterogeneous systems [Henning and Vinoski, 1999], [Bolton, 2002]. TAO (The ACE ORB) based on ACE is open-source and adheres to the RT-CORBA specification [Schmidt and Kuhns, 2000].
Conclusions
Table 1 summarizes the middleware toolkits reviewed. This table shows that while CORBA is the largest consumer of computing resources it also allows for the most flexible, modular, portable, and extensible implementation.
A subjective comparison of Middleware Toolkits: Ranked on a scale of 1 (low) to 5 (high).
A subjective comparison of Middleware Toolkits: Ranked on a scale of 1 (low) to 5 (high).
Over the last 20 years, robotics has swung from philosophically grounded deliberative AI to reactive control, before settling on pragmatic hybrid architectures. This return to pragmatism, captured by Gowdy [Gow00b], resonates with DRDC's long experience with UGVs. Gowdy divides robot architectures into either reference or emergent architecture philosophies. Reference architectures establish idealized guidelines for component design and data flow. Emergent design advocates software frameworks that allow architectures to emerge and evolve.
As with middleware, DRDC evaluated a number of robot-specific middleware systems [Broten et al, 2004] specifically seeking frameworks meeting the basic criteria above and compatibility with an emergent design philosophy. Specifically: Player [Gerkey et al., 2003], DRCS [Albus, 1997], NASREM [Albus et al., 1987], TCA [Simmons, 1994], Dervish [Powers and Birchfield, 1995], CLARAty[Nes, 2003], RAP [Firby, 1989], Xavier [Koenig et al., 1998], Saphira [Konolige and Myers, 1998], 3T [Bonasso et al., 1997], Berra [Oreback and Christensen, 2000], Marie [Cote et al., 2004], Carmen [Roy and Thrun, 2003], OCP [Wills et al., 2001], MIRO [Utz et al., 2002] and Orca [Brooks et al., 2005]. The criteria quickly separated the potential candidates: Player/Stage, Carmen, Marie, MIRO and Orca; from the closed source (such as CLARAty, OCP and Saphira) and reference design (DRCS and NASREM) candidates. Each of the potential candidates are described below.
Player
Player/Stage/Gazebo is the de facto standard for academic mobile robot control and 2 or 3D robot simulation [Vaughan et al., 2003], but as a monolithic device server, lacks the robustness, extensibility, and network capability of the others.
MARIE
MARIE (Mobile and Autonomous Robotics Integration Environment) attempts to create an integrated and coherent framework to facilitate application reuse through tools and programming environments. Unfortunately, Marie's adoption is very limited.
CARMEN
CARMEN (The Carnegie Mellon Navigation Toolkit) is an open source collection of robot control software designed to provide a consistent interface and a basic set. of primitives for robotics research on a wide variety of commercial robot platforms [Roy et al 2003]. CARMEN is a complex toolkit with very limited application to largely indoor vehicles.
Orca
Orca is an open-source framework for component-based robotic systems with roots in the OROCOS KTH project, mandated to build communications patterns for distributed objects. Orca provides the means for defining, developing and assembling the building-blocks that form arbitrarily complex robotic systems, from single vehicles to distributed sensor networks. Though immature and incomplete in many respects, Orca provides a simple interface to TAO.
MIRO
Like Orca, MIRO (MIddleware for RObots) is a distributed, object-oriented framework for mobile robot control. MIRO reduces software development times and costs by providing data structures, functions, communications protocols and synchronization mechanisms specific to robots. Used predominantly by the Univ. of Ulm for soccer robots, MIRO provides a powerful but complex TAO toolset.
Conclusions
Five frameworks were examined for their ability to implement autonomy on DRDC vehicles, as summarized in Table 2. The investigation concluded that CORBA-based middleware offered the most modularity, extensibility, flexibility and scalability. Of the two reviewed frameworks based upon CORBA, only one is sufficiently mature and in current use. Thus MIRO, originally designed for soccer playing robots, proved to possess the flexibility and expandability sufficient for DRDC's unmanned vehicle program.
A subjective comparisons between candidate frameworks ranked on a scale of 1 (low) to 3 (high).
A subjective comparisons between candidate frameworks ranked on a scale of 1 (low) to 3 (high).
DRDC adapted and extended MIRO to support the Kyoker Industries Raptor, an Ackerman steered, hydrostatic, all wheel drive utility vehicle. XJ Designs modified the vehicle, shown in Figure 2, such that throttle, brakes, steering, and other parameters could be monitored and controlled through a single software interface. DRDC added sensors for outdoor, autonomous operations including: forward and backward nodding SICK lasers, forward stereo cameras, differential GPS, inertial measurement unit, wheel encoders, wireless routers and computers.

The Raptor UGV
While many of Univ. of Ulm's MIRO-based Robocup components were inappropriate for DRDC's Raptors, MIRO can easily address the more complex problems of outdoor multivehicle autonomy with uncertain communications.
MIRO natively supports some sensors applicable to outdoor UGVs such as the odometry and RangeSensor interfaces. DRDC extended the original SICK laser driver to support a nodding SICK laser generating 3D data over TCP/IP. New drivers were developed to support a Novatel GPS, a Microstrain IMU, a stereo camera (Digiclops), and the Raptor vehicle command set. Each driver published to a device neutral data interface, a CORBA object. Interestingly, a Player device driver thread could be easily ported to a MIRO Device Server, often resulting in superior performance.
Components
Other than a basic DAMN-like structure, DRDC did not prescribe architecture details at the outset, instead allowing the final architecture to emerge and evolve based on sensing and control requirements. Depicted in Figure 3, the resulting services fall into 7 sub-domains:
Sensing: Laser ranging, Stereo camera, IMU, GPS and odometry. World Representation: Vehicle Pose; Terrain and Traversibility maps. Global Goal Management (not shown). User Interface (not shown). Navigation: Pure Pursuit waypoint following, D*-lite Path Planning, Obstacle Avoidance and Hazard Detection. Arbitration: Vote based Selection of steering arc and speed. Low level Vehicle Command and Control.

Raptor Architecture Flow Diagram
Together these services formed four parallel “threads” of control: hazard detection, obstacle avoidance, path planning, and waypoint following.
Table 3 summarizes the implementation effort, estimated through simple source code line count, for this project. Adapting MIRO to support a UGV application required roughly 20,000 lines of new code implemented through 6 to 8 man years of effort. At project start in the Summer 2004, none of the staff were familiar with MIRO or CORBA. By Summer 2005, the staff were conversant in most aspects of MIRO operations after a steep but manageable learning curve.
DRDC's estimated effort to adapt MIRO
DRDC's estimated effort to adapt MIRO
In fall 2005, the Raptor vehicle performed field trials designed to reveal the system's strengths and weaknesses travelling through obstacle fields and over unimproved grassland prairie. This assessment falls into three categories: hardware assessment, software utility, and algorithmic suitability.
Hardware Assessment
For the moderate grassland prairie environment, the Raptor's sensing proved adequate for low speed maneuvers. The nodding laser and stereo imagery provided sufficient detail for traversing the selected environment at 5–10 km/h. With excellent range, field of view, and resolution, the nodding laser played a crucial role in the system.
Software Utility
Though complex, the ACE/TAO/MIRO toolchain greatly simplified software development. The mature publish/subscribe architecture, arbitrary data logging and playback, and IDL interface discipline, proved pivotal in the system's rapid evolution. With experience, developers could quickly develop and test new modules, often in parallel with earlier versions. MIRO effectively hides much of TAO's internal complexity, though the remaining learning curve is steep. MIRO's publish/subscribe architecture permits multiple processes to opportunistically draw on output data streams. Subscribers can be created or destroyed with little consequence to the publisher and can reside anywhere on the network. Through MIRO's event system, a single developer could quickly log arbitrary CORBA object events in the field, such as device or module output, for instant playback in the lab.
Algorithm Suitability
DRDC implemented a wrappable, variance weighted terrain map on the Raptor UGV under MIRO. Taking Pose, Laser, and Stereo events, the Terrain Map service inserted range data into 0.2times0.2 grid elements within a 20times20m patch centered on the vehicle bumper.
A Traversability Service translated the terrain map into a 20×20m traversability map with 1×1m grid. Proving sufficient for low speed maneuvers over Suffield's grassland environment, the traversability service's sensitivity to pose error effects reduced the map's range to 15m. A resulting traversibility map is shown in Fig. 4.

A Traversibilty Map overlaid with 25 candidate arcs. Obstacles: Blue, Traversable: Red
DRDC's Arbitration services combined discrete behaviour modules in a reactive arbitration system to create autonomous behaviour. The pure pursuit controller performed without fault, even using unfiltered low resolution GPS modes. In obstacle avoidance, the system performed reasonably well. However, with only a bumper-forward terrain map, obstacles disappeared as they fell behind the vehicle bumper. Passing within 20cm of an obstacle on the inside of an avoidance turn, the vehicle could collide with obstacles, now off the map, on the return to the path.
Due to computing power limitations the field of robotics has traditionally favored light weight implementations, such as IPC/IPT, over heavy weight, computationally demanding implementations such as CORBA. Performance tests, conducted on the Raptor, revealed that this processing power axiom no longer applies. Table 4 shows percentage of the CPU consumed by the top 5 Raptor processes.
Percent CPU and Percent Memory consumed by top 5 Processes.
Percent CPU and Percent Memory consumed by top 5 Processes.
Processes 1, 3, 4 and 5 run on a quad Intel Xeon@3.0 GHz with 2GB of RAM while process 2 runs on a Pentium
DRDC encountered one pressing problem with the TAO software underlying MIRO. When software component A published events to consumers B and C, if either B or C's execution interval exceeds A's event period, the event delivery mechanism would hang. With no new events available the vehicle would continue on its last commanded velocity without obstacle avoidance or navigation services. The addition of a watchdog process partially allieviated this problem by monitoring the delivery of events in the system and taking corrective action if required.
Conclusions
DRDC required a modular, extensible, flexible and scalable framework to support its unmanned vehicle program. The research and development at DRDC occurs over long time horizons, and this framework must support diverse platforms types in ground, air and marine variations and the activities of numerous labs in their specialized fields of expertise. The framework also must allow the appropriate architecture to emerge from the specific system requirement. Researchers at DRDC-Suffield conducted an in-depth review of middleware toolkits and architectures and concluded the MIRO framework satisfied DRDC's research and development requirements. MIRO uses the capabilities of CORBA to create a framework which implements the set of components where each component has a clearly defined interface that allows it to share data and methods with other components. While the MIRO framework was originally developed for soccer playing robots, its modular, flexible, scalable and extensible design allowed it to be easily and quickly extended. DRDC has extended MIRO to serve the needs of outdoor UGVs. This involved implementing components that encapsulated the specific functionality required by the target UGV and integrating these new components into the existing MIRO structure. DRDC's experiences with MIRO and CORBA has led the DRDC research group to conclude that this framework and middleware pair implements infrastructure services that will meet both our current and future research needs.
