<div dir="ltr">As others have said, usability is critical, and the ROS learning curve has only been getting steeper and steeper.<div><br></div><div>A lot of people have been saying for a long time that updating the transport layer would dramatically improve the performance of all ROS systems. I see a lot of standards that have been explored which would see the entire transport layer re-implemented, but there are simpler things that could be done like just adding UDP multicast as has been done in the ethzasl_message_transport stack [1]. This stack serves as an example of how to override the normal transport in a case where it needs to be optimized. In the end, I think whatever "default" settings get used for the ROS transport need to be as "good enough" for beginners as the current defailts without having to specify on what kind of network connection your computers are connected.</div>
<div><br></div><div>Regardless of how the transport layer or APIs get modified, Nicholas makes a good point:</div><div><br></div><div><div class="gmail_quote">On Fri, Feb 14, 2014 at 9:14 AM, Armstrong-Crews, Nicholas - 1002 - MITLL <span dir="ltr"><<a href="mailto:nickarmstrongcrews@ll.mit.edu" target="_blank">nickarmstrongcrews@ll.mit.edu</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"><div id=":1nk" style="overflow:hidden">Doing it right will take some work, but I think it'll be worth it to enough<br>
people, and the advanced features can be spooled out incrementally over<br>time.<br></div></blockquote></div><br></div><div>I'd like to add to this that any significant change in the way ROS is used (like this) should necessitate a usability study with users who aren't directly involved in the changes. Most of the ROS core was subject to Willow's "Milestone 3" push [2] to document and verify the usability of nearly 200 packages in 2010. Newer core utilities like Catkin haven't benefited from such a broad push. This lack of a broad usability study has both the effect of a software tool that is harder to use and necessitates much more engineering effort from the designers to modify after it has been released.</div>
<div><br></div><div>[1] <a href="http://wiki.ros.org/ethzasl_message_transport">http://wiki.ros.org/ethzasl_message_transport</a></div><div>[2] <a href="https://web.archive.org/web/20130520230550/http://www.willowgarage.com/blog/2010/01/22/milestone-3-complete-pr2-betas-ready-and-ros-10">https://web.archive.org/web/20130520230550/http://www.willowgarage.com/blog/2010/01/22/milestone-3-complete-pr2-betas-ready-and-ros-10</a></div>
<div><br></div><div>-j</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Feb 14, 2014 at 9:20 AM, Christian Schlegel <span dir="ltr"><<a href="mailto:schlegel@hs-ulm.de" target="_blank">schlegel@hs-ulm.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
Indeed, ease of use is decisive but it should not come with ignoring major technical needs (complex robotic systems depend on advanced technologies like those from domains like distributed systems and software engineering).<br>
<br>
Again:<br>
communication patterns provide two views.<br>
One is a precise interface and semantics exposed to the robotics community. Make their live as simple as possible and match their needs.<br>
The other is the interface to the underlying middleware which is not seen by robotics users but just by framework builders and middleware experts. They do all the mappings duch that the agreed semantics remains the same whatever middleware mapping you prefer. They keep the middleware away from the robotics people!<br>
<br>
This way, it is also completely transparent to the robotics community which mapping you prefer and how finally messages are transmitted (even in "any" types of DDL)<br>
<br>
The way to go is to introduce this separation of concerns: precise semantics and stable interfaces for robotics people and internal stable interfaces towards middleware used by framework builders, middleware experts to map communication patterns but not visible to robotics.<br>
<br>
Christian<br>
<br>
---<br>
<div class="">Prof. Dr. Christian Schlegel<br>
Prodekan, Studiendekan Master IS<br>
Fakultät Informatik<br>
Hochschule Ulm<br>
<br>
Tel.: 0731 / 50-28242<br>
<br>
<a href="http://www.hs-ulm.de/schlegel" target="_blank">http://www.hs-ulm.de/schlegel</a><br>
</div><a href="http://www.zafh-servicerobotik.de/" target="_blank">http://www.zafh-servicerobotik.de/</a><br>
<div class=""><a href="http://www.youtube.com/user/roboticsathsulm" target="_blank">http://www.youtube.com/user/roboticsathsulm</a><br>
<a href="http://smart-robotics.sourceforge.net/" target="_blank">http://smart-robotics.sourceforge.net/</a><br>
<a href="http://www.joser.org/" target="_blank">http://www.joser.org/</a><br>
<br>
</div>> Am 14.02.2014 um 15:05 schrieb "Ryan Gariepy" <<a href="mailto:rgariepy@clearpathrobotics.com">rgariepy@clearpathrobotics.com</a>>:<br>
<div class="HOEnZb"><div class="h5">><br>
> Ease of use is *critical*. We're already receiving regular feedback<br>
> that the usability of ROS is getting worse with each distribution.<br>
><br>
> -Ryan<br>
><br>
>> On Fri, Feb 14, 2014 at 8:43 AM, Ingo Lütkebohle <<a href="mailto:iluetkeb@gmail.com">iluetkeb@gmail.com</a>> wrote:<br>
>>> On Fri, Feb 14, 2014 at 2:27 PM, Edwards, Shaun M. <<a href="mailto:sedwards@swri.org">sedwards@swri.org</a>> wrote:<br>
>>> My main concerns is Geoffrey Biggs' comment below. Tuning should be a dirty<br>
>>> word in software. I know it's needed, but successful software just works.<br>
>>> Ease of use should always be our focus. It is this single issue that has<br>
>>> been the nail in the coffin of every middleware I have used.<br>
>><br>
>> I agree on that.<br>
>><br>
>> One could reasonably argue that the attempt to solve the communication<br>
>> problem in a relatively application-independent manner is doomed, and<br>
>> that application-specific protocols are the way to go. Some people may<br>
>> dismiss that as unrealistic, but I would argue that<br>
>> application-specific protocols are the IETF approach, and that it has<br>
>> been fairly successful, so far.<br>
>><br>
>> That said, there is a question of what the basis for such developments<br>
>> should be, or, in other words, whether the protocols in the DDS family<br>
>> are a better foundation for robotics applications than base-level<br>
>> TCP/IP.<br>
>><br>
>> I guess answers to that question will be influenced significantly by<br>
>> whether you're coming from an enterprise environment, or from an open<br>
>> systems environment.<br>
>><br>
>> cheers<br>
>><br>
>> --<br>
>> Ingo Lütkebohle, Dr.-Ing.<br>
>> Machine Learning and Robotics Lab, IPVS, Universität Stuttgart<br>
>> <a href="http://www.ipvs.uni-stuttgart.de/abteilungen/mlr/abteilung/mitarbeiter/Ingo.Luetkebohle" target="_blank">http://www.ipvs.uni-stuttgart.de/abteilungen/mlr/abteilung/mitarbeiter/Ingo.Luetkebohle</a><br>
>> <a href="tel:%2B49-711-685-88350" value="+4971168588350">+49-711-685-88350</a><br>
>><br>
>> PGP Fingerprint 3187 4DEC 47E6 1B1E 6F4F 57D4 CD90 C164 34AD CE5B<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>
> 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>
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><br clear="all"><div><br></div>-- <br>Jonathan Bohren<br>Laboratory for Computational Sensing and Robotics<br><a href="http://dscl.lcsr.jhu.edu/People/JonathanBohren">http://dscl.lcsr.jhu.edu/People/JonathanBohren</a><br>
<br>
</div>