[Robotics] Integration of middlewares

[Herman Bruyninckx]

On Thu, 16 Apr 2009, Séverin Lemaignan wrote:

[...]
>> - the ideal case for using middleware is that _nothing_ should be added to
>>   blender except for a _generic_ interface for communication of "objects"
>>   with the external world; the choice of concrete middleware is then to be
>>   reduced to a _runtime configuration_ option.
>
> From my experience, and Paul seems to agree, it's always something we
> dream of (independance towards middleware) but rarely something
> achieved. We shouldn't forget that middlewares were created in first
> place to offer hardware decoupling :-)

I agree with your analysis. And I would add that this is a very unfortunate
fact, which leaves us with basically zero interoperability between the
middleware projects, while interoperability should have been _the_ major
design criterium of middleware, almost by definition.

So, the ideal solution is not within the scope of Blender, because it
is much more fundamental. Should we try to integrate "some" middleware into
Blender anyway...? I don't think so! Blender must get improved mechanisms
to interact with other software, but it should rather not have to know what
that other software is...

> we are now at the second degree: middleware decoupling...

> To better define the problem, could you write down on the Wiki what a
> "generic interface" in the context of Blender would look like for a
> sensor like a camera, for instance? I'm not sure, for example, that the
> framerate of a virtual (Blender) camera is something we can easily
> control -> should it appears in the interface? etc...

These are the right questions! Let me try to give a partial "answer"... :-)
(This "answer" is basically a summary of the reasons why "component based
programming" is needed in addition to "object oriented programming".)
- different classes of sensors provide "data structures" that can be shared
   by all members of the class. For example, in the camera case: an image is
   a matrix with pixel values, with some configuration parameters such as
   size, time stamp, gray value intervals, ...
- these "data structures" would be the only thing that should be encoded
   in Blender.
- Blender should get a "Read" and "Write" interface to the "outside world",
   where any activity within Blender can input or output such data
   structures in a _non blocking_ way.
- Blender should get a "component wrapper" around itself (whose use or
   not-use could be a simple configuration setting) that allows to connect the
   above-mentioned "Read"/"Write" data ports to "ports" offered by
   communication middleware. In the worst case, each middleware project that
   wants to integrate with Blender provides its own "Blender device driver"
   to make this happen. In the best case, Blender can have a "generic"
   interface to such middleware. (And the concrete middleware projects then
   have to add a "device driver" for this generic interface to their own
   code.)
- The "component wrapper" to communication middleware can have several
   (configurable!) policies: (un)buffered, FIFO, overwrite when new
   data arrives, ...
- The paragraphs above only deal with "data flow"; the next step is to
   introduce "event flow".

>> - in our group, we use often CORBA implementations for middleware (which is
>>   "easy" for us, since we have the appropriate bindings :-)
>
> Something home-made? I'm not really familiar with the different
> implementations of CORBA...
No, we have used things like OmniOrb, or TAO.

>> If so, separating the "object definitions" from
>> the "inter-process communication" is a Good Thing, and middleware should be
>> evaluated along these directions.
>
> Yes, I agree. We will probably stumble on some "middleware dependant"
> issues like the way middlewares handle (or not) events, but the
> definition of standard objects is in any case useful.

Indeed. But as I mentioned earlier, this is an effort which is much more
general than only our Blender needs... So, it should be done in the whole
robotics community. In this Blender scope, we could think with other
"domains" about how to provide the "component wrapper" stuff in a
domain-independent way.

The other threads started by Benoit and Damien, about the current state of
the game engine and the prototype C++ extensions to them, are the perfect
starting points for this discussion I think.

Herman