Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

If ROS had solved most problems in mobile robotics, we'd have waaaaaaaaay many more robots deployed in this world ;-) Even though ROS is extremely useful, it is just not correct to say that "most of the problems have already been solved" by it. I would agree that ROS has a good start on virtually all of the things you need to put together a robotics application...but both the field of robotics and ROS are too young to say that ROS is mostly complete.

As Dave mentioned, if you're looking for problems to solve in mobile robotics, they are endless. Just looking at hector_slam -- even though I've never used it I would bet that there's tons in just that one package that can be improved. Think of the following questions:

  • Have you read the paper on hector_slam? What are it's strengths/weaknesses? Are there things you can do to do address its shortcomings? Are there corner cases that the original code can't handle that can be improved upon?
  • Can the code be made more efficient? Can it use less memory and/or CPU? Are there optimizations that can be introduced?
  • Can the code be refactored to accommodate sensors or other technology that did not exist when it was written?
  • Did you actually run the code to see how it performs or did you just assume it was good because of the video? Was it as easy to use as the documentation said? If not, you can improve the documentation and/or code.

Everything in ROS can be improved in some manner, whether it be computational performance, robustness in the face of bad sensor data, cleaning up code, or adding documentation.

Personally I would take the approach of trying to improve what is most interesting/useful to myself. If you need a package and it exists - use it and improve it as needed. If it doesn't exist - write it. Sounds like you're interested in SLAM -- get a robot with a 3D sensor up and running and try the different SLAM packages in ROS. Evaluate how each one works, figure out the tradeoffs, and then see how you modify the code to improve it. If you think you can improve it, fork the repository on GitHub, make your changes, and then pull request to the original author to see if they will merge them.