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

Fri Apr 17 11:04:22 CEST 2015

Morning,

I think it it really a good way to improving base types.
Thank's to all dev's for their contribution (regarding this and for 
everything else too).

BUT regarding changing a so deep and wide used base time we need a more 
powerful tooling.
Specially a announcement on rock-users is not what we need here 
specially it is not discussed within the dev group before.
I don't know if we should revert this "is chaining" statement on 
rock-users now because it would feel strange that we revert meanings 
there...

Nevertheless,
There was already a few discussions and thoughts regarding dynamic 
conversion and port deprecation features.
As long as we don't have implemented these framework based compatibility 
function i would not provide a recommendation from a developer point of 
view to the 'customers'.  New types can be used if someone needs them. 
BUT to really integrate them in the framework we need a way to convert 
them on the fly (if possible), or provide a transparent way to realize 
both approaches.

I think we should put this on the Agenda for the next meeting.

Matthias

On 17.04.2015 09:10, Dennis Mronga wrote:
> 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
>>>

-- 
  Dipl.-Inf. Matthias Goldhoorn
  Space and Underwater Robotic

  Universität Bremen
  FB 3 - Mathematik und Informatik
  AG Robotik
  Robert-Hooke-Straße 1
  28359 Bremen, Germany

  Zentrale: +49 421 178 45-6611

  Besuchsadresse der Nebengeschäftstelle:
  Robert-Hooke-Straße 5
  28359 Bremen, Germany

  Tel.:    +49 421 178 45-4193
  Empfang: +49 421 178 45-6600
  Fax:     +49 421 178 45-4150
  E-Mail:  matthias.goldhoorn at informatik.uni-bremen.de

  Weitere Informationen: http://www.informatik.uni-bremen.de/robotik