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

Dear All,
First of all I must congratulate Herman on the courage to undertake  the
ambitious endeavor of creating general purpose control framework. I am a
pronounced advocate of a project delivering a free of charge open source
programming framework to the scientific community. 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. Focus on broadly viewed robotics (manipulators, walking machines,
wheeled and tracked robots, underwater and flying robots, and all the
systems composed of those components) is quite an ambitious plan – that
could be a good starting point.  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. This is my general comment to the very interesting
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. Although good
scientific content is a necessary condition for the success  of the project
it is not the satisfactory condition. I want to mention other risk factors.

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. Moreover, it cannot be
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. Hence, the coordination will become vital to the
success of the project anyway. 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,
- 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,
- a bigger group can get larger funds, as the success of the project will be
more probable,
- 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,
- more academic partners means greater capability of attracting industrial
partners, as the project will not be then perceived as a very local
initiative with minor chances of becoming a standard tool used by the
industry.
The obvious drawback is that the coordination problems increase with size,
but the above benefits dominate.
Cezary