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

[...]
> Nevertheless I share
> Henrik's worry that the scope of the project is too large. Perhaps the
focus
> only on industrial manipulation robots would be much too narrow, but I
would
> not venture beyond - lets say - mechatronic devices and systems composed
of
> them.

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.

I think that having this mechatronic scope in mind is fine. It's my
scope anyway. So, practically speaking, the outcome will not be much
different. Just making sure to replace "machine", or "robot" or
"mechatronic device" (and their combinations) by "feedback control
system" solves the scope problem. (If you think I am oversimplifying
here, please post _arguments_.)
At least, that's my understanding of the whole thing; based on years
of talking to people not in robotics but in "factory automation".

Ans: Obviously you are right that form this perspective all of those systems
are primarily feedback systems. Nevertheless the repetition times and
control methods differ considerably. If you neglect this fact you are bound
to provide only a very rudimentary shell, and the workload imposed on the
one coding his/her application will be quite great, thus the chances that
our software will become popular is diminished. Moreover repetition
(sampling) times do influence the structure of the system, so you need to
provide too many alternatives, making the system quite "heavy" (difficult to
master).

> If Herman wants to include process control,
> optimization etc. the resulting software will be too broad in scope, thus
> very difficult to master, not to mention effectiveness, thus not many
people
> will want to use it.

The two examples you mention are easy to argument about:
- 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. 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". As you see we differ only in this that you are much more courageous
and I am more cautious.

> discussion between Herman and Henrik. I do not want to pursue this topic
in
> detail, as the scientific content of the project can be discussed later
when
> the final decision of what needs to be created will be taken.

Well, I think both discussion influence each other! By trying to get
concrete technical content for the workpackages, we will get a much
clearer view as to what scope these technical contributions can cover
exactly.

Ans: Sure - I only wanted to discuss also some other relevant topics that
are imortant to the success of the project.

> The project is to rely on only 3 academic partners writing the core of the
> software. Each of the partners is to supply just 2 people. For a project
of
> the anticipated size this is not a large potential.

I know, but:
- more people cost more money.
Ans: TRUE
- finding really good people is the _real_ problem.
Ans: I think you are exagerating the problem - I can supply a few - provided
I get funding for them.
- much of the code should be "imported" from already existing systems,
  otherwise the project will definitely fail.
Ans: Sure
- 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.

> I would suggest to enlarge the group. I see
> the following benefits:
> - larger potential of the group,
> - reduced implementation workload on each partner,
> - more people having intimate knowledge of the created software, thus
better
> dissemination perspectives and larger pool of experts delivering answers
to
> FAQs from potential users,

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.

> - better chances of getting funding for the project (3 academic
> partners will not suffice for an IP - funding of a STREP can be
> obtained at the most): lack of the so called critical mass,
Don't forget that the core is only part of the project: there is also
the subcontracting part, which is reasonably large.

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.

> - a bigger group can get larger funds, as the success of the project will
be
> more probable,
The EU doesn't buy this argument for open source projects: we have to
convince them that there is indeed a large community (not paid by the
project!) that is interested in supporting the project actively.

ANS: If the core is bigger the attachments are more probable (you have more
people disseminating the good news).

> - more people are likely to have the knowledge from greater number of
> application domains, thus the created tool will be more general in its
> scope, and better tailored to the needs of potential users,
That's exactly the goal of the subcontracting projects!


ANS: Yes, but you assign low value to those activities (please see above).

> The obvious drawback is that the coordination problems increase with size,
> but the above benefits dominate.

I am not convinced :-)

Herman

ANS: Well, then you are heading for dire straits.

To keep things straight: I am very much in favour of the project. My slight
critique is caused by my worry that it can be jeopardised by the lack of the
necessary critical mass. Through this it can fail either with the Commission
or at the final stage - people will not be inclined to use the results. I
hope that through this doscussion we can avoid such pitfalls.

Cezary


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