<div dir="ltr"><div><br></div>Accidentally hit send, sorry. Continuing...<br><div><br></div><div>I have watched and avoided entering alot of discussions about usability over the last six months. Given that they're repeating, they're obviously a concern to many, but it's probably time to start doing rather than talking. If you have time, write some code (see previous email), test every which way but loose and then harry Tully & co if you think it needs to be integrated at a more fundamental level (e.g. catkin_create scripts). I like seeing things like roslint which Mike and Jack have done a splendid job on.</div>
<div><br></div><div>To be honest, I'd rather see William work on crazy issues like middleware debate than consuming inordinate amounts of oxygen and pizza in order to writing catkin_create scripts - that's where the average grad student or company engineer can help out with a bit of guidance.</div>
<div><div><br></div><div>There is another point I'd like to bring up about usability. To me</div><div><br></div><div style="text-align:center"><i>usability</i> != <i>ease of use for beginners</i>.</div></div><div><br>
</div><div>I wouldn't consider something usable if, despite being brilliant for a newbie, it isn't capable of doing everything that it's specified to do. <br></div><div><div><br></div><div>I think it's very important for people to sit down and work out the fundamental set of things that ROS must do, make everyone aware of these and THEN consider how to best make ros easy to use whilst being capable of that fundamental set of things. Only then do you have what I'd call a <i>usable</i> system. Alot of 'ease of use' discussions are often unaware of the very important practical needs that you don't see within the first day (or sometimes ever depending on your work) of becoming a rosified human. Good examples of this include the needs of research robots vs product robots, embedded needs, connecting outside the robot to pc's, the lan or the web. This lack of awareness has a habit of diverting attention from whatever original discussion was started. At least some separate threads were made here (thanks to whoever did this!).</div>
<div><br></div></div><div>Ok, back to the wonderful world of ROS (kicks ass on emails, although admittedly emails about ROS aren't so bad....)!</div><div><br></div><div>Cheers,</div><div>Daniel.</div></div><div class="gmail_extra">
<br><br><div class="gmail_quote">On 19 February 2014 18:14, Daniel Stonier <span dir="ltr"><<a href="mailto:d.stonier@gmail.com" target="_blank">d.stonier@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote"><div class="">On 19 February 2014 00:21, Ryan Gariepy <span dir="ltr"><<a href="mailto:rgariepy@clearpathrobotics.com" target="_blank">rgariepy@clearpathrobotics.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">So, I actually ask "What would you improve about ROS" in every single related job interview I conduct...I've got a long list.<div>
<br></div><div>On ROS usability itself, the largest thing which has come up has been the renewed difficulty in getting started. Even though new users are no longer being thrown into the middle of the rosmake/catkin transition, the overhead in creating a new package has increased dramatically.</div>
<div><br></div><div>It's been a long time since I've used the rosmake/rospy/Electric combo, but IIRC all you needed to do was:</div><div>1) Source setup.bash</div><div>2) Call the package creation script</div><div>
3) Write a .py script</div><div>4) Add the package to ROS_PACKAGE_PATH</div><div><br></div><div>Three of those four steps are one-liners, and the fourth has near-instant gratification for the developers.</div><div><br></div>
<div>Another point: ROS used to be three steps for a full install: (key, update, install), and now you need to jump through hoops for rosdep and other "noncritical yet required" items.</div><div><br></div><div>
Something else which is important to note is that the purpose of all of those above steps are easily explainable to someone who knows nothing about ROS at all, which is certainly not the case now. (ex. "Why do I have to specify basic ROS dependencies in three different locations?", "Why do I need to set up build instructions for a script I intend to run in place?")</div>
<div><br></div><div>So, we've made development and installation more difficult by leaps and bounds, and now we have the potential to make the same mistake with the transport layer?</div><div><br></div><div>IMO, we should all keep in mind that ROS is where it is in large part due to it being easy to install and get started on. I'm not saying at all that we should stop improving performance, but I am saying that we should consider the "getting started" for new developers more than we have been. Even from a personal note, it sometimes takes me longer to set up a workspace and package setup for a quick test than it does for me to write the actual code. True, I can set up templates and scripts to speed this up...but why should I have to?</div>
</div></blockquote><div><br></div></div><div>I actually think all of these issues can be very quickly remedied, except perhaps for the little extra effort involved in adding a bit more information to CMakeLists.txt and setup.py than there used to be.</div>
<div><br></div><div>We even go to some of this effort internally and have a few tools that make life easier for interns/engineers who aren't so familiar with ros and are often only temporarily in and out of the ros team. For them getting started with something like turtlebot is as easy as:</div>
<div><br></div><div># Pull rosinstalls located by our <a href="https://github.com/yujinrobot/yujin_tools/tree/master/rosinstalls" target="_blank">rosdistro like github database</a></div><div>> yujin_init_workspace turtlebot ./turtlebot</div>
<div>> cd turtlebot</div><div># Create a whole bunch of useful scripts for starting konsole, gnome-terminal, eclipse with sourced setup.bash</div><div>> yujin_init_build . </div><div># Install all dependencies and compile</div>
<div>> yujin_make --install-rosdeps</div><div><br></div><div>From there we also have a few of our own catkin_create_xxx wizards - e.g. for java we utilise catkin_create_rosjava_package, catkin_create_rosjava_library_project, catkin_create_rosjava_project. Ros could definitely use some extra default catkin_create_xxx scripts and this would simplify things alot for <i>new</i> users and with these, I don't see it really being that much more difficult than electric.</div>
<div><br></div><div>Perhaps this small (and it is small compared to catkin or a middleware overhaul) effort should be given higher priority given the anxiety this issue creates.</div><div><div class="h5"><div><br></div><div>
<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
</div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Feb 16, 2014 at 5:56 AM, Thibault Kruse <span dir="ltr"><<a href="mailto:kruset@in.tum.de" target="_blank">kruset@in.tum.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> 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>
Hi Ryan,<br>
<br>
it would be interesting to hear more details about what parts of ROS<br>
suffered usability most, and what impact this has on Clearpath Robotics<br>
Business.<br>
<br>
The question about DDS was not asked by some OSRF technical underling or<br>
the ROS platform manager, but by the OSRF CEO. So we can presume that the<br>
internal discussion about DDS at OSRF is not just philantrophic idle talk,<br>
but more relevant to the future of OSRF itself (not just ROS).<br>
<br>
It seems unclear whether the loss of usability of ROS will have an impact<br>
on OSRF funding, or whether OSRF should invest into integrating accepted<br>
industry standards (like DDS) into ROS rather than improving usability.<br>
<br>
The loss of usability itself is a pity, but OSRF closing shop would be<br>
much more dramatic for the future of ROS.<br>
<br>
regards,<br>
Thibault<br>
<br>
_______________________________________________<br>
ros-users mailing list<br>
<a href="mailto:ros-users@lists.ros.org" target="_blank">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>
</blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
ros-users mailing list<br>
<a href="mailto:ros-users@lists.ros.org" target="_blank">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></blockquote></div></div></div><span class="HOEnZb"><font color="#888888"><br><br clear="all"><div><br></div>-- <br>Phone : +82-10-5400-3296 (010-5400-3296)<br>Home: <a href="http://snorriheim.dnsdojo.com/" target="_blank">http://snorriheim.dnsdojo.com/</a><br>
<div>Yujin R&D: <a href="http://rnd.yujinrobot.com/" target="_blank">http://rnd.yujinrobot.com/<br>
</a><br></div>
</font></span></div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>Phone : +82-10-5400-3296 (010-5400-3296)<br>Home: <a href="http://snorriheim.dnsdojo.com/" target="_blank">http://snorriheim.dnsdojo.com/</a><br><div>Yujin R&D: <a href="http://rnd.yujinrobot.com/" target="_blank">http://rnd.yujinrobot.com/<br>
</a><br></div>
</div>