[Robotics] Introduction

[Séverin Lemaignan]

Thanks, Herman, for your quick answer.

I think you misunderstand the point with Genom3.

To put it clearly, the main design requirement of Genom3 is: do not 
impose anything "LAAS made" to anyone.
That's really what we want to achieve.


>> That's one of the big challenges. Our current idea is to rely on Genom3
>> (Herman, I think you attended the presentation at ICAR. Cf the attached
>> slides): it's basically a code generator that take in input a
>> description of the services (and datatypes) your component offers, a set
>> of so-called "codels" that implement the actual computation required to
>> generate the sensor output or actuator actions and a generic template
>> per middleware.
>>
>> With that, someone who wants to use the simulator with it's own
>> middleware just need to write its own template and everything works, and
>> someone who want to add a new component just describe the services the
>> component offers and write the Python code to be executed in Blender to
>> generate the data.
> 
> That means the Genome data structures are "the standard"... And I am not so
> sure that that's a right choice. (The same remark holds for other
> frameworks, of course.) The real challenge is not so much to make Blender
> interoperable with one particular framework, but to make it interoperable
> with _all_ frameworks! That requires a higher level of standardization
> between these frameworks, of course. And Blender could be the catalyst to
> start such interoperability work...

It's not very easy to explain all the concepts behind Genom3 by mail. 
Hopefully the slides I added to my previous mail can explain a bit 
better the idea.

In Genom3, you can use your own datatypes (as long as it fits in the IDL 
standard, which is not a big constraint), you decide upon the name of 
your ports or services, and you decide on your middleware.

Genom3 does a very simple job: it parses a description file and 
instanciate a template from it.
The only thing it requires is a standard way to describe the services 
and datatypes (the .gen file) and a standard way to describe how to use 
*your* middleware (the template file).

I'm not sure it helps a lot, but so far, the project looks promising, 
and we were for example able to generate modules for YARP, OpenRTM (and 
our own pocolib communication library) from a single codebase.

Cheers
Severin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: severin_lemaignan.vcf
Type: text/x-vcard
Size: 310 bytes
Desc: not available
Url : http://lists.blender.org/pipermail/robotics/attachments/20090827/ed03bdb6/attachment.vcf