<div dir="ltr">I'm really excited about using a more mature middleware, like DDS, for more configurable QoS. The amount of data that gets thrown around in a typical ROS system can be massive and have a wide range of necessary demands for the data it subscribes to:<br>
<ul><li>Closed loop controllers often need low latency and high QoS but usually require low bandwidth</li><li>Perception like RGBD sensing requires high bandwidth but can tolerate high latency and poor QoS<br></li><li>AI/high level planning is often painfully in need of throttling mechanisms (DDS can do this out of the box!)</li>
<li>You shouldn't have to choose between having visualization and your robot moving smoothly, there should be a non-trivial inbetween</li><li>If I just want to know some static transform in my URDF at some random location in my application, I shouldn't have to hook up to the /tf firehose! (even though I pick on /tf, this is a general problem)<br>
</li></ul><p>I've been using ROS since C-turtle, but despite the improvements, it still feels like it takes a little ROS black-magic to get things working smoothly. Rarely have I had a project where I didn't have to redesign some aspect of the communication because I sloppy about how I was routing it. I still don't see it as a framework capable of designing very reliable systems. Furthermore, these problems will only get worse as sensors/actuators/algorithms become more sophisticated and increase their demands.<br>
</p><p>The time spent redesigning communication is just as much lost time as a learning a slightly more complicated communication mechanism. And honestly, I think the learning curve is really only going to be as difficult as the ROS implementation makes it. The model is still, for the most part, similar, and so an interface which emulates ROS basic communication can probably be written. While I understand the concerns of people who prioritize ease of use, I'd be disappointed if ROS didn't eventually improve its communication mechanism.</p>
<p>Also, having a low-footprint solution for embedded system
communication would be really nice. There still doesn't seem to be a commonly
accepted standard for this: rosc is in alpha, simple_message is still in
development, apparently people are already using DDS... <br></p><p>-Kelsey<br></p></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Feb 15, 2014 at 1:56 AM, Georg Bartels <span dir="ltr"><<a href="mailto:georg.bartels@cs.uni-bremen.de" target="_blank">georg.bartels@cs.uni-bremen.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">+1 from me for the following paragraph from Ben:<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
> What I love about ROS is that it has so far been focused on the software experience rather than the hardware. It almost seems like a contradiction to be worrying about QoS when much of your code is Python scripts and other higher-level languages (instead of C) running on Ubuntu (instead of a RTOS). I'm certainly not saying that QoS is unimportant -- it would be very nice to have -- but I would place simplicity as a higher priority. Maybe ROS Industrial would be a better place for DDS or baked-in QoS?<br>
><br>
> -Ben<br>
><br>
> ________________________________________<br>
> From: <a href="mailto:ros-users-bounces@lists.ros.org">ros-users-bounces@lists.ros.org</a> [<a href="mailto:ros-users-bounces@lists.ros.org">ros-users-bounces@lists.ros.org</a>] On Behalf Of Brian Gerkey [<a href="mailto:gerkey@osrfoundation.org">gerkey@osrfoundation.org</a>]<br>
> Sent: Thursday, February 13, 2014 3:56 AM<br>
> To: User discussions<br>
> Subject: [ros-users] ROS & DDS<br>
><br>
> hi,<br>
><br>
> As we work on improving the communications middleware within ROS, one<br>
> of the approaches that has come up repeatedly is DDS (Data<br>
> Distribution Service; <a href="http://portals.omg.org/dds/" target="_blank">http://portals.omg.org/dds/</a>). There are lots of<br>
> positive aspects of DDS as a middleware, and of course some tradeoffs<br>
> (e.g., in exchange for lots of features in the message transport, the<br>
> API is incredibly verbose; while there are open source<br>
> implementations, there's not the feeling of an active community doing<br>
> development on them).<br>
><br>
> We'd like to understand what the level of interest is within the ROS<br>
> community for DDS support.<br>
><br>
> 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>
><br>
> thanks,<br>
> brian.<br>
> _______________________________________________<br>
> ros-users mailing list<br>
> <a href="mailto:ros-users@lists.ros.org">ros-users@lists.ros.org</a><br>
> <a href="http://lists.ros.org/mailman/listinfo/ros-users" target="_blank">http://lists.ros.org/mailman/listinfo/ros-users</a><br>
><br>
> UTS CRICOS Provider Code: 00099F<br>
> DISCLAIMER: This email message and any accompanying attachments may contain confidential information.<br>
> If you are not the intended recipient, do not read, use, disseminate, distribute or copy this message or<br>
> attachments. If you have received this message in error, please notify the sender immediately and delete<br>
> this message. Any views expressed in this message are those of the individual sender, except where the<br>
> sender expressly, and with authority, states them to be the views of the University of Technology Sydney.<br>
> Before opening any attachments, please check them for viruses and defects.<br>
><br>
> Think. Green. Do.<br>
><br>
> Please consider the environment before printing this email.<br>
> _______________________________________________<br>
> ros-users mailing list<br>
> <a href="mailto:ros-users@lists.ros.org">ros-users@lists.ros.org</a><br>
> <a href="http://lists.ros.org/mailman/listinfo/ros-users" target="_blank">http://lists.ros.org/mailman/listinfo/ros-users</a><br>
><br>
<br>
_______________________________________________<br>
ros-users mailing list<br>
<a href="mailto:ros-users@lists.ros.org">ros-users@lists.ros.org</a><br>
<a href="http://lists.ros.org/mailman/listinfo/ros-users" target="_blank">http://lists.ros.org/mailman/listinfo/ros-users</a><br>
</div></div></blockquote></div><br></div>