Re: My 2c

Herman Bruyninckx wrote :

| my idea of what Orocos should become is, in the first
| place, a set of robotics _libraries_ of high quality, and, only in the
| second place, a reference architecture (or rather, a _set_ of possible
| reference architectures, because I don't believe that there is only
| one superior design).

That's also my vision of this project.

We've already seen in this list that many people will come with their
architecture design and ideas (and have very good reseons to do so).
I think that the challenge is --- at first --- a matter of
"compatibility" between all those systems, rather than trying to find
which one is the best.

Imho, one of the goals of Orocos is to gather experience from existing
systems and agree on commons interfaces (especially for communication ---
control or data --- between functionalities).
[ Ideally, this should make all existing systems converge toward the
ultimate, generic, universal design ;) ]


| Both things (libraries and designs) have to be
| as decoupled as possible: whatever architecture you want to use for
| your system you should be able to construct it out of Orocos (and
| other) building blocks for more than 90%.

I agree, but I think we should also be able to exchange "blocks" (you
mention it below). This means that we have to agree and share some code
or some ideas at some abstraction level.

Don't you think that, for instance, it would be great to agree on common
data structures? (what should be a video image, a 3d image, a robot
position... etc...). It's the most basic level of compatibility.
Of course, it can (should) be object oriented and we don't necessarily
have to share C or C++ structures, but the information we'll put into
those object must have at least something in common.


| And the issues you mention
| (CORBA and XML) should only be means to _glue_ things together, and
| not key factors in the _contents_ of Orocos.

Sure

| Nothing in the orocos code should depend on CORBA if
| you don't want to use it.

Ok, but I think it will be necessary to define and use some common
communication systems (or, at least, interfaces) in order to obtain some
level of compatibility between the various systems. If you decide to use
CORBA and I decide to use some other protocol, it won't be easy to share
what we'll build on the top of those protocols!

I don't know much of CORBA and IDL, but I think (?) they're just a kind
of spec. From what I understand, choosing CORBA does not imply choosing
an implementation of it --- f.i. we're free to define our subset of
CORBA provided it's compatible with existing tools?.

At the momment, a question that I am asking is: does IDL provide
sufficient level of description/abstraction to suit our needs?
From the experience of GenoM, I would say no. That is: we must extend
somehow the abstraction of the description we'd like to share.


| But I do see some useful applications for CORBA (or SOAP, or...), at
| higher, less time-critical and machine-dependent levels. For example:
| I want to test your motion planner on my system, or you want to
| compare my pattern recognition algorithm with yours, etc.

That's what I called "blocks sharing" above. I think it's a key issue,
and I think we should aim at this.



| > I will be attending the meeting at the start of September so we can
| > continue this discussion over a beer or two. :-)
| Great! But I'll leave the beer drinking to you, and take a glass of
| wine, if you don't mind :-)

Could I have both ? ;)