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

On Thu, 26 Jun 2003, Cezary Zielinski wrote:

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

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

> 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.
- simulation: this is an area where the application-independent
  generality I am aiming for has proven to work. Proofs: bond graphs,
  modelica.org, dymola, 20sim, ...
If I would to make objections myself, I would say that, for example,
multimedia processing or telecommunication is too different from
mechatronic systems control; that's why these things are also
explicitly _excluded_; they are not really feedback control systems
anyway.

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

> 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.
- finding really good people is the _real_ problem.
- much of the code should be "imported" from already existing systems,
  otherwise the project will definitely fail.
- 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, ...)

> claimed that the smallness of the group size is caused by the easiness of
> coordination, as anyway they are not located in one place, and thus will not
> work together very closely. 

They should!

> Hence, the coordination will become vital to the success of the
> project anyway. 
Yes, but:
- open source is more experienced in these things than traditional
  development projects.
- the vital thing is that the core people are thinking along the same
  software engineering lines. 

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

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

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

> - 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!

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

I am not convinced :-)

Herman

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