Open Source Robotics Foundation Prepares for DRC Finals and Beyond

The Open Source Robotics Foundation (OSRF) spun out of Willow Garage three years ago this month, after having been awarded a contract from DARPA to develop the Gazebo simulation environment for the DARPA Robotics Challenge. With the DRC about to conclude, OSRF will no longer have the support of DARPA to keep itself up and running, so earlier this month we stopped by the OSRF World Headquarters and Volcano Lair in Mountain View, Calif., to talk with CEO Brian Gerkey about the future of Gazebo, ROS, and the OSRF, and to get an early look at a few cool demos that the visitors to the DRC Finals will be back to check out.

In case you’re not familiar with the Open Source Robotics Foundation, or what it does, here’s a (very) brief overview just to get you up to speed. OSRF is a non-profit organization that oversees the management and development of the Robot Operating System, or ROS. They’re also in charge of the development of Gazebo, an advanced dynamic 3D robotics simulator.

You’ve probably heard of ROS because many (if not most) of the most interesting robots that we write about around here are running it. Gazebo, meanwhile, was used to decide which of the DARPA Robotics Challenge teams got a free ATLAS robot, and has been used since then as teams develop their software (and by lots of other people for simulating all sorts of other robots).

We should also emphasize that both ROS and Gazebo are free. You can download them and use them for whatever you want, and OSRF doesn’t get a dime. Instead, OSRF relies on community involvement to help them update, upgrade, and maintain ROS, as well as sponsors to help them keep the lights on. We discussed this and other issues with Brian Gerkey:

IEEE Spectrum: DARPA has been a significant sponsor from the inception of the OSRF until just a few weeks from now, so what’s next?

It’s a really interesting point of transition for us. We got started with the promise of a contract with the DRC in the summer of 2012, and that will officially come to an end for us in the finals in June. And so there’s been this question, at least in my mind, of, ‘Can we get everything in place so that we can continue operating after that,’ or do we just end up relying too much on that one thing and then we all have to go home?

Right now, the future looks really bright. We’ve put together a portfolio of projects, including support from other government agencies like NASA, like the National Science Foundation, other DARPA projects like HAPTIX… But also, and I think this is more interesting for us in terms of feature support, we’re getting more close connections with industry. Qualcomm is one example, and I have several other examples that I can’t tell you about yet, where we’re talking with companies who are using our software and depending on it and they’re willing to support us to make improvements. I’m really interested in seeing the portion of our funding that comes from industry grow because I think that’s clear evidence that what we’re doing has real economic utility. We’re looking good, I think we’re on a really good footing after the DRC.

IEEE Spectrum: As the DRC Finals approach, what’s the status of the OSRF’s development of Gazebo?

Our role has shifted a little bit because at this point… we’re so close to the competition, and have been for a couple months now, that the teams are basically locked in to whatever they’ve got. Since [January], we’ve shifted our focus to some of the other stuff that we can do to ensure the long-term legacy of Gazebo, which is something that [DRC program manager Dr. Gill Pratt] had in mind from the beginning: he really wanted this simulator to be the legacy of the DRC.

This includes things as mundane as making it work on Windows, which we’re actually really close on now, to things more profound, like can we speed up the physics computation by parallelizing it in various ways. It’s a mixture of engineering stuff and some science stuff that we never had a chance to do. In a way, it’s been kind of nice: we had this six month run at the end where we were still responsive to what the teams want, but we’re really looking more to, what are the things that we can do in the time we have left to make sure that Gazebo comes out of this program being as awesome as we can make it.

UPDATE: “Really close?” Try finished! Mostly! Check out Gazebo on Windows here

IEEE Spectrum: Is the lack of support for Gazebo and ROS on Windows still a significant barrier to entry for users? Is there going to be a version of ROS that runs on Windows?

Absolutely, and it’s a question that we get all the time. Although, we don’t get it as often now, as people have taken for granted that it’s just not an option: they know that the answer’s going to be ‘no,’ so they’ve stopped asking. I think it’s a really significant barrier to entry for two groups of people: for people who are not software engineers; you get a lot of interest in using our tools from people who are mechanical engineers or robot designers who would like to use Gazebo as part of their workflow to design robots, test workspaces, and things like that. But, they’re used to running things like SolidWorks on Windows, and just that shift where you’ve got to install Ubuntu on a machine in order to use this tool, that's enough to keep them away.

I think it’s also had a big impact in terms of keeping folks in Asia from using ROS or Gazebo nearly as much as they could. Windows has a much much higher penetration in Asia than it does anywhere else in the world, percentage wise, historically because [Windows] had better internationalization support way back in the day. That hasn’t stopped China and Japan from being our third and fourth in hits to our documentation site. But still, I think that could grow a lot more, and it think it would if we had support on Windows.

With ROS, all effort is on ROS 2.0, where we’re rewriting the middleware system from scratch, building on top of DDS, we’re making sure that all of that works on Windows from the start. So we actually have continuous integration machines that are building and testing the code, making sure that all the tests pass on Windows. We decided that we don’t have the spare cycles to address ROS 1, to go back and make it work on Windows. We’re just going to say, ‘We learned from this experience that from the beginning, we need to make sure that it works on all the platforms that we care about,’ which for us now are Linux, Mac, and Windows. But even after we get the first version of ROS 2.0 out this summer, we expect that people are still going to be using ROS 1 for years, and we’re committed to supporting that, and that will be reflected in how we roll out ROS 2.0: you won’t need to switch wholesale, because we know that’s not realistic. ROS 2.0 can be installed alongside your entire ROS 1 system, and you can use the two at the same time.

IEEE Spectrum: Can you give us some examples of why ROS 2.0 will be worth switching over to?

Maybe you have a multi-robot system, and you want to use the new peer-to-peer support for multi-robot systems that’ll be built in to ROS 2.0. You can use ROS 1 on each robot to have the control system there, but you can use ROS 2.0 to communicate between the robots. Or, if you’ve got a lossy WiFi link, you can use ROS 1 on either side, but you can use ROS 2.0 to communicate between them. Where it becomes important, people will start to use it, and then it will eventually spread through the rest of the system. 

If you’ve got realtime control requirements: if you’ve got a walking, balancing humanoid and you need to run a control loop reliably at a kilohertz or greater, historically with ROS 1, we said, “Well, that’s your problem.’ We’re building ROS 2.0 so that you can use our code directly in a realtime loop. 

Another use case we have in mind is taking a product all the way into production and deployment into the field using ROS. We’ve seen a lot of examples of people doing R&D with ROS, getting to a prototype, and switching to something else before they actually ship. The reasons for that are complicated: sometimes they’re technical and sometimes they’re not, but I believe that one of the big barriers is people look at the core messaging system and they say, ‘This is an ad-hoc thing that you guys built yourself, and it seems to work well enough, but how do we know we can trust it?’ We don’t have a great answer for that, but I believe that it’s something that we will get by virtue of depending on DDS, which is an open middleware specification that’s been widely used throughout the world in mission-critical applications.

Since they’ve been involved in the DRC from the very beginning, it’s no surprise that OSRF will be putting on an appearance at the expo part of the DRC Finals in Pomona next month. We got an early look at what they’ve been preparing, and if you can make it out to Fairplex for the DRC, here’s some of what you’ll find at their booth:

Virtual foosball via Oculus Rift and Razer Hydra:


This demo is a sort of showcase of how Gazebo works, with a world populated by interactive objects that you can control. Objects like the ball come with parameters that are easy to adjust, so that you can (say) change the amount of friction that the ball displays, or fine tune how bouncy it is.

Destroying a stack of virtual cups with a motion capture haptic feedback glove:


Gazebo integrates very well with all kinds of hardware, including sophisticated motion tracking systems like the Polhemus. For this demo, a head tracker is coupled with a motion tracking glove that also has vibrating haptic feedback to help the user tell when they've contacted an object in simulation.

Virtual quadcopter piloting in Gazebo:


This demo wasn’t quite ready for primetime yet (hence the picture of the real quadcopter, which you won’t get to pilot at the DRC), but when it’s up and running, you’ll be putting on an Oculus Rift and then flying around virtual terrain in Gazebo as a quadcopter, FPV-style. What’s cool, though, is that you’ll be using Gazebo’s physics engine to fly a model based on the actual flight characteristics 3D Robotic’s Iris quadcopter. The controller on the quadcopter is getting simulated flight data, and as far as it can tell, it’s actually up in the air. It’s lots of open source software integrated together, and is a total community effort, which is pretty awesome, if you ask me. Getting the physics of flying robots integrated into Gazebo is still a work in progress, but there’s a lot of demand for it, and this is what OSRF does: they continually make improvements to community driven tools for the betterment of the community, and with enough support, they’ll keep on doing this until robots are solved.

So, forever.

[ OSRF ]



IEEE Spectrum's award-winning robotics blog, featuring news, articles, and videos on robots, humanoids, drones, automation, artificial intelligence, and more.
Contact us:

Erico Guizzo
Senior Writer
Evan Ackerman
Jason Falconer
Angelica Lim

Newsletter Sign Up

Sign up for the Automaton newsletter and get biweekly updates about robotics, automation, and AI, all delivered directly to your inbox.