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

Fri Apr 17 14:41:09 CEST 2015

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.
It will simplify for example:
newBodystate = deltaBodystate * Bodystate
handling pose, twist and associated uncertainties at once.
>
> 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.
Thanks. This is a good point. This is what I wanted to know from e.g.: 
manipulator tasks perspective.  Acceleration twist is the combination of 
translational and rotational acceleration applied at one point. Wrench 
represents the combination of a force and a torque. Wrench is just the 
acceleration twist scaled by the mass:

a = [a_x, a_y, a_z] = 1/m * [f_x, f_y, f_z]

>
> 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!?).
This is the idea.

Javier.
>
> 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
>>>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.dfki.de/pipermail/rock-dev/attachments/20150417/883297fe/attachment.htm