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

On Sat, 21 Jun 2003 [email protected] wrote:

[...]
> a) The proposal seems to be primarily targeted to factory automation and
>    manipulation type robotics. Is this the direction you want to emphasize?
Not at all! It should be completely application independent.
But I do realise that it's awefully difficult to consistently use
fully neutral terminology :-(

>    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

My subdivision was orthogonal to this: "real-time", "small distributed
system", "large distributed system". Whatever these systems might be.
Your suggestion is too much application oriented, IMHO, and the
project should not be guided by applications. 
Not immediately at least; of course, the applications should be known
to the designers, but these should be sufficiently strong in software
engineering in order to find the appropriate decouplings between
infrastructure and applications.

> 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

This is _very_ much what I had in mind. (But apparently wasn't able to
describe clearly enough :-) The "frameworks" are what I called
"infrastructure"; the process oriented components are "functionality
libraries".

> 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.
No, but this is basically a matter of time: the CORBA specs are the
only ones that are vendor-neutral. But, as in the current Orocos
project, CORBA should not be the norm but rather an option. I mean,
all functionality should be available and useable without having to
use CORBA.

> 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.
GUIs is an important topic, indeed. And the problems you describe are
quite well known too.(At least, nobody in the Orocos GUI workshop of
yesterday was surprised by these facts :-)
"The" answer is: to provide neutral stuff as far as we can, with
event-driven and polling client-server communication policies. Anyway,
there will be _many_ client toolkits. Many. But that's an unavoidable
fact, that also doesn't compromise the whole project.

> 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, ... 

Absolutely! So the project is not focussing on the HMI clients! (HMI =
Human Machine Interface). It's providing "everything" below the HMI.
(And probably also some HMI clients, for demonstration purposes.)
Again, this is what I mean when I talk about "infrastructure" :-)

> The use of patterns is excellent to capture process models, but it does
> not capture standard models for data. 
Agreed!

> 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

Well, this is certainly needed, but this is quite robotics-centered.
WHile Orocos-II would consider robotics _only_ as one of the many
application domains. The things you mention above should be done by
the current Orocos community, i.e., the robotics people. 
(And two people in KUL are working towards these things... We _must_
start discussing these issues on the mailinglist _very_ soon!)

[...]
> 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.

Absolutely. So, my concrete suggestion in this area is the following:
the core group should be good enough to cope with the independence and
compatibility issues, and sufficiently expert in "control" in order to
work together with the "key area expertise" groups that have to fill
in the subcontracting projects.

> As I said in the beginning: good start, but it might be useful to consider
> 
> I) what are the application domains
"Everything" in feedback control! At all levels of real-time, and all
levels of complexity.

> II) How can the different parts be organised to provide
>     -- progress
> 	-- independence in design ...
> 	-- compatibility
My (current) answer to this: the people of the core group of three
partners. So, this group will not be easy to find :-)

Thanks for the useful criticism! My impression was that we are
thinking along the same lines, but the current text does not convey
the ideas clearly enough.

Herman Bruyninckx
-- 
  K.U.Leuven, Mechanical Engineering, Robotics Research Group
<http://people.mech.kuleuven.ac.be/~bruyninc> Tel: +32 16 322480