Yamyam: 1版をインポートしました

2018-06-28T18:41:25Z

1版をインポートしました

wiki>Mindrones: moved Robotics/Middleware to Community:Science/Robotics/Middleware: moving under Community:Science ("Community" being a new namespace)

2011-11-02T19:51:47Z

moved Robotics/Middleware to Community:Science/Robotics/Middleware: moving under Community:Science ("Community" being a new namespace)

新規ページ

= Blender and middleware integration =

== List of middleware software ==

* [http://softs.laas.fr/openrobots/wiki/ OpenRobots], the LAAS robotics software projects, that, themselves want to use other middlewares.
* [http://eris.liralab.it/yarp/ YARP] (MIT/IIT ''Yet Another Robotic Platform'')
* [http://pr.willowgarage.com/wiki/ROS ROS], Willow Garage's ''Robotic Operating System''.
* [http://www.cs.unc.edu/Research/vrpn/ VRPN] (''Virtual Reality Peripherical Network'')
* [http://opensoundcontrol.org/introduction-osc 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!''')
* [http://zeroc.com ICE] General ORB with many features and bindings to most of the popular programming languages. Works cross-platform and cross-language.
* [http://www.blender.org/download/get-blender/verse-blender/ 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 [[Robotics:Middleware/YARP|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 [[Robotics:Contents|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:

[[File:Decoupled-architecture-for-middleware.png|400px]]

This [http://en.wikipedia.org/wiki/High_Level_Architecture_%28simulation%29 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...

← 古い版	2018年6月28日 (木) 18:41時点における版
(相違点なし)

Community:Science/Robotics/Middleware - 版の履歴

Yamyam: 1版 をインポートしました

wiki>Mindrones: moved Robotics/Middleware to Community:Science/Robotics/Middleware: moving under Community:Science ("Community" being a new namespace)

Yamyam: 1版をインポートしました