[prev in list] [next in list] [prev in thread] [next in thread] 

List:       orocos-dev
Subject:    [Orocos-Dev] Proposal: conversion elements in channels
From:       Herman.Bruyninckx () mech ! kuleuven ! be (Herman Bruyninckx)
Date:       2011-09-23 9:01:47
Message-ID: alpine.DEB.2.02.1109231057180.13176 () roble
[Download RAW message or body]

On Fri, 23 Sep 2011, Ruben Smits wrote:

> On Thursday 22 September 2011 14:35:05 Sylvain Joyeux wrote:
>> 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.
>
> Just because you use ROS types on some of your ports does not mean you are
> limited to only ROS types. That's a bridge too far IMHO, and not true, we have
> several components with a mixture of non-ROS typed.

I agree here: it is not relevant _where_ the (model of) your data port
comes from, the important thing is what RTT has to support you doing with
those data models. In other words, if you decouple the tool chain(s) you use
from the outputs of those tool chain(s), you should be fine.

> BTW, if you want your
> component to be interoperable with ROS, then what wrong with depending on ROS.
> It's just some bash-tools and python scritps. That's basically it. They have
> seperated out all the middleware specific stuff already out of the core ros
> stack/debian package.
>
>> 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.
>
> That's the people's responsibility . At the moment you start writing
> components you actually already left the library implementation, I'm not
> saying you should use ROS types in your library, but I don't see any harm in
> using them in your component implementation.

Agreed.

>> 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.
>
> I totally disagree here,

Me too: you are assuming that a tool chain can not be separated from what
it generates, and that is only the case in very badly designed tool chains,
or in tool chains that don't _want_ you to decouple things, like Simulink
etc. Maybe ROS _was_ of the latter type (and some people are still using it
in this way) but it is moving more and more in the "right", decoupled
direction.

> IMO the first thing you have to do if you want to
> interoperate with another framework is to agree on the data you want to
> exchange, and how this data looks like. Using ROS types is just about agreeing
> on the data. And nothing more.
>
> -- Ruben

Herman

[prev in list] [next in list] [prev in thread] [next in thread]