[Robotics] Integration of middlewares

[Séverin Lemaignan]

Herman Bruyninckx a écrit :
> Some comments based on my experiences:
> - statements such as "YARP, which is really easy since it has Python 
> bindings"
>   are relevant, but dangerous: is 'easy' is reduced to 'fast to use in the
>   very short term because it has bindings in the "appropriate" language',
>   but that does not necessarily mean that it is a good long term solution.

Yes, I forgot to say that I was playing with YARP mostly because it's 
today the main middleware we are using at LAAS (mostly in European 
projects), and we have some experience with it. Since it has Python 
bindings, it was very easy for me to build a working prototype in 
Blender, but you're completely right Herman: the fact YARP has Python 
bindings doesn't mean that it is automatically a great middleware :-)

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

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

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

Severin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: severin_lemaignan.vcf
Type: text/x-vcard
Size: 310 bytes
Desc: not available
Url : http://lists.blender.org/pipermail/robotics/attachments/20090416/458770fe/attachment.vcf