Once you contribute to the community, who manages all of that?
One of the interesting aspects of the ROS community is from the beginning we structured it with what we call a federated development model. By that I mean that here at OSRF, we maintain control of the core system. Not all of the ROS software is stored in one place. It is stored in thousands of different repositories around the world. We did this on purpose, and what we tell people is if you want to contribute to ROS, then the way you contribute is you create a repository at a place like GitHub or Bitbucket and put your code there. If you tell us where it is, then we will add it to our index and we’ll make sure other people can find it. It becomes part of the ROS ecosystem, but it is up to you to manage it, maintain it and release it when you want with whatever license you want.
Of course we want to make sure that the core system is working properly, and so the core tools are maintained by OSRF employees and a handful of people from other organizations, and we collectively are doing quality assurance and making sure we have test suites in place for the stuff that we maintain.
Why is ROS well suited for the new industry of drones?
It is fascinating for us to see this because this is an industry that didn’t exist at the time we were developing ROS, so we certainly didn’t design for this use case. I think it is a good fit for a couple of reasons: One is that right now the drones you can buy have basically a GPS autopilot on them, a little embedded microcontroller that can autonomously take off, hover, go to a GPS waypoint, and it can land.
What is hard with the current drones is the ability to extend that capability. If you want to plug in a camera or a laser ranging device or something else, and add a new capability like flying around and using the camera to avoid obstacles along the way, that is not something that is built into today’s drones, and it is not something that is easy to add on to that really kind of special-purpose GPS autopilot.
What people are doing now is adding a second small computer, they call it either a companion computer or sometimes a copilot to provide a full suite of peripherals to plug in. You can plug in all your USB, Ethernet and whatever-based sensors, and now essentially you have a classic robot problem there. You have a reasonably powerful computing environment, you are running Linux, you can put ROS in there and you are building up the representation of the world. You are deciding what path to take and so on, and then the output of that is you are generating commands down to that GPS autopilot, which is a perfectly capable system that you can make smarter by adding another computer and better software.
The second reason is that drones by nature are a difficult thing to test. Every time you make a change (and it is a bad change), you probably are going to break the drone if you are testing the physical drone, so what you need is a really good software-based simulation of the drone in order to be able to test changes without breaking all your equipment, and also to be able to test every change in a variety of situations across a variety of vehicles. In addition to running ROS onboard, there is increasing interest in using Gazebo, which is an open-source robot simulation project we maintain. People in the drone community are now starting to use it as their simulation test bed together with ROS based software on the vehicle.
What does the future of ROS look like? What can we expect in 2016?
Based on what I have seen this year, I expect to see much more use of ROS in two areas that are frankly the hottest in robotics around the world, and that is drones and cars. Self-driving cars and driving assistance systems are a really hot topic of research right now, and we have seen a lot of interest from car companies, equipment suppliers, and startups who want to use ROS as part of the software infrastructure for their cars, so I think we will see a lot more of that.
From the development side at OSRF, we are focused on ROS 2.0. Now that we are about 8 years in, we have been working for the past year in earnest on a rewrite of the core communication system. The way that we are doing that is we are building on top of an industry standard for communication middleware called DDS because it brings us a whole bunch of new capabilities that we didn’t have with our old communication system. It also makes it easier for both government agencies and companies to prove that their software is working in a reliable fashion because the DDS communications middleware is used already in mission-critical applications by the U.S. Navy and NASA and a bunch of other companies and agencies.
So we expect to see ROS 2.0 next year, I would say probably in the summer to the fall when there should be enough of the system in place that people can start to experiment with it, and maybe switch over to a mix of ROS 1 and ROS 2.