<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 13 February 2014 01:56, Brian Gerkey <span dir="ltr"><<a href="mailto:gerkey@osrfoundation.org" target="_blank">gerkey@osrfoundation.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">So, for those of you who already know something about DDS (especially<br>

if you have experience using it), here are some questions to start a<br>
discussion.  Don't feel obliged to answer every question, and also<br>
feel free to answer questions not asked here.  If you prefer, you can<br>
reply directly to me, and we'll anonymize your comments before<br>
potentially sharing them.<br>
<br>
What's your opinion of DDS (good, bad, ugly, other)?  If you like DDS,<br>
why?  If you don't like it, why not?<br>
<br>
How would you compare DDS to the ROS middleware?<br>
<br>
Do you see others in your field using DDS?  Have you ever wished that<br>
ROS could "speak DDS"?  Have you already used DDS in combination with<br>
ROS?<br></blockquote><div><br></div><div>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).</div>
<div><br></div><div>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).</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div><div><br></div><div>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.</div>
<div><br></div><div>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.</div><div><br></div><div><a href="http://www.rti.com/resources/university-participants.html">http://www.rti.com/resources/university-participants.html</a><br>
</div><div><br></div><div>Geoff</div></div></div></div>