[Rock-dev] Dynamic Ports in Task Model

[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.
>> 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.

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

-- 
Dipl.-Inf. Martin Günther
Researcher

DFKI GmbH
Robotics Innovation Center Bremen - Außenstelle Osnabrück
ICO InnovationsCentrum Osnabrück GmbH
Albert-Einstein-Straße 1
49076 Osnabrück, Germany

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5258 bytes
Desc: S/MIME Cryptographic Signature
Url : http://www.dfki.de/pipermail/rock-dev/attachments/20161014/57cbd8ff/attachment.bin