orca-robotics
INTRODUCTION
Overview
Download and Install
Quick Start
Documentation
Publications
REPOSITORY
Interfaces
Components
Libraries
Utilities
Software Map
DEVELOPER
Tutorials
Examples
Dev Guide
Dashboard
Wiki
login/pass: orca/orca
PEOPLE
Contributors
Users
Project
Download
Mailing lists
Orca Overview
- Note:
- Reviewed for release 2.7.0.
- Goals and Requirements
- 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
- 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
- "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 compile in QNX.
- 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, and Ruby. All of these can be used to implement or use Orca interfaces.
- Repository
- 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
- History
- 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. A recently launched Hydro distribution contains this kind of code. 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).
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.
