[Rock-dev] [Rock-users] RigidBodyState is changing

Dennis Mronga dennis.mronga at dfki.de
Fri Apr 17 09:10:32 CEST 2015 

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ó
>>> <javier.hidalgo_carrio at dfki.de> 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
>>>> Rock-users at dfki.de
>>>> http://www.dfki.de/mailman/cgi-bin/listinfo/rock-users
>> _______________________________________________
>> Rock-dev mailing list
>> Rock-dev at dfki.de
>> 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:   dennis.mronga 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
  -----------------------------------------------------------------------

More information about the Rock-dev mailing list