[ros-users] ROS & DDS

[Francis Belliveau]

On Feb 14, 2014, at 10:12 AM, Jonathan Bohren <jonathan.bohren at gmail.com> wrote:

> As others have said, usability is critical, and the ROS learning curve has only been getting steeper and steeper.
> 

I have trimmed out most of Jonathan’s reply and the thread content because I wish to respond to this one statement along with a few that others wrote on this subject.  There is also the following:

On Feb 14, 2014, at 9:14 AM, Armstrong-Crews, Nicholas - 1002 - MITLL <nickarmstrongcrews at ll.mit.edu> wrote:

> Resonance.
> 
> I might suggest:
> ...
> Doing it right will take some work, but I think it'll be worth it to enough
> people, and the advanced features can be spooled out incrementally over
> time.
> 
> Thanks,
> -Nick


Again paraphrased for brevity.

My important contribution to this discussion is that I believe it critical to the success of ROS that you listen to both of the above responses an “make it simple” and as transparent as possible.

That being said, you can stop reading here if you do not want to know the story of this ROS new-commer’s experiences trying to get ROS to do something that he feels should be simple.

--------------------------------------------------------------------------------

First I must introduce myself as a highly experienced embedded software engineer with minimal ROS experience.  I understand ME, EE and CS reasonably well, but have little robotics training.  In summer of 2012 I joined a robotics team in competition and was able to stand up a number of ROS nodes, using Fuerte, with very little trouble.  My efforts were isolated to redundant multi-path communications between out multiple robots each running on-board ROS.

Having wishing to know more about robotics and deciding to switch hobbies, from amateur radio, I bought a robot kit in January of 2013.  It is an Arduino-based hexapod with an underdeveloped control system.  My goal was to add a camera and control it from ROS.  I figured that the ROS model of this robot would provide a number of useful examples for the future.

Time lapsed for a number of reasons that are not pertinent.  
In the fall of 2013 I  began my “ROS integration” thinking that a URDF model was where I should start.  The two tutorials that I was following led me to upgrading to Groovy and then dead-ended when something was not compatible with Groovy.  I posted a number of questions, but the important ones were probably so broad in scope that I got no useful answers.  I have since decided that the URDF “Beginner tutorial” assumes intermediate knowledge of basic ROS development frameworks that I do not yet have.

The shift from Fuerte to Groovy came with the need to change to catkin.  Now there are nearly two more upgrades that I am faced with in order to “keep-up”.  The need to try an keep up with the incompatibilities that these upgrades seem to come with, makes me wonder if I will be able to complete the task and maintain it properly.

I say this as an example of one new user’s frustration that has been caused by the lack of “upgrade” path.  I believe that the ROS community needs to acknowledge that there are a lot of users with widely varying backgrounds.  Even though we do not pay for this “product”, it should be managed like a product.  As such I believe that the following rule should apply to ALL changes of all kinds:

When a change produces an incompatibility in development files, a tool should be provided to convert the information in older format into the newer one.

Changing the middleware in use may not be so easy to “automatically upgrade”, but it should be possible to either hide the change, because nobody should be modifying the middleware, or to automatically find the places where the middleware access may be incompatible.  Guidance on incompatibilities should always be included.

Thanks to those who read my little story.  I hope that is explains why I feel strongly about the need for simple upgrade paths.

Fran
On Feb 14, 2014, at 10:12 AM, Jonathan Bohren <jonathan.bohren at gmail.com> wrote:

> As others have said, usability is critical, and the ROS learning curve has only been getting steeper and steeper.
> 

I have trimmed out most of Jonathan’s reply and the thread content because I wish to respond to this one statement along with a few that others wrote on this subject.  There is also the following:

On Feb 14, 2014, at 9:14 AM, Armstrong-Crews, Nicholas - 1002 - MITLL <nickarmstrongcrews at ll.mit.edu> wrote:

> Resonance.
> 
> I might suggest:
> ...
> Doing it right will take some work, but I think it'll be worth it to enough
> people, and the advanced features can be spooled out incrementally over
> time.
> 
> Thanks,
> -Nick


Again paraphrased for brevity.

My important contribution to this discussion is that I believe it critical to the success of ROS that you listen to both of the above responses an “make it simple” and as transparent as possible.

That being said, you can stop reading here if you do not want to know the story of this ROS new-commer’s experiences trying to get ROS to do something that he feels should be simple.

--------------------------------------------------------------------------------

First I must introduce myself as a highly experienced embedded software engineer with minimal ROS experience.  I understand ME, EE and CS reasonably well, but have little robotics training.  In summer of 2012 I joined a robotics team in competition and was able to stand up a number of ROS nodes, using Fuerte, with very little trouble.  My efforts were isolated to redundant multi-path communications between out multiple robots each running on-board ROS.

Having wishing to know more about robotics and deciding to switch hobbies, from amateur radio, I bought a robot kit in January of 2013.  It is an Arduino-based hexapod with an underdeveloped control system.  My goal was to add a camera and control it from ROS.  I figured that the ROS model of this robot would provide a number of useful examples for the future.

Time lapsed for a number of reasons that are not pertinent.  
In the fall of 2013 I  began my “ROS integration” thinking that a URDF model was where I should start.  The two tutorials that I was following led me to upgrading to Groovy and then dead-ended when something was not compatible with Groovy.  I posted a number of questions, but the important ones were probably so broad in scope that I got no useful answers.  I have since decided that the URDF “Beginner tutorial” assumes intermediate knowledge of basic ROS development frameworks that I do not yet have.

The shift from Fuerte to Groovy came with the need to change to catkin.  Now there are nearly two more upgrades that I am faced with in order to “keep-up”.  The need to try an keep up with the incompatibilities that these upgrades seem to come with, makes me wonder if I will be able to complete the task and maintain it properly.

I say this as an example of one new user’s frustration that has been caused by the lack of “upgrade” path.  I believe that the ROS community needs to acknowledge that there are a lot of users with widely varying backgrounds.  Even though we do not pay for this “product”, it should be managed like a product.  As such I believe that the following rule should apply to ALL changes of all kinds:

When a change produces an incompatibility in development files, a tool should be provided to convert the information in older format into the newer one.

Changing the middleware in use may not be so easy to “automatically upgrade”, but it should be possible to either hide the change, because nobody should be modifying the middleware, or to automatically find the places where the middleware access may be incompatible.  Guidance on incompatibilities should always be included.

Thanks to those who read my little story.  I hope that is explains why I feel strongly about the need for simple upgrade paths.

Fran