Community:Science/Robotics/Middleware

Blender and middleware integration

List of middleware software

• OpenRobots, the LAAS robotics software projects, that, themselves want to use other middlewares.
• YARP (MIT/IIT Yet Another Robotic Platform)
• ROS, Willow Garage's Robotic Operating System.
• VRPN (Virtual Reality Peripherical Network)
• OSC, Open Sound Control, that came out of the music world but seems to have grown far beyond that, e.g., Nick Porcaro successfully interfaced it with Blender. (Reference/link needed!)
• ICE General ORB with many features and bindings to most of the popular programming languages. Works cross-platform and cross-language.
• Verse, probably not a good idea to invest efforts in:
  • Pros: already integrated with Blender
  • Cons:
    • No good armature support
    • No support in Game Mode
    • Not been worked on in a long time (like 2006)

How to connect Blender with an external programme?

Via a Python script in a Game Engine controller

An "always" sensor triffers a controller, whose Python script writes or reads data to/from the middleware. Some initialization/finalization can be done through "runOnce"/"quit" sensors. For an example, see the YARP page.

Via new C implementations of the Game Engine sensors/actuators

Conceptually, sensors and actuators are the natural objects that interact with the real world. However, Blender does currently not allow Python scripts in its Game Engine sensors or actuators. This would require a C/C++ development effort to implement custom sensors/actuators that can read/write from a middleware "socket".

Some background on the Robotics:Sensors, Controllers, Actuators architecture in the GameEngine by Benoit Bolsee.

Architectural issues

All implementations of the first three use cases of Blender in robotics (visualisation, simulation, and emulation) use the same architecture: a Python script in a controller of the Game Engine, that runs the communication middleware. This approach means that, for each middleware that someone needs to use, the Python code has to be extended, with a middleware-specific piece of code. Nevertheless, the functionality for which middlewares are used is almost always the same, and only the implementation details (choice of message data structure, policy of communication, names of objects that are being communicated, etc.) differ. This situation typically emerges in organically growing projects, and leads (potentially, but not necessarily) to a lot of code duplication and to a large maintenance overhead. So, in principle, one could come up with the following "HLA" architecture:

This HLA approach is more flexible, and has (at least in theory) more potential in large-scale integrated system, or in an application where different simulation/emulation components have to be tightly synchronized. One necessary (but not sufficient) condition for Blender (or any other software component) to be a full HLA component, it has to allow to let its own "clock" (i.e., the "Frames Per Second", fps) be triggered by the HLA system Coordinator. That is possible, in principle, via a Python script in a Game Engine controller that blocks on a socket connection with the Coordinator. A second necessary condition is that Blender has to be executed asynchronously with the middleware process, since all components in an HLA architecture must be mutually asynchronous, and their activities are only synchronized through (asynchronous) communciations with the HLA Coordinator (not shown in the image).

The "middleware-neutral mediator" is a programme running outside of Blender, and to which the Blender Python script exchanges messages, containing the information that Blender needs from the outside world and/or provides to the outside world. Such a mediator would contain all the above-mentioned middleware-specific translation code, using a "standardized" data format to communicate with Blender. To make such "standardized" data format is a job that is not only relevant to the whole robotics community, but probably should also be done there, and not in this relatively small Blender-centric project...