This mail is meant to propose an addition to the dataflow
implementation: the addition of channel elements that "transform" a
channel of type A into a channel of type B.
Rationale: the purpose of these elements would be twofold
1. allow transparent interoperability between frameworks (here, my
personal goal is the convertion between ROS and Rock types)
2. do type slicing, in particular start handling inheritance in the
type system, through allowing the usage of a subclassed source to send
data to a parent class sink (think using a Pose output port to feed an
Orientation input).
Technical solution:
- add a new conversionElement(from_name, to_name) method to the type
system, which returns a channel element that can convert between the two
types
- integrate in the connection infrastructure
- who is doing the conversion can be decided based on the connection
"kind"
* port-to-port connections: the conversion is done by the sender
* streams: the orocos side is converting, as in this case the stream
infrastructure (e.g. ROS topics) will REQUIRE the target type.
- alternatively, the "who is converting" can be made part of the
policy. I don't personally see the point, however, as the acceptable
types is already constrained by the actual IPC channel used (see ROS
topic example above).
Proposal: conversion elements in channels
On Tuesday 20 September 2011 12:18:51 Sylvain Joyeux wrote:
> This mail is meant to propose an addition to the dataflow
> implementation: the addition of channel elements that "transform" a
> channel of type A into a channel of type B.
>
> Rationale: the purpose of these elements would be twofold
>
> 1. allow transparent interoperability between frameworks (here, my
> personal goal is the convertion between ROS and Rock types)
> 2. do type slicing, in particular start handling inheritance in the
> type system, through allowing the usage of a subclassed source to send
> data to a parent class sink (think using a Pose output port to feed an
> Orientation input).
>
> Technical solution:
>
> - add a new conversionElement(from_name, to_name) method to the type
> system, which returns a channel element that can convert between the two
> types
> - integrate in the connection infrastructure
> - who is doing the conversion can be decided based on the connection
> "kind"
> * port-to-port connections: the conversion is done by the sender
> * streams: the orocos side is converting, as in this case the stream
> infrastructure (e.g. ROS topics) will REQUIRE the target type.
> - alternatively, the "who is converting" can be made part of the
> policy. I don't personally see the point, however, as the acceptable
> types is already constrained by the actual IPC channel used (see ROS
> topic example above).
I don't see any immediate issues here. Keep an eye on the compilation times,
since we're still in a regression situation with respect to data flow ports.
I quietly wonder if it's worth the effort, since plain ROS types 'on ports' are
already supported. We don't consider a dependency on ROS core infrastructure
any more troublesome than one on Boost or CORBA (the latter ones are many
times bigger).
Peter
Proposal: conversion elements in channels
On 09/22/2011 02:23 PM, Peter Soetens wrote:
> I quietly wonder if it's worth the effort, since plain ROS types 'on ports' are
> already supported. We don't consider a dependency on ROS core infrastructure
> any more troublesome than one on Boost or CORBA (the latter ones are many
> times bigger).
Big difference: if you start using ROS types on the ports, you have a
hard dependency on ROS - your components NEED the ROS infrastructure to
just "be", and you are limited to ROS types to communicate on your
ports. In the long run, it gives people a tendency to mix their
libraries with the ROS infrastructure instead of separating the
libraries from the framework, which is a very bad thing.
Moreover, if you want to be interoperable with ROS with that solution,
you NEED everything in your system to use ROS types already. In my book,
that's not "being interoperable", it is "being the same". It achieves
the same effect if all you care about is talking to ROS, but is IMO a
bad design decision.
Proposal: conversion elements in channels
2011/9/22 Sylvain Joyeux <sylvain [dot] joyeux [..] ...>
> On 09/22/2011 02:23 PM, Peter Soetens wrote:
> > I quietly wonder if it's worth the effort, since plain ROS types 'on
> ports' are
> > already supported. We don't consider a dependency on ROS core
> infrastructure
> > any more troublesome than one on Boost or CORBA (the latter ones are many
> > times bigger).
> Big difference: if you start using ROS types on the ports, you have a
> hard dependency on ROS - your components NEED the ROS infrastructure to
> just "be", and you are limited to ROS types to communicate on your
> ports. In the long run, it gives people a tendency to mix their
> libraries with the ROS infrastructure instead of separating the
> libraries from the framework, which is a very bad thing.
>
> Moreover, if you want to be interoperable with ROS with that solution,
> you NEED everything in your system to use ROS types already. In my book,
> that's not "being interoperable", it is "being the same". It achieves
> the same effect if all you care about is talking to ROS, but is IMO a
> bad design decision.
> --
> Sylvain Joyeux (Dr.Ing.)
> Space & Security Robotics
>
> !!! Achtung, neue Telefonnummer!!!
>
> Standort Bremen:
> DFKI GmbH
> Robotics Innovation Center
> Robert-Hooke-Straße 5
> 28359 Bremen, Germany
>
> Phone: +49 (0)421 178-454136
> Fax: +49 (0)421 218-454150
> E-Mail: robotik [..] ...
>
> 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
> -----------------------------------------------------------------------
> --
> Orocos-Dev mailing list
> Orocos-Dev [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>
I agree with Sylvian here; I would like my app to be able to talk to ROS
without depending on it.
Theo.
Proposal: conversion elements in channels
2011/9/23 Vries, Theo J.A. de [imotec bv] <t [dot] j [dot] a [dot] devries [..] ...>
>
>
> 2011/9/22 Sylvain Joyeux <sylvain [dot] joyeux [..] ...>
>
>> On 09/22/2011 02:23 PM, Peter Soetens wrote:
>> > I quietly wonder if it's worth the effort, since plain ROS types 'on
>> ports' are
>> > already supported. We don't consider a dependency on ROS core
>> infrastructure
>> > any more troublesome than one on Boost or CORBA (the latter ones are
>> many
>> > times bigger).
>> Big difference: if you start using ROS types on the ports, you have a
>> hard dependency on ROS - your components NEED the ROS infrastructure to
>> just "be", and you are limited to ROS types to communicate on your
>> ports. In the long run, it gives people a tendency to mix their
>> libraries with the ROS infrastructure instead of separating the
>> libraries from the framework, which is a very bad thing.
>>
>> Moreover, if you want to be interoperable with ROS with that solution,
>> you NEED everything in your system to use ROS types already. In my book,
>> that's not "being interoperable", it is "being the same". It achieves
>> the same effect if all you care about is talking to ROS, but is IMO a
>> bad design decision.
>> --
>> Sylvain Joyeux (Dr.Ing.)
>> Space & Security Robotics
>>
>> !!! Achtung, neue Telefonnummer!!!
>>
>> Standort Bremen:
>> DFKI GmbH
>> Robotics Innovation Center
>> Robert-Hooke-Straße 5
>> 28359 Bremen, Germany
>>
>> Phone: +49 (0)421 178-454136
>> Fax: +49 (0)421 218-454150
>> E-Mail: robotik [..] ...
>>
>> 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
>> -----------------------------------------------------------------------
>> --
>> Orocos-Dev mailing list
>> Orocos-Dev [..] ...
>> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>>
>
> I agree with Sylvian here; I would like my app to be able to talk to ROS
> without depending on it.
> Theo.
>
+1
>
> --
> Orocos-Dev mailing list
> Orocos-Dev [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>
>