Orca Overview

Note:

Reviewed for release 2.13.0.

Goals and Requirements

We think that software reuse is key for continuing progress in robotic research and industry. Orca is our attempt at doing it. The project's goals are:

• to enable software reuse by defining a set of commonly-used interfaces;
• to simplify software reuse by providing libraries with a high-level convenient API; and
• to encourage software reuse by maintaining a repository of components.

To be successful, we think that a framework with such objectives must be:

• general, flexible and extensible,
• sufficiently robust, high-performance and full-featured for use in commercial applications,
• yet sufficiently simple for experimentation in university research environments.

Licence and Copyright

• Orca software is released under LGPL and GPL licenses
• A special clause in the Ice licence allows us to distribute LGPL libraries linking to Ice.
• Copyright belongs to developers and major contributors. Read more...

Our Approach

A combination of several design choices sets this project apart from other initiatives with similar objectives. Namely, Orca:

• adopts a Component-Based Software Engineering approach without applying any additional architectural constraints
• uses a commercial open-source library for communication and interface definition
• provides tools to simplify component development but makes them strictly optional to maintain full access to the underlying communication engine and services
• uses cross-platform development tools. Read more...

How to Use Orca

We can think of several scenarios which lead to different usage patterns:

• "You like everything we are doing." Then download and install Orca, configure a system out of existing components, write your own components, contribute them back to Orca if you wish.
• "You like Ice and would like to use some of the existing components, but you don't like our build system or something else about the project." You can setup your own build system outside of Orca but use our interface definition files (Slice files with .ice extension). They are key to inter-operability. If you want to add new interfaces or modify existing ones, we'd be happy to work with you.
• "You don't want to use Ice at all but like the idea of "standardization" in the robotics community." Even if your software cannot talk to Orca directly, it may still be useful to have our interfaces and data structures designed so that they are as close to each other as possible. This way it would be easier to write "glue libraries" which translate from one to another. So when writing your interfaces take a look at our interface definition files (Slice files with .ice extension). Of course we'd consider making changes to make our definitions more general or more understandable.

OS support

• full Linux support
• interfaces and most of source code used to compile in QNX; it would not be hard to make it work again.
• interfaces, core libraries and utilities, and some components compile in Windows XP.
• experimental builds in MacOS-X

The basic tools we use are cross-platform, so in principle Orca can be deployed as widely as CMake/Ice combination.

Programming language support

• all components which are currently in the repository are written in C++
• there are examples in Java, Python, and PHP.

Slice interfaces can be compiled to C++, Java, Python, PHP, C#, Visual Basic, Ruby, and Objective C. All of these can be used to implement or use Orca interfaces.

Repository

We recognise that the usefulness of both the framework and any particular component increases with the variety and quality of the available components with which one can interact. We therefore maintain an online repository. Users are encouraged to contribute their own components and to point out omissions in components' documentation.

• currently contains components useful in mobile robotics, e.g. sensor drivers, obstacle avoidance, etc.
• feel free to contribute components or libraries for any subfield of robotics.

Terminology

In addition to standard definitions of components and interfaces, Orca naming conventions also refer to robotic platforms. Read more...

History

Orca grew out of Orocos@KTH project. It has been on SourceForge.net since June 2004. Read more...

Current snapshot and future directions

Source code size gives some idea about the project's activity. The stats above are generated using David A. Wheeler's SLOCCount. This figure also helps illustrate our main objective: writing useful robotics software.

We are certainly not interested in a deep "foundation" (red) -- the infrastructure necessary to allow components to talk to each other. Virtually all communication functionality of Orca comes from Ice (gray). This was the main motivation for switching to Ice which is visible since v.2.0.0-rc1 at the end of 2005.

We are interested in a large "superstructure" -- useful components. But we recognize several types of code here. Utilities (green) are used for visualization, logging, debugging, deployment, etc. These are usually fairly complicated and intimitely tied to the particular framework (Orca). Algorithm and driver implementations (blue) are what robotics is all about and, if done properly, can be independent of a particular framework. The communications-independent Hydro distribution contains this kind of code. The well-documented high-quality generally-useful code moves to Gearbox (light blue), which is intended to be used across multiple projects. Finally, the components themselves (orange) are the modular wrappers for algorithms and drivers, acting as conduits of data between different subsystems.

Our objectives

• keep our infrastructure code (red) to absolute minimum
• stabilize the growth in the utility code (green) after the necessary functionality is achieved
• look for ways to minimize and simplify the component code (orange) by writing wrapper functions for most common use-cases
• increase the size and quality of the algorithm and driver code (blue).
• share the best reusable code with others by moving it to Gearbox (light blue).

For comparison, we show a similar analysis of the Player project. For the purposes of this figure, Player software since v.2.0.2 is classified as follows. Player "infrastructure" includes the contents of {libplayercore, client_libs, libplayertcp} and Player "components" includes the code in {server, utils}. The autogenerated bindings are excluded.