<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 17.04.2015 09:10, Dennis Mronga
wrote:<br>
</div>
<blockquote cite="mid:5530B1E8.4070605@dfki.de" type="cite">
<pre wrap="">Hi,
changing RBS like this would indeed affect a lot of code. I would really
consider whether the actual improvements are worth the pain.</pre>
</blockquote>
It will simplify for example:<br>
newBodystate = deltaBodystate * Bodystate<br>
handling pose, twist and associated uncertainties at once.<br>
<blockquote cite="mid:5530B1E8.4070605@dfki.de" type="cite">
<pre wrap="">
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.</pre>
</blockquote>
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:<br>
<br>
a = [a_x, a_y, a_z] = 1/m * [f_x, f_y, f_z] <br>
<br>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
<blockquote cite="mid:5530B1E8.4070605@dfki.de" type="cite">
<pre wrap="">
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!?).</pre>
</blockquote>
This is the idea.<br>
<br>
Javier.<br>
<blockquote cite="mid:5530B1E8.4070605@dfki.de" type="cite">
<pre wrap="">
Best,
Dennis
On 17.04.2015 07:36, Steffen Planthaber wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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):
<a class="moz-txt-link-freetext" href="https://rock.opendfki.de/ticket/419">https://rock.opendfki.de/ticket/419</a>
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ó:
</pre>
<blockquote type="cite">
<pre wrap="">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:
</pre>
<blockquote type="cite">
<pre wrap="">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ó
<a class="moz-txt-link-rfc2396E" href="mailto:javier.hidalgo_carrio@dfki.de"><javier.hidalgo_carrio@dfki.de></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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:
<a class="moz-txt-link-freetext" href="https://github.com/rock-core/base-types/wiki/TranformWithUncertainty-in-base-types#list-of-imminent-actions">https://github.com/rock-core/base-types/wiki/TranformWithUncertainty-in-base-types#list-of-imminent-actions</a>
Javier.
_______________________________________________
Rock-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Rock-users@dfki.de">Rock-users@dfki.de</a>
<a class="moz-txt-link-freetext" href="http://www.dfki.de/mailman/cgi-bin/listinfo/rock-users">http://www.dfki.de/mailman/cgi-bin/listinfo/rock-users</a>
</pre>
</blockquote>
</blockquote>
<pre wrap="">_______________________________________________
Rock-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Rock-dev@dfki.de">Rock-dev@dfki.de</a>
<a class="moz-txt-link-freetext" href="http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev">http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev</a>
</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<br>
<br>
</body>
</html>