Roadmap to Orocos 1.0

Hi,

We had recently some off-list discussions about Orocos 1.0. The key question 
was: how much does Orocos need to be changed for - and which parts of Orocos 
will be in - the 1.0 release.  We believe we came to a realistic conclusion. 
It's first appropriate to explain how the 'Orocos Project' will be 
partitioned. There are top->down 3 layers : "Applications", "Components" and 
"Libraries". 

  O ----------------------------------------------
  R                 Applications
  O ----------------------------------------------
  C               Components
  O ----------------------------------------------
  S         Libraries (RTT/BFL/KDL/...)
---------------------------------------------------
              Operating System
---------------------------------------------------

The lowest level will exist out of 3 independent libraries:
The "Real-Time Toolkit", the "Bayesian Filtering Library" and the "Kinematics 
and Dynamics Library"

 Real-Time Toolkit (RTT)
This is a set of C++ classes which allows a developer to build
Orocos components (see later on). It provides the OS abstraction, low-level 
device drivers and device interfaces, and the 'task infrastructure' to build
components.  It also encapsulates any distribution (CORBA) specific code
required to distribute components. This is what we are now calling the 
'Real-Time Control Services' on our website. Beginning Orocos users will not 
be working immediately with this toolkit.

 Bayesian Filtering Library (BFL)
This C++ library can be used independent of Orocos today but will get a more 
prominent place on the Orocos webpage. It will be used by Orocos Components
which (actively) do intelligent sensor processing. Current BFL users will 
still be able to use this library as before.

 Kinematics and Dynamics Library (KDL)
This C++ library is today integrated within Orocos as the 'geometry' and 
'kindyn' packages. It will be split off as an independent library for 
kinematics usable by developers who do not wish to use the Real-Time Toolkit. 
Credits go to Erwin Aertbelien who developed a major part of this library, 
and new candidates are ready to take over the job.

 Control Components
The layer above these three libraries is taken by the Orocos "Control 
Component". A distributable entity which has a control oriented interface.
A single component may be well capable of controlling a whole machine,
or is just a 'small' part in a whole network of components, for example an 
interpolator or kinematic component. The components are built with the
"Real-Time Toolkit" and optionally make use of the BFL or KDL or any other 
library (like a vision toolkit). Most users will interface components through
their (XML) properties or command/method interface in order to configure their
applications. The current Orocos 'Control Kernel' components need to be 
converted in order to fit in this description and are to be split off in 
separate packages. The 'correct' interface is that of the 'TaskContext' class
as will be released in 0.22.0 and described in the "Component Builders Guide".

 Application Templates
The layer above the Control Components is formed by the "Application 
Templates". These are the kick-start 'Component tapers' which do nothing more
than selecting and connecting a few components which work well together in 
order to realise a running application. An application template should be so
simple that any Orocos user can pick one and modify it, hence it is the first 
thing a new user will encounter. An application template should be 
explainable on one page with one figure explaining the architecture. The 
current "Control Kernel" application template does not fit that description 
very well and will disappear as such. Also, an application template will have 
no longer any relation to 'C++' templates.

 The Release
So far the layers. Now about the release. This will consist of the "Real-Time 
Toolkit 1.0", a set of components built upon that interface and
the application templates to set up applications. The idea is that any 
component built upon that Toolkit version is connectable in the application.
The components themselves do not need to have the same version number,
although they need to have compatible data exchange ports and may depend upon 
each other.

 The Roadmap
One major release between 0.22.0 and 1.0 (thus 0.24.0) is planned to gather 
feedback and allow to merge projects 'gradually' into the main line. We'll 
use the Bugzilla 'Milestones' to denote the order or merging and if a feature 
is going to be part of 1.0 or later. The development plan (see the bottom of 
<http://www.orocos.org/developmentplan.html#timeline>) will be used to give a 
user friendly overview of the plans and progress. As you can see, the 1.0 
release is now scheduled for September 2006.

 Actions to be taken
Besides the 'usual' project merging, 3 large efforts need to complete for a 
successful 'launch':
1. Repartition Orocos as above.
2. Rewrite the website to clearly reflect this structure
3. Rewrite the documentation such that new users can gradually
    learn the system and clearly state who is targeted by which 
    documentation.
We'll be using the Bugzilla database for tracking these matters.

That's about it what I had to tell. Your opinions are welcome, as usual.

Peter

-- 
Peter Soetens -- FMTC -- <http://www.fmtc.be>