My last reply was rejected from the list, hopefully this isn't duplicate. Jonathan, your tutorials are awesome! I especially appreciate how the catkin intro motivates and explains *why* one might want a build system and proper dependency management. I've bookmarked your articles :) In regards to speed of bringing up new packages, to what extent is the community aware of catkin_simple ? Is there a plan to officially release this and put it in the debs? It does make setting up a new workspace quite a bit easier and is great for development. (It seems perhaps nothing should be *released* this way, but a conversion from catkin_simple to plain catkin isn't so bad, and is probably worth the time, once you have a testable system in place.) --Adam - - - - - - - - - - - - Adam Leeper 650.ROBOT.44 On Wed, Feb 19, 2014 at 1:36 AM, Daniel Stonier wrote: > > Accidentally hit send, sorry. Continuing... > > 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. > > 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. > > There is another point I'd like to bring up about usability. To me > > *usability* != *ease of use for beginners*. > > 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. > > 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 > *usable* 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!). > > Ok, back to the wonderful world of ROS (kicks ass on emails, although > admittedly emails about ROS aren't so bad....)! > > Cheers, > Daniel. > > > On 19 February 2014 18:14, Daniel Stonier wrote: > >> >> >> >> On 19 February 2014 00:21, Ryan Gariepy wrote: >> >>> So, I actually ask "What would you improve about ROS" in every single >>> related job interview I conduct...I've got a long list. >>> >>> 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. >>> >>> It's been a long time since I've used the rosmake/rospy/Electric combo, >>> but IIRC all you needed to do was: >>> 1) Source setup.bash >>> 2) Call the package creation script >>> 3) Write a .py script >>> 4) Add the package to ROS_PACKAGE_PATH >>> >>> Three of those four steps are one-liners, and the fourth has >>> near-instant gratification for the developers. >>> >>> 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. >>> >>> 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?") >>> >>> 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? >>> >>> 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? >>> >> >> 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. >> >> 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: >> >> # Pull rosinstalls located by our rosdistro like github database >> > yujin_init_workspace turtlebot ./turtlebot >> > cd turtlebot >> # Create a whole bunch of useful scripts for starting konsole, >> gnome-terminal, eclipse with sourced setup.bash >> > yujin_init_build . >> # Install all dependencies and compile >> > yujin_make --install-rosdeps >> >> 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 *new* users and with these, I don't see >> it really being that much more difficult than electric. >> >> 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. >> >> >> >>> >>> On Sun, Feb 16, 2014 at 5:56 AM, Thibault Kruse wrote: >>> >>>> > Ease of use is *critical*. We're already receiving regular feedback >>>> > that the usability of ROS is getting worse with each distribution. >>>> > >>>> > -Ryan >>>> >>>> Hi Ryan, >>>> >>>> it would be interesting to hear more details about what parts of ROS >>>> suffered usability most, and what impact this has on Clearpath Robotics >>>> Business. >>>> >>>> The question about DDS was not asked by some OSRF technical underling or >>>> the ROS platform manager, but by the OSRF CEO. So we can presume that >>>> the >>>> internal discussion about DDS at OSRF is not just philantrophic idle >>>> talk, >>>> but more relevant to the future of OSRF itself (not just ROS). >>>> >>>> It seems unclear whether the loss of usability of ROS will have an >>>> impact >>>> on OSRF funding, or whether OSRF should invest into integrating accepted >>>> industry standards (like DDS) into ROS rather than improving usability. >>>> >>>> The loss of usability itself is a pity, but OSRF closing shop would be >>>> much more dramatic for the future of ROS. >>>> >>>> regards, >>>> Thibault >>>> >>>> _______________________________________________ >>>> ros-users mailing list >>>> ros-users@lists.ros.org >>>> http://lists.ros.org/mailman/listinfo/ros-users >>>> >>> >>> >>> _______________________________________________ >>> ros-users mailing list >>> ros-users@lists.ros.org >>> http://lists.ros.org/mailman/listinfo/ros-users >>> >>> >> >> >> -- >> Phone : +82-10-5400-3296 (010-5400-3296) >> Home: http://snorriheim.dnsdojo.com/ >> Yujin R&D: http://rnd.yujinrobot.com/ >> >> > > > -- > Phone : +82-10-5400-3296 (010-5400-3296) > Home: http://snorriheim.dnsdojo.com/ > Yujin R&D: http://rnd.yujinrobot.com/ > > > _______________________________________________ > ros-users mailing list > ros-users@lists.ros.org > http://lists.ros.org/mailman/listinfo/ros-users > >