I began using ROS about 4 months ago and am just now getting the hang of it. As i look back on how confused I was, I've noticed a few key things that made it very difficult for me to learn ROS. I'm not sure where the appropriate place to leave comments is, so dropping them here.
**ROS is shackled to its past**
ROS has grown tremendously thanks to a large, active user base. However, with that growth it has retained some relics from the past that - i believe - should never be presented to a novice, entry level user. A stark example is the choice between rosbuild and catkin. I chose to go the catkin way, and thankfully that was the right choice for the simple tasks of an entry level user. However, being presented that choice lead to early confusion, required research, and ultimately left me unsure of my path from the start. I had similar confusion over how to choose the correct version of ROS to pair with gazebo, which is no longer an issue because gazebo is automatically installed when using the ROS deb.
**Tutorials focus on writing code too early**
One of ROS's most lauded strengths is its ever growing library of open source code. However, from the beginning the tutorials focus on writing your own code rather than using the existing library. From what I've seen many entry level users want to use ROS libraries to control a simulated, ROS ready, or custom robot. This usually involves piecing together packages with launch files, much more so than writing new packages/nodes. However, there is little to no focus on launch files in the beginner ROS tutorials.
**Its difficult to figure out how to set a node's parameters**
When you rely on existing packages, much of what you do involves figuring out how to use them, and much of that is figuring out how to set parameters. For many common packages, the available parameters and their acceptable values are not well documented. If you're lucky there's info on the wiki, or maybe an example launch file. But by and large the only way to figure out what parameters are available and how they are used is to start digging through code. Imagine learning linux commands with no man pages and no -h or --help. I recognize this is more the responsibility of the package developer, but I believe documentation is an important aspect to making code accessible to a larger community with varying backgrounds and skill sets.
This is coming from an engineer, not a software developer. Perhaps these issues are trivial to others, but just thought i'd offer my perspective.
↧