Re: First draft of "OROCOS II" proposal...

Dear Herman

The provided proposal could be a good outline for an EU project, but
I have a number of issues that I think needs to be considered

a) The proposal seems to be primarily targeted to factory automation and
   manipulation type robotics. Is this the direction you want to emphasize?
   Robotics today is much more than that. It might be sensible to divide
   the work into

   i)   factory automation (intg with PLC, NC control...)
   ii)  manipulation systems
   iii) mobile systems

b) it might also be useful to divide the effort into seperate tracks for

   i)   application domain specific code
   ii)  Process oriented components
   		I)   Sensory components
		II)  Std control models
		III) Std libraries for estimation ...
		IV)  User interfaces
   iii) Frameworks
        I)   hard-real time mechanisms
		II)  soft real-time mechanisms
		III) Non-real time mechanisms

As an example Corba is good for soft real-time but so far there is
only liimited support for hard real-time and TAO is one option, but
on the other hand do you want to be tied into a single software provider,
I guess not.

Another topic is user interfaces, where QT and similar libraries are
excellent for general graphics and Java is also an excellent choice. For
hard real-time both of them are however inadequate. All X derived components
have the problem that X relies on a queuing model for graphics, while
in hard real-time you want the graphics system to discard output if it is
too old and you want a system that is scalable with respect to load. This
is not true for X based graphics today.

in user interfaces one also needs to consider the diverse needs of user
interfaces. Most systems will be used for a variety of different users with
differing requirements: floor operator, system repair person, System installer,
plant operator, unit manager ... Module programmer, ... Each of these
persons have different requirements in terms of access to details, data,
organisation of interface to accommodate differences in training and
use. .... So there are real issues to be considered in terms of how the
rich set of data availabel inside a process should/could be presented to
different types of users. 

The use of patterns is excellent to capture process models, but it does
not capture standard models for data. It might be useful to consider if
something can be done to standardise data / representation models as well.
Woudl it be possible to standardise data models across

a) basic geometry
   i)  point, lines, planes, vectors, matrices, ....
   ii) std operations on data points
b) geometry with uncertainty
   i)  points lines, ... with associated uncertainty
   ii) std estimators for operations on data types

It is likely impossible to provide comprehensive coverage as this was
attempted by the IUE effort and they failed in several respects, but
there is a danger that we might end up with good patterns but without
the set of libraries to allow us to share information. For serialisation/
off-line storage one might use XML as a basis for trivial datatypes, but
it is not an efficient models for storage of large amounts of data such as
laser scans or images. Thus there is a need to consider the definition of
such data and also the "off-line" model for exchange of data across
generations.

Thus it might be good to consider how the development process can be
divided to ensure assembly of key people across a particular topic and
how how it can be programmed with enough independence while at the same
time ensuring compatibility across the system.

As I said in the beginning: good start, but it might be useful to consider

I) what are the application domains
II) How can the different parts be organised to provide
    -- progress
	-- independence in design ...
	-- compatibility

Sincerely

Henrik I Christensen