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
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Rock-dev mailing list Rock-dev@dfki.de http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
