Extending RTT into Other Middlewares

I know RTT has ties into Corba, ROS, and YARP for extending the reach of Orocos components into distributed systems. We would like to further extend RTT into other middlewares, like DDS and/or ZeroMQ. Is there a guide somewhere for how this should be done, or should I just look at the existing extensions and improvise?

--
Dustin Gooding

Extending RTT into Other Middlewares

Hi,

Gitorious hosts the "Orocos communication" project (
https://gitorious.org/orocos-communication), that for the moment only
contains the Yarp transport.

The code of a communication layer is then clearly isolated from the core RTT
code.

Do not hesitate in hosting and managing your code on a new repository on the
project (ask any Orocos maintainer to create a new repository).

Charles.

2011/7/29 Gooding, Dustin R. (JSC-ER411) <dustin [dot] r [dot] gooding [..] ...>

> I know RTT has ties into Corba, ROS, and YARP for extending the reach of
> Orocos components into distributed systems. We would like to further extend
> RTT into other middlewares, like DDS and/or ZeroMQ. Is there a guide
> somewhere for how this should be done, or should I just look at the existing
> extensions and improvise?
>
> --**
> *Dustin Gooding*
>
> --
> Orocos-Users mailing list
> Orocos-Users [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>
>

Extending RTT into Other Middlewares

On Fri, 29 Jul 2011, Gooding, Dustin R. (JSC-ER411) wrote:

> I know RTT has ties into Corba, ROS, and YARP for extending the reach of
> Orocos components into distributed systems.  We would like to further extend
> RTT into other middlewares, like DDS and/or ZeroMQ.  Is there a guide
> somewhere for how this should be done, or should I just look at the existing
> extensions and improvise?

A group in Bonn-Rhine-Sieg University near Bonn, Germany, is doing a
similar effort with ZeroMQ nowadays. (There has been one or two messages
about that on orocos-dev...)

I would like to keep the middleware stuff _completely_ out of the RTT
source tree.

The way to go, in my opinion, is to (finally) start a decent discussion on
orocos-dev about how this _should_ be done, since all efforts until know
have been very ad hoc. (By lack of a decently _modelled_ separation of
concerns between Communication (read 'middleware') and the other concerns
(Computation, Coordination, Configuration and Connection).
A very important aspect of this serious design is how to deal with the
models for data flow, and how to integrate those models in the binaries
that are being deployed, such that they become available for introspection.

> Dustin Gooding

Herman

Extending RTT into Other Middlewares

Hello all,

we moved the discussion to "orocos-dev". See below.

>> I know RTT has ties into Corba, ROS, and YARP for extending the reach of
>> Orocos components into distributed systems. We would like to further extend
>> RTT into other middlewares, like DDS and/or ZeroMQ. Is there a guide
>> somewhere for how this should be done, or should I just look at the existing
>> extensions and improvise?
>
> A group in Bonn-Rhine-Sieg University near Bonn, Germany, is doing a
> similar effort with ZeroMQ nowadays. (There has been one or two messages
> about that on orocos-dev...)

Indeed. By that means we start with the discussion.

>
> I would like to keep the middleware stuff _completely_ out of the RTT
> source tree.
>

Agree.

> The way to go, in my opinion, is to (finally) start a decent discussion on
> orocos-dev about how this _should_ be done, since all efforts until know
> have been very ad hoc. (By lack of a decently _modelled_ separation of
> concerns between Communication (read 'middleware') and the other concerns
> (Computation, Coordination, Configuration and Connection).
> A very important aspect of this serious design is how to deal with the
> models for data flow, and how to integrate those models in the binaries
> that are being deployed, such that they become available for introspection.
>

We have posted this a while ago that we started to work on a ZeroMQ
integration to Orocos. We still have to tackle some conceptual issues
which we would like to communicate to the Orocos developers now.

The main goal which we want to achieve is to make all choices
concerning communication in distributed systems *explicit* and
*accessible* for the
system integrator. Moreover, the framework itself (in our case Orocos) should
not constrain the available functionality provided by a middleware.

(1) Use case: a user might want to use ZeroMQ as a communication
library, Google protocol buffer for message definition and
marshalling, and some ZeroConf implementation for service discovery
within the framework (e.g. Orocos). We call this the available "points
of variation" or "protocol stack view" (including service discovery,
IDL, messaging, and transport) and
we showed in our recent IROS paper that such a separation would allow
to improve a system with respect to quality attributes, e.g.
scalability. As an example we proved this concept by a naive
implementation with ZeroMQ plus custom marshalling.

(2) Use case: a user might want to use ZeroMQ features (e.g. software
network devices like Brokers or Proxies) in Orocos.

Now the question is how do we support these use cases in Orocos and
the current Orocos toolchain? Further, how should these aspects be
decoupled from RTT?

IMHO the first use case is right now quite tough to implement because
it would require several changes for the toolchain (e.g. orogen and
typegen). A naive implementation for the second use case would be to
provide standalone Orocos components providing only that special
functionality (e.g. Brokers). That would be similar to the TaskBrowser
and Deployer components already provided by OCL.

Nico & Azamat

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

Extending RTT into Other Middlewares

Hello all,

we moved the discussion to "orocos-dev". See below.

>> I know RTT has ties into Corba, ROS, and YARP for extending the reach of
>> Orocos components into distributed systems. We would like to further extend
>> RTT into other middlewares, like DDS and/or ZeroMQ. Is there a guide
>> somewhere for how this should be done, or should I just look at the existing
>> extensions and improvise?
>
> A group in Bonn-Rhine-Sieg University near Bonn, Germany, is doing a
> similar effort with ZeroMQ nowadays. (There has been one or two messages
> about that on orocos-dev...)

Indeed. By that means we start with the discussion.

>
> I would like to keep the middleware stuff _completely_ out of the RTT
> source tree.
>

Agree.

> The way to go, in my opinion, is to (finally) start a decent discussion on
> orocos-dev about how this _should_ be done, since all efforts until know
> have been very ad hoc. (By lack of a decently _modelled_ separation of
> concerns between Communication (read 'middleware') and the other concerns
> (Computation, Coordination, Configuration and Connection).
> A very important aspect of this serious design is how to deal with the
> models for data flow, and how to integrate those models in the binaries
> that are being deployed, such that they become available for introspection.
>

We have posted this a while ago that we started to work on a ZeroMQ
integration to Orocos. We still have to tackle some conceptual issues
which we would like to communicate to the Orocos developers now.

The main goal which we want to achieve is to make all choices
concerning communication in distributed systems *explicit* and
*accessible* for the
system integrator. Moreover, the framework itself (in our case Orocos) should
not constrain the available functionality provided by a middleware.

(1) Use case: a user might want to use ZeroMQ as a communication
library, Google protocol buffer for message definition and
marshalling, and some ZeroConf implementation for service discovery
within the framework (e.g. Orocos). We call this the available "points
of variation" or "protocol stack view" (including service discovery,
IDL, messaging, and transport) and
we showed in our recent IROS paper that such a separation would allow
to improve a system with respect to quality attributes, e.g.
scalability. As an example we proved this concept by a naive
implementation with ZeroMQ plus custom marshalling.

(2) Use case: a user might want to use ZeroMQ features (e.g. software
network devices like Brokers or Proxies) in Orocos.

Now the question is how do we support these use cases in Orocos and
the current Orocos toolchain? Further, how should these aspects be
decoupled from RTT?

IMHO the first use case is right now quite tough to implement because
it would require several changes for the toolchain (e.g. orogen and
typegen). A naive implementation for the second use case would be to
provide standalone Orocos components providing only that special
functionality (e.g. Brokers). That would be similar to the TaskBrowser
and Deployer components already provided by OCL.

Nico & Azamat

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

Extending RTT into Other Middlewares

On 07/29/2011 05:26 PM, Nico Hochgeschwender wrote:
> IMHO the first use case is right now quite tough to implement because
> it would require several changes for the toolchain (e.g. orogen and
> typegen).
I don't see a major difficulty right there. orogen uses an intermediate
representation for its types, so as long as the IDL can be represented
in this intermediate representation ("value types" most likely can),
that won't be a problem.

We are thinking of ways to bridge ROS messages to rock C++ types
automatically. Your use case would be related.

Extending RTT into Other Middlewares

On 07/29/2011 05:26 PM, Nico Hochgeschwender wrote:
> IMHO the first use case is right now quite tough to implement because
> it would require several changes for the toolchain (e.g. orogen and
> typegen).
I don't see a major difficulty right there. orogen uses an intermediate
representation for its types, so as long as the IDL can be represented
in this intermediate representation ("value types" most likely can),
that won't be a problem.

We are thinking of ways to bridge ROS messages to rock C++ types
automatically. Your use case would be related.