[Robotics] Blender and UAVs

[Séverin Lemaignan]

Hi,

I'm adding the robotics at blender.org mailing-list to this interesting 
discussion.

> Currently I'm building a virtual lab in Blender to test my human motion
> tracking algorithms. This includes exporting
> virtual camera data to my comp. vision algorithm (as the sensor data
> from multiple cameras) but also controling the models armatures from my
> cv program.

Excellent project. I'd be very glad to see some videos/papers about that!

> In this context I started looking into the possibilities to use blender
> as a "component". (in our Orocos naming scheme).
> This is something I would like to discuss with you all and hopefully
> present some ideas and goals at the Annual Meeting, in order
> to combine our efforts into a common goal/effort. Because this goes way
> further than a single person can accomplish.
> Some things that I (and Herman) think are related to such a problem:
>
> - It means there must be a FSM around blender (configuring, starting and
> updating as primary functions, timing for ex. as secondary)

What do you call a "FSM"? a Finite State Machine, I guess. But then what 
do you mean by "timing"? you would like to have smthg like a common 
clock line for all your components?

In any case, we call at LAAS/ONERA this control component the 
"simulation supervisor", and we are currently implementing something 
like that in the Blender UI. We wrote a partial specification for that, 
but I can imagine that your needs are likely to be a bit specific.

> - It means we should write our communication as middleware independent
> as possible and make it multifunctional compatible with certain middlewares:
>
>   * YARP (Laas)
>   * ROS ( Leuven, TUM, ...) (I'm currently testing this)
>   * Standard TCP/UDP data dumps
>   * Corba (Leuven) (we already have implementations based on Corba)
>   * ... whatever I've might overseen

Yes, this point (middleware independence) was very high on the 
requirements list for ORS (OpenRobots Simulator) from the beginning.

The path we would like to use rely on LAAS's Genom3: an important, 
under-development, software project that aim to automatically generate 
module for a wide range of middleware from a single module specification.

Genom3 is not yet available (we are in the process of converting the 
prototype to a full-featured application), so we've been implementing 
"by hand" support for YARP (and raw TCP sockets, if I'm right. Gilberto?).

I would like to add that generally speaking, LAAS does *not* rely on 
YARP. We are merely YARP user because of several European projects we 
are involved in. But our everyday "middleware" (inter components 
communication framework, should I say) is an internal tool called Pocolibs.

> - It should mean that we both need to get input and _output_ out of blender
> - In the long term it should mean that we could load a unified
> description of our virtual environment from the FSM. (for example load a
> Collada file, ...):
>
>   * the model/meshes
>   * the kinematics/armatures
>   * the dynamics of such models
>   * lighting and camera parameters
>   * user interface (if needed)
>   * ... think I forgot a whole lot here

This point on Collada files appear very important to me. I'll wite 
another mail on this topic later on.


> PS2: Herman, should we include people from TUM in this discussion or are
> they coming to the Annual Meeting?
I'm currently discussing it with them. They are using Gazebo as primary 
simulation platform, and are not likely to change anytime soon, I think.

At least not until it's well integrated with ROS with an easy path to 
convert current models to models usable in Blender.

> PS3: Severin, did I meet you on my last visit at TUM (I was there for a
> whole week with Jan Bandouch)?
Depends when you came. I'm here since the beginning of January.


Cheers!
Séverin
-- 
          Séverin Lemaignan - severin.lemaignan at laas.fr
  [00]    PhD student on Cognitive Robotics
/|__|\   LAAS-CNRS - RIS group / Technische Uni München - IAS group
   ''     +33561337844 / +498928917780
          http://www.laas.fr/~slemaign