The Open Source Robot Operating System (ROS) and AWS RoboMaker

中文版

“There are certain problems within the robotics community that, at this point, are well enough solved that everybody kind of understands and more or less recognizes that this is the best approach to solve that problem. And so, wherever we can in the ROS community, we take those algorithms, implement them in open source libraries, and then provide them so that everyone can take advantage of them.”

~ Brian Gerkey, CEO and Co-founder of Open Robotics

Brian Gerkey, Open Robotics

Reinventing the wheel, or in this case, the robot, was a problem that Brian Gerkey and his colleagues set out to solve over a decade ago. They recognized that too much time and effort was being spent by graduate students building robots from scratch in academic research labs.

What if they developed a robot programming framework that captured the best of what had already been proven effective and provided a jumpstart for students building robotics applications? And what if they open sourced it?

That’s exactly what they did.

If you’re into robots or open source, then you’re in for a treat. Adrian Cockcroft, AWS’ VP of Cloud Architecture Strategy, recently spoke with Brian Gerkey about the Robot Operating System (ROS) project and how AWS’ recent announcement on AWS RoboMaker will benefit both the ROS community and AWS customers.

Brian, please introduce yourself and tell us more about the ROS project.

My name is Brian Gerkey, CEO and co-founder of Open Robotics, where we develop open source software for use with robotics. Our two main products are ROS and Gazebo. ROS stands for Robot Operating System, but it’s not really an operating system. It is better understood as a Software Development Kit (SDK) that you use to develop robotics applications: it provides you with the software, libraries, and tools that you need to develop, debug, test, and eventually deploy your robotics application.

Alongside ROS, Gazebo is a 3D, physics-based simulator for robotics apps, with the ability to simulate robot populations in complex indoor and outdoor environments. These robotics apps may or may not be developed with ROS, but most of them are.

Building robotics apps with ROS and Gazebo is akin to mobile development environments, such as Android or iOS, where developers can use tools and libraries that provide building blocks, levels of abstraction, common UI elements, and a simulation environment to test in before deploying the application to hardware.

How long ago did ROS come about? What is its lineage?

We are celebrating our 11th anniversary this month. In 2007, we made our very first commit to SourceForge, the original home of ROS.

ROS’ heritage goes back to a collaboration between Stanford University and Willow Garage, a robotics incubator, who teamed up to design a new open source robot programming framework. The intent was for it to supply researchers in primarily academic labs with the tools they needed to do science with robots. Since then, ROS has developed into something that is widely used in industries outside the lab.

If I can go back a little bit further, we can trace ROS back to a project called Player that I and some colleagues developed at USC in the late 1990s. Many parts of Player have been incorporated into ROS.

When we say “robot,” lots of different things come to mind – from a robotic arm to R2D2 and so on. What’s the scope when we’re talking about robots? What are they typically used for?

I’m glad you asked me what it’s used for as opposed to asking me to define a robot! Where ROS is most useful is in a system where you’ve got a combination of sensors and actuators that are interacting with the physical world. In other words, you’ve got something that is taking in data that needs to be analyzed so that a decision can be made and action taken. That action goes out in the form of a command to, let’s say, a motor.

One of the best-understood use cases for ROS are robots that move materials around in factories or warehouses. So you’ve got a robot, a device on wheels, that carries some useful objects or materials. It senses its environment, keeps track of where it is, where it needs to go, and how to get there – not to mention the obstacles in its way.

But there are broader examples. It’s not just wheeled robots. It’s anything that has a pattern of taking in data from the world, doing something with it, and then deciding how to act in the world. That’s where ROS is really handy.

To clarify, when we talk about robots, this will go all the way from small, battery-operated devices up to the full range of huge machinery, right?

Yes, absolutely. I would guess that the vast majority of ROS-based robots are battery-powered because they tend to be mobile. However, this doesn’t mean they’re resource-constrained.

For example, the PR2 robot we built at Willow Garage in 2010 was battery-powered. It was the robot for which we designed ROS and was aimed at being used by researchers when it went out to their labs. It was, in fact, the most powerful computing system they had in many of these labs. It was a thoroughly sophisticated compute system in a robot.

So when it comes to robots, you can go up from there and talk about a fixed manipulation system in a warehouse environment where you’ve got unlimited power, and you can go all the way down to a very small embedded system.

It seems like ROS has a lot of plug-ins for incoming sensors of different types, and then more plug-ins for different kinds of actuators. Is that how ROS is structured – with a core in the middle that’s figuring out what to do next?

Yes. In fact, ROS is sometimes called middleware because what it’s doing is providing the plumbing to get messages routed between the sensors and the algorithms that process them and then between the algorithms that take the data out of the sensor processing step and route them out to the actuators. What you end up with are implementations of best-in-class drivers, algorithms, and tools.

As robots move from academia into real production use, we also see a move to ROS 2. What was missing in the original ROS and what has been added to ROS 2 to make it more commercially capable?

I’ll start with the technical aspects that were missing from ROS 1. We developed the middleware system in a custom fashion. The way that messages are defined, how they’re serialized to be sent from one machine to another network, and the way that communication actually happens – that was all part of a bespoke system we developed.

It works well enough, but it was missing certain features like quality of service, where you can differentiate between different data streams that say this stream’s more important than that one, for example. There was also no provision for real-time computations. So these are the kinds of things that are missing from ROS 1 that we’ve targeted explicitly in ROS 2.

In ROS 2, we’re building on top of an open industrial standard called Data Distribution Service (DDS). We support multiple implementations of the DDS standard under the hood, including both open source and closed source. And then we build on top of that to provide all the hooks you need to develop your robot application efficiently.

Another aspect in ROS 1 that was missing is security. ROS 1 doesn’t have any computer or cyber security features built in. Once you are part of the ROS 1 network, you can access all of the data streams. That was by design; it wasn’t an oversight. We did that because we were primarily targeting a research environment where that kind of flexibility is paramount. In ROS 2, we are taking advantage of the DDS security specification, which allows us to provide authentication, encryption, and access control.

Those are some examples on the technical side. Let me talk more on the communication and design side. I think that ROS 1 suffers from its heritage in a way, because it’s understood that it grew out of a research community, and that has made it very flexible. It’s caused it to be very widely adopted and get a lot of participation, but that story gives pause to certain product managers in large companies who say, “Wait a minute. I understand what you’ve built, but you’re telling me it was designed for use by grad students and labs? Maybe I don’t want to put ROS into my product.”

That’s why we made the painful and costly decision to rewrite the system from scratch as opposed to iterating in place. We are now able to tell those people that we took in all their feedback and started from the beginning, using the same overall philosophy in terms of building the system. Now we’re targeting ROS for production use cases. We’re changing our development process to be more amenable to the demands of the user communities that we’re hoping to satisfy with ROS 2.

Regarding contributions, you have a technical steering committee that many have joined, including Amazon. With ROS, we’re looking at a relatively large project with a lot of different pieces. Where are the main places open source contributions are coming from – input/output devices, algorithms, or core system debugging? I know that Amazon has contributed some migration tools. Where do you see the biggest need?

Amazon and many other large companies have joined the ROS 2 Technical Steering Committee. The threshold for joining is committing at least one engineering FTE (Full-Time Equivalent) to make open source contributions to the core of ROS 2. This is not a fundraising effort. We’re really trying to entice large organizations to put their engineering effort into ROS 2.

We’re seeing core ROS 2 contributions in two key areas. As you mentioned, the first area is migration – for example, migrating existing ROS 1 packages to ROS 2 and also generating migration tools. Amazon is helping out here. And Intel is taking the lead on the ROS navigation stack. We’re directing where we can, but they’re mainly working independently of our team – which is great!

The other area is features and tools that don’t exist in ROS 1 because the underlying hooks aren’t there. A good example is security, like I mentioned earlier. Since ROS 1 doesn’t support security, there is no way to manage keys. For ROS 2, ARM is contributing the underlying libraries to generate and store keys in the Trust Zone side of their processors.

Is ROS built on Linux or on a real-time operating system (RTOS)?

Historically, ROS has been used almost entirely on Linux. This is where we do most of our development. Starting with ROS 2, we are explicitly supporting Linux, MacOS, and Windows, and we’re already seeing developers and users benefit from our support for those platforms.

We’re also seeing growing interest in deploying ROS 2 on a variety of embedded systems, from single-board computers that run either Linux or a real-time environment like QNX, to microcontrollers that don’t have a full operating system. In that latter category, Renesas recently announced their work enabling smart sensors and actuators that can “speak” ROS 2 directly using low-power microcontrollers.

What if someone asks: “Hey, I like robots” and wants to help out, what do they need to know to contribute to ROS 2?

Like ROS 1, ROS 2 is a multi-language system, primarily based on C++ and Python. Those two languages tend to be the ones most often used in robotics apps, get the most attention, and are how a lot of the core pieces were written.

So, ideally, you’ll be the kind of person who has great skills in one or both of these languages and has an interest in robotics. And you don’t have to be a robotics expert. Frankly, a lot of the work we do is not terribly robotics-specific.

As a GitHub project, does ROS tend to get forked before it gets embedded in something, or are you trying to encourage developers to contribute back into the mainstream version?

We always encourage everyone to contribute everything they possibly can back upstream. Practically speaking, if you’re going to take the code and put it into production, as with anything you receive from the outside, you will probably fork it, if only to freeze it at a particular version before you deploy it. I know that not everything comes back, and that’s fine, but we try to get back as much as we possibly can.

Tell us about your plans for a Long-Term Support (LTS) version for ROS 1.

As I mentioned earlier, ROS is 11 years old this year. The project has a lot of users around the world; we estimate hundreds of thousands of users. We do a LTS release every two years. Our last release went out this past May. The next ROS 1 LTS release will be in 2020.

At Open Robotics, we are primarily focused on ROS 2, and we want as many people as possible in our community to contribute to ROS 2 development when the time is right for them. Having said that, we know there’s a large deployed codebase out there that depends on ROS 1. We need to make it as easy as possible for people to make the ROS 2 transition.

Our belief is with the upcoming ROS 1 LTS release, and depending on how quickly ROS 2 development happens, it will be possible for most users to transition to ROS 2 by 2020, if not earlier. Migration tools, shim libraries, migration guides, and other documentation will help make that transition easier.

Where are you looking for people to contribute more? And how are you building open source community around this?

As an open source project, we do all the normal things. Communication happens in the community through issue trackers, pull requests, comments, code review, and stuff like that. Most of the code is hosted on GitHub. We use Discourse, which is a discussion forum that works like a mailing list, and we also host an instance of Askbot, which is a Q&A forum similar to Stack Overflow.

On the conference front, annually for the last seven years, we’ve hosted a developers’ conference called ROSCon. This year in Madrid, we sold out the event for the fourth year in a row, with over 500 attendees and 47 sponsoring companies. It’s a fun way to bring the community together and meet people face-to-face.

We also tried something new this year: we put on our first local edition of ROSCon in Japan. It also sold out, with almost 200 attendees. I don’t speak Japanese, but I was able to give a presentation that was translated for the audience.

How many robots go to ROSCon?

Sony has successfully demoed their robotic dog, Aibo, on stage at ROSCon JP—but that’s an exception. Having worked with robots for a while now, I can appreciate the difficulties of making a live demo work. It would be great to see more robots on stage, but we do have plenty of robots in the exhibit area. It’s up to the exhibitors to decide whether they want to bring them or not.

What does the ROS community get out of AWS RoboMaker?

We already mentioned that Amazon has full time engineers working on contributions to ROS 2, and has already released some open source tools that help migrate from ROS 1 to ROS 2. However, a major barrier to entry for many ROS and Gazebo users historically has been getting their development environment up and running on local machines. Up to now, it has worked best on a particular kind of Linux machine with a certain type of graphics card and the right drivers installed. That’s expensive and a lot of work to get set up right and stay current.

With AWS RoboMaker, Amazon has smoothed the path to entry, making it possible to develop and test robotics software, with full simulation, from any platform, at a low cost, and with a free tier for trying it out. AWS RoboMaker handles simulation and deployments of software and updates to individual robots and fleets of robots.

What Amazon has contributed with this new service offers the promise of being able to develop robotics apps much more easily. All of the dependencies and installation headaches get pushed to the cloud, making it easy for ROS users to access all the same tools and libraries without having to install anything locally.

Now that’s exciting! Like the AWS SageMaker release a year ago, which made advanced AI algorithms accessible to any developer and easy to deploy, AWS RoboMaker makes robotics accessible to a much wider audience. AWS SageMaker and AWS RoboMaker can even be used together to deploy AI models to fleets of robots.

If you’d like to learn more about AWS RoboMaker, check out Jeff Barr’s post – AWS RoboMaker – Develop, Test, Deploy, and Manage Intelligent Robotic Apps.