My first experience with ROS was when my students and I started working with a prototype PR2 at Willow Garage in early 2010. We had been developing new algorithms for handling cloth items, such as towels, and needed a robot to experimentally test and validate our ideas.
Even at that early stage of development, it was impressive to see the extent of the capabilities offered by ROS, as well as the level of their integration. The low-level tasks, from sensor access, to diagnostics reporting, to power management, were transparently handled by ROS. And so were higher-level tasks, from a variety of arm controllers, over 1-D and 3-D perception, to autonomous navigation.
ROS has been an accelerator for the research in my lab. Thanks to the many building blocks provided by ROS, students in my lab have been able to spend their time on the specific research problems they are studying, rather than on implementing the many necessary, but unrelated parts of the system. This freedom to focus is incredibly important in our field, where the interdisciplinary nature of the work involved can make the most talented and promising specialist into a frustrated generalist who builds a navigation system when they should have been working on their novel learning or manipulation algorithm.
When we set out five years ago to reinvent the manufacturing industry, we knew that smart, flexible automation was the key. We built our Baxter robot to work not just for people, but with people, removing the cumbersome safety cages and expert-only programming interfaces that had come before. And when we built Baxter, we built it on ROS.
From the beginning, our goal at Rethink Robotics was to build a versatile, affordable, and interactive production robot that would provide value to customers right out of the box. Naturally, we faced many technical challenges. Some of the challenges, like designing an intuitive human-robot interaction system or low-cost yet high-performance mechanical systems, are our specialty - excelling in those areas is what sets us apart and that was where we chose to focus our resources. There were other elements of the system that we could have chosen to do in-house but instead relied on ROS for convenience and time-to-market. Being able to rely on ROS for system integration tasks freed up our team to focus on our areas of expertise, and helped us to ship a successful product, saving time and money along the way.
Now that ROS is in our DNA, we're also able to work hand-in-hand with the research community. With the release of the Baxter Research Robot, we've made a serious commitment to foster a vibrant developer ecosystem in the research community, including an open source SDK and an active discussion forum with hundreds of participants. We're shipping quite a few Baxters to corporate and academic labs around the globe, with high hopes for what the next generation of developers will be able to do with this ROS-powered robot.
Back in 2009, I was in the middle of programming my own general framework for robotics using Windows and C# when I came across a video of the Willow Garage PR2 plugging itself into a regular wall socket to recharge. Without another thought, I deleted every line of code I had written over the past two years, installed Linux over Windows and jumped on the ROS train.
Thanks largely to the foundations laid by the original programmers at Willow Garage, ROS enables even hobby robot builders to think big. Right out of the box, a ROS user can do SLAM, robot simulation, 3D object detection, skeleton tracking, arm navigation, task management, face tracking, text-to-speech and speech recognition. And you don't need a PR2 to get started; there are now ROS drivers for low-cost hardware options such as the Arduino, Dynamixels, Lego NXT(TM) and the TurtleBot.
My own interest in ROS has always been two-fold: first, to prove to myself that almost anyone can learn to run ROS on hobby-level hardware; and second, to share what I have learned with others. To that end, I have posted a number of ROS tutorials on my website and I wrote the first ROS book for beginners called ROS By Example.
The ROS community owes a great deal to the folks at OSRF for taking stewardship of the core ROS packages and the ROS Wiki. As a result, ROS will no doubt have a long and illustrious future which is good news for robot builders everywhere.
ROS forms the basis of our lab's infrastructure and is an invaluable tool in my everyday work as a graduate student studying robotics. ROS provides an easy-to-use framework for setting up robots in our lab, and open-source software stacks such as navigation allow our robots to quickly get to an operational level with minimal effort.
Since our research deals with high-level applications like multi-robot coordination and robot task planning, using ROS as a robust backbone means that we don’t end up spending all of our time on low-level details. Instead, we can devote more time and effort to what we’re most interested in, which is our research. Whenever we’ve used a commercially-available sensor or other peripheral on our robot, we’ve typically found a ROS driver readily available for it. And even when we're building custom devices and writing our own drivers, if we design them to use the established ROS message structures and conventions, we can immediately leverage the standard visualization and analysis tools.
We also benefit from the modular development model that is encouraged by ROS. The ROS packaging system provides a natural mechanism for achieving separation between different pieces of our code that can be independently implemented. We use our robots to teach freshmen undergraduate students about robotics research, and this separation model enables them to work on simple projects without having to worry about how the entire system works. In a more complex research setting, different students can take responsibility for implementing, maintaining and documenting code for different components and projects. As students come and go through the lab, it's critical that we can package up code in this way to make it usable by students who are unfamiliar with it. As an added bonus, the code in our public repositories is automatically indexed on the ROS wiki, where we document it when we distribute our code using the ROS Release system alongside paper publications.
My job is to turn science into technology. Our team bridges the gap between laboratory demonstrations and reliable systems, aiming to put those systems to work in next-generation Bosch products.
We employ ROS in our R&D work and were one of the first non-academic institutions to have a PR2. We continue to use and contribute to ROS for several reasons. Whether we're designing a new robot or reprogramming an old one, the flexible ROS developer tools give us the ability to quickly and easily visualize, inspect, record, and simulate our systems, which is a big efficiency win for our team. When we want to work with the latest algorithms, from perception to motion planning, the ROS ecosystem is a pipeline that connects us with working implementations of recently published results.
That pipeline flows in both directions: we collaborate with others in the robotics community by releasing work as ROS packages. Additionally, when we hire recent graduates from robotics groups around the world, they're already intimately familiar with ROS, so they can hit the ground running on our projects.
In the more than fifteen years that I have been teaching robotics in undergraduate and graduate classes, I have tried to balance teaching the core theoretical concepts with giving the students experience with tools and systems that they will actually use after they graduate. To help me accomplish these goals, I rely on ROS.
Robotics is an interdisciplinary subject, requiring the integration of lots of different components to produce a working system. In the classroom, I need to be able to focus on one component at a time. For example, when talking about localization, I want my students to be able to implement and test localization algorithms without also building sensor drivers, motor controllers, and everything else that is needed to make a robot wander around its environment. ROS lets them do just that: students can start with a full, working system on a real robot or in simulation, swap in their localization algorithm, and quickly see the results. This is true at all levels of abstraction, from sensor drivers to high-level behaviors. At each level, I can decide exactly which components the students should build and which ones they should take off-the-shelf from the ROS ecosystem.
Using ROS in the classroom exposes students to the libraries and tools that are increasingly being used in industry. In robotics job postings, we routinely see companies seeking candidates with ROS experience. My students, with both a strong theoretical background in the underlying material and extensive hands-on experience with the powerful ROS development tools, are ready to play a key role in the rapidly-growing robotics economy.