Report on the Open Source Robotics Workshop

Euron Annual Meeting, Warsaw, February 17th 2005

Organizer and reporter: Herman Bruyninckx, K.U.Leuven.

The goals of the workshop were (i) to present an overview of existing open source projects (goals, target public, status, expectations), and (ii) to discuss possible and necessary (common) activities in the future.

The overview part of the workshop drew about 30 participants; the discussion part after the break drew about 20 (mostly active) participants.

1. Overview

The following projects were presented by their own developers: Orocos (Herman Bruyninckx), Mrocc++ (Cezary Zielinski), and Miro (Gerhard Kraetzschmar). Herman Bruyninckx briefly presented the other projects: Player/Stage, OROCOS::SmartSoft(*), Orca(*), the Laas projects(*), Marie, CAS Toolbox, RobotCub. (The projects marked with a "*" prepared a brief presentation themselves.)

2. Discussion

The discussion session was started by finding out from the participants which topics they were most interested in. In decreasing order of "importance" this were:

1. Why use open source?,
2. How could/should a "user" select an open source project?,
3. What are the differences between the various "middleware projects" (Miro, OROCOS::SmartSoft, Orca, Marie)?,
4. What about standardization?,
5. How should we act with respect to commercial robotics systems?

The following paragraphs summarize the discussions of these five topics. But first we describe some "action points" that were identified (and agreed upon) in the course of the workshop:

• the open source projects could do much better in information dissemination: a "20-page" introduction for "new users", some standard information items (features, existing applications, comparison and complementarity to other projects).
• the Open Source Robotics interest group should have a web page in www.euron.org, with a summary of all the relevant projects. If possible, it should also have its own mailinglist, where meta-information about all projects could be given, and the discussion about the topics mentioned below could be held.

2.1 Why use open source?

Three major criteria were identified:

• price (of licensing, not of development or customization).
• quality (as long as the project has enough critical mass to have many people look at the same parts of the code).
• survivability (the ability to adapt your code, even if the original "provider" disappears, or if you want to enhance/port/modularize/... the existing software).

For a company, open source can be attractive if it provides a large amount of the necessary infrastructure that the company would have to develop or pay for anyway. The license should allow the company to add its own specific added value to that infrastructure. However, besides the open source aspect, the aspect of using open standards for interoperability is even more important.

2.2 How could/should a "user" select an open source project?

The following relevant selection criteria were identified, (more or less ordered according to importance):

• available features (how well does the project support my current needs?).
• available applications (can I play with an end-user porogram or do I have to construct/configure/compile my own application first?).
• available documentation (_not_ user or reference manual, but a simple "starterkit for newbies").
• availability for the user's hardware and software platform.
• number of developers and users (the more of them, the more chances that the project will prosper).
• vision and code quality.

2.3 What are the differences between the various "middleware projects"?

Since only one representative of one of the middleware projects was present (Gerhard Kraetzschmar, Miro) this topic could not be thoroughly discussed. One clear difference is that Miro and Orca use the TAO/ACE project to build upon.

2.4 What about standardization?

About everybody thinks standardization is needed, but it is not at all clear what and how to standardize! The participants mostly agreed that standardization can only succeed if a critical mass of the projects accepts the standards. No real consensus or roadmap was reached, except maybe the following two complementary and short-term standardization opportunities:

1. device interfaces (i.e., the common access to the most common hardware robotic systems);
2. "low-level" domain objects, such as geometry and motion.

The higher one goes in the "intelligence" dimension, the more difficult it becomes to standardize. So, a common, provider-independent "wrapper" around commercial robots (manipulators as well as mobile platforms) could be feasible. The suggestion was raised to submit a proposal with Euron in order to generate concrete standardization drafts.

2.5 How should we act with respect to commercial systems?

The common wrapper mentioned above is one possible reaction; it would make the brand of robot irrelevant to our applications, and hence puts some modest form of pressure on the commercial providers. A second observation is that ethernet has a high chance of becoming the most important de facto "field bus" (it _is_ already in the mobile robot world), which would (potentially) reduce the effort to make open source projects compatible to commercial systems. The problem of open specifications of the protocols used on the field bus remains, of course.