This year marks the 10th anniversary of the inception of the Robotic Operating System (ROS) — an open source robotics platform being used around the world in research, industrial, and recreational settings. The premise of ROS is simple: to simplify and standardize robotic programming, enabling faster development of robotic systems through the spirit of open source collaboration.
On September 21st and 22nd, the Open Robotics (formerly the Open Source Robotics Foundation) will convene for the fifth time for ROSCon 2017. Delegates ranging from students, researchers, industry representatives, and hobbyists/enthusiasts will meet, discuss, and present on a range of topics related to the development of ROS. Even though ROSCon is still a relatively young event, every year it has continued to grow in both number of attendees and sponsors.
In anticipation of ROSCon 2017, All About Circuits had a chance to speak with CEO of the Open Source Robotics Foundation, Brian Gerkey, about ROS, ROSCon, and the future of robotics.
Brian Gerkey, CEO of OSRF. Image courtesy of Open Robotics.
AAC: ROS was established in 2007. Since then, there have been advances and changes in technology, especially within the robotics domain. Is there is anything particularly surprising with how ROS has evolved with new changes in technology since it was established?
Brian Gerkey: We started working on ROS in late 2007. I joined the project when I joined Willow Garage in early 2008, and then really worked on it with the core development team at Willow for about two years until we hit critical mass. That was at about the time we released the PR2 which was a robot we were working on at Willow.
I’d say two things surprised me along the way: one, even before we really had anything like a finished system—and certainly before the PR2 was ready, which was really the robot we were building ROS for—people all over the world were picking it up and using it. So we were getting comments, suggested changes, and bug reports from labs all over the world where people were picking up what we still thought was this highly experimental speculative system we were building, and using it in earnest in their labs, which was really motivating, but surprising. We didn’t know it would catch on so quickly in the research community.
What continually surprises me now is the extent to which ROS is being used in deployed products and services. We really incubated the product and originally targeted it at R&D users in both university and industry labs, and now we are really seeing the growth in use is in industry where people are rolling ROS out in products. That’s everything from warehouse and factory logistics robots. There was just an acquisition announced last week where John Deere bought Blue River Technologies, which does precision agriculture, for something like $300 million. And inside their CN spray box is a camera system that looks at the ground and at the plants and decides where to apply a high concentration fertilizer that is an ROS-based robot. So that’s pretty significant commercial success for this platform we’ve built.
The PR2 Robot by Willow Garage at Maker Faire 2011. Image courtesy of Timothy Vollmer.
AAC: It appears ROS 2.0 is being developed with more industrial applications in mind with features for real-time communications and operation in non-ideal networks. Are there any particular features that you think will be a game changer for open source robotics?
BG: You are exactly right. When we started the design of ROS 2.0, we were basing that effort on the feedback we had received from people over the years, and so while there are a number of successes like the one I just mentioned [with John Deere], a number of companies are using ROS in earnest in production.
There are other cases where people are not, and they are holding back for a variety of reasons, which I could best summarize as — some of them are technical some of them are more qualitative— but there is a general sense that maybe ROS isn’t ready to be deployed in something like an autonomous car in a production environment. I’d say that’s a fairly common perception. And because we see a lot of opportunities for ROS in mission-critical environments, like autonomous cars, we want to build ROS 2.0 in such a way that people wouldn’t have any hesitation at all using it in those kinds of environments.
So that’s influenced our decisions to, for example, make the underlying message system an industrial middleware standard called DDS [Data Distribution Service] that is a system that has already been deployed and shown to be effective in a variety of mission-critical environments. We’re paying a lot of attention to real-time safe computation so that you can do things that meet deadlines if you use the system correctly.
We want to support very small embedded systems, so that is something we are working on in collaboration with ARM. They’re the main designer of the smaller no-OS embedded system with their whole Cortex M lineup of microcontrollers, where we think there are some significant parts of ROS which can be put into those environments where you have a lot more control over how processing happens. In which case, it’s somewhat easier to build safety-critical systems.
I think all of that together, as well as other kinds of process changes that we’ve made, in terms of how we develop design documentation and explain what we’re doing and why. I think all that taken together will make ROS 2.0 even more immutable for production environments than ROS 1.0.
AAC: What has been, to you, the most innovative or interesting use of ROS you have seen to date?
BG: I think the one [example] that I can’t help but go back to is NASA using ROS on their humanoid robots. They started using ROS with the Robonaut 2 several years ago for development on the ground. They did an upgrade to the Robonaut 2 that’s on the International Space Station, so that robot actually runs ROS. To be clear, it's a research platform—it’s not part of station operations in a critical way. They are still trying to figure out what can we do with the system, but we actually have ROS on the space station which I think is pretty cool. I went to Space Camp in 8th grade and this will be as close as I’ll ever get to being in space: code that we wrote is actually on a robot on the space station and that’s pretty cool.
We’ve done a number of projects with NASA over the years—we just wrapped up the Space Robotics Challenge in which we were simulating their newer humanoid robot, it used to be the Valkyrie and now it’s called the R5 that they’ve built with the DARPA Robotics Challenge. We’re also working locally with the group here at the NASA Ames Research Center to simulate a new rover that they're designing, called the Resource Prospector, that they are going to land on one of the poles of the Moon to look at subsurface water ice. That is a system we are helping them to design and simulate using Gazebo, and build a control system for it using ROS. So that’s all areas of space applications that I just I can’t help but be excited about.
Otherwise, I say that you get these examples like the one I mentioned with Blue River Technologies. Who knew ROS would find a place in agriculture? That, I think, is just the right problem to solve and it’s a really innovative application of automation. It’s really cool to see that ROS was useful there.
AAC: It's interesting to see ROS being used in so many different applications that are unexpected, like space and agriculture.
BG: That's the thing about open source—you release something open source and you have no idea what people are going to do with it and that’s one of the fun things. We use either the BSD or the Apache 2 licence, which are both what I call permissive open source licenses which basically say you can take the software, incorporate it into your product, change it, do whatever you like more or less, and you don’t have to tell us about it or ask us for permission.
On one hand, that [could] mean that the software is going to be used in a way that we are never going to find out about. On the other hand, when we do find out, it’s often being used in surprising ways [where] if we did insert ourselves in there somewhere and say, hey you have to ask us or use permission of some sort, then it wouldn’t be picked up and it wouldn’t get the scale that ROS has.
AAC: Where else do you see ROS being applicable?
BG: I think where there is a huge growth opportunity for ROS is in automotives. There is a lot of effort being put in now for everything from full autonomous driving to data acquisition with vehicles.
Here's another example, one that surprised me. A couple of years ago, there was a division of Nokia called HERE, and I knew one of the guys there and he got in touch with me to let me know they built data-gathering vehicles. They are not autonomous cars—a person drives them—but they are outfitted with lasers, cameras, GPS, and other sensors as needed to gather the kind of data you would use to build street-level maps. He wanted to let us know he built the entire thing using ROS and they have a fleet of them on all six continents, driving seven days a week.
That’s a case where it’s not traditionally a robot in the sense that it makes a decision and then decides where to go in the world. A human driving it, but it's one half of a robot—the perception side of it—and they found ROS to be the best way to build the data acquisition and storage system that they were designing. They also had a successful exit. Nokia sold that division to a group of German automotive companies, a consortium, for something like $2.5 billion.
NASA's Robonaut2. Image courtesy of NASA.
AAC: What has been your motivation to foster the development of open source and collaborative software?
BG: Motivation is a funny thing. For me, personally, I got into this work when I was in graduate school at USC in the late 90s. I was in a robotics lab and, just like any PhD student in computer science, I was meant to be working on scientific problems and developing a project to write a dissertation around.
What I found at the time was that there wasn’t really software infrastructure that you really needed to have in place in order to do the science we were supposed to be doing. What was happening was that, in every lab, somebody was taking on the task of writing the tools. Everything from device drivers to graphical interfaces—all the stuff you need to have in place before you can do any useful work. So with a couple of colleagues in the lab, we started something that became the Player Stage Project, which is a set of open source tools for robot programming and simulation. That actually spawned the Gazebo simulator, which we still develop here.
We put it up on Sourceforge, people started using it, and I found that so much more gratifying personally. To put software out there and to see people use it [was more gratifying] than what I was supposed to be doing, which was answering important scientific questions and writing papers. I did that too, but I personally get more satisfaction by putting these platforms out there and seeing what people do with them.
AAC: Looking at the ROSCon program for 2017, there is quite a variety of presentations and discussions on ROS applications and development. Is there anything particularly new you are seeing this year, perhaps a surprising new trend, that stands out from the previous ROSCon?
BG: The first trend I would call out is the automotive development. The first talk this year will be from Shinpei Kato about the Autoware system that he and his team have developed in Japan—this is a fully ROS-based autonomous driving stack. You can take the software, put it on your car that’s been outfitted to drive by wire with the appropriate sensors, and, in a relatively short period of time, arrive at a fairly capable autonomous vehicle. This isn't a product you can sell or that has been certified in any way, but it's a starting point for whatever it is you are doing with autonomous driving. That’s all open source. Other than that talk, we have one from Daimler AG, and some from a group in Switzerland [ETH Zurich and AMZ] talking about the autonomous car work they are doing.
Otherwise, I'd say that there is a lot of attention these days paid to simulation. Developing robotics applications is hard because it has all the elements of software problems, but you are also dealing with the physical world. You're also often developing the software at the same time that you are developing the hardware. Having access to a good simulator is really important in being able to develop systems efficiently. There will be a talk from us about what we did with the NASA Space Robotics Challenge, which is a class of challenges using NASA’s Valkyrie or R5 robot, [and there is also] Greg Dudek and his group form McGill University using Gazebo to simulate an underwater robot that they do experiments with.
[There is also a presentation] from our group on using Gazebo for vehicle-city simulation. So, that’s kind of a crossover point where it’s one of the applications of simulation specifically in the automotive domain, where I think we’re going to need a lot of really good simulation technology to convince ourselves that the autonomous car products that are being built are actually safe enough to use.
The PR2 robot in a Gazebo simulation. Image courtesy of ROS.
Let me call out one other trend: security. That’s something that historically we did not pay a lot of attention to. In fact, we designed ROS in the beginning with explicitly no security features and [did not incorporate] security features in ROS because we are not security experts—rather you need to know how to deploy the system in a secure environment. You need to use a VPN, physical security, and things like that.
But now that ROS is being rolled out into products and being used in earnest in a bunch of government programs, there is much greater attention being paid to security. So, we are having two talks this year, one from our group one form another group, on different ways to add security features to ROS so that you can get more of a layered approach that is more appropriate for being used in a fielded system.
AAC: Is it still a principle in ROS 2.0 that security is on the user and not on the development of ROS?
BG: No, that’s actually something that we changed fundamentally in ROS 2.0. I mentioned earlier that ROS 2.0 is based on the industrial middleware standard called DDS. That standard has an extension that was ratified last year called DDS Security, and it specifies how to do on the wire security in everything from authentication to encryption, up to access control and a couple of other features. So, that’s something that we are explicitly leveraging in ROS 2.0.
At some level, it is still up to the user. You have to decide how to use it, you have to know how to configure it, and you have to understand it well enough to use it in a reliable way. But now it is built in from the ground up as opposed to being put in afterwards, which is all we could do with ROS 1.0 as it exists today. Since it is 10-year-old code, there are only so many intrusive changes that you can reasonably make.
AAC: Are there any misconceptions or inaccuracies about ROS that keep coming up that you want to correct?
BG: I would say that the biggest [misconception] is that ROS is not appropriate for use in products, and that can be trivially proven false just by example. You can look at Blue River Technologies, then you’ve got companies like Fetch, Clearpath, Locust, Six River, and Savios that are all selling or leasing ROS based products that deliver in a variety of environments. And there are plenty of other examples out there. That’s probably the biggest one I would want to challenge.
Another [misconception] is that you can’t [achieve] real-time control with ROS. It gets a little more technical, and even that is not strictly true. With ROS 1.0 as it exists today, there are plenty of examples of mixing ROS with a real-time safe system. It’s a little harder than it needs to be—but even way back in the days of when we were building the PR2, it had a real-time control component to it which runs reliably at 1 KHz in order to [achieve] stable control of the entire mechanism. And that we built with a bunch of infrastructure so, you have to use different APIs but it mixes well with the ROS system. So that is something that absolutely can be done, and lots of groups do it, but often people look at it and say you can’t do real time and that’s not true.
AAC: There are companies using open source platforms, like ROS, in their products. What are your thoughts on the monetization of ROS and how do you think open source platforms like ROS and intellectual property protection can co-exist?
BG: Those are a good couple of questions. So, first of all, how can open source and intellectual property protection coexist—I think that’s easy. We choose to license our software under BSD license [for previous code], and these days for new code we use the Apache 2 license. Those are licenses that are both very clear in what they allow and what they do not allow. Some people, if they are not that well-informed about the nuances of open source, they [might believe they] can’t use open source in their products because then they’ll have to give away their IP, and that’s just not true at all. You can absolutely take the software we’re using, you can build it into your product, and you can sell it. And you don’t owe us anything and you don’t have to change anything about your IP.
So, I think that there is ongoing education that needs to be done so that people understand that there are open source licenses—in fact, the vast majority of open source licenses—permit that kind of use.
Monetization is a little more complicated. Certainly, there are companies out there that are monetizing applications and products that are based on ROS, so they are building products and services and selling them, and that’s a pretty well-understood path forward.
AAC: What do you think the future of robotics will be—particularly open source robotics?
BG: I think that the future of robotics is very bright. I think we’re finally at the point where just around the corner we are going to see robots and robotic technology deployed widely.
People have been using robots in automotive factories since the 60s, but it’s been a long time coming for us to actually experience robots in our daily lives. I think we are finally just about there. I think we’ve cracked enough of the hard algorithmic problems to do with localization and navigation. We’re still working on manipulation but we’ll get there.
Along the way, we’ve gotten enough advances in the sensors and actuator design, as well as all the supporting open source software, that now it’s actually straightforward to start a company, design a product, and get it out on the market in relatively short order. I think that is encouraging more people to come into the field.
Like I said earlier, we never know who is using our tools or who is using other open source system but I think it is fair to say that the vast majority of the people active in this field right now are using ROS and/or Gazebo in some way as part of their development process. So, I think we are going to see more and more of ROS-based products, and more and more Gazebo simulation software.