[Robotics] Integration of middlewares

[Herman Bruyninckx]

On Wed, 15 Apr 2009, Séverin Lemaignan wrote:

> I would like to discuss the integration of robotics (or virtual reality)
> middleware in Blender.
>
> I think this could be a very interesting field for cooperation, allowing
> us to develop tools easily reusable by other teams.
>
> I had a talk with Damien Marchal, from IRCICA and he told me about VRPN
> (Virtual Reality Peripheral Network,
> http://www.cs.unc.edu/Research/vrpn/). We are using ourselves YARP and
> ROS at LAAS. I know that quite a lot of people are using Player/Gazebo
> for their work.
>
> It would be very nice to have a well identified mechanism allowing the
> use of these middlewares for inputs and outputs in Blender.
>
> I'm currently working with YARP, which is really easy since it has
> Python bindings. Paul Fitzpatrick is one of the lead developpers of YARP
> and he is ready to help on this.
>
> Are you using specific architectures in your labs? how do you see this
> could be integrated in Blender?
>
Blender is, in the context of this thread, not different at all from 'real'
robots: you want to use middleware to get data from one "agent" to the
other.

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.
- one of the major reasons why some middlewares are or are not good long
   term solutions is the extent to which they decouple the _communication_
   aspects from the concrete _communication policy_ and from the way how
   to deal with not-yet supported data types. I don't have enough experience
   with YARP (yet) to make a motivated suggestion for or against it.
- another (short time) evaluation criterium for middleware is the number of
   (relevant) "objects" or "devices" that it currently supports. This
   advantage could also become a disadvantage, if adding new devices or
   objects is "not easy".
- 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.
- there exists a specific "middleware" for computer animation software,
   namely "Verse" <http://en.wikipedia.org/wiki/Verse_protocol>. I don't
   have the feeling that the open source project around it is very active
   still...
- in our group, we use often CORBA implementations for middleware (which is
   "easy" for us, since we have the appropriate bindings :-)

In summary, I think the priority for us now is to see whether the "generic
middleware interface" option is viable, and if so, what has to happen for
it to become reality.

In the context of a previous thread (about the standardization of "sensors"
and "actuators" in the Blender Game Engine) I think that both discussions
have a lot of overlap: the kind of "objects" for which one needs GE
standardization are exactly(?) the same as the ones for which we want to
use middleware, isn't it? If so, separating the "object definitions" from
the "inter-process communication" is a Good Thing, and middleware should be
evaluated along these directions.

Herman