ROS & DDS

classic Classic list List threaded Threaded
82 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

ROS & DDS

Brian Gerkey-3
hi,

As we work on improving the communications middleware within ROS, one
of the approaches that has come up repeatedly is DDS (Data
Distribution Service; http://portals.omg.org/dds/).  There are lots of
positive aspects of DDS as a middleware, and of course some tradeoffs
(e.g., in exchange for lots of features in the message transport, the
API is incredibly verbose; while there are open source
implementations, there's not the feeling of an active community doing
development on them).

We'd like to understand what the level of interest is within the ROS
community for DDS support.

So, for those of you who already know something about DDS (especially
if you have experience using it), here are some questions to start a
discussion.  Don't feel obliged to answer every question, and also
feel free to answer questions not asked here.  If you prefer, you can
reply directly to me, and we'll anonymize your comments before
potentially sharing them.

What's your opinion of DDS (good, bad, ugly, other)?  If you like DDS,
why?  If you don't like it, why not?

How would you compare DDS to the ROS middleware?

Do you see others in your field using DDS?  Have you ever wished that
ROS could "speak DDS"?  Have you already used DDS in combination with
ROS?

thanks,
brian.
_______________________________________________
ros-users mailing list
[hidden email]
http://lists.ros.org/mailman/listinfo/ros-users
Reply | Threaded
Open this post in threaded view
|

Re: ROS & DDS

Dr. Markus Eich
Hi Brian,

we have extensively used DDS in combination with ROS. What we basically
did is to implement ROS<=>DDS proxies which are pushing topics to the
DDS cloud and
vice versa. The advantage we see in using DDS is the quality of service
(e.g. that it can be assured that no data is lost, even if the
connection fails.).
another advantage using ROS-DDS proxies is that the very same code can
be run without running DDS (only that the robot does not receive other
messages).

In our experiments, we used localized laser scans in a multi-robot
scenario using graph-based slam approaches. Each robots uses its own
roscore and the shared DDS topics (coming from other robots) to generate
a common map during our distributed exploration approach.

In this scenario it would be critical, if scans are lost and not added
to the pose graph. If the WiFi connection breaks down all scans are
buffered by the DDS cloud and re-sent once the connection is re-established.

Our JFR  paper, where we used ROS with DDS can be found here:

http://onlinelibrary.wiley.com/doi/10.1002/rob.21491/abstract

We used the Prismtech implementation of DDS which also provide an
academic license.

Only drawback with DDS is that it is somewhat hard to set up with all
the parameters, especially if you have no expensive enterprise edition
(including support).
Maybe there are other implementations of DDS.

More detailed questions related to DDS can be send directly to me ;-)

Cheers,

Markus


Am 12.02.2014 17:56, schrieb Brian Gerkey:

> hi,
>
> As we work on improving the communications middleware within ROS, one
> of the approaches that has come up repeatedly is DDS (Data
> Distribution Service; http://portals.omg.org/dds/).  There are lots of
> positive aspects of DDS as a middleware, and of course some tradeoffs
> (e.g., in exchange for lots of features in the message transport, the
> API is incredibly verbose; while there are open source
> implementations, there's not the feeling of an active community doing
> development on them).
>
> We'd like to understand what the level of interest is within the ROS
> community for DDS support.
>
> So, for those of you who already know something about DDS (especially
> if you have experience using it), here are some questions to start a
> discussion.  Don't feel obliged to answer every question, and also
> feel free to answer questions not asked here.  If you prefer, you can
> reply directly to me, and we'll anonymize your comments before
> potentially sharing them.
>
> What's your opinion of DDS (good, bad, ugly, other)?  If you like DDS,
> why?  If you don't like it, why not?
>
> How would you compare DDS to the ROS middleware?
>
> Do you see others in your field using DDS?  Have you ever wished that
> ROS could "speak DDS"?  Have you already used DDS in combination with
> ROS?
>
> thanks,
> brian.
> _______________________________________________
> ros-users mailing list
> [hidden email]
> http://lists.ros.org/mailman/listinfo/ros-users


--
 Dr.-Ing. Markus Eich

 Project Management
 Marine Inspection Robotics
 Space Robotics
 
 Besuchsadresse der Nebengeschäftstelle:
 DFKI GmbH
 Robotics Innovation Center
 Robert-Hooke-Straße 5
 28359 Bremen, Germany
 
 Postadresse der Hauptgeschäftsstelle Standort Bremen:
 DFKI GmbH
 Robotics Innovation Center
 Robert-Hooke-Straße 1
 28359 Bremen, Germany

 Tel.:     +49 421 178 45-4105
 Zentrale: +49 421 178 45-0
 Fax:      +49 421 178 45-4150 (Faxe bitte namentlich kennzeichnen)
 E-Mail:   [hidden email]

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

_______________________________________________
ros-users mailing list
[hidden email]
http://lists.ros.org/mailman/listinfo/ros-users
Reply | Threaded
Open this post in threaded view
|

Re: ROS & DDS

Armstrong-Crews, Nicholas - 1002 - MITLL
In reply to this post by Brian Gerkey-3
This is an important topic, but I don't personally have any DDS experience.
Instead, I'm forwarding comments from our DDS guy... who also has experience
with ROS and many other middlewares.

Thanks,
-Nick

-----Original Message-----
From: Daniel Herring [mailto:[hidden email]]
Sent: Wednesday, February 12, 2014 1:16 PM
To: Armstrong-Crews, Nicholas - 1002 - MITLL
Subject: Re: FW: [ros-users] ROS & DDS

On Wed, 12 Feb 2014, Armstrong-Crews, Nicholas - 1002 - MITLL wrote:

> Any comments for the gods of ROS?

Hi Nick,

Its a no-brainer.  Go for it.  The strength of ROS is in its body of modules
and the messages connecting them, not its middleware.  DDS is gaining
momentum for good technical reasons.


RTI and PrismTech both have good, freely available implementations for MSWin
and Linux.  Establish ROS as an "infrastructure community" with RTI.
Just download the LGPL packages from PrismTech.  Many other players from IBM
to Twin Oaks have commercial DDS implementations.  OCI DDS was a build
nightmare and nearly unusable when the "first usable release" came out
roughly 7 years ago; I've heard it has improved since then but is still
feature poor.

http://www.rti.com/products/licensing/infrastructure-community.html

http://www.prismtech.com/opensplice/products/opensplice-community


Other communications middlewares like JMS or {Active,Zero,*}MQ have
proponents but really aren't appreciably better than DDS.  DDS is king
because of the range of QoS options it supports, a long history of users and
standards documents refining rough edges, and a growing body of industry
support.  I expect the opensource community will eventually stop toying with
these ideas and start writing DDS implementations.

(As an analogy, I view these other middlewares as being like GNU Hurd or
Plan 9 and view DDS as being like Unix/Linux.  The other OSes have some good
features, but Linux has a complete, proven package.  DDS is one of the few
middlewares to have a proper standard, with independent implementations.
Most just have a single reference implementation, with some documentation on
how it works.  The difference in design maturity is
considerable.)


Regarding the DDS API:  Nobody likes the full API.  Most companies (LL
included) start by writing a library that insulates the user from all the
factory and QoS boilerplate.  There is a new C++ DDS API that should be much
simpler.  The vendors also have added (vendor specific) config files that
can replace all the tedious QoS API calls.  ROS should be able to hide all
this behind a few simple API calls, possibly with some DDS-specific config
files.


Regarding IDL:  Meh, it works but is not very special unless you need OMG
CORBA legacy support.  They recently added support for dynamically
extensible data types -- not widely available or used yet.

Switching existing ROS messages to IDL would be a big breaking change with
little benefit.  It is probably easier to put the ROS-encoded message in a
"sequence<octet,MAX_LENGTH>" IDL message packet.  Putting an integer key
before this sequence value allows sending multiple data types over a single
topic (DDS enforces 1:1).  The opaque encoding does defeat some DDS
features; but these can be supported by adding/copying a few fields out of
the sequence and into the IDL.  Overhead for this approach should be
comparable to a memcpy of the sequence length (i.e. negligible in most
cases).

Whether new ROS messages should use IDL or the current ROS approach is a
separate but related question.  There are benefits to separating the
encoding from the transport.  For example, it makes it easier to save
messages to disk and maintains compatibility with existing ROS message
inspection tools.  DDS only exposes unpacked data structures.  The separate
encoding may also simplify support for languages that DDS doesn't support;
do the serialization in the niche language and just pass byte arrays to the
foreign function interface.


Later,
Daniel



> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Brian Gerkey
> Sent: Wednesday, February 12, 2014 11:57 AM
> To: User discussions
> Subject: [ros-users] ROS & DDS
>
> hi,
>
> As we work on improving the communications middleware within ROS, one
> of the approaches that has come up repeatedly is DDS (Data
> Distribution Service; http://portals.omg.org/dds/).  There are lots of
> positive aspects of DDS as a middleware, and of course some tradeoffs
> (e.g., in exchange for lots of features in the message transport, the
> API is incredibly verbose; while there are open source
> implementations, there's not the feeling of an active community doing
development on them).
>
> We'd like to understand what the level of interest is within the ROS
> community for DDS support.
>
> So, for those of you who already know something about DDS (especially
> if you have experience using it), here are some questions to start a
discussion.
> Don't feel obliged to answer every question, and also feel free to
> answer questions not asked here.  If you prefer, you can reply
> directly to me, and we'll anonymize your comments before potentially
sharing them.
>
> What's your opinion of DDS (good, bad, ugly, other)?  If you like DDS,
why?

> If you don't like it, why not?
>
> How would you compare DDS to the ROS middleware?
>
> Do you see others in your field using DDS?  Have you ever wished that
> ROS could "speak DDS"?  Have you already used DDS in combination with ROS?
>
> thanks,
> brian.
> _______________________________________________
> ros-users mailing list
> [hidden email]
> http://lists.ros.org/mailman/listinfo/ros-users
>

_______________________________________________
ros-users mailing list
[hidden email]
http://lists.ros.org/mailman/listinfo/ros-users

smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: ROS & DDS

Brian Gerkey-3
Thanks, Markus, Nick, and Daniel!

More feedback is most welcome.

On Wed, Feb 12, 2014 at 11:51 AM, Armstrong-Crews, Nicholas - 1002 -
MITLL <[hidden email]> wrote:

> This is an important topic, but I don't personally have any DDS experience.
> Instead, I'm forwarding comments from our DDS guy... who also has experience
> with ROS and many other middlewares.
>
> Thanks,
> -Nick
>
> -----Original Message-----
> From: Daniel Herring [mailto:[hidden email]]
> Sent: Wednesday, February 12, 2014 1:16 PM
> To: Armstrong-Crews, Nicholas - 1002 - MITLL
> Subject: Re: FW: [ros-users] ROS & DDS
>
> On Wed, 12 Feb 2014, Armstrong-Crews, Nicholas - 1002 - MITLL wrote:
>
>> Any comments for the gods of ROS?
>
> Hi Nick,
>
> Its a no-brainer.  Go for it.  The strength of ROS is in its body of modules
> and the messages connecting them, not its middleware.  DDS is gaining
> momentum for good technical reasons.
>
>
> RTI and PrismTech both have good, freely available implementations for MSWin
> and Linux.  Establish ROS as an "infrastructure community" with RTI.
> Just download the LGPL packages from PrismTech.  Many other players from IBM
> to Twin Oaks have commercial DDS implementations.  OCI DDS was a build
> nightmare and nearly unusable when the "first usable release" came out
> roughly 7 years ago; I've heard it has improved since then but is still
> feature poor.
>
> http://www.rti.com/products/licensing/infrastructure-community.html
>
> http://www.prismtech.com/opensplice/products/opensplice-community
>
>
> Other communications middlewares like JMS or {Active,Zero,*}MQ have
> proponents but really aren't appreciably better than DDS.  DDS is king
> because of the range of QoS options it supports, a long history of users and
> standards documents refining rough edges, and a growing body of industry
> support.  I expect the opensource community will eventually stop toying with
> these ideas and start writing DDS implementations.
>
> (As an analogy, I view these other middlewares as being like GNU Hurd or
> Plan 9 and view DDS as being like Unix/Linux.  The other OSes have some good
> features, but Linux has a complete, proven package.  DDS is one of the few
> middlewares to have a proper standard, with independent implementations.
> Most just have a single reference implementation, with some documentation on
> how it works.  The difference in design maturity is
> considerable.)
>
>
> Regarding the DDS API:  Nobody likes the full API.  Most companies (LL
> included) start by writing a library that insulates the user from all the
> factory and QoS boilerplate.  There is a new C++ DDS API that should be much
> simpler.  The vendors also have added (vendor specific) config files that
> can replace all the tedious QoS API calls.  ROS should be able to hide all
> this behind a few simple API calls, possibly with some DDS-specific config
> files.
>
>
> Regarding IDL:  Meh, it works but is not very special unless you need OMG
> CORBA legacy support.  They recently added support for dynamically
> extensible data types -- not widely available or used yet.
>
> Switching existing ROS messages to IDL would be a big breaking change with
> little benefit.  It is probably easier to put the ROS-encoded message in a
> "sequence<octet,MAX_LENGTH>" IDL message packet.  Putting an integer key
> before this sequence value allows sending multiple data types over a single
> topic (DDS enforces 1:1).  The opaque encoding does defeat some DDS
> features; but these can be supported by adding/copying a few fields out of
> the sequence and into the IDL.  Overhead for this approach should be
> comparable to a memcpy of the sequence length (i.e. negligible in most
> cases).
>
> Whether new ROS messages should use IDL or the current ROS approach is a
> separate but related question.  There are benefits to separating the
> encoding from the transport.  For example, it makes it easier to save
> messages to disk and maintains compatibility with existing ROS message
> inspection tools.  DDS only exposes unpacked data structures.  The separate
> encoding may also simplify support for languages that DDS doesn't support;
> do the serialization in the niche language and just pass byte arrays to the
> foreign function interface.
>
>
> Later,
> Daniel
>
>
>
>> -----Original Message-----
>> From: [hidden email]
>> [mailto:[hidden email]] On Behalf Of Brian Gerkey
>> Sent: Wednesday, February 12, 2014 11:57 AM
>> To: User discussions
>> Subject: [ros-users] ROS & DDS
>>
>> hi,
>>
>> As we work on improving the communications middleware within ROS, one
>> of the approaches that has come up repeatedly is DDS (Data
>> Distribution Service; http://portals.omg.org/dds/).  There are lots of
>> positive aspects of DDS as a middleware, and of course some tradeoffs
>> (e.g., in exchange for lots of features in the message transport, the
>> API is incredibly verbose; while there are open source
>> implementations, there's not the feeling of an active community doing
> development on them).
>>
>> We'd like to understand what the level of interest is within the ROS
>> community for DDS support.
>>
>> So, for those of you who already know something about DDS (especially
>> if you have experience using it), here are some questions to start a
> discussion.
>> Don't feel obliged to answer every question, and also feel free to
>> answer questions not asked here.  If you prefer, you can reply
>> directly to me, and we'll anonymize your comments before potentially
> sharing them.
>>
>> What's your opinion of DDS (good, bad, ugly, other)?  If you like DDS,
> why?
>> If you don't like it, why not?
>>
>> How would you compare DDS to the ROS middleware?
>>
>> Do you see others in your field using DDS?  Have you ever wished that
>> ROS could "speak DDS"?  Have you already used DDS in combination with ROS?
>>
>> thanks,
>> brian.
>> _______________________________________________
>> ros-users mailing list
>> [hidden email]
>> http://lists.ros.org/mailman/listinfo/ros-users
>>
>
> _______________________________________________
> ros-users mailing list
> [hidden email]
> http://lists.ros.org/mailman/listinfo/ros-users
>
_______________________________________________
ros-users mailing list
[hidden email]
http://lists.ros.org/mailman/listinfo/ros-users
Reply | Threaded
Open this post in threaded view
|

Re: ROS & DDS

Jack O'Quin

On Wed, Feb 12, 2014 at 4:09 PM, Brian Gerkey <[hidden email]> wrote:
Thanks, Markus, Nick, and Daniel!

More feedback is most welcome.

I am curious to hear from anyone with experience using DDS on low-end micro-controllers or embedded systems. 

Is it feasible to create firmware with a DDS interface for ROS messages?
-- 
 joq

_______________________________________________
ros-users mailing list
[hidden email]
http://lists.ros.org/mailman/listinfo/ros-users
Reply | Threaded
Open this post in threaded view
|

Re: ROS & DDS

Geoffrey Biggs
On 13 February 2014 08:47, Jack O'Quin <[hidden email]> wrote:
I am curious to hear from anyone with experience using DDS on low-end micro-controllers or embedded systems. 

Is it feasible to create firmware with a DDS interface for ROS messages?

RTI has a small-footprint implementation for embedded systems. I haven't used it so I can't comment on how good (or how small) it is, but they are at least aware of the need.

Geoff 

_______________________________________________
ros-users mailing list
[hidden email]
http://lists.ros.org/mailman/listinfo/ros-users
Reply | Threaded
Open this post in threaded view
|

Re: ROS & DDS

Geoffrey Biggs
In reply to this post by Brian Gerkey-3
On 13 February 2014 01:56, Brian Gerkey <[hidden email]> wrote:
So, for those of you who already know something about DDS (especially
if you have experience using it), here are some questions to start a
discussion.  Don't feel obliged to answer every question, and also
feel free to answer questions not asked here.  If you prefer, you can
reply directly to me, and we'll anonymize your comments before
potentially sharing them.

What's your opinion of DDS (good, bad, ugly, other)?  If you like DDS,
why?  If you don't like it, why not?

How would you compare DDS to the ROS middleware?

Do you see others in your field using DDS?  Have you ever wished that
ROS could "speak DDS"?  Have you already used DDS in combination with
ROS?

We have quite a bit of experience with DDS here, both from using it and from sitting in some of the meetings where the standards are defined (although often "argued over" may be a better term).

DDS is the state-of-the-art. The features available make it ideally suitable for robotics. I cannot think of any good reason not to use DDS unless you are only dealing with a single computing node, and even then only if the cost of serialisation is too high and you don't want features such as QoS, logging and introspection. The QoS features alone make DDS a must-have in many applications (fun fact: Robonaut talks DDS between the ISS and the ground - apparently RTI initially couldn't understand the need to support a one minute latency).

DDS is standardised at both the API level (the C++ API is quite nice to use, in my opinion) and at the wire level, meaning any conforming implementation has compatibility with any other. I have seen at least five independent implementations all talking at once. Although vendors obviously add their own extensions to the C++ API, we have found that they tend to be focused on API simplicity over new features.

The parameter tuning is important if the defaults don't do what you need, but it is nothing new to anyone who's had to tune network performance, especially in a wifi environment. Specifying QoS parameters in an XML file is standardised now, so all implementations do or shortly will support it. This is extremely useful; you can save different profiles for different links and load them dynamically depending on what sort of deployment you do.

Using DDS instead of a home-grown transport, whether the existing one or a new one, would mean an instant boost in compatibility with non-ROS systems.

There are some open-source implementations available, such as the actually open OpenDDS (which uses CORBA, specifically TAO, internally), and PrismTech's OpenSplice DDS. Then there are the we-pretend-to-be-open ones such as RTI Connext DDS. Most of our experience is with the RTI one - the tools they provide are incredibly useful.

RTI has a page listing some of their academic license uses. The number of them doing robotics is telling, as is the number of those that are field applications.


Geoff

_______________________________________________
ros-users mailing list
[hidden email]
http://lists.ros.org/mailman/listinfo/ros-users
Reply | Threaded
Open this post in threaded view
|

Re: ROS & DDS

Brian Gerkey-3
In reply to this post by Geoffrey Biggs
On Wed, Feb 12, 2014 at 4:54 PM, Geoffrey Biggs
<[hidden email]> wrote:

> On 13 February 2014 08:47, Jack O'Quin <[hidden email]> wrote:
>>
>> I am curious to hear from anyone with experience using DDS on low-end
>> micro-controllers or embedded systems.
>>
>> Is it feasible to create firmware with a DDS interface for ROS messages?
>
>
> RTI has a small-footprint implementation for embedded systems. I haven't
> used it so I can't comment on how good (or how small) it is, but they are at
> least aware of the need.

There's also a small-footprint implementation from Twin Oaks, intended
for use in embedded systems (I haven't tried it):
http://www.twinoakscomputing.com/coredx/coredx_size

Anybody know whether a minimal DDS implementation can be done in
hardware (e.g., VHDL)?

brian.
_______________________________________________
ros-users mailing list
[hidden email]
http://lists.ros.org/mailman/listinfo/ros-users
Reply | Threaded
Open this post in threaded view
|

Re: ROS & DDS

Geoffrey Biggs
On 13 February 2014 11:23, Brian Gerkey <[hidden email]> wrote:
On Wed, Feb 12, 2014 at 4:54 PM, Geoffrey Biggs
<[hidden email]> wrote:
> On 13 February 2014 08:47, Jack O'Quin <[hidden email]> wrote:
>>
>> I am curious to hear from anyone with experience using DDS on low-end
>> micro-controllers or embedded systems.
>>
>> Is it feasible to create firmware with a DDS interface for ROS messages?
>
>
> RTI has a small-footprint implementation for embedded systems. I haven't
> used it so I can't comment on how good (or how small) it is, but they are at
> least aware of the need.

There's also a small-footprint implementation from Twin Oaks, intended
for use in embedded systems (I haven't tried it):
http://www.twinoakscomputing.com/coredx/coredx_size

Anybody know whether a minimal DDS implementation can be done in
hardware (e.g., VHDL)?

You could certainly do the wire protocol in hardware. The QoS features could be done provided you know what data types will be used in advance so buffers can be allocated (software implementations have the same restriction when real-time communication is used), but I don't think it would be easy or pretty.

Geoff 

_______________________________________________
ros-users mailing list
[hidden email]
http://lists.ros.org/mailman/listinfo/ros-users
Reply | Threaded
Open this post in threaded view
|

Re: ROS & DDS

Paul Bouchier
In reply to this post by Brian Gerkey-3
We evaluated the Twin Oaks implementation on a group of PowerPCs at my last
company. It took a couple of months to set up, and once it was going we
found it had about the same response time as a socket connection for "once
in a while" messages. This makes sense, because that's what it uses under
the hood. Of course it brings lots of other features that you don't get with
your home-grown socket connection, and that's really the value it brings.
However, I can report that on a relatively simple application it worked fine
on largish embedded powerpc systems (512MB RAM, 1GB flash, 700MHz CPU
class).

Regards

Paul Bouchier

> -----Original Message-----
> From: [hidden email] [mailto:ros-users-
> [hidden email]] On Behalf Of Brian Gerkey
> Sent: Wednesday, February 12, 2014 7:23 PM
> To: User discussions
> Subject: Re: [ros-users] ROS & DDS
>
> On Wed, Feb 12, 2014 at 4:54 PM, Geoffrey Biggs
> <[hidden email]> wrote:
> > On 13 February 2014 08:47, Jack O'Quin <[hidden email]> wrote:
> >>
> >> I am curious to hear from anyone with experience using DDS on low-end
> >> micro-controllers or embedded systems.
> >>
> >> Is it feasible to create firmware with a DDS interface for ROS
messages?

> >
> >
> > RTI has a small-footprint implementation for embedded systems. I
> > haven't used it so I can't comment on how good (or how small) it is,
> > but they are at least aware of the need.
>
> There's also a small-footprint implementation from Twin Oaks, intended for
> use in embedded systems (I haven't tried it):
> http://www.twinoakscomputing.com/coredx/coredx_size
>
> Anybody know whether a minimal DDS implementation can be done in
> hardware (e.g., VHDL)?
>
> brian.
> _______________________________________________
> ros-users mailing list
> [hidden email]
> http://lists.ros.org/mailman/listinfo/ros-users

_______________________________________________
ros-users mailing list
[hidden email]
http://lists.ros.org/mailman/listinfo/ros-users
Reply | Threaded
Open this post in threaded view
|

Re: ROS & DDS

Ingo Lütkebohle-2
In reply to this post by Brian Gerkey-3
Well, to say this up-front, I think it would be a smart move to get
out of the middleware game by using something proven. It saves a lot
of time and development effort.

Regarding DDS, my personal exposure has been very limited. We're not
using it ourselves, and I don't know anybody using it (well, except
for Geoff of course, who might also be a good guy to ask about this,
see https://github.com/gbiggs/rtmdds)

That said, I've done a comparison between ORTE
(http://orte.sourceforge.net/) and ZeroMQ (http://zeromq.org/) once.
ORTE is not a full DDS implementation, but realizes the the Real-Time
Publish-Subscribe (RTPS) Protocol that many of the commercial DDS
vendors also speak (I believe it is currently the only protocol which
is actually interoperable). ZMQ also implements something which was
intended to become an interoperability standard, but as I understand,
that effort met some issues.

Now, I should say that is somewhat comparing apples with oranges,
because the feature-set is very different. Most importantly, ZMQ does
not provide data marshaling/unmarshaling (which we could live with),
and it also does not provide a naming and discovery service (which is
a bit annoying). Both of these are things where using a proven
middleware would be great.

I still ended up using ZMQ because I wanted a zero-copy transport, and
also -- to be honest -- because the API was so dead simple. However,
for the ROS use case, I would recommend going with something which
also supports naming and marshaling, like DDS. Maybe you could pick a
small and simple implementation like ORTE, and wrap it appropriately,
which should be a no-brainer.

On Wed, Feb 12, 2014 at 5:56 PM, Brian Gerkey <[hidden email]> wrote:

> hi,
>
> As we work on improving the communications middleware within ROS, one
> of the approaches that has come up repeatedly is DDS (Data
> Distribution Service; http://portals.omg.org/dds/).  There are lots of
> positive aspects of DDS as a middleware, and of course some tradeoffs
> (e.g., in exchange for lots of features in the message transport, the
> API is incredibly verbose; while there are open source
> implementations, there's not the feeling of an active community doing
> development on them).
>
> We'd like to understand what the level of interest is within the ROS
> community for DDS support.
>
> So, for those of you who already know something about DDS (especially
> if you have experience using it), here are some questions to start a
> discussion.  Don't feel obliged to answer every question, and also
> feel free to answer questions not asked here.  If you prefer, you can
> reply directly to me, and we'll anonymize your comments before
> potentially sharing them.
>
> What's your opinion of DDS (good, bad, ugly, other)?  If you like DDS,
> why?  If you don't like it, why not?
>
> How would you compare DDS to the ROS middleware?
>
> Do you see others in your field using DDS?  Have you ever wished that
> ROS could "speak DDS"?  Have you already used DDS in combination with
> ROS?
>
> thanks,
> brian.
> _______________________________________________
> ros-users mailing list
> [hidden email]
> http://lists.ros.org/mailman/listinfo/ros-users



--
Ingo Lütkebohle, Dr.-Ing.
Machine Learning and Robotics Lab, IPVS, Universität Stuttgart
http://www.ipvs.uni-stuttgart.de/abteilungen/mlr/abteilung/mitarbeiter/Ingo.Luetkebohle
+49-711-685-88350

PGP Fingerprint 3187 4DEC 47E6 1B1E 6F4F  57D4 CD90 C164 34AD CE5B
_______________________________________________
ros-users mailing list
[hidden email]
http://lists.ros.org/mailman/listinfo/ros-users
Reply | Threaded
Open this post in threaded view
|

Re: ROS & DDS

Christian Schlegel
In reply to this post by Brian Gerkey-3
Dear Brian,
  • DDS definitely is a very interesting candidate. If it comes to QoS, it is the most standardized and most advanced approach. In particular, due to the high degree of standardization, different implementations of the DDS standard can smoothly interact.

Let me give some more hints:

  • I have been wondering for a long time why robotics more or less ignored so far existing middleware standards and often comes up with solutions ignoring the achievements in the scientific community of distributed / middleware systems. That is in particular interesting since in robotics, we need the most advanced middleware systems (scalability across different H/W and OS platforms ranging from embedded to full-scale systems, QoS, partly even realtime etc.). The DDS standard deals with many of these things!
  • "freedom from choice" instead of "freedom of choice":
    • it will be decisive not just to migrate to DDS (or any other middleware) and then present the complexity of DDS ("freedom of choice") to the robotics user (configuring DDS is complex  but that is because DDS is powerful). We need to have an abstraction layer (execution container) that comprises "robotics communication patterns" ("freedom from choice") like query (request / response) and push (publish / subscribe). These provide stable interfaces to the robotics experts but can be mapped onto whatever middleware that is appropriate. Going beyond state-of-the-art would introduce QoS attributes with such communication patterns and mapping them with QoS will most likely consider DDS a very good candidate.
    • this way, you separate the "robotics communication patterns" from the middleware and ignoring that separation unfortunately has a long tradition in robotics: for very good reasons, you should not expose the complexity of CORBA, zeroMQ, ACE, ACE/TAO, DDS to the robotics user but should have framework experts that once do these mappings
  • If you are interested in such communication patterns (and how they can be mapped onto different middleware systems, but right now still without QoS), you might want have a look at the "SmartSoft communication patterns"
http://www.intechopen.com/books/robotic-systems-applications-control-and-programming/robotic-software-systems-from-code-driven-to-model-driven-software-development

Christian


Am 12.02.2014 17:56, schrieb Brian Gerkey:
hi,

As we work on improving the communications middleware within ROS, one
of the approaches that has come up repeatedly is DDS (Data
Distribution Service; http://portals.omg.org/dds/).  There are lots of
positive aspects of DDS as a middleware, and of course some tradeoffs
(e.g., in exchange for lots of features in the message transport, the
API is incredibly verbose; while there are open source
implementations, there's not the feeling of an active community doing
development on them).

We'd like to understand what the level of interest is within the ROS
community for DDS support.

So, for those of you who already know something about DDS (especially
if you have experience using it), here are some questions to start a
discussion.  Don't feel obliged to answer every question, and also
feel free to answer questions not asked here.  If you prefer, you can
reply directly to me, and we'll anonymize your comments before
potentially sharing them.

What's your opinion of DDS (good, bad, ugly, other)?  If you like DDS,
why?  If you don't like it, why not?

How would you compare DDS to the ROS middleware?

Do you see others in your field using DDS?  Have you ever wished that
ROS could "speak DDS"?  Have you already used DDS in combination with
ROS?

thanks,
brian.
_______________________________________________
ros-users mailing list
[hidden email]
http://lists.ros.org/mailman/listinfo/ros-users



-- 
Prof. Dr. Christian Schlegel
Prodekan, Studiendekan Master IS
Fakultät Informatik
Hochschule Ulm

Tel.: 0731 / 50-28242

http://www.hs-ulm.de/schlegel
http://www.servicerobotik-ulm.de/
http://www.zafh-servicerobotik.de/ (Sprecher)
http://www.youtube.com/user/roboticsathsulm
http://smart-robotics.sourceforge.net/
http://www.joser.org/

_______________________________________________
ros-users mailing list
[hidden email]
http://lists.ros.org/mailman/listinfo/ros-users

communicationpatterns.png (119K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: ROS & DDS

Daniele Calisi
I agree with Christian Schlegel on the following points:
- Configuring DDS is very complex and the effort makes sense only for big projects. I personally have an experience with DDS used in robotics and it has often be a pain to configure everything in such a way that it works as expected. If you are not a DDS expert, you can easily have configurations that perform worse than using whatever middleware.
- Let's write an abstraction layer, this is the best solution, because we are not sure how ROS middleware can perform with respect to DDS for specific robotic applications (and I see using ROS middleware much more simple for those who are just beginning with robotics, e.g., students). Moreover, we are not sure about what the future has to offer, what if we discover that a new-born middleware is better than everything for robotics and embedded systems? I personally did this for our framework OpenRDK (http://openrdk.sf.net), and, although the abstraction was not complete and sometimes requires some hacks, I was able to use OpenRDK own middleware, ROS middleware, DDS or even KDE D-Bus or HTTP, depending on the application.


On Thu, Feb 13, 2014 at 10:14 AM, Christian Schlegel <[hidden email]> wrote:
Dear Brian,
  • DDS definitely is a very interesting candidate. If it comes to QoS, it is the most standardized and most advanced approach. In particular, due to the high degree of standardization, different implementations of the DDS standard can smoothly interact.

Let me give some more hints:

  • I have been wondering for a long time why robotics more or less ignored so far existing middleware standards and often comes up with solutions ignoring the achievements in the scientific community of distributed / middleware systems. That is in particular interesting since in robotics, we need the most advanced middleware systems (scalability across different H/W and OS platforms ranging from embedded to full-scale systems, QoS, partly even realtime etc.). The DDS standard deals with many of these things!
  • "freedom from choice" instead of "freedom of choice":
    • it will be decisive not just to migrate to DDS (or any other middleware) and then present the complexity of DDS ("freedom of choice") to the robotics user (configuring DDS is complex  but that is because DDS is powerful). We need to have an abstraction layer (execution container) that comprises "robotics communication patterns" ("freedom from choice") like query (request / response) and push (publish / subscribe). These provide stable interfaces to the robotics experts but can be mapped onto whatever middleware that is appropriate. Going beyond state-of-the-art would introduce QoS attributes with such communication patterns and mapping them with QoS will most likely consider DDS a very good candidate.
    • this way, you separate the "robotics communication patterns" from the middleware and ignoring that separation unfortunately has a long tradition in robotics: for very good reasons, you should not expose the complexity of CORBA, zeroMQ, ACE, ACE/TAO, DDS to the robotics user but should have framework experts that once do these mappings
  • If you are interested in such communication patterns (and how they can be mapped onto different middleware systems, but right now still without QoS), you might want have a look at the "SmartSoft communication patterns"
http://www.intechopen.com/books/robotic-systems-applications-control-and-programming/robotic-software-systems-from-code-driven-to-model-driven-software-development

Christian



Am 12.02.2014 17:56, schrieb Brian Gerkey:
hi,

As we work on improving the communications middleware within ROS, one
of the approaches that has come up repeatedly is DDS (Data
Distribution Service; http://portals.omg.org/dds/).  There are lots of
positive aspects of DDS as a middleware, and of course some tradeoffs
(e.g., in exchange for lots of features in the message transport, the
API is incredibly verbose; while there are open source
implementations, there's not the feeling of an active community doing
development on them).

We'd like to understand what the level of interest is within the ROS
community for DDS support.

So, for those of you who already know something about DDS (especially
if you have experience using it), here are some questions to start a
discussion.  Don't feel obliged to answer every question, and also
feel free to answer questions not asked here.  If you prefer, you can
reply directly to me, and we'll anonymize your comments before
potentially sharing them.

What's your opinion of DDS (good, bad, ugly, other)?  If you like DDS,
why?  If you don't like it, why not?

How would you compare DDS to the ROS middleware?

Do you see others in your field using DDS?  Have you ever wished that
ROS could "speak DDS"?  Have you already used DDS in combination with
ROS?

thanks,
brian.
_______________________________________________
ros-users mailing list
[hidden email]
http://lists.ros.org/mailman/listinfo/ros-users



-- 
Prof. Dr. Christian Schlegel
Prodekan, Studiendekan Master IS
Fakultät Informatik
Hochschule Ulm

Tel.: 0731 / 50-28242

http://www.hs-ulm.de/schlegel
http://www.servicerobotik-ulm.de/
http://www.zafh-servicerobotik.de/ (Sprecher)
http://www.youtube.com/user/roboticsathsulm
http://smart-robotics.sourceforge.net/
http://www.joser.org/

_______________________________________________
ros-users mailing list
[hidden email]
http://lists.ros.org/mailman/listinfo/ros-users




--
Daniele "MadMage" Calisi
"Your limit is always a bit beyond"

_______________________________________________
ros-users mailing list
[hidden email]
http://lists.ros.org/mailman/listinfo/ros-users
Reply | Threaded
Open this post in threaded view
|

Re: ROS & DDS

Nikolai Ensslen

Hi Brian,

 

as you know from our recent conversations, at Synapticon we’re absolutely in favour of putting ROS onto any of the mature middleware options available and DDS is the most promising candidate. Christian and Daniel (forwarded by Nick) gave great summaries to which we can’t add much. We think making ROS supporting or using DDS would finally enable ROS to gain the traction it deserves in industrial/product applications.

 

However we also think it makes sense not to replace the traditional ROS middleware but to just add DDS spec to it, maybe replacing some elements that make sense after some time. Backwards compatibility is important and there are some things ROS middleware is obviously good at that DDS can’t provide, e.g. messaging or streaming larger amounts of data.

 

We‘d be happy to contribute to the efforts of adding DDS as a middleware choice to ROS.

 

Best,

Nik

 

Von: [hidden email] [mailto:[hidden email]] Im Auftrag von Daniele Calisi
Gesendet: Donnerstag, 13. Februar 2014 11:26
An: User discussions
Betreff: Re: [ros-users] ROS & DDS

 

I agree with Christian Schlegel on the following points:

- Configuring DDS is very complex and the effort makes sense only for big projects. I personally have an experience with DDS used in robotics and it has often be a pain to configure everything in such a way that it works as expected. If you are not a DDS expert, you can easily have configurations that perform worse than using whatever middleware.

- Let's write an abstraction layer, this is the best solution, because we are not sure how ROS middleware can perform with respect to DDS for specific robotic applications (and I see using ROS middleware much more simple for those who are just beginning with robotics, e.g., students). Moreover, we are not sure about what the future has to offer, what if we discover that a new-born middleware is better than everything for robotics and embedded systems? I personally did this for our framework OpenRDK (http://openrdk.sf.net), and, although the abstraction was not complete and sometimes requires some hacks, I was able to use OpenRDK own middleware, ROS middleware, DDS or even KDE D-Bus or HTTP, depending on the application.

 

On Thu, Feb 13, 2014 at 10:14 AM, Christian Schlegel <[hidden email]> wrote:

Dear Brian,

  • DDS definitely is a very interesting candidate. If it comes to QoS, it is the most standardized and most advanced approach. In particular, due to the high degree of standardization, different implementations of the DDS standard can smoothly interact.

Let me give some more hints:

  • I have been wondering for a long time why robotics more or less ignored so far existing middleware standards and often comes up with solutions ignoring the achievements in the scientific community of distributed / middleware systems. That is in particular interesting since in robotics, we need the most advanced middleware systems (scalability across different H/W and OS platforms ranging from embedded to full-scale systems, QoS, partly even realtime etc.). The DDS standard deals with many of these things!
  • "freedom from choice" instead of "freedom of choice":
    • it will be decisive not just to migrate to DDS (or any other middleware) and then present the complexity of DDS ("freedom of choice") to the robotics user (configuring DDS is complex  but that is because DDS is powerful). We need to have an abstraction layer (execution container) that comprises "robotics communication patterns" ("freedom from choice") like query (request / response) and push (publish / subscribe). These provide stable interfaces to the robotics experts but can be mapped onto whatever middleware that is appropriate. Going beyond state-of-the-art would introduce QoS attributes with such communication patterns and mapping them with QoS will most likely consider DDS a very good candidate.
    • this way, you separate the "robotics communication patterns" from the middleware and ignoring that separation unfortunately has a long tradition in robotics: for very good reasons, you should not expose the complexity of CORBA, zeroMQ, ACE, ACE/TAO, DDS to the robotics user but should have framework experts that once do these mappings
  • If you are interested in such communication patterns (and how they can be mapped onto different middleware systems, but right now still without QoS), you might want have a look at the "SmartSoft communication patterns"

http://www.intechopen.com/books/robotic-systems-applications-control-and-programming/robotic-software-systems-from-code-driven-to-model-driven-software-development

Christian




Am 12.02.2014 17:56, schrieb Brian Gerkey:

hi,
 
As we work on improving the communications middleware within ROS, one
of the approaches that has come up repeatedly is DDS (Data
Distribution Service; http://portals.omg.org/dds/).  There are lots of
positive aspects of DDS as a middleware, and of course some tradeoffs
(e.g., in exchange for lots of features in the message transport, the
API is incredibly verbose; while there are open source
implementations, there's not the feeling of an active community doing
development on them).
 
We'd like to understand what the level of interest is within the ROS
community for DDS support.
 
So, for those of you who already know something about DDS (especially
if you have experience using it), here are some questions to start a
discussion.  Don't feel obliged to answer every question, and also
feel free to answer questions not asked here.  If you prefer, you can
reply directly to me, and we'll anonymize your comments before
potentially sharing them.
 
What's your opinion of DDS (good, bad, ugly, other)?  If you like DDS,
why?  If you don't like it, why not?
 
How would you compare DDS to the ROS middleware?
 
Do you see others in your field using DDS?  Have you ever wished that
ROS could "speak DDS"?  Have you already used DDS in combination with
ROS?
 
thanks,
brian.
_______________________________________________
ros-users mailing list
[hidden email]
http://lists.ros.org/mailman/listinfo/ros-users
 




-- 
Prof. Dr. Christian Schlegel
Prodekan, Studiendekan Master IS
Fakultät Informatik
Hochschule Ulm
 
Tel.: 0731 / 50-28242
 
http://www.hs-ulm.de/schlegel
http://www.servicerobotik-ulm.de/
http://www.zafh-servicerobotik.de/ (Sprecher)
http://www.youtube.com/user/roboticsathsulm
http://smart-robotics.sourceforge.net/
http://www.joser.org/


_______________________________________________
ros-users mailing list
[hidden email]
http://lists.ros.org/mailman/listinfo/ros-users



 

--

Daniele "MadMage" Calisi
"Your limit is always a bit beyond"


_______________________________________________
ros-users mailing list
[hidden email]
http://lists.ros.org/mailman/listinfo/ros-users
Reply | Threaded
Open this post in threaded view
|

Re: ROS & DDS

Georg Bartels
Hi Brian, hi all,

thank you very much for initiating and pursuing this discussion on the
mailing list. I, as a ROS user, appreciate being in the loop, at least
initially, of such design discussions!

I have two questions:
(1) For a researcher using ROS to run experiments on a single robot +
local LAN, what is the __single__ most important advantage of a
middleware switch to, for instance, DDS?

(2) For a maintainer of a client language of ROS (not cpp or python),
what is the overhead of the discussed switch?

Thanks for any response, and keep up the interesting discussion.

Cheers,
Georg.


On 02/13/2014 12:38 PM, Nikolai Ensslen wrote:

> Hi Brian,
>
>
>
> as you know from our recent conversations, at Synapticon we're absolutely
> in favour of putting ROS onto any of the mature middleware options
> available and DDS is the most promising candidate. Christian and Daniel
> (forwarded by Nick) gave great summaries to which we can't add much. We
> think making ROS supporting or using DDS would finally enable ROS to gain
> the traction it deserves in industrial/product applications.
>
>
>
> However we also think it makes sense not to replace the traditional ROS
> middleware but to just add DDS spec to it, maybe replacing some elements
> that make sense after some time. Backwards compatibility is important and
> there are some things ROS middleware is obviously good at that DDS can't
> provide, e.g. messaging or streaming larger amounts of data.
>
>
>
> We'd be happy to contribute to the efforts of adding DDS as a middleware
> choice to ROS.
>
>
>
> Best,
>
> Nik
>
>
>
> *Von:* [hidden email] [mailto:
> [hidden email]] *Im Auftrag von *Daniele Calisi
> *Gesendet:* Donnerstag, 13. Februar 2014 11:26
> *An:* User discussions
> *Betreff:* Re: [ros-users] ROS & DDS
>
>
>
> I agree with Christian Schlegel on the following points:
>
> - Configuring DDS is very complex and the effort makes sense only for big
> projects. I personally have an experience with DDS used in robotics and it
> has often be a pain to configure everything in such a way that it works as
> expected. If you are not a DDS expert, you can easily have configurations
> that perform worse than using whatever middleware.
>
> - Let's write an abstraction layer, this is the best solution, because we
> are not sure how ROS middleware can perform with respect to DDS for
> specific robotic applications (and I see using ROS middleware much more
> simple for those who are just beginning with robotics, e.g., students).
> Moreover, we are not sure about what the future has to offer, what if we
> discover that a new-born middleware is better than everything for robotics
> and embedded systems? I personally did this for our framework OpenRDK (
> http://openrdk.sf.net), and, although the abstraction was not complete and
> sometimes requires some hacks, I was able to use OpenRDK own middleware,
> ROS middleware, DDS or even KDE D-Bus or HTTP, depending on the application.
>
>
>
> On Thu, Feb 13, 2014 at 10:14 AM, Christian Schlegel <[hidden email]>
> wrote:
>
> Dear Brian,
>
>    - DDS definitely is a very interesting candidate. If it comes to QoS, it
>    is the most standardized and most advanced approach. In particular, due to
>    the high degree of standardization, different implementations of the DDS
>    standard can smoothly interact.
>
> Let me give some more hints:
>
>    - I have been wondering for a long time why robotics more or less
>    ignored so far existing middleware standards and often comes up with
>    solutions ignoring the achievements in the scientific community of
>    distributed / middleware systems. That is in particular interesting since
>    in robotics, we need the most advanced middleware systems (scalability
>    across different H/W and OS platforms ranging from embedded to full-scale
>    systems, QoS, partly even realtime etc.). The DDS standard deals with many
>    of these things!
>    - "freedom from choice" instead of "freedom of choice":
>
>
>    - it will be decisive not just to migrate to DDS (or any other
>       middleware) and then present the complexity of DDS ("freedom of
> choice") to
>       the robotics user (configuring DDS is complex  but that is because DDS is
>       powerful). We need to have an abstraction layer (execution
> container) that
>       comprises "robotics communication patterns" ("freedom from choice") like
>       query (request / response) and push (publish / subscribe). These provide
>       stable interfaces to the robotics experts but can be mapped onto whatever
>       middleware that is appropriate. Going beyond state-of-the-art would
>       introduce QoS attributes with such communication patterns and
> mapping them
>       with QoS will most likely consider DDS a very good candidate.
>       - this way, you separate the "robotics communication patterns" from
>       the middleware and ignoring that separation unfortunately has a long
>       tradition in robotics: for very good reasons, you should not expose the
>       complexity of CORBA, zeroMQ, ACE, ACE/TAO, DDS to the robotics user but
>       should have framework experts that once do these mappings
>
>
>    - If you are interested in such communication patterns (and how they can
>    be mapped onto different middleware systems, but right now still without
>    QoS), you might want have a look at the "SmartSoft communication patterns"
>
> http://www.intechopen.com/books/robotic-systems-applications-control-and-programming/robotic-software-systems-from-code-driven-to-model-driven-software-development
>
> Christian
>
>
>
>
> Am 12.02.2014 17:56, schrieb Brian Gerkey:
>
> hi,
>
>
>
> As we work on improving the communications middleware within ROS, one
>
> of the approaches that has come up repeatedly is DDS (Data
>
> Distribution Service; http://portals.omg.org/dds/).  There are lots of
>
> positive aspects of DDS as a middleware, and of course some tradeoffs
>
> (e.g., in exchange for lots of features in the message transport, the
>
> API is incredibly verbose; while there are open source
>
> implementations, there's not the feeling of an active community doing
>
> development on them).
>
>
>
> We'd like to understand what the level of interest is within the ROS
>
> community for DDS support.
>
>
>
> So, for those of you who already know something about DDS (especially
>
> if you have experience using it), here are some questions to start a
>
> discussion.  Don't feel obliged to answer every question, and also
>
> feel free to answer questions not asked here.  If you prefer, you can
>
> reply directly to me, and we'll anonymize your comments before
>
> potentially sharing them.
>
>
>
> What's your opinion of DDS (good, bad, ugly, other)?  If you like DDS,
>
> why?  If you don't like it, why not?
>
>
>
> How would you compare DDS to the ROS middleware?
>
>
>
> Do you see others in your field using DDS?  Have you ever wished that
>
> ROS could "speak DDS"?  Have you already used DDS in combination with
>
> ROS?
>
>
>
> thanks,
>
> brian.
>
> _______________________________________________
>
> ros-users mailing list
>
> [hidden email]
>
> http://lists.ros.org/mailman/listinfo/ros-users
>
>
>
>
>
>
>
>
> _______________________________________________
> ros-users mailing list
> [hidden email]
> http://lists.ros.org/mailman/listinfo/ros-users
>

_______________________________________________
ros-users mailing list
[hidden email]
http://lists.ros.org/mailman/listinfo/ros-users
Reply | Threaded
Open this post in threaded view
|

Re: ROS & DDS

Brian Gerkey-3
In reply to this post by Nikolai Ensslen
On Thu, Feb 13, 2014 at 3:38 AM, Nikolai Ensslen
<[hidden email]> wrote:
> However we also think it makes sense not to replace the traditional ROS
> middleware but to just add DDS spec to it, maybe replacing some elements
> that make sense after some time. Backwards compatibility is important and
> there are some things ROS middleware is obviously good at that DDS can't
> provide, e.g. messaging or streaming larger amounts of data.

Can you say more about this point?  I'm very interested in learning
about use cases where DDS can't meet our messaging needs in the
robotics / embedded systems space.

> We'd be happy to contribute to the efforts of adding DDS as a middleware
> choice to ROS.

Outstanding!

brian.
_______________________________________________
ros-users mailing list
[hidden email]
http://lists.ros.org/mailman/listinfo/ros-users
Reply | Threaded
Open this post in threaded view
|

Re: ROS & DDS

Yamnia
This post has NOT been accepted by the mailing list yet.
Hello,

In the present we have a communication framework based on RTI DDS. We have wrapped the DDS API for hiding the complexity of it, for example a publisher program can be written with five code line. Also, we have created a ROS bridge that joins the DDS topics with ROS topics and vice versa. This module is auto generated from a XML configuration file, which defines the convertions between IDLs and ROS messages. In this way, the framework and the bridge are updated and extended very fast and easily. We also auto generate the IDLs and ROS messages. A important feature is that we are able to communicate isolated clients and servers of actions (they run in different roscore) through the DDS framework with very good performance.
We have been working on this a long time and framework covers all our needs for communication between multi-system. For example, this framework is been applied in the ARCAS European project (http://www.arcas-project.eu/). Here there is a nice video: http://youtu.be/wN3pcSdEUSk.
If you have any questions, I would be happy to answer you.

Best regards,
Yamnia Rodríguez
Center for Advanced Aerospace Technologies (CATEC).
e-mail: yrodriguez at catec point aero
web:     www.catec.aero
Reply | Threaded
Open this post in threaded view
|

Re: ROS & DDS

Edwards, Shaun M.
In reply to this post by Geoffrey Biggs

All,

 

I’m fully supportive of adopting a standard middleware, even at the expense of backwards compatibility (assuming ROS 1.0 will continue to exist, but perhaps not updated).

 

My main concerns is Geoffrey Biggs’ comment below.  Tuning should be a dirty word in software.  I know it’s needed, but successful software just works.  Ease of use should always be our focus.  It is this single issue that has been the nail in the coffin of every middleware I have used.  Whatever we choose, it should be easy to use or we should make it so.

 

The parameter tuning is important if the defaults don't do what you need, but it is nothing new to anyone who's had to tune network performance, especially in a wifi environment. Specifying QoS parameters in an XML file is standardised now, so all implementations do or shortly will support it. This is extremely useful; you can save different profiles for different links and load them dynamically depending on what sort of deployment you do.

 


_______________________________________________
ros-users mailing list
[hidden email]
http://lists.ros.org/mailman/listinfo/ros-users
Reply | Threaded
Open this post in threaded view
|

Re: ROS & DDS

Ingo Lütkebohle-2
On Fri, Feb 14, 2014 at 2:27 PM, Edwards, Shaun M. <[hidden email]> wrote:
> My main concerns is Geoffrey Biggs' comment below.  Tuning should be a dirty
> word in software.  I know it's needed, but successful software just works.
> Ease of use should always be our focus.  It is this single issue that has
> been the nail in the coffin of every middleware I have used.

I agree on that.

One could reasonably argue that the attempt to solve the communication
problem in a relatively application-independent manner is doomed, and
that application-specific protocols are the way to go. Some people may
dismiss that as unrealistic, but I would argue that
application-specific protocols are the IETF approach, and that it has
been fairly successful, so far.

That said, there is a question of what the basis for such developments
should be, or, in other words, whether the protocols in the DDS family
are a better foundation for robotics applications than base-level
TCP/IP.

I guess answers to that question will be influenced significantly by
whether you're coming from an enterprise environment, or from an open
systems environment.

cheers

--
Ingo Lütkebohle, Dr.-Ing.
Machine Learning and Robotics Lab, IPVS, Universität Stuttgart
http://www.ipvs.uni-stuttgart.de/abteilungen/mlr/abteilung/mitarbeiter/Ingo.Luetkebohle
+49-711-685-88350

PGP Fingerprint 3187 4DEC 47E6 1B1E 6F4F  57D4 CD90 C164 34AD CE5B
_______________________________________________
ros-users mailing list
[hidden email]
http://lists.ros.org/mailman/listinfo/ros-users
Reply | Threaded
Open this post in threaded view
|

Re: ROS & DDS

Ryan Gariepy
Ease of use is *critical*. We're already receiving regular feedback
that the usability of ROS is getting worse with each distribution.

-Ryan

On Fri, Feb 14, 2014 at 8:43 AM, Ingo Lütkebohle <[hidden email]> wrote:

> On Fri, Feb 14, 2014 at 2:27 PM, Edwards, Shaun M. <[hidden email]> wrote:
>> My main concerns is Geoffrey Biggs' comment below.  Tuning should be a dirty
>> word in software.  I know it's needed, but successful software just works.
>> Ease of use should always be our focus.  It is this single issue that has
>> been the nail in the coffin of every middleware I have used.
>
> I agree on that.
>
> One could reasonably argue that the attempt to solve the communication
> problem in a relatively application-independent manner is doomed, and
> that application-specific protocols are the way to go. Some people may
> dismiss that as unrealistic, but I would argue that
> application-specific protocols are the IETF approach, and that it has
> been fairly successful, so far.
>
> That said, there is a question of what the basis for such developments
> should be, or, in other words, whether the protocols in the DDS family
> are a better foundation for robotics applications than base-level
> TCP/IP.
>
> I guess answers to that question will be influenced significantly by
> whether you're coming from an enterprise environment, or from an open
> systems environment.
>
> cheers
>
> --
> Ingo Lütkebohle, Dr.-Ing.
> Machine Learning and Robotics Lab, IPVS, Universität Stuttgart
> http://www.ipvs.uni-stuttgart.de/abteilungen/mlr/abteilung/mitarbeiter/Ingo.Luetkebohle
> +49-711-685-88350
>
> PGP Fingerprint 3187 4DEC 47E6 1B1E 6F4F  57D4 CD90 C164 34AD CE5B
> _______________________________________________
> ros-users mailing list
> [hidden email]
> http://lists.ros.org/mailman/listinfo/ros-users
_______________________________________________
ros-users mailing list
[hidden email]
http://lists.ros.org/mailman/listinfo/ros-users
12345