Hi,

related to this and following up on Georg's questions: I'd ask to keep in mind that, although many professional users join, large parts of the ROS community are students and PhD students that do not primarily develop products, but use ROS as simple-to-use tool for their research work and that have limited time for software maintenance.

If large changes are required, it may be that the only option is to drop maintenance of working and useful code. For example, my knowrob knowledge base had been released since the early days of cturtle/diamondback, but is not released in hydro any more since I don't have time for catkinizing it. It does compile and work, is maintained and is being used by other people, but there is no time for catkinizing the project (written in Prolog and Java using rosjava_jni) and for us, there is no killer feature that would enforce the switch.

For new users (e.g. when using ROS for teaching), the buildsystem switch made things much more complex since they have to set up mixed workspaces and understand the relation between both build systems e.g. to debug dependency problems.

So if a majority would like to switch to DDS, much care should be given to keeping ROS's ease of use and platform- and language-independence that from my point of view have been have key success factors. And please don't forget that every client library has to be updated if the transport mechanism is changed.

best,
Moritz


On 02/14/2014 03:12 PM, Daniele Calisi wrote:
I agree with both Ryan, Shaun and Ingo: application-specific protocols (ROS or DDS or whatever needed) and, moreover, EASE OF USE.
Whatever things we are going to implement, should be reasonably working out-of-the-box, tweaking/hacking/configuring should be an option only for production phase or very big applications.


On Fri, Feb 14, 2014 at 3:04 PM, Ryan Gariepy <rgariepy@clearpathrobotics.com> wrote:
Ease of use is *critical*. We're already receiving regular feedback
that the usability of ROS is getting worse with each distribution.

-Ryan

On Fri, Feb 14, 2014 at 8:43 AM, Ingo Lütkebohle <iluetkeb@gmail.com> wrote:
> On Fri, Feb 14, 2014 at 2:27 PM, Edwards, Shaun M. <sedwards@swri.org> wrote:
>> My main concerns is Geoffrey Biggs' comment below.  Tuning should be a dirty
>> word in software.  I know it's needed, but successful software just works.
>> Ease of use should always be our focus.  It is this single issue that has
>> been the nail in the coffin of every middleware I have used.
>
> I agree on that.
>
> One could reasonably argue that the attempt to solve the communication
> problem in a relatively application-independent manner is doomed, and
> that application-specific protocols are the way to go. Some people may
> dismiss that as unrealistic, but I would argue that
> application-specific protocols are the IETF approach, and that it has
> been fairly successful, so far.
>
> That said, there is a question of what the basis for such developments
> should be, or, in other words, whether the protocols in the DDS family
> are a better foundation for robotics applications than base-level
> TCP/IP.
>
> I guess answers to that question will be influenced significantly by
> whether you're coming from an enterprise environment, or from an open
> systems environment.
>
> cheers
>
> --
> Ingo Lütkebohle, Dr.-Ing.
> Machine Learning and Robotics Lab, IPVS, Universität Stuttgart
> http://www.ipvs.uni-stuttgart.de/abteilungen/mlr/abteilung/mitarbeiter/Ingo.Luetkebohle
> +49-711-685-88350
>
> PGP Fingerprint 3187 4DEC 47E6 1B1E 6F4F  57D4 CD90 C164 34AD CE5B
> _______________________________________________
> 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



--
Daniele "MadMage" Calisi
"Your limit is always a bit beyond"


_______________________________________________
ros-users mailing list
ros-users@lists.ros.org
http://lists.ros.org/mailman/listinfo/ros-users


-- 
Dr. Moritz Tenorth     | tenorth@cs.uni-bremen.de
Universität Bremen     | Am Fallturm 1
29359 Bremen           | Germany
Tel: +49 421 218-64016 | ai.uni-bremen.de/team/moritz_tenorth