[Rock-dev] Dynamic Ports in Task Model

Mon Oct 17 16:49:09 CEST 2016

> This is ok, when you only consider components living in an environment
in which dynamic port creation/destruction is possible and/or easy to do.

And why should I consider other environments ?

This is not a "blue sky" discussion, but one that is grounded in Rock.
In addition, generic cross-framework model-based frameworks (which
Syskit is really close to being) work only if you play each
framework's  strength (i.e. forbid dynamic connections on ROS but push
for them on RTT) instead of playing the "what if the other framework
cannot do X ?" game.

In other words, I'm not working to develop a component framework,
there's more enough of them already. I'm working to making them usable
for the kind of robotic applications I envision running.

> Maybe its also solvable by allowing dynamic connections (but not dynamic
ports) between components (?).

The need for dynamic connections is the basic reason why Rock exists.
And no, it's not enough.

Multiplexing connections (putting datastreams that need to be
disassociated later, e.g. transform stream using
sourceFrame/targetFrame) is not a panacea either. Out of the top of my
head:

 - generic monitoring of them is a major pain. You have to build
dedicated demultiplexers for things as simple as "what's the datarate
of stream X ?"
 - you're wasting your time marshalling/demarshalling what is
basically static metadata, and analyzing the streams.
 - it's wasteful in a major way for high-datarate streams (since you
need to send everything to everyone)

Sylvain

On Mon, Oct 17, 2016 at 12:39 PM, Moritz Schilling
<moritz.schilling at dfki.de> wrote:
>
>
> On 14.10.2016 15:22, Sylvain Joyeux wrote:
>>> And they dont need to do that, because the robot model is known at compile time.
>>> Another approach would be to introduce Task templates which are used together with other information to define a specialized version of a task.
>>> An example would be a Transformer template which uses URDF information to define a specific Transformer for a specific robotic system.
>> Even assuming that it would be true (and others in this thread gave
>> you reasons why it is not so), requiring codegen for everything that
>> looks like a dynamic feature is shooting yourself in the foot. Codegen
>> is not a silver bullet. It's actually a fairly horrible-to-maintain
>> mean to put models in systems.
>>
>> I usually prefer to use "modelling time" instead of "compile time".
> I agree. Actually I thought of 'modelling time' :)
>> Having a transformer that does no "transform chain discovery" and that
>> does not depend on demultiplexing a unknown stream of transformations
>> is definitely on my list. The components would still be dynamic (ports
>> created at configure time, transform trees created at configure time)
>> but the knowledge extracted from the model is given to the component
>> instead of being guessed.
> This is ok, when you only consider components living in an environment
> in which dynamic port creation/destruction is possible and/or easy to do.
> If you also consider other environments this might not be possible and
> would rely on code gen.
> Maybe its also solvable by allowing dynamic connections (but not dynamic
> ports) between components (?).
>
> Regards,
>
> Moritz
>>
>> Sylvain
>>
>> On Fri, Oct 14, 2016 at 7:56 AM, Moritz Schilling
>> <moritz.schilling at dfki.de> wrote:
>>> Hi there,
>>>
>>>
>>> On 14.10.2016 11:29, Martin Günther wrote:
>>>
>>> Hi all,
>>>
>>> On 14.10.2016 10:46, Raul Dominguez wrote:
>>>
>>> What if the number of ports is dynamic? I don't know of an existing
>>> case.
>>>
>>> Robot_frames
>>> (https://github.com/rock-control/control-orogen-robot_frames) does that.
>>> It reads an URDF and creates one dynamic RigidBodyState output port for
>>> each joint in the URDF.
>>>
>>> Transformer does a similar thing on the transformation_monitor branch:
>>>
>>> And they dont need to do that, because the robot model is known at compile
>>> time.
>>> Another approach would be to introduce Task templates which are used
>>> together with other information to define a specialized version of a task.
>>> An example would be a Transformer template which uses URDF information to
>>> define a specific Transformer for a specific robotic system.
>>>
>>> https://github.com/rock-core/drivers-orogen-transformer/blob/89f0428a8668687f15b6ff84d9da524eed5b6c2c/transformer.orogen#L45
>>>
>>> Cheers,
>>> Martin
>>>
>>> Have a nice weekend,
>>>
>>> Moritz
>>>
>>>
>>>
>>> _______________________________________________
>>> Rock-dev mailing list
>>> Rock-dev at dfki.de
>>> http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
>>>
>>>
>>> --
>>>   Dipl.-Phys. Moritz Schilling
>>>   Space Robotics
>>>
>>>   Hauptgeschäftsstelle Standort Bremen:
>>>   DFKI GmbH
>>>   Robotics Innovation Center
>>>   Robert-Hooke-Straße 1
>>>   28359 Bremen, Germany
>>>
>>>   Tel.:     +49 421 178 45-6601
>>>   Zentrale: +49 421 178 45-0
>>>   Fax:      +49 421 178 45-4150 (Faxe bitte namentlich kennzeichnen)
>>>   E-Mail:   moritz.schilling at dfki.de
>>>
>>>   Weitere Informationen: http://www.dfki.de/robotik
>>>   -----------------------------------------------------------------------
>>>   Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
>>>   Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
>>>   Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
>>>   (Vorsitzender) Dr. Walter Olthoff
>>>   Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
>>>   Amtsgericht Kaiserslautern, HRB 2313
>>>   Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
>>>   USt-Id.Nr.:    DE 148646973
>>>   Steuernummer:  19/673/0060/3
>>>   -----------------------------------------------------------------------
>>>
>>>
>>> _______________________________________________
>>> Rock-dev mailing list
>>> Rock-dev at dfki.de
>>> http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
>>>
>
> --
>   Dipl.-Phys. Moritz Schilling
>   Space Robotics
>
>   Hauptgeschäftsstelle Standort Bremen:
>   DFKI GmbH
>   Robotics Innovation Center
>   Robert-Hooke-Straße 1
>   28359 Bremen, Germany
>
>   Tel.:     +49 421 178 45-6601
>   Zentrale: +49 421 178 45-0
>   Fax:      +49 421 178 45-4150 (Faxe bitte namentlich kennzeichnen)
>   E-Mail:   moritz.schilling at dfki.de
>
>   Weitere Informationen: http://www.dfki.de/robotik
>   -----------------------------------------------------------------------
>   Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
>   Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
>   Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
>   (Vorsitzender) Dr. Walter Olthoff
>   Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
>   Amtsgericht Kaiserslautern, HRB 2313
>   Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
>   USt-Id.Nr.:    DE 148646973
>   Steuernummer:  19/673/0060/3
>   -----------------------------------------------------------------------
>
> _______________________________________________
> Rock-dev mailing list
> Rock-dev at dfki.de
> http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev