Sharing software with ROS

Abstract

Robot operating system (ROS) is designed to promote code sharing and enable the development of opensource robotics commons. Sharing code will help the robotics community to progress faster by letting the researchers in the community replicate and extend the results of other research groups. ROS makes it easy to find the software and integrate it into robot systems. In this issue, we’ll discuss how sharing is facilitated by the ros.org Web site, look at some examples of code being developed and refined at different sites, and finally consider the personal robot (PR2, version 2) program, which is making the common hardware available to accelerate robotics innovation. Willow Garage is setting an example of code sharing by creating and releasing a set of mature and stable software stacks, and other institutions around the world have been following suit. ROS contains the software stacks for everything, from building blocks such as controllers and filters to applications like autonomous navigation. Breaking Down the User/Developer Divide A successful open-source project can attract a staggering number of users. Most of them will strictly use the software, a minority of them will report problems or ask questions, a smaller minority will yet provide bug fixes or minor enhancements, and only a tiny percentage will become developers and contribute heavily to the project. With ROS, we are aiming for a substantially different mix. While a small development team works well for many projects, the endeavor to build a robotics commons is too broad and varied in scope to be accomplished by any single group. We need help from experts in all of the areas that make up the interdisciplinary field of robotics, from lowlevel control to high-level reasoning, and everything in between. With the goal of enlisting those experts as contributors, we made three key design decisions in ROS. First, we enforce symmetry in the development and runtime environments. ROS development is governed by a package system, with no one package more privileged than another. Code is added to ROS by simply creating a new package. Similarly, a running ROS system is a graph comprising nodes, with no one node more privileged than another. The way to add functionality to a system is to launch a new node. The users naturally become developers, because their work can be reused by others. If you create new functionality in your work, we can easily take advantage by adding your package(s) to our ROS installation and launching your nodes on my system. We build on this symmetry in our second design decision; instead of going through an official gatekeeper, ROS code is maintained in a decentralized federation of repositories. When someone asks, “How can I contribute to ROS?” our answer is, “Create a publicly accessible ROS repository.” By hosting their code in their own repository, the user developers retain control over their software (deciding on licenses, development policies, etc.) and get credit for their work (by convention, repositories are named after the contributing institution). The overhead of maintaining a repository is minimized by the use of community-hosting sites such as SourceForge.net, Google Code, and GitHub. To see the benefit of the federation model, we have to only look at the repositories hosted by the ROS community. At the time of writing, we know of 18 public repositories that are maintained by institutions other than Willow Garage, and they collectively host 300 packages.