Diversions

Robot Operating System (ROS)

May 1, 2013

Thin, robust, and language-neutral, Robot Operating System provides a standardized core of OS functions and an extensive library of over 2,000 packages, enabling researchers and engineers to focus on invention instead of re-invention.

Without a robust, standardized core of OS functions, robotics researchers must often allocate considerable time to programming project-specific embedded software. This presents a considerable bottleneck to the development and commercialization of robotics, as every individual project demands a prohibitive breadth of engineering and programming disciplines.

Robot Operating System removes this constraint, providing an open-source software base free for commercial and research use. Its core libraries handle standard OS functions, such as hardware abstraction, memory allocation, process and contention management, and cross-component communication, while providing an easily-extensible package framework for custom hardware drivers and algorithms. With thousands of such packages already available, writing code for your robot can be more like assembling a bespoke Unix distro than chiseling out a new framework from scratch.

 

Origin and Development

In 2007, the Stanford Artificial Intelligence Laboratory developed the original core of ROS (then Morgan Quigley’s “Switchyard”) for use in the Stanford AI Robot project. The notion of creating a thin, robust, and open source core operating system for robotics attracted the interest of Willow Garage, a federated research lab and technology incubator founded by Scott Hassan. Willow Garage recruited Keenan Wyrobek and Eric Berger, of the Stanford Personal Robotics Program, on the basis of their work on both Switchyard and the PR1 robot platform. These projects would continue as the Robot Operating System and the PR2.

Core stewardship of ROS passed to a spin-off foundation, the Open Source Robotics Foundation, following the decision to transition Willow Garage from a research lab and incubator to a commercial, self-sustaining company. A number of key developers followed ROS to the Foundation and there is no sign of the transition having an adverse effect on continued development.

Sixty-eight autonomous robotic platforms have been either developed natively in ROS or can be ported through open-source package stacks. These include a variety of platforms, from humanoids (such as NASA’s Robonaut 2, the NAO, and others) to CSIRO’s Bobcat S185 skid-steerer. For industrial applications, the ROS-Industrial software library offers a number of tools specific to the needs of industrial robotics and plant management. Specialized libraries for control of Adept and Motoman industrial robots are already available, and ROS’s peer-to-peer message-handling architecture enables communication across platforms regardless of OEM.

At this time, the ROS package stack repository contains over 2,000 packages, free for commercial or research use by robotics researchers and engineers. (Exact license terms may vary, of course, but all of the packages we reviewed for this article were offered under the revised, three-clause BSD license.)

 

How ROS Works

Robot Operating System is built for flexibility and resilience. The OS itself remains thin, keeping drivers and project-specific algorithms out of the core and in standalone executables. (This approach also keeps ROS small and simple to use, as complexity is kept outside of core functions and in the libraries.) It’s a tools-based microkernel environment for much the same reason; a centralized runtime environment creates both a single failure point and invites complex, hard-to-squash bugs. With ROS components built and run through small executable commands, it’s not only easier to diagnose and recover from problems, but to use ROS as a framework for fully-customized distributions.

Engineering Jobs: Keyword “Robot Operating System”

As robots of sufficient complexity require constant dialog between components, ROS is designed around a peer-to-peer architecture. Every component, computer, or sensor can communicate directly with any other, synchronously or asynchronously, by relaying messages through the OS. This works just as well for onboard components as it does over a network (as in when computation-intense operations are farmed out to an external computer). As far as ROS is concerned, a node is a node.

Since dynamic, multi-component communication is so central to robot design, this point deserves further explanation.

 

Nodes and the Master

The tracker at the core of ROS’ peer-to-peer communication system is referred to as the Master, while every instance of a component (hardware or software) is a Node. For the robot to function, these Nodes need to pass information seamlessly and in parallel, as well as have access to global parameters and system resources.

The Master functions as a registration service and parameter server. When a Node initializes, it declares itself to the Master, which then facilitates communication between it and the rest of the system.

Nodes can communicate synchronously (directly) through Services, or asynchronously by publishing Messages to Topics. Nodes can subscribe to various system Topics, monitoring them for updates or publishing feedback to Topics for other Nodes to review. Messages contain typed data generated by Nodes, packaged in a standard format. As a simple example, a Node representing a touch sensor might publish a Message indicating it is functional and detecting pressure (two booleans wrapped in a Message) to a Topic monitored by a collision-response navigation algorithm (another Node). This algorithm may then communicate synchronously to servos via a Service, backing the robot away from the collision, or pass the information on to a higher-level navigation Topic for other Nodes to formulate a correct response.

This peer-to-peer architecture gives the engineer maximum design flexibility, as any Node in their robot can communicate and react to information from any other, in whatever way they see fit.

 

ROS Guides and Resources

There are many excellent, community-maintained resources to help you decide if ROS is a good fit for your next project. The Open Source Robotics Foundation curates the core of ROS and maintains tutorials, reference materials, and an API and package index at ROS.org. There, you’ll also find a list of robots and manipulators running on ROS (or which can be ported to do so), as well as sensor drivers for a number of common components. (Willow Garage has a nice collection of videos featuring ROS-driven robots on their site, too.)

Engineering Jobs: Keyword “Robotics”

For test drives in a virtual environment, ROS integrates quite well with Gazebo, an open-source multi-robot simulator, which models robots, sensors, and objects in a three-dimensional space. While the program’s original intent was to aid in algorithm development and testing, Gazebo’s fidelity is great enough to allow robotics behavior experimentation in an entirely virtual space.

 

Ever work with ROS? Share your tips and stories with fellow readers @EngineerJobs or in the comments, below.

Image credit: PR2 Robot