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

-----Original Message-----
From: Cezary Zielinski [mailto:[email protected]]
Sent: Monday, June 30, 2003 1:10 PM
To: Herman Bruyninckx; [email protected]
Subject: RE: [Orocos] First draft of "OROCOS II" proposal...


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.

ANS: This is exactly what I want too.

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

ANS: Well, yes, but this is the theoretic model. The transition between k
and k+1 involves computations. The implementation depends on how much time
you have to perform them, i.e. how far apart in time are k and k+1. If they
are very near to each other you might want to distribute the computations,
hence the structure becomes different.

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?

ANS:  Yes they are, but I was rather thinking about different approaches
taken by the process engineers and robotics control designers.
Please forgive me the oversimplification of this crude example, but this
will explain what I have in mind in general. Let us say that we want to
control the transfer of a rigid object by two manipulators. A roboticist
would concentrate on individual control of each of the manipulators and on
each of the servomechanisms within each robot, and then would try to
synchronise the the two elements of the system. The process control engineer
would rather perceive the system as a multi-variable one, where variables
would be the positions and velocities of the joints of manipulators. On top
of that he would rather want the transfer to be optimal with respect to some
criterion, e.g. time. I think that each of those approaches results in a
different structure of the system from the software point of view.

Talking about control methods, and their diversity, I had in mind the fact
that in process control usually you deal with nonlinearity by linearisation
about the stable state. In robotics, we rarely require the stabilisation of
the output around the set point, but rather require trajectory following,
the nonlinearity is treated either as a disturbance or has to be taken into
account fully. In robotics you don't use predictive control and DMC, while
those techniques are quite popular withe process control community. The same
applies for optimal control theory, which by itself imposes a certain
structure of computations and is highly time demanding. I am aware that you
can find papers introducing those methods into robotics, but one cannot
claim that they are mainstream of robotics.

In robotics as well as in process control we use distributed systems, but in
both cases the dividing lines tend to be placed in different places. In
robotics the demarcation lines are drawn along functional modules (i.e.
steming from the realised function), wheras in process control the lines
tend to discriminate between computational modules (i.e. steming from the
kind of computations that are needed). E.g. in robotics you would have
separate modules for sensor processing, actuator control trajectory
generation, etc. In process control the modules would compute diverse
matrices, etc. Perhaps you can show that both approaches boil down to the
same architectural structure, but before we can prove that beyond resonable
doubt I would refrain from venturing the unknown teritory. Maybe it would be
reasonable to stick to mechatronic devices and also look at process control
on the sidelines. If it turns out that we can do both, lets provide this as
a bonus, rather than commit ourselves and then have problems with delivery.

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


[...]
> - 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 :-)

ANS: You seem to be rather harsh. I think that the current OROCOS has more
than 6 such persons. I don't want to name those persons for the fear of
excluding someone, and thus treating him/her unfairly. Nevertheless, I can
supply another 6-8 persons from my university, provided that you can fund
them adequately, so that they can concentrate on the project. The amount
that you quted (5000 Euro/man/mont) is more than enough, so I think that my
expectations are reasonable. Under those circumstances I would encourage you
to fly to Warsaw for a couple of days and I would show you what and who is
available. I am talking about people holding Ph.Ds with some years of
experience in writing diverse software for real-time systems. They are
currently employed by the Institute of Computer Science and the Institute of
Control and Computational Engineering and have some experience in robotics
too. I think that their background is adequate. If required we can get extra
people from the Mechanical Engineering Departments - they might become
usefull in the phase of user system testing.

> - 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"? :-)

ANS: Baroque is a cultural period in the history of Europe. Its greatest
impact was on architecture and literature of XVI/XVII c. Europe. I was
refering to the architectural style. If you go into a Gothic church the
first think that strikes you is the structure of the building. If you go
into a Baroque church the first thing that srikes you is the multitude of
fine details. In Leuven the majority of churches is Gothic - this is a good
forecast for our project ;-). Nevertheless, in the city center there is at
least one Baroque church, so you can visit it and, lets say, the cathedral
(the one in front of the town hall) and you will see the difference.

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.


ANS: I thought that the core of the group would focus on the specification
of the framework and the choice of the software tools and libraries that
will be used. The implementation can be subcontracted, as well as the case
studies that verify the concepts.

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.

ANS: The formula should be:

             n
e_0 + SUM delta e_i
           i=1
----------------------------
         E (n+1)

where:
e_0 - is the experience of the coordinator
delta e_i - is the increment in experience of the i-th participant in
relation to all participants numbered 0 to i-1
E - is the total experience required
n  - is the number of participants excluding the coordinator.

I hope that farther discussion will concentrate on this formula, as its
evaluation is paramount to the success of the project ;-).

Cezary