> 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". 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. Sylvain On Fri, Oct 14, 2016 at 7:56 AM, Moritz Schilling <moritz.schill...@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@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.schill...@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@dfki.de > http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev > _______________________________________________ Rock-dev mailing list Rock-dev@dfki.de http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
