Interviewing Brian Gerkey at Willow Garage

I normally write about robots in Japan on this blog but today I am going to write about a robot that is being developed in the U.S.  This is because I had the chance to interview Brian P. Gerkey, Research Scientist at Willow Garage, for the Japanese GetRobo Blog, and I felt it important for me to report this in English too at this time of era.

Willow Garage is a privately-funded research lab in California which is developing a hardware and software platform for Personal Robots - robots that do tasks for humans in everyday lives. The company is unique in that it has enough resources to "indefinitely" maintain a lab of 60 researchers without making any profit. The goal of the company is to make a positive and big impact in the robotics community by fully utilizing the open source development process.

The hardware platform is called PR2 and the software team at Willow Garage is developing the Robot Operating System (ROS) for PR2, a modular software system designed to facilitate code reuse throughout the robotics community. Brian is on the team developing ROS (led by Morgan Quigley at Stanford University) and is also the lead in developing all the applications that sit on top of ROS. Brian is well-known as the founder of The Player Project which he will explain about during the interview.

The following is an edited version of the interview with Brian (photographed below).

GetRobo: How did you get to join Willow Garage?

Brian: I was at SRI doing various kinds of robotics research. I had been there for 2 and a half years and was perfectly happy and wasn't particularly looking for another opportunity. But Eric Berger at Willow Garage whom I knew from Stanford contacted me and asked whether I was interested in joining. I was a bit wary at first since it is an unusual place. And I took a little bit of convincing to be sure.

GetRobo: What were you wary about?

Brian: One aspect of it is that I wanted to understand what the motivations were in particular of Scott and Steve, meaning that they’re running the organization so I wanted to understand what their motivations were in what they were doing. Because I’m used to places like universities where the motivation is to do science, and to do research you have to go out and get contracts to support it. Then there are places like SRI where you do science but the goal there is to get clients. And in a fully industrial setting the goal is to get clients by selling products or services. Willow Garage doesn't fit into any of those categories, so I just wanted to understand why it was that they were doing what they were doing. And eventually they came to convince me that the idea is to take this long runway approach in developing technologies by putting significant resources into a focused topic in a way that allows you to spend years working on it to get to a point where business opportunities present themselves. So we are neither living off day-to-day contract income as like a place like SRI would nor are we trying desperately to get a marketable product out the door in order to satisfy our venture capital investors like a normal startup would operate.

GetRobo: What is your role at Willow Garage?

Brian: My role is software lead for the PR2. Morgan at Stanford is the lead on ROS which is the underlying infrastructure that we are building on, and I’m the lead here in developing all the applications that sit on the top of ROS. And that involves everything from designing the architecture of the software that we are building to the determination of the development policy since we have a lot of people writing the software. We have things like testing infrastructure and coding guidelines - not all of it are my favorite things to do, but important things for a professional software development process to get going.

GetRobo: Can you explain a little about your Player Project?

Brian: Sure. By way of history, when I was in graduate school we had a variety of robots in the lab and you need some software to control them. We were interested in the artificial intelligence aspect of the robot, in other words building the autonomy into the robot. But that requires handling a bunch of low level details. With a robot you have to talk over the serial port to the laser, you have to talk over to the USB port to the robot, and you have to get the data in and out and these things are tedious to deal with but they have to be done.

Now the robot that we bought from a company that sells research robots came with some proprietary software that allowed us to control them. But that proprietary software had some problems. The biggest problem was that it was proprietary. When we had a problem we couldn't’t do anything about it. I can look at it and see that it’s not doing the right thing and if I look at the code I can fix it, but they won’t give me the code so I can’t. That was really impeding our research.

So we started from scratch and wrote Player which is basically a hardware abstraction layer for robots. It does the same job for a robot that your operating system does for your computer. It hides the details of how things are subtly different so you can plug in whatever mouse or whatever monitor you want. So we took that idea to robotics and said we have different kinds of robots, we have 2 wheels and we have 4 wheels and there are those that have legs, but in the end what they do is move around on the ground. So we can control them by saying here’s how fast to go forward, or here’s how fast to turn, that’s the mission. If you create that abstraction layer then suddenly you start to be able to ignore those low level details. And then the code you write becomes portable over robots because you programmed it against this abstraction layer and it will work on other robots that present the same abstraction. And we did the same thing for sensors. So the cameras and lasers are slightly different but hide that behind this well-defined interface and then you get portable code.

So one part of it is the abstraction layer, the other part is the library of drivers. Very much like your OS has drivers for all these different components that you can plug in, so does Player. Player has drivers to support pretty much every piece of robot hardware out there so that’s really a demonstration of the success of the open software movement.

We got this working for ourselves and the first thing we did in the beginning of 2001 was to put it out on the web, on SourceForge. We put it out there and much to our surprise we got users from other universities. One of the first contributors was a robotics group at the university of Massachusetts at Amherst. They picked it up and said hey, it satisfies the need that we have but we have a slightly different robot so we’ll write a driver for our robot. And now it supported two types of robots, and then it just took off from there. There was this time when before I would make a release of Player I would actually sit in my lab and test everything. But now, I’ve probably never seen 80-90% of the hardware. I don’t even know what they look like. And that’s because the drivers have been written by people around the world that have access to systems that I don’t. All these contributions flow into this system and benefit everybody.

GetRobo: Why are you building ROS given that Player is already there?

Brian: PR2 introduces some new constraints that we didn’t have when we built Player. One of them is real-time constraint. To safely control the arms of the robot we actually need a real-time system in there. That’s a whole computing realm in itself with particular requirements. I wouldn’t say that we couldn’t fit that into Player, but it wasn’t a natural fit. ROS is designed explicitly to allow some parts of the system to work in real-time and some parts not in real-time.

Another aspect of it is that when we built Player, we designed it to support small mobile robots that basically have a fixed configuration of sensors. If you want to know how to interpret the laser data, you can ask the robot, 'hey where is your laser?' Oh, my laser is here. That’s fine till the laser is attached to the hand which is constantly moving through space. Then having the system set up where you periodically ask 'hey where are you' doesn’t make sense anymore. You need to have the concept of changing coordinate frames built into the system. You want every sensor to report to you 'here’s my data and here’s the frame that it’s in' because now we have a robot that has sensors all over the body. In the case of PR2, the forearms have cameras in them. So as the arms move through space you always need to know where that camera is. And knowing where that camera is a combination of knowing where the elbow is and where the shoulder is where the spine is AND where the robot is in the world. So that’s one of the things we built in, the ability to talk about coordinate frames and coordinate transforms in a very natural way.

A third aspect is that Player is a client-server architecture. So there’s a privileged server that has all these drivers in it and the user writes client programs to talk to that server. That’s a perfectly good model and it’s an easy model to implement, giving the user a fairly easy job to write the client code. But you do end up with this asymmetry, where clients are not the same as drivers. So for example, clients can’t produce data that can be consumed by other clients. So if you have multiple clients and you want them to talk to each other, it's difficult. ROS is a completely peer-to-peer distributed system. Each module is the same as each other module and they can all produce and consume data. But importantly Player already has this extensive library of drivers for all these hardware pieces and algorithms, so we are pulling these into ROS.

GetRobo: And all the development is done open source?

Brian: Yes, it's open now through SourceForge. And we wanted to make a strong statement that we’re doing this open source. We are really committed to open source development . We are actually developing all code out of repositories at SourceForge. For the core of ROS, there is a handful of contributors. To the application stack, right now we have about 15 interns during the summer, grad students from some of the best schools in the country here. They’re producing code at an amazing rate. So counting them, we got in the order of 30-40 people. We have not had an official release, so there will come a point probably not too long after the end of the summer, where we look back and see what was accomplished over the summer and sort of look at what the interns have done and find a point where we will make an official release of ROS with some parts of the application stack that are ready to go.

The PR2 hardware release was originally planned in December of this year, but due to manufacturing delays, it will be more like first quarter of 2009.

GetRobo: From the software side, what do you need to accomplish by that date?

Brian: In principle it’s kind of a moving target, because the robot is a research platform, and it’s not a consumer product. We don’t have a list of guaranteed capabilities that we need to work on. On the other hand we are doing our very best to get as much functionality in there that work as we can. From object recognition to stereo computation on the sensing side. Over at the control side, path planning for the base moving around the building, motion planning for the arms so that they don’t run into the table, grasp planning so that they know how to pick things up. And we’re trying to take the best existing solutions for each of those problems and ship the robots out with an instance of each of those solutions. And we want to make sure that what we put out there works.

I want to make sure that whatever we put out there is solid and well-scoped. I don’t want to over-claim what it can do. We’re not trying to solve general motion planning, we’re not trying to solve general object recognition, that would be folly. We want to ship these modules and they do something and they always do it right but they’re open. So if you can make it better, you can come in and change them. Or if you don’t like it, the whole system is open so you can take that part out and put in a different part.

We do have a set of demos that we plan that we hope that the robot can do out of the box. So things like basic navigation around the environment so that it doesn't run into things and basic motion planning with the arms, basic identifying which is looking at an object and picking it out from sitting on the table and picking it up and moving it somewhere. So the idea is that it should have some basic mobile manipulation capabilities so that the researcher who’s interested in object recognition doesn’t have to touch the arm part in order to make the object recognizer better. The arm part is not to say that it can be improved but good enough.

GetRobo: Is developing ROS different in terms of technical aspects compared to Player?

Brian: In that respect there are a lot of similarities, what I would say is that we’re aiming for a higher degree of professionalism in ROS code than we looked for in Player code. I don’t want to degrade Player because it works perfectly well and I am still working on it. But we are trying to be a little more professional about the software development model with ROS. With ROS, we are trying to build a system that we are completely comfortable basing a company off. We want to make this an underlying infrastructure that a new company can rely on to build up its own intellectual property in the market. And that requires a certain degree of unit testing, code reviews and quality assurance process that I never put it into place for Player because I didn't need to.

GetRobo: Japan has developed something called RT-Middleware. Does it compete with ROS?

Brian: It’s been a while since I looked at RT-Middleware. I’ve read papers about it but I don’t have the details in hand to compare them. To my understanding ROS and RT-Middleware operate at the same level. I believe they would compete if you want to put it like that.

The thing is, there’s space for many different systems like this. So I think Player is the de facto standard in the mobile robot community but there are many other systems that do the same thing but with a different focus. And RT-Middleware to my understanding is more focused on the real-time aspects of the middleware. So there will never be just one system.

GetRobo: What do you think about standards? Do you want ROS to become a 'standard?'

Brian: There was an effort for standards in the past. There was an organization called the Robotics Engineering Task Force modeled after the Internet Engineering Task Force. I participated in these meetings and we met for a couple of years and tried to come up with standards for things like how do you talk to a laser, how do you talk to a camera. And it was very very difficult to get an agreement on anything of substance because you have people that have a 4 core Pentium machine on their desks and then you have the people who have a 8 bit microcontroller. Both of them want to use cameras, and you can’t meaningfully develop a standard that allows them to share code.

I think it’s probably still too early in robotics to come up with a standard. I don’t think we have enough deployed systems that do real work to have a meaningful standard. Most of the complex robots we have are in research labs. A research lab is the first place we throw away a standard. They’re building the next thing. So in robotics labs, a standard will be of not much use. They are much more useful when you get to the commercialization side to build interoperable piece. And at that point we may want to talk about standards and I think it’s still a little early.

Right now I’m much more interested in getting a large user community and large developer community. I’m less interested in whether it’s blessed as a standard by a standard’s body.