Minutes of meeting at LAAS (22-23 April)

Minutes of the Orocos meeting at LAAS-Toulouse, 22-23 April 2002

Topics
1. Component architectures
2. Component interface description
3. Object libraries
4. Version 1.0 specifications
5. Actions

Present:
Sara Fleury, Anthony Mallet, Anders Oreback, Peter Soetens, Herman
Bruyninckx (minutes)

---------------------------------------------------------------------

1. Component architectures
We discussed what types of components Orocos needs. The difference
between the types lies in the different architecture, and hence the
different support the component needs from the framework.  For
example, all the components that LAAS uses at this moment are
structured as a simple finite state machine, without the need for
events, or for distribution over multiple processor; the application
builder fills in some functions and data structures in a standard
template, and the component is generated automatically. The servo
control components Leuven is working on have more advanced needs for
distribution and event handling. Etcetera. 

We identified (as a minumum) the following three types of
fundamentally(?) different architectures:
 - Feedback control 
 - Robotic service
 - Autonomous system 
These coincide, not by accident, with the classical three layers of
an autonomous system: reactive, coordination, deliberation, or any of
the other names this pattern is known under. One specific aspect of
robotic components is that their actions often involve interaction
with the physical world, so things such as complete control and
atomicity of actions can not be guaranteed.

(Note: the structuring into the above-mentioned types still needs
elaborate discussion on the mailinglist. So, don't interpret it as the
official Orocos point of view on this matter.)

The goal is to define widely accepted architectures for each. More
detailed reports will become available in the near future, but
the basic features underlying the architectures are as follows:

 - Feedback control: ``feedforward, feedback and observer''
   sub-components, that process data from the sensors and turn them
   into data for the actuators; all this in hard real-time and with
   configurable reporting to the ``outside world.''

 - Robotic service: ``reading device, processing its data, making
   the data available to users of the service''. Real-time is not
   really important; services are often completely independent;
   communication over a network is important.

 - Autonomous system: ``monitoring data made available by robot service
   devices, recognize the context in which particular data is useful for
   the completion of the task at hand, apply this data to determine the
   next action of robot''. This architecture is a heavy user of
   robotic services, in a very dynamically changing configuration.
   Centralization of decision making is typical, but the services can be
   distributed over a network.

Within each architecture, all sub-components are at the same level
from the point of view of the component builder; i.e., the component
doesn't know anything about the architecture it is used in. It's the
application builder that puts an architecture onto the components he
uses. Therefore, each application (level) has a ``supervisor''
component: it's the only one that knows (or has to know) about the coupling
between the components that the architecture introduces in this
application. So, it's also this supervisor that processes service
requests for the application, and that translates them into
``elementary'' service requests for the sub-components it uses.


2. Component interface description
LAAS is developing its new generation of the Genom tool. This tool
reads in a textual specification of the interface of a component, and
processes it into executable code and threads. The tool covers three
goals: (i) it is a formal description (``contract'') of a component,
(ii) it alleviates the burden for a component builder to know about
the internals of the architecture his component will use, and (iii) it
makes sure the binary component it builds from this specification
obeys the interface (by construction).

Any component should have some sort of interface description,
but not necessarily an automatic tool to build the binary component.
We decided to think together about the formal description in the
coming weeks, and see how the Genom structure needs to be adapted to
cover the two other above-mentioned types of architectures. (If,
contrary to what we expect now, no need for a different specification
arises, this means that the components are not really fundamentally
different!)

The practical short-term approach we agreed on is:
 - let's try what comes out of the adaptation of the current Genom
   specification, allowing possibly for a temporary phase of rapidly
   changing API.
 - let's only introduce new architectures when the urgent need arises.
   (Because we prefer simplicity over feature richness in these early
   stages of the project.)
 - let's go through the CORBA 3.0 specs and get as many definitions
   and concepts out of it that are directly relevant for Orocos, in
   order to define a terminology that is very well defined and
   standardized.  Things that come to mind immediately are: Which of the
   four different types of CORBA components do we need in Orocos? What
   keywords from CORBA do we use in the component interface
   specification? What CORBA services do we adopt in Orocos? What is a
   component according to CORBA? Etcetera.
 - let's define ``Orocos Version 1.0'' goals. 

All these short-term activities (i.e., for the next two months) should
be accessible through the Orocos web site. Maybe tools such as Wiki
should be used to foster co-development on the different subjects. 

We should look at existing interface specification efforts, such as
DAIS (``Distributed Acquisition of Information Systems'') in the OMG
Manufacturing group and others, for inspiration and reality checks.


3. Object libraries
There is an urgent need to define the object classes that are relevant
to robotics, because using the same libraries is a key enabler for
exchange and/or co-development of functionality, and for exchange of
components. The component interfaces should use these objects whenever
possible, instead of functionaly identical but syntactically unrelated
data structures and methods.


4. Version 1.0 specifications
These are targets for Orocos Version 1.0:
 - class libraries: position and motion representations; servo
   controllers; (Distributed) Finite State Machines; event handling;
   communication; robot kinematics; robotic devices.
 - components: formal specification of the three above-mentioned
   architectures, with reference implementations.
 - initial applications: position controlled manipulator arm; mobile
   platform with basic reactive navigation skills.
 - builds for Linux, RTLinux, and RTAI.
 - extend Comedi device driver library with the few missing devices
   (encoders).


5. Actions
 - Expect some actions from Leuven w.r.t. the web support for
   cooperative development of the Version 1.0 specifications.
 - Everybody should give feedback about the Version 1.0
   specifications.
 - LAAS and Leuven will make reports available on the component
   architectures they are working on. Both have published already
   preliminary versions some months ago, but these versions are currently
   undergoing extensive adaptation.
 - Leuven will initiate the definition of the class libraries for the
   most common objects: positions, controllers, kinematics,
   communication, device interfaces, etc.
 - Everybody should collaborate on the class libraries.
 - Leuven will update the web glossary, with the relevant terminology
   from the CORBA 3.0 standard.