[Robotics] Blender and academic world

Herman Bruyninckx Herman.Bruyninckx at mech.kuleuven.be
Wed Apr 15 19:19:50 CEST 2009


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

>> But how do you see the way to follow to get this "simulated sensor"
>> information from Blender to your real robot? Via (Python, C++) code in the
>> corresponding "sensor" block in the Game Engine, or via an GE 'actuator'
>> (because Blender then 'actuates' your external robot...)
>
> Well my parallel mail should partially answer your question :-)
yes :-) Or rather, it stimulated me to raise more questions! :-)

> For our needs, Blender "actuates", as you say, the robot. For instance,
> I have a model of robot with a (Blender) parented to it, I grab the
> (Blender) camera output (via the OpenGL buffer), and I output it to my
> (external) robot software. It's basically an "always" sensors which
> calls a Python script (the ImageGrabber).

This is a nice example (because I am interested in such a thing too :-))
and it gives me the opportunity to illustrate what I mean with the need to
separate the _mechanism_ of communication (i.e., getting the image from
Blender to your robot controller) from the _policy_ of the communication
(e.g., do you want Blender to generate images at a predefined rate? As fast
as it can? Only when triggered by your robot controller?...) Some
middleware projects do not allow to (re)configure the policy, which _I_
think is not a Good Thing...

>> Whatever we choose, the C++ additions to and from the GE blocks are a very
>> worthwhile addition, I think. It was not very clear to me what the C++ code
>> does exactly: does it open a "device driver" on the Blender host? Does it
>> open a "TCP socket", or a similar "network"-like communication?
>
> That my point with the mail concerning the middlewares. It's not yet
> very clear for me if it can be integrated at the C++ level or not.
>
> I'm not yet able to do benchmarking of this image grabber example
> powered by Python, but I don't expect great results. C/C++ will probably
> be required to have correct performances.

That would indeed also not contradict my own expectations :-)

Herman 
--
   K.U.Leuven, Mechanical Eng., Mechatronics & Robotics Research Group
     <http://people.mech.kuleuven.be/~bruyninc> Tel: +32 16 322480
   Coordinator of EURON (European Robotics Research Network)
     <http://www.euron.org>
   Open Realtime Control Services <http://www.orocos.org>


More information about the Robotics mailing list