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

On Fri, 27 Jun 2003, Cezary Zielinski wrote:

> [...]
> > Nevertheless I share
> > Henrik's worry that the scope of the project is too large. 

I've been thinking about this some more, and I guess I have to start
agreeing :-) I do want to have a scope that is larger than Orocos-I,
but maybe the following would be a workable approach:
 (i) the goal remains to make generic things;
(ii) but the concrete inspiration and the immediate application
     targets are intelligent robotics and factory floor "agents".
I think the latter application is needed to force us "low level
robotics people" to also take the "very large scale" control problems
into account. At the same time, this "very large scale" is also
tackled in robotics, of course. E.g. the work at LAAS and other labs
with their robot fleets, robocup, etc.

> >  What makes mechatronic devices different form other control processes
> >  at the generic infrastructure level?
> 
> Ans: Sampling time is different and control methods used are different.

Sampling times should not make a difference, I guess...? Because all
control laws work with sampled data systems, i.e, with u(k) and u(k+1)
whatever the time between k and k+1 is.

On the other hand, I do not fully understand what you mean with
"control methods"? The term suggest things to me such as: pole
placement, Bode diagrams, Luenberger and Kalman filter design, etc.
Which are already fully general methods, aren't they?

[...]
> - process control: this is much easier than robotics control, so if we
>   cover robotics, then we have covered process control too.
>   Mind you: I am _not_ talking about the complexity of the processes
>   themselves! These might be very complex chemical reactions, or
>   whatever. But nothing in process control has generic needs that are
>   useless in robotics. [...]
> 
> Ans: Well, but I am talking about this complexity. If you abstract it away,
> you end up with just a rudimentary shell. 

Maybe I do not completely understand what you mean by "abstract it
away", but I do not want to "abstract away" any complexity.On the
contrary: I think the project should explicitly find what is the
(generic) complexity of feedback control systems, and what are the
(generic) solutions to it. Any exact model of one particular complex
process or system should  be supported by the infrastructure.

For example, let's look at a bunch of cooperation mobile robots. Or at
a set of flexible work cells on a factory floor. I think these are of
the same complexity: many "agents" making their own decisions, but
knowing what the goal of the whole system is, and willing to act as
"good citizens" in this whole system. I am quite confident that we
will be able to go a long way in providing software support for these
systems, independently of what exactly their states, sensors and
decision criteria are.


> Moreover, if you want to
> substantiate your claim that the framework can control virtualy anything you
> need to provide numerous test cases - and that would be prohibitively
> expensive. It seems that I am not looking at this project from the same
> perspective as you are. You seem to take the theoretical stance: "If in
> theory something can be done lets do it". My view is practical: "First let's
> do something that we can prove that is working well for a certain domain (in
> my case: mechatronic devices that share the comparable sampling rates and
> control methods) and later if it is successful let's venture into broader
> fields". 

I follow your stance completely, because it's the same as mine :-)
What I say extra is that I think that the field of controlling complex
systems is sufficiently rich in practical working systems that the
time is mature to see the "software patterns", i.e., the things that
are generic and that have been proven to work.
I am _not_ targeting the project proposal towards theoretical advanced
control. (Which is still necessary, but which will be done in other
projects.)

> As you see we differ only in this that you are much more courageous
> and I am more cautious.
The "courageous" part of the problem is what the EU wants to sponsor!
It should be grounded in reality, of course, but I guess that is
certainly the case.

[...]
> - finding really good people is the _real_ problem.
> Ans: I think you are exagerating the problem - I can supply a few 

I would be willing to believe you :-) If you can prove that they
satisfy the poject's severe requirements, I suggest you provide their
names to the partners that will (hopefully) be funded by this project :-)

> - some or even much of the required man power should come from other
>   projects with complementary/similar goals.
>   (E.g. all GUI things, numerical algorithms, communication, FSM and
>   Petri net libraries, agent software, ...)
> Ans: yes, but then the result might be a bit Baroque, hence not that easy to
> master, thus rather unpopular.
What is "Baroque"? :-) 

There is certainly an important effort to be done in "streamlining"
the integration of projects; but that's "boring" work, for which the
project foresees subcontracting sub-projects. The essential, creative
part of the project (done by the academic partners) is (i) to define
the real needs, and (ii) to evaluate existing projects with which
integration is possible and desirable.

[...]
> I would love to find a larger group ofpartners that have the required
> expertise! Don't forget that we are putting _very_ high demands:
> - expert software engineers (proven by code).
> - open source experience.
> - control experience, in more than a narrow application area.
> 
> ANS: Well, we are thinking about the same group of people, but I think that
> this group is much larger than you think.

That is great news! Let's hear some more details about that. In all
the projects I have been involved in (more than a dozen), I have
met only two or three people that satisfy these criteria...

[...]
> ANS: Looking at the figures it is difficult to see it. You alloted 250kEuro
> to short term contracts, which is less than 10% of the budget. Moreover, you
> have split this amount into 10 portions - I assume that you want to have 10
> small projects. As you assume 60kEuro per man-year you end up with just 4
> man-months per such project - not much I must say.

These subprojects should have very focused contents: not research to
be done anymore, just deliver. Of course, the budget estimates I have
put in the draft are by no means final! :-)

[...]
> To keep things straight: I am very much in favour of the project. My slight
> critique 

I welcome criticism! It can only improve things.

> is caused by my worry that it can be jeopardised by the lack of the
> necessary critical mass. 

Critical mass is not equal to having many partners; critical mass is
proportional to 
 
        expertise per person
        --------------------
             people

that is: the more people you need to reach the expertise level you
need, the worse your critical mass is. So, I am looking for maximizing
the nominator of this expression, not the denominator.

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