Hi, changing RBS like this would indeed affect a lot of code. I would really consider whether the actual improvements are worth the pain.
However, if there is consensus to do it, please don't use base::Wrench for representing accelerations. base::Wrench is representing Cartesian forces and torques. Acceleration should be another type. Furthermore, I like the idea of having Pose, Twist and Acceleration types, which can be used separately or (together) in RigidBodyState (which is the idea, if I get it right!?). Best, Dennis On 17.04.2015 07:36, Steffen Planthaber wrote: > Hi, > > > On 16.04.2015 18:57, Sylvain Joyeux wrote: > >> backward compatibility. Having a Deprecated class is, as far as I can > >> see, close to useless as RBS is mainly an orogen interface type, and > >> one will not be able to connect a Deprecated port to a non-deprecated > >> port. > > Some time ago we started to implement deprecation for port types (not > the type itself): > > https://rock.opendfki.de/ticket/419 > > And Matthias already had a patch for that (attached to the ticket). > > But we actually never tested the results, as the use case vanished. > > If we can implement something similar for the types itself, we can solve > the stable-master issue, as compatibility is not affected. > > The port deprecation code works like this: > > When you tell the port, its type is deprecated: > output_port("rbs", > "base/samples/RigidBodyState").deprecates("base/deprecated/samples/RigidBodyState") > > Orogen generates two ports: > 1. _rbs with type "base/samples/RigidBodyState" > 2. _rbs_deprecated with the old type > > The magic happens in orocos.rb: When a connection fails, it > automatically tries to connect the <name>_deprecated port(s) (and pops > up a deprecation warning). This way, the component can be used with both > types. > > But it still has to implement the handling of both types in cpp (read > both ports), as long the deprecation period is active. > > This is NOT fixing "the name issue", as a rename of the old type is > needed here. "base/samples/RigidBodyState" -> > "base/deprecated/samples/RigidBodyState" > > Components which don't have the deprecated ports would directly change > the type, but I wonder if the ports can be auto-deprecated, when they > use a type that is marked deprecated for orogen in a similar way: > > For Example: When base/orogen/types are build, the > "base/samples/RigidBodyState" type is marked affected by deprecation > similar to this: > > import_deprecated_types_from 'new_type_name' 'header of deprecated type' > or > import_types_from 'base/samples/RigidBodyState' > "base/samplesdeprecated/RigidBodyState.hpp" > > (TODO: think of a good way to use a deprecation command in the orogen > file, i don't really like this example, it expects one type per header) > > This makes orogen generate two types: > > 'base/samples/RigidBodyState' > 'deprecated/base/samples/RigidBodyState' > > This way, orogen knows about the deprecated type and could > automatically deprecate all ports using it. > > Still, the internal port name changes (inside Task.cpp) and the code has > to be touched. But the intitial work to make the code work again is > minimal (change the read command from "port.read()" to > "port_deprecated.read()"). The component "works" again, but has no > support for the new type (the port is not read until it is implemented). > > The nice thing about this: All the devs get notified about the change > and the compiler error will (hopefully) tell a type mismatch between the > new and the deprecated type, when _port.read() is used with the "wrong" > type. > > > This approach is far from being finished, but it could be a start... > > At least it allows mixing the branches because a task from master has > the _deprecated ports and orocos.rb can automatically connect > *_deprecated output ports to the normal ports of a component from stable > and vice versa > > Steffen > > > > Am 16.04.2015 um 20:08 schrieb Javier Hidalgo Carrió: >> The list of actions are more into "let's have the right RBS >> implementation" than "let's have a smooth transition to the new RBS". I >> am worried more about the first one than about the second one. I >> understand the second issue is an enormous issue which I don't have >> experience with. >> >> Replacing RBS by a new version will break building all-of-Rock as for >> example already happened in the past when changing vizkit3d. >> >> One possible solution I could see is to create new types, e.g.: >> BodyState and BodyAcceleration. To have them together with RBS and >> RBAcceleration and progressively change to the new types. For example, >> making a warning compilation when using the RBS. Maintainers of each >> package would have time to adapt to the new type (similar to when we >> moved from actuators to Joints). >> >> Thanks for the comments and prompt reply, >> >> Javier. >> >> On 16.04.2015 18:57, Sylvain Joyeux wrote: >>> Javier: the plan looks great, and I am very grateful that you try so >>> hard to fix the base types ... But there is IMO still the same >>> unresolved issues, and that's a lot for an "imminent change". >>> >>> You put all over the place "changing the type is not that hard". Have >>> you already changed to the new type ? How much changes did you need to >>> make in your code ? Have you tried building the vanilla (i.e. >>> unmodified) all-of-Rock with the new type in ? >>> >>> From my perspective, changing a base type *is* hard. It has an effect >>> on day-to-day work for all people that have been using RBS. It breaks >>> backward compatibility. Having a Deprecated class is, as far as I can >>> see, close to useless as RBS is mainly an orogen interface type, and >>> one will not be able to connect a Deprecated port to a non-deprecated >>> port. >>> >>> Mixing the two types will be impossible (since they have the same name >>> but different ABIs). So, that's all-or-nothing: either you change all >>> your code to use the new RBS, or you keep the old one. Mixing stable >>> and master will be unreliable at best. Lot of people will probably end >>> up using master (with the pain and suffering that entails). >>> >>> Does someone have any experience for a wide-ranging change like this ? >>> How would we get to the point where we *do* have experience before we >>> push it to everyone ? How do we avoid just randomly pushing this >>> change to everyone, while many people won't have the time and energy >>> to migrate to a brand new RBS ? >>> >>> There is zero documentation and zero experience for a wide-ranging >>> change like this, and I currently have the impression that the issue >>> of such a change are just brushed off with a "let's do it, it's going >>> to be fine". rock-convert exists, but is documented nowhere. >>> >>> Now, if this "changing RBS is just fine" is the consensus, I would >>> vote for just creating a new type. At least, we would not pretend that >>> we're providing a clean upgrade path, and won't upset those of us that >>> don't have the time to just migrate to a completely new type that just >>> happens to have kind-of the same API. >>> >>> Finally, you guys seem to push so much towards changing the base >>> types. If that's so high in your agenda, it might be time to put the >>> effort to make the process butter-smooth by doing the necessary >>> toolchain work ? >>> >>> Sylvain >>> >>> On Thu, Apr 16, 2015 at 10:54 AM, Javier Hidalgo Carrió >>> <[email protected]> wrote: >>>> Hi, >>>> >>>> RigidBodyState (RBS) is changing. There is a list of imminent actions (1 >>>> - 10 bullets). >>>> Your comments and alternative solutions are very welcome. Write them here: >>>> https://github.com/rock-core/base-types/wiki/TranformWithUncertainty-in-base-types#list-of-imminent-actions >>>> >>>> Javier. >>>> >>>> _______________________________________________ >>>> Rock-users mailing list >>>> [email protected] >>>> http://www.dfki.de/mailman/cgi-bin/listinfo/rock-users >> _______________________________________________ >> Rock-dev mailing list >> [email protected] >> http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev >> > -- Dennis Mronga Researcher Besuchsadresse der Nebengeschäftsstelle: 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-6560 Zentrale: +49 421 178 45-0 Fax: +49 421 178 45-4150 (Faxe bitte namentlich kennzeichnen) E-Mail: [email protected] 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 [email protected] http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
