The Orca Way

Note:: Reviewed for release 2.0.0.

In designing Orca the following design choices have been made:

An Unconstrained Component-Based System

The approach we take is frequently called Component-Based Software Engineering (CBSE). CBSE offers developers the opportunity to source existing plug-in software components, rather than building everything from scratch. In addition, CBSE offers significant software engineering benefits by enforcing modular systems, which helps control dependencies, reduce maintenance costs and increase system flexibility and robustness.

For a broad overview of "componentry" look in Wikipedia. For a summary of CBSE and its application to robotics, you may want to read recent papers by Orca developers.

Fundamental to CBSE are:

the concept of interfaces considered to be contractual obligations between components, and
the choice of a mechanism to implement these interfaces. Strict adherence to a set of predefined interfaces imposes severe constraints on the interactions allowed between components. These constraints are necessary to ensure interoperability of the components.

In the design of a framework for reuse it is certainly possible to go beyond the fundamental interface constraints but, because Orca aims to be as broadly applicable as possible, we choose not to do so. In particular, we make no prescriptions or assumptions about:

component granularity,
system architecture,
the set of provided or required interfaces, and
the components' internal architecture.

Why Use Ice?

To implement a distributed component-based system, one must be able to define interfaces and make a choice of communication mechanism. In the case of cross-platform operation involving different operating systems, the software which provides such functionality is typically referred to as middleware. Given the realities of robotic software development we consider support for C/C++ on Linux to be essential. This rules out Microsoft's COM+ and Sun's Enterprise JavaBeans. With this in mind, the following options exist today:

using XML-based technologies such as SOAP,
using CORBA,
writing custom middleware from scratch, or
using Ice.

We discount XML-based technologies on the grounds that they are too slow and inefficient for low-level robotic control tasks. While CORBA is sufficiently flexible for Orca's middleware requirements, it is also large and complex. Experience with CORBA in earlier versions of Orca showed this complexity to be problematic. In comparison, Ice offers a much smaller and more consistent API, superior feature set and similar performance. For a details see Ice vs. Corba comparison or read a paper by ZeroC staff.

Earlier versions of Orca also experimented with writing custom middleware from the ground up. While communicating over a socket is simple, implementing middleware sufficiently flexible and reliable to support Orca's requirements involved re-implementing (and maintaining) large parts of CORBA functionality, which is a non-trivial task. Our conclusion was that it is unrealistic to expect robotics researchers to have the time or skills to develop middleware to the same standards as commercial products.

These arguments led to the decision to choose Ice as the single middleware foundation for our project. The rest of this section briefly describes what Ice is and what features it offers.

Slice is the Specification Language for Ice, analogous to IDL for CORBA. Slice is used to define interfaces -- a contract between clients and servers. Slice specifications are then compiled into various programming languages. Ice supports C++, Java, Python, PHP, C#, and Visual Basic. Ice clients and servers can work together regardless of the programming language in which they are implemented.

The Ice core library manages all the communication tasks using a protocol which includes optional compression and support for both TCP and UDP. Ice optionally provides a flexible thread pool for multi-threaded servers.

Ice builds natively under various operating systems including Linux, Windows, and MacOS~X. A Figure above shows an example of two Orca components written in different languages and running on two different operating systems.

Optional Tools

Ease of use is certainly one of the main factors contributing to popularity of a particular software tool. We consider the Player API to be the gold standard of simplicity, particularly on the client side. In our experience, using the Ice API directly falls somewhere in between the simplicity of a custom robotic-specific middleware like Player and the complexity of CORBA.

To lower the entry barrier for developers, Orca provides a library called libOrcaIce which is intended to provide a simplified API sufficient for the majority of usage patterns encountered in the development of robotics components. It is important to emphasize that the use of libOrcaIce and all other Orca utilities is strictly optional, and it is possible to write new components and communicate with the existing ones without using any of the supplied tools.

Even if a component is written with the help of libOrcaIce, it is still possible to use the full range of Ice functionality. This fact is shown graphically in the Figure above, where Component 1 has access to both libOrcaIce and the underlying libIce for C++.

While we avoid enforcing particular design patterns for either systems or components, we do provide guidelines (and working code!) for designs that have worked well in the past. One useful feature of libOrcaIce is the transparent integration of component code into a stand-alone application and an IceBox service.

Cross-platform Tools

Orca was designed with the intention of being used on various platforms. To this end, we use CMake (cross-platform make) for its build system. Ice has language mappings to many languages and builds natively under several operating systems. The majority of components in the Orca repository use the Linux/C++ combination. The core of the project compiles on Windows and there is currently a simple example in Java. For GUI development we use TrollTech's Qt -- a multi-platform C++/Java GUI framework.