[Rock-dev] Dynamic Ports in Task Model

[Steffen Planthaber]

Am 14.10.2016 um 13:13 schrieb Martin Günther:
> Hi,
>
>
> On 14.10.2016 12:56, Moritz Schilling 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.

In multi-robot systems you might want exactly that, create new ports to 
connect a recently added new robot which might support the team with new 
functionality or capacity. Think of an autonomous warehouse with robots 
and the company wants to add a additional transporting robot. Should 
they recompile the central controller to add ports to control the new one?


>>> 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.
>
> I fully agree.

The resulting code is not generic enough to be reused by others, so 
people will start reimplementing the same code.

This discussion is about modelling time, is it? So when you model high 
level networks (e.g. mapping), it might be possible that you do NOT know 
the transformation of the robot(s).

I think the modelling layer should support the existence of dynamic 
ports, perpahs by parsing the same configuration files the execution 
layer uses (I think this is what Jakob intended).

>
> You could of course have transformations about objects in the world that
> are not known at compile time, but probably you don't want to model that
> with dynamic ports anyway.
>
> Regarding transformer / robot_frames, I also don't quite get why each
> transformation has their own port, instead of only one port for all
> transformations. All required information is in the `sourceFrame` /
> `targetFrame` fields anyway. But then again, I don't know enough about
> Rock's higher level task composition features to know why this design
> choice was made.
>
> Cheers,
> Martin
>
>
>
> _______________________________________________
> Rock-dev mailing list
> Rock-dev at dfki.de
> http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
>


-- 
  Steffen Planthaber
  Weltraumrobotik

  Besuchsadresse der Nebengeschäftstelle:
  DFKI GmbH
  Robotics Innovation Center
  Robert-Hooke-Straße 5
  28359 Bremen, Germany

  Postadresse der Hauptgeschäftsstelle Standort Bremen:
  DFKI GmbH
  Robotics Innovation Center
  Robert-Hooke-Straße 1
  28359 Bremen, Germany

  Tel.:     +49 421 178 45-4125
  Zentrale: +49 421 178 45-0
  Fax:      +49 421 178 45-4150 (Faxe bitte namentlich kennzeichnen)
  E-Mail:   Steffen.Planthaber 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
  -----------------------------------------------------------------------