[Euron] Open RObot COntrol Software: IST project proposal

[Herman Bruyninckx]

As the responsible for the open source software interest group within
EURON, I am preparing a proposal for the 15th January deadline of the
IST Programme of the EU's Fifth Framework. I attach the drafts of the
two main proposal documents that are needed for such a proposal.

I based myself on the EU website that supports open source initiatives
within this IST Framework:
 <http://www.cordis.lu/ist/ka4/tesss/impl_free.htm>

The deadline is rapidly approaching, so I'm looking for motivated and
capable partners. The objectives of the project have to be to develop
the basis of a software system, in order to have a workable result on
which others will want to build. The goal of the EU is to sponsor the
difficult start-up phase. This fits exactly on the current status of
open robot control software :-)

According to information that the EU responsible gave me, a target
project size of about 5 man years for two years would be okay. That
means that I have to get a consortium of 3-5 partners. (I would prefer
3.) Partners need to have both much experience in robotics and much
understanding of how open source software works.

Who is willing to join this OROCOS project? Please react quickly!
Even if you don't want to be a partner, every constructive feedback on
the proposal is useful.

Best regards,

Herman

-- 
Herman.Bruyninckx at mech.kuleuven.ac.be
We hire Linux programmer: <http://www.mech.kuleuven.ac.be/~bruyninc/jobs>
-------------- next part --------------
B1. Title page

Open Robot Control Software
OROCOS

B2. Content list

B3. Objectives

The technological objectives are:
- to produce a functional basis for general robot control software,
- which is released under an open source software license, i.c., the GPL
  (GNU Public License).
- which is computer platform independent (i.e., runs on most hardware, or
  is portable to any appropriate hardware with modest effort).
- which is robot independent (i.e., has software modules that can be
  adapted (with modest effort) for all known robot hardware, manipulators
  as well as mobile robots).
- which is modular and distributable (e.g., using the CORBA standard for
  distributed components).
- which obeys international standards.
- which integrates with, and reuses the open source software code of,
  relevant complementary projects (e.g., for 3D visualisation, numerical
  methods, networking, etc.).

The current situation in robotics is very similar to the proprietary
software industry: non-existing interoperability between different
systems; proprietary languages; lack of software standards; each
manufacturing has its own small scope.  Because none of the current major
players in the robot industry has the incentive to change the
non-interoperability problem, the first initiative in this direction has to
come from the users; open source software is very effective in this
respect, as proven by the exponential growth of the internet, thanks to the
availability of open data standards, and open source software to support
these standards. The OROCOS project wants to create a similar boost in the
area of robot control software.

A second reason behind the OROCOS project is the persistent lack of
innovative features in existing proprietary robot control software: none of
these proprietary controllers offers the users the possibility to, for
example, integrate advanced force control algorithms or high-speed visual
tracking into the servo control loops of their robots; none of these offers
the possibility to integrate planning, logging or monitoring software in
the real-time control level; none of them allows users to change, for
example, the position control into a current control in order to make
joint torque control possible; none of them allows to add user-specific
programs unless the proprietary, non-standard robot language of the
particular robot vendor is used (and these languages are without exception
too simplistic for the job); etc.  These are just some of the many reasons
why innovative research from (mostly) academic institutes takes so long
before it is offered to interested end-users.

Hence, the innovative contents of the project are obvious: to design and
implement (the basis of) an ``Open'' robot control software. ``Open'' means
that users can not only interface the software on any level they desire
(without being limited by the modest high-level functionality that
commercial robot controllers offer today), but also adapt or extend each of
these software control levels when needed.

As soon as the OROCOS project provides the basic functionality of such an
open robot controller, research institutes will require much less
time and efforts to try out and compare new research results, to make
them available to interested third parties, or to create spin-off companies
commercialising their know-how. Indeed, an open source software
approach allows for much faster innovation and continuous improvement of
quality and functionality, because of the much larger group of competent
peers that can contribute to the software, and the more detailed
suggestions and feedback that users of the software can generate.

Application areas of particular importance for OROCOS are the many
user-oriented research and interest groups (programming by human
demonstration; safe interaction control between humans and robots;
internet-based, remotely monitored and programmed service robots that can
help elderly and disabled people; etc) that participate in the EURON
(EUropean RObotics Network) Network of Excellence, and whose results
are currently impossible to implement on commercial robot systems.

The software engineering approach behind the project combines the
example of existing and successful open source projects with the extensive
experience of the project partners: 
- the robot control software is decomposed into
  components (object-oriented ``software agents,'' or ``holons'').
- the interface of these components can be described by specialists in the
  area, such that small groups of developers can work relatively
  independently on each of the components.
- building a working robot control system then consists of `shopping' from
  the list of available components, and glueing them together with, for
  example, standardized CORBA.

Many open source projects typically have a two-phase life cycle:
- the first developments are evaluated and tested in a critical and
  open-minded world. This world consists of academic labs and 
  innovative-minded early adopters, who are not afraid to re-think and
  re-design the code base, if experience suggests these changes are
  worthwhile. This phase usually results in a workable code base, proving
  the viability of the project, without much emphasis on completeness or
  advanced user-friendeliness.
- as soon as the project has reached the end of this first phase, and
  solves the targeted problem(s), industrial parties get involved in the
  polishing of the code base, in extending the range of target systems,
  in building market-proof products, and in providing a service
  infrastructure for these products.
The OROCOS projects aims at realising the first phase: design and implement
a working code base, without much emphasis on sleek interfaces or
particular robot systems.

The project partners all have long-standing experience in advanced robotics
research, such that the concrete sub-goals of the project, as described in
the Workplan, will already be reasonably concrete and complete. Indeed,
fifty years of experience in robotics have resulted in lots of so-called
``software patterns,'' i.e., traditional ways of solving problems that are
(implicitly) recognised and applied by experienced engineers in the field.
However, many of these software patterns have not been made explicit yet.
So, roughly speaking, each of the project's Work Packages will specify and
implement these software patterns: sensing, planning, modelling, control,
task specification, ...

The project's `first-phase' results will be available for `second
phase' commercialisation, in the same way as, for example, the open source
software of the Linux operating system of the Apache web server are
available for commercial use. Nothing prevents a close cooperation between
academia and industry, because both of them will benefit, in the long run,
from reducing robot control software to a `commodity' product. The most
succesful business model in open source software is service: service in
packaging, distributing and installing the software; service in helping
client solve their problems using the software; or service in extending the
code base of the project in directions that are of particular interest for
the clients. 

From an organisational point of view, the OROCOS project is a spin-off from
the recently started EURON network (EUropean RObotics Network), and its
Interest Group on open source software in particular. This facilitates
cooperation, through the use of an already existing communication
and contacts infrastructure. It also guarantees that the design phase of
the project can tap a source of know-how, experience and application scope
that is unmatched by any proprietary commercial vendor.

The technical set-up of the OROCOS project is already firmly established,
even before the start of the project:
- on the hardware side, it consists of the many research robotic systems
  that are already available in the partners' labs: force-controlled robots
  at K.U.Leuven, mobile robots and manipulators at ...,
  service robots at ...
- on the software side, the open source software community has already
  developed very mature co-operation and development tools and practices:
  mailinglist software (Mailman, Majordomo, ...), CVS code repositories,
  bug tracking tools (BugZilla, Gnats, ...), documentation tools (LaTeX,
  DocBook, Doc++, ...), software distribution tools and channels (the rpm
  and deb package management systems; the sourceforge.net, rpmfind.net and
  freshmeat.net portals), etc.
- on the management side, open source software projects have proven to be
  manageable in a distributed way, using the Internet as major
  communication and synchronisation means.



B4. Contribution to programme/key action objectives

The OROCOS project fits nicely into the IST framework for the following
reasons:
- the private individual will profit (in the medium to long term) from the
  availability of high quality software with a very wide scope; not only as
  `user' (e.g., profiting from the reduced costs and increased
  functionality of service and other robots), but also as potential
  entrepeneur (see next point).
- European SME enterprises will profit (in the short to medium term)
  because the step to start up a small service company in robotics
  decreases drastically from what it is now (in a world dominated by
  a few large proprietary players). This same evolution has already been
  proven possible in the area of internet and server services.
- although the results of an open source software project are available to
  users and competitors worldwide, experience has shown that the group of
  initiative takers of a project profits most from commercialisation
  of the results: clients prefer to hire their services in the first
  place, because their track record and capabilities are clear from the
  source code. Hence, it is a competitive advantage that an initiative such
  as OROCOS be born and maintained in Europe.


B5. Membership

Co-ordinator:
  K.U.Leuven, Department of Mechanical Engineering
Partners:
  ...
  ...



B6. Workplan

a) Introduction
The rationale behind the Workplan presented below is twofold:
1. The technological content (innovative as well as well-established),
   comes from the project partners with a long experience in the field,
   and from any qualified `outsider' that follows the development of the
   project via the communication channels that are always available
   in any open source project. The openness of the project is the best
   guarantee for both its quality and the relevance of its functionality.
2. The software engineering and organisation approach is the one applied
   in most open source software projects.  Indeed, because the OROCOS
   project is `just' one of so many open source software projects, it will
   use the organisational pattern that has proven successful many times
   before: 
   - a website (www.orocos.org) that contains the classical items:
     overview, code repository (CVS), mailinglist + archives, bug tracking
     server, documentation and FAQ (Frequently Asked Questions).
   - a maintainer for each of the independent sub-modules, and an
     `enlightened dictator' (the project co-ordinator and other members of
     the `core team') who decides about (i) which code is accepted into the
     released code, and (ii) the vision of the project.
   - the proven approach of dual version code structure: stable release and
     development release.
   - re-use of existing code from, or interoperability with, other open
     software projects, through documented interfaces.

The core team identifies component modules and specifies their interfaces,
such that the contributors in any component module implementation Work
Package can work very independently from other modules. (This has proven to
be the primary reason behind the efficiency of cooperation of very large
groups of contributors, as it gives a solution to the ``Mythical Man
Month' problem already identified thirty years ago by Brooks.) This
methodology also leads to a natural three-level interdependency structure
of the project:
 1. core component and interoperability identification.
 2. design and implementation of components.
 3. documentation.
The classical decomposition of a large software project (functional
specification, architectural design, development), is much less outspoken,
or even appropriate, in a typical open source software project: although
the existence of a clear and speficied view on the project can increase the
efficiency of the code development, it is not a necessary condition,
because of the `organic' growth of ideas and functionality, in all open
source software projects, in combination with a high level of adaptability
through feedback.

An important remark must be made at this point: open source software
projects are, by definition, not completely manageable with a traditional
work plan approach: the code contributions, criticism, functionality
desiderata,... of people outside of the formal OROCOS project structure
will be very influential in the actual evolution of the project, and this
will often take place beyond the control of the project management. It is
not unlikely that the emphasis of the project starts to deviate from what
is specified in this proposal, for the sole reason that user interests
happen to be different from what this proposal predicts. This adaptation
is, by definition, in line with the spirit of the IST programme, which
emphasizes the central place of the users.



b) Action plan and time table
to be filled in


c) Interdependency of components
The interdependency follows the structure outlined in part a):
 1. core component and interoperability identification.
 2. design and implementation of components.
 3. documentation.
The `Component brokers' and `User interface' Work Packages in point 2
depend on the other components in point 2, and can hence start only after
the first Deliverables of these other components.


d) Work Packages

Work Package 0: Management
One of the advantages of open source projects is at the same time one the
largest paradoxes for those who are not familiar with how open source
projects work: they manage themselves! That means: the openness of the
project allows for continuous `peer review', not only by all project
partners but also by all qualified outsiders that are interested in the
project. This peer review, in combination with the fast communication
infrastructure offered by an open project's mailinglist, provides
a level of progress assessment, feedback and ideas that cannot be matched
by traditional `closed' projects. Moreover, open source software projects
have since long all necessary infrastructure and experience to make
face-to-face meetings in persons the exception rather than the rule.
Therefore, the OROCOS project's management Work Package is limited to
organising the financial matters and the coordinating the production of the
Deliverables.



Work Package 1: Core component identification
Objectives.
To define the design goals of the project, to specify the interfaces of the
software components, and to develop the architecture. 


Description of work.
As in any open source software project, this task is never finished,
because all these goals are constantly evaluated, and, whenever necessary,
adapted to the current evolution of both the code and the insights into the
problem.  This Work Package is light in the number of man months (basically
only the small core team will produce some `work' in this Package), but
very important for both the innovative and software engineering results.
Experience has proven that the quality of this core module is proportional
to the intensity of discussion on the project mailing list; in turn, this
intensity depends on (i) the number of people that get interested in the
project, and (ii) the responsiveness of the project maintainer(s) to
suggestions of all contributors. 


Deliverables.
Month  3 (D1.1): Skeleton of OROCOS functionality and architecture.
Month 12 (D1.2): Revised and detailed skeleton.
Month 24 (D1.3): Complete documentation about OROCOS (in the form of
                 a journal paper submission).

Milestones.
Month  3 (M1.1): Decision about OROCOS functionality and architecture.



Work Package 2.0: Interoperability 
Objectives.
To follow-up on other open source software projects, in order to detect
which of their functionalities are directly relevant for OROCOS, and how to
make these projects fully interoperable. 


Description of work.
Examples of projects to be examined are: 3D visualisation (OpenGL),
numerical library (www.Octave.org), modelling of dynamical and mechanical
systems (www.Modelica.org), real-time operating software (www.rtlinux.org,
www.rtai.org, sourceware.cygnus.com/ecos, www.uclinux.org), CNC control
(Enhanced Motion Control, http://www.isd.cme.nist.gov/projects/emc/),
real-time device drivers (Comedi, http://stm.lbl.gov/comedi/), XML
configuration and specification of robot tasks (DocBook,
www.oasis-open.org/docbook), diagram editing for task programming or
controller and kinematics modelling (Dia,
http://www.lysator.liu.se/~alla/dia/dia.html), etc.

The expected work load in this Work Package is light, because open source
software developers do this job automatically all the time already. 
No tangible results are to be expected from this activity, because its goal
is not to create results, but to avoid duplication of efforts.

Deliverables.
No Deliverables are attached to this Work Package: it is only defined in
order to make it very clear that OROCOS wants to re-use as many good ideas
and code from other open source software projects as possible.

Milestones.
None.



Work Package 2.1: Real-time servo control

Objectives.
This Work Package detects, classifies, designs and implements the software
patterns needed in the hard real-time kernel of a robot controller.

Description of work.
Robots require a (relatively small) kernel of functionality that runs in
hard real time, e.g., an inner servo control loop with a sample frequency
of 1 kHz. This kernel is responsible for the accurate timing of several
high-priority threads: encoder interfacing, sensor interfacing, advanced
model-based control loops, trajectory generation, etc.
This Work Package detects, classifies, designs and implements the software
patterns that have surfaced during the last couple of decades:
- trapezoidal velocity and acceleration profiles, parabolic acceleration,
  S-curve trajectory, ... for single axis trajectory generation.
- acceleration and velocity resolved position control of multi
  degree-of-freedom robots, with or without dynamic models in the loop.
- Finite State Machines for servo controllers (IDLE, READY, RUNNING,
  SOFT-INTERRUPTED, HARD-INTERRUPTED, BLENDING, ...).
- hybrid, impedance and interaction control.

The major technological innovation of this Work Package is the software
engineering aspect: to build a modelling framework that is an appropriate
trade-off between generality and efficiency, and that, at the same time, is
sufficiently generic in order to be applicable to small scale applications
(e.g., a computer controlled milling machine, or an automated wheel chair),
as well as to large scale applications (e.g., a team of humanoid robots
participating in the RobotCup soccer contest). 

Deliverables.
Month  6 (D2.1.1): Design of hard real-time kernel for OROCOS.
Month 24 (D2.1.2): Complete documentation about hard real-time kernel (in
                   the form of a journal paper submission).

Milestones.
Month  6 (M2.1.1): Decision about hard real-time kernel for OROCOS.



Work Package 2.2: Sensor device drivers

Objectives.
To design generic `templates' for robot sensor device drivers, and to
implement drivers for the most commonly used sensors.


Description of the work.
Every robot system must interface to multiple sensors: encoders, tachos,
force sensor, sonar arrays, camera, etc.  The activity in this Work
Package is inspired on, and facilitated by, existing large scale device
driver projects for the Linux operating system, such as, for example, the
PCMCIA project; the added value of these projects is that they build one
general framework in which the marginal costs of adding a new device driver
is minor, in contrast to the classical commercial approach where each
vendor makes its own device driver from scratch, and independently from all
thos other drivers which might have very similar needs and structure. For
robotics purposes, the real-time device driver project Comedi
(http://stm.lbl.gov/comedi/) is the natural starting point. 

Deliverables.
Month  6 (D2.2.1): Specification about device driver framework.
Month 24 (D2.2.2): Implementation for most common sensors.


Milestones.
Month  6 (M2.2): Decision about device driver framework.



Work Package 2.3: Sensor processing libraries

Objectives.
To design and implement libraries with advanced sensor processing
functionality for the most commonly used sensors.

Description of work.
The innovation of most academic research institutes lies in the development
of advanced sensor processing algorithms. Some of them have already got
open source software support (e.g., the vision libraries of
www.TargetJt.org, or neural network library of ...), but others lack such
unifying basis: Bayesian estimation (Kalman Filter, Markov Localization, EM
algorithms), human demonstration, active sensing, dynamic and kinematic
identification and calibration, etc. In these areas, libraries with the
basic required functionality will be implemented.

Deliverables.
Month  6 (D2.3.1): Specification of library functionalities.
Month 24 (D2.3.2): Implementation of library functionalities.

Milestones.
Month  6 (M2.3): Decision about library functionalities.


Work Package 2.4: Robot kinematics and dynamics

Objectives.
To design and implement libraries for robot kinematics and dynamics.

Description of the work.
Robots are, in the first place, devices that move. Hence, a general and
advanced library for kinematics and dynamics is needed. This Work Package
first formalizes the `software patterns' in this area (serial chain
kinematics and dynamics, closed chain kinematics and dynamics, Jacobian
matrices, singularities, redundancy resolution, dynamic simulation, etc.),
and then implements the appropriate classes of objects and their methods.


Deliverables.
Month  6 (D2.4.1): Specification of library functionalities.
Month 24 (D2.4.2): Implementation of library functionalities.

Milestones.
Month  6 (M2.4): Decision about library functionalities.


Work Package 2.5: Task specification

Objectives.
To design and implement libraries for robot task specification.

Description of work.
This Work Package tackles the problem of a `universal' robot programming
language. All existing robot languages have a too narrow focus, and a
proprietary format. OROCOS will design an XML-based component for a
flexible robot programming language; or rather, for a tool to define robot
programming languages. The similarities with XML-based standards in
document formatting (e.g., DocBook, www.oasis-open.org/docbook) are deep,
and hence many of the existing tools and ideas can be re-used in a robotics
context. The idea is that users can define new `tags' in the programming
language, according to the needs of their tasks and the capabilities of
their robot system (including sensors).

Deliverables.
Month  6 (D2.5.1): Specification of library functionalities.
Month 24 (D2.5.2): Implementation of library functionalities.

Milestones.
Month  6 (M2.5): Decision about library functionalities.


Work Package 2.6: Component brokers

Objectives.
To design and implement the component services that are
not yet available in existing CORBA implementations (ORBit, bonobo, ...),
in particular, light-weight, small-scale and real-time brokerage
services are needed.

Description of work.
The OROCOS project has a broad scope, hence its design and
implementation should be very modular: specific robot systems should be
able to use only those components that are really necessary. Hence, a
modularized structure is important, but also the fact that different
components can run on different computers on a network. Therefore, a
component broker is necessary, and the CORBA standard (Common Object
Request Broker Architecture, www.omg.com) is a natural (but not complete!)
reference frame.

Deliverables.
Month  6 (D2.6.1): Specification of broker functionalities.
Month 24 (D2.6.2): Implementation of broker functionalities.

Milestones.
Month  6 (M2.6): Decision about broker functionalities.


Work Package 2.7: User interface

Objectives.
To design a component-based user interface (graphical and non-graphical),
that flexibly adapts to any robotic system that can be controlled by the
software components developed in the other Work Packages.

Description of work.
All existing commercial user interfaces for robots are very inflexible and
targeted to one particular system. A major requirement is the
platform-independence of eventual graphical components. However, this Work
Package is not mainly focussed on the implementation of a GUI, but will
investigate a general software approach to interface robots and humans.
Ongoing research in this area and in the EURON network should be integrated
into this Work Package.

Deliverables.
Month 12 (D2.7.1): Specification of user interface design.
Month 24 (D2.7.2): Implementation of user interface.

Milestones.
Month 12 (M2.7): Decision about user interface design.



Work Package 3: Documentation and advocacy

Objectives.
To write documentation for the OROCOS code, but also for a general robotics
course.

Description of work.
The OROCOS project should not only result in software code, but will also
develop extensive documentation, targeted not only at the software users
but also at students and classroom use. Moreover, dissemination 
and promotion of results are considered to be fundamental for the success
of the project: the more people get interested in OROCOS, the more
`external' contributions can be expected. Because engineering students
all over the world are ideal potential contributors, the development of
didactical material (robotics textbook and educational software) will have
a large leverage effect. 

Deliverables.
Month 24 (D2.8): Complete documentation.

Milestones.
None.

-------------- next part --------------
C1. Title page

Open Robot Control Software
OROCOS

C2. Content list

C3. Community added value and contribution to EC policies
The OROCOS project definitely is too big for any national scale, because of
its very ambitious (long term!) goals and scope. Designing and implementing
such a large software project requires a minimal critical mass of some
dozens of people, as well as the combined vision and experiences from
people with as diverse a robotics background as possible. This
`community' interest has already been created by the EU sponsored EURON
network (EUropean RObotics Network); the OROCOS project will materialize
this interest into a code base, which will be useful for many small but
innovative companies in the EU: many SMEs have the potential to apply
robotics technology, or to contribute to it, but are frightened by the high
threshold for entering this market. 


C4. Contribution to Community social objectives
The OROCOS project will facilitate the development and commercialisation of
ongoing research in many European robotics centers in the area of `service
robots': in contrast to the more traditional usage of robots (in
manufacturing and assembly), service robots are much more diverse (the
service needs of people are very particular and individual) and the
requirements for flexibility in their control and interaction interfaces
are much higher. An open software project is ideally suited for this kind
of applications, because open software projects are, by definition,
user-driven. The evolution that has taken place in the Internet economy
(i.e., small enterprises can make a living by providing services, because
of the cheap availability of high quality Internet software) can be
repeated, on a smaller scale, in the area of service robots, or
`intelligent machines' in general.

Other important side-effects of open software projects are:
- the high personal involvement and responsibility feeling that
  contributors (volunteers as well as professionals) to such projects
  have: they like to work on them, they like to meet new people with
  common interests, and they learn to show respect for other individuals,
  irrespective of social status or diplomas.
- an increased awareness and educational value for students that are
  interested in robotics, because of the unmatched inherent potential for
  self-study offered by open source software projects.


C5. Management
Proper management of an open software project is not too difficult, once
one has understood their `natural social dynamics': 
- every successful project has a natural leadership (one or two key
  people), respected by all contributors to the project; these leaders must
  earn this respect by their deeds, not by their authority. The OROCOS
  project has very good chances of starting with such a natural leadership,
  by choosing a co-ordinator that satisfies the following two criteria:
  (i) he or she comes from one of the established robotics research
  institutes in Europe, and (ii) has a thorough understanding of open
  software.
- contributors are normal mortals, hence they have changing interests;
  that means that people that started to work in one Work Package of the
  project will want to contribute to other Work Packages too. This
  phenomenon should be understood and respected by the management.
  (Whether or not the people involved are paid for their contributions is
  less important than the quality of their contributions!)
- open software projects have a long tradition is being managed through the
  Internet, and all necessary tools to support this co-operation are
  available and widely used.
- open software projects have the best possible quality control: peer 
  review. That is, the openness of the code allows all qualified people
  to evaluate the existing designs, documentation and code, and the
  standard infrastructure of any open software project streamlines the
  integration of such feedback, code patches and suggestions into the
  project.
- conflicts are an almost daily phenomenon in open software projects, but,
  again, they are equally often dealt with successfully  by the traditional
  infrastructure, i.c., the project's mailinglist: any conflict in vision
  or solution is openly discussed, with inputs and reactions from every
  other contributor. Examples where conflicts lead to an unmanageable
  project are very, very scarce, and in most cases they even lead to
  improved design or code.


C6. Consortium


C7. Description of participants


C8. Economic development and scientific and technological prospects