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

On Sun, 22 Jun 2003 [email protected] wrote:

> Thank you for your response. I think it is important to clearly define 
> the scope and task of a new project. If you make it too general then it 
> will automatically "compete" with other projects on distributed systems 
> and at the same time it is difficult to achieve the cohesion across the 
> involved partners.

The opposite approach (focussing, again, on robotics) will have the
same risk, I guess.

> I agree that tying it to close to application is a dead-end, but they 
> might been seen as "examples" that at least must be possible with the 
> infrastructure. 
I agree. I guess the concrete applications will follow from the
partners' interests...

> At the same time the division into
> 
> a) real real-time, soft real-time and non-realtime is import as the 
> requirements are radically different.
I agree too. (And I thought I made this clear in my first draft :-)

> a) Hardware abstraction / interfaces
I don't think this is valid in this project: the way I see it, the
project's focus is far away form the hardware. Except maybe for some
smaller parts.

> b) Operating system services (scheduling, communication, mutex, ...) -- 
> incl architecture think of it as an abstract engine/architecture for
> tying components together and offer default services for process
> handling and integration

I would phrase it differently: the goal is to give application builders
tools and interfaces that are "optimally" suited for control. And that
means that they are quite far from the traditional OS primitive.
The project would result in an "control-oriented operating system".

> c) Toolkits (libraries).... toolkits to enable / support applications.
> d) User interfaces
Yes.

> Does your text imply that you primarily will focus on a) and b)? 
No, b,c and e.

> needed but it is not a core focus. What about toolkits? Where does the 
> project end and where do other take over? Would you want standard 
> toolkits for estimation, control design, process modelling (a la UML, 
> Process algebra, ...) ...

"Standard" is a dangerous thing to talk about... I want software that
every control project can use.

[...]
> I agree 100% you want "patterns" (and interfaces / abstractions) that 
> allow use of (in principle) any communication mechanism.

Indeed: the infrastructure provides useful "mechanism", while the
concrete application builder chooses his favorite "policy".

[...]
> But it might be important in particular to consider how HARD real-time 
> graphics can be handled in a fashion similar to what is done for 
> example in QNX where the graphics is supposed to be real-time.

With the emphasis on "supposed" :-) I indeed want a
as-fast-as-possible plotting library, but this would be a rather
simple and focussed subset of the whole UI effort.

[...]
> > Well, this is certainly needed, but this is quite robotics-centered.
> 
> fair enough, but where do you want to draw the line, if you make the 
> focus too wide then it will be close to impossible to design data 
> representations that are actually useful. 

Finding the most appropriate "line" is indeed an important topic of
discussion within the project...

> For control it might still be 
> useful to use the representations above as it woudl allow handling of 
> SISO systems, State space models and with an addition of discrete 
> mathematic models (as done in LEDA) you can handle DES and in some 
> cases HDS systems.

Okay, but this is "systems and control theory", and the "objects"
there are sufficiently mature and agreed upon such that they indeed
belong in the project. In the draft, I somewhere talk about
"simulation of control systems"; the things you mention (and some
more) are part of that WP.

[...]
> OK, but I woudl still like to see a further subdivision to make it 
> manageable. I.e. you/we need to devide the problem space to attract 
> "domain" experts to each of the areas. 

I agree. That's what I hope this open discussion can lead to.

> > My (current) answer to this: the people of the core group of three
> > partners. So, this group will not be easy to find :-)
> 
> Yes you have made a challenge for yourself.
> 
The EU wants challenging project...

Herman

PS The suggestions I made are "far away" from robotics, with the
   express purpose of not to compete with possible robotics STREPS.
-- 
  K.U.Leuven, Mechanical Engineering, Robotics Research Group
<http://people.mech.kuleuven.ac.be/~bruyninc> Tel: +32 16 322480