Trying to structure the CORBA efforts...

There has been very active (and useful :-) CORBA development going on
in the Orocos context, both at KTH <http://cogvis.nada.kth.se/orocos/>
and at FAW <http://www1.faw.uni-ulm.de/orocos/>. I do think however
that these efforts are not very accessible for non-CORBA experts :-)

Therefore, this message is a first try to come up with an introductory
overview document, that motivates the use of CORBA and explains the
common background of the communication libraries that are developed,
all targeted to the "layman" robotics user.

I would like to start with asking your feedback on the following
large-granularity overview. Let me know whether you think my overview
makes sense, is incomplete or wrong, or whatever.

I see three big aspects in the whole CORBA stuff:

1. Communication mechanism.
   That is: information can be sent over a CORBA infrastructure in
   three technically different ways:

   1.1 One method call per object.
       For example, I want to get the latest data from the laser
       scanner on my mobile robot, so I ask for it.

   1.2 One method call per buffer of objects.
       For example, I want to follow on a graphical user interface
       what my mobile robot is doing out there, so I ask it to send me
       data continuously, but collected into buffers, such that I need
       only one method call overhead for each buffer, and not for each
       individual data, as in the previous case.

   1.3 Streaming
       I want to get all data from my mobile robot, as fast as
       possible, and with minimal CORBA overhead. Therefore, I use CORBA
       calls to set up a "data channel" towards my robot, over which the
       robot can send a continuous stream of data. This streaming
       itself is not done with CORBA calls, but with any available,
       efficient communication infrastructure; e.g., a socket.
       (This implies that both communicating parties have
        matching implementations of that non-CORBA communication.)

2. Communication policy.
   For each of the possible communication mechanisms, I can implement
   different policies, i.e., different ways how to _use_ the available
   communication mechanism. The KTH and FAW libraries present such
   policies, in the form of "send", "query", "push", "push newest", etc.
   I can imagine that each policy could be implemented on top of each
   of the above-mentioned mechanisms. But of course, some combinations of
   mechanism and policy are more appropriate than others in each
   particular application; therefore, the application builder should
   be allowed to configure the mechanism/policy combination, without
   much overhead.

3. Object ontology.
   This is the "class hierarchy" of objects that are relevant in
   robotics. They define "what" we want to communicate (via CORBA or via
   direct method calls in a compiled language).
   Both the KTH and FAW libraries have defined a couple of these
   objects; I have myself been very busy the last months in filling out
   this ontology, and these efforts can be followed "in real time" via
   the documentation section of the orocos web page.
   Anyway, there is still a lot of work to be done here, both in
   filling out the ontology as in integrating the already existing object
   definitions.
   (I still believe this latter integration determines failure or success
    of the Orocos project...)

Hopefully, we will be able to decouple (completely?) design and coding
activities in all three of these aspects. Do you think this is a
correct statement?

So, let me get your ideas and suggestions. Hopefully, I will get so
much inputs that I cannot cope with writing them up in an Orocos
documentation document :-) (For some reason or another, I doubt
that...)

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