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

On Wed, 9 Jul 2003, Henrik I. Christensen wrote:

[...]
> Yep OROCOS should provide an abstraction for IPC and below the
> abstraction one might use Corba (as KTH/FAW uses TAO). One problem is
> often to provide the hiding in such a fashion that the programmer of
> OROCOS is completely hidden from the Corba layer, but this should be
> the case. For general communication to make it transparent across
> templates... (all the fancy C++ features) is use of valuetypes, which
> makes programming more difficult to understand, but the software
> engineering is "prettier", so there is trade-off. 

Are you aware of some sort of "Howto" about this topic? (I.e., about
how and why to hide CORBA from programmers.)

> 
>     HB> Also note that CORBA has provisions (but not yet
>     HB> implementations, if I am not mistaken) to use "streaming-like"
>     HB> data flows; CORBA is just used to set up the stream, which can
>     HB> then stream efficiently without CORBA intervention.
> 
> Corba is a moving target and it ought to be possible to provide an
> abstraction in OROCOS that makes the OROCOS less of a moving
> target. So bleeding edge features might be useful but they do pose a
> threat to portability ....

Indeed! Any concrete suggestions here also? At first sight, I would
just assume that the project will follow the moving target, but need
not wait for it to offer something useful. Or do you think that the
moving CORBA target is going to cause real trouble?

Anyway, I still think that all OROCOS stuff that is "behind" the CORBA
interfaces is the most important thing, and there is plenty to do
before we have to worry about CORBA not being advanced enough :-)

[...]
> a) You want the soft synchronous system support, but more importantly
>    there is a need to integrate VISION functionality / libraries into
>    the system. This is more than access to a frame grabber, so you
>    need to have libraries for basic image processing, tracking,
>    recognition, so far noone in OROCOS is working on this, but it
>    would be useful to have various code contributed and interfaced.

Don't you think this is something that the "vision community" has to
come up with? (Intel's OpenCV, VXL, ...)

>    To me it would be useful to have an effort to define a standard set
>    of datatypes (point, lines, planes) and datatypes with uncertainty
>    (points, lines, planes) and of course basic types of
>    semantics. This could be used in vision and in various robotics
>    systems with estimation libraries ....

I would love to cooperate on these topics, and as many others we have
been using some of these things already in applications. But I am
troubled by my mathematical background that tells me that lines and
planes are _not_ members of vector spaces, and hence just adding
additive uncertainty to whatever representation of lines or planes
is not really correct. (In the sense that different representations
will have different uncertainties, even if they start of with the same
initial values.)

> Soon the present OROCOS effort will finish its contract, and there is
> still a need to determine how / if OROCOS will survive once there are
> not funds to maintain the effort. At KTH we have had no funds for
> quite some time (for OROCOS), and a community has to come into place
> in which several institutions contribute to the same body of
> code. Today there seem to be several competing software bodies, but
> unless we start to see contribution to one or more of them, I suspect
> the effort might cease to exist. The KUL activity is involved in
> several projects and I am sure it will continue to operate, but for
> the others SmartSoft and OROCOS@KTH it is not obvious that "free"
> support is a good model for a long-term contributions to the
> community.

Absolutely... 

Herman

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