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

>>>>> "HB" == Herman Bruyninckx <[email protected]> writes:

Hi!

    HB> On Wed, 9 Jul 2003, Sebastian Wrede wrote: [...]
    >> I strongly agree with Markus that vision-oriented projects
    >> sometimes have other requirements and differently to Herman's
    >> opinion I cannot currently see an obvious solution to realize
    >> complex vision systems.

    HB> Did I suggest that these solutions are obvious? :-)

I think the issue here is that within the general framework of
robotics there are a number of different system types that needs to be
considered.

a) Hard real-time manipulation type control systems
   -- As done at KU Leuven
   -- Typically local system with a well defined system architecture
      and clear control objectives.

b) Soft real-time systems for mobile robotics ...
   -- As done at KTH and FAW (Christian where are you today?)
   -- Loosely synchronous processes typically interconnected using IPC
      techniques (typically implies soft real-time synchronisation).
   -- Architecture might be time varying and the control objectives
      might change over time.

c) Non realtime
   -- Well anything goes.

    >> >From past experiences with realizing complex vision systems, I
    >> think that the limited usability and high complexity of CORBA
    >> is a problem for application developers.

    HB> Yes, that's why (i) Orocos does not depend on CORBA, but is
    HB> CORBA-ready for those who want to use it; (ii) if you _really_
    HB> need networked complex systems, you are either doomed to
    HB> re-invent CORBA (poorly) or to use it (or other forms of
    HB> middleware such as offered in Java or .NET).

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. 

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

    >> We at Bielefeld University are dealing with integrating several
    >> vision components, e.g. in the IST-project VAMPIRE.  As we also
    >> have a mobile robot, we ended up testing OROCOS@KTH which was
    >> indeed non-trivial to get running on our linux machines.

    HB> All these things are still beta, you know. It's only by
    HB> feedback and help from courageous groups like yours that these
    HB> things will mature :-)

We are always happy to get development assistance. Use of the system
of course give feedback on features but it is better if more people
contribute.

    >> But finally we got it to work and we are now in the process of
    >> evaluating how well it fits our needs. Although OROCOS@KTH is
    >> work in progress, we have the impression that it might be very
    >> well suited as middleware solution.
    HB> Good! So work with them to make it better...

Excellent, thank you will you contribute your code back to the
community??

    >> For us at Bielefeld as 'vision and robotics' application
    >> developers, we would be very interested in a reliable and
    >> simple to use framework that could be used to integrate systems
    >> in both domains.

    HB> Do you have any concrete suggestions about what would be your
    HB> requirements?

The problem here is several:

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.

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

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.

Cheers

Henrik