Even programming for robots is increasingly crowd-sourced.
Robot Operating System (ROS) software — a suite of software libraries that help developers create robot applications — is fast becoming the dominant open-source information-exchange code in both research and industrial robots. Developed in 2007 at the Stanford University Artificial Intelligence Laboratory, ROS has been expanded to handle master coordination nodes; process actuator, control, and feedback data; multiplexing information; and node creation and destruction for distributed operation, even over multiple controllers.
ROS is not an operating system or software application, but a layer of middleware that can run on Java, Windows, Linux (common in research settings for its own open-source nature), and other operating systems. It communicates using TCP/IP and other protocols.
“Think of ROS as the switchboard for messages from cameras, PCs calculating algorithms, accelerometers, and so forth — a messaging system that gives each node the information it needs,” says Erik Nieves, technology director, Yaskawa America Inc., Motoman Robotics Div., Miamisburg, Ohio. “It’s also a large and growing library of functions and developer tools.”
Currently, 33 service robots, unmanned ground vehicles (UGVs), and mobile manipulators are programmed with ROS. In addition, a few cutting-edge industrial robotics companies including Rethink Robotics, Boston, use ROS.
“Developers choose ROS for two reasons,” says Mitch Rosenberg, vice president of product management for Rethink Robotics. “First, it has the low-level functionality that saves us from reinventing the wheel. Second, it has gathered quite a lot of momentum in the past few years with companies including General Motors adopting it to drive high-profile robotic platforms such as the Robonaut 2 in the International Space Station.”
Others using ROS include Meka Robotics LLC, San Francisco, and (possibly) charter San Francisco operation Redwood Robotics; the latter isn’t yet disclosing design details, but its venture partner Willow Garage, Menlo Park, Calif., is a main ROS proponent.
“For open-source robotics software, ROS is the clear choice internationally,” says Nieves. “Through ROS, Willow Garage and its founder Scott Hassan have made research robotics relevant again.” Willow is not focused on the straightforward task of getting robots to move from A to B, which industry has already addressed, but on the higher functions of perception and intelligence.
ROS for expanding industrial capabilities
When a plant adds a robot to its operations, it is typically set up with the proprietary software that comes with the robot hardware. Some such software offers modules that let robots adapt to dynamic environments — those requiring changeable motions to manipulate objects, avoid collisions with nearby machinery, and execute preprogrammed tasks even when relocated, for example. That said, adaptive functionality is often limited.
ROS-based code by engineers of the ROS-Industrial program initiated by Southwest Research Institute (SwRI), San Antonio, more effectively drives some nonpreprogrammed robotic actions.
For example, SwRI researchers recently devised a module to let two robots collaborate on a sorting task. Moves are based on point-cloud data from cameras imparting stereo vision and depth perception for real-time environmental comprehension. The software runs on robots from nearly any manufacturer; it’s currently programmed in C++ and Python. Networking is via (and drivers are typically developed for) Ethernet, as most robots support it. EtherCAT operates the I/O because it too has an opensource driver already written, and it’s ubiquitous.
“Near-term robotic applications of this ROS-based code is anything requiring perception: One could install 3D cameras around a work cell to collect and use data on interactions between robots and the parts they work on,” explains Shaun Edwards, senior research engineer of the Robotics and Automation Engineering Section of the Manufacturing Systems Department at SwRI. The research group is also touted as an advanced systems integrator: “We don’t compete with larger players that buy robots and vendor software and combine them. We take jobs requiring still-uncommon technology.”
ROS-Industrial’s long-term vision is widespread adoption for industrial applications, to advance state-of-the-art robotics faster than it’s developing now. “Advancement in this area is currently slow,” says Edwards.
Nieves agrees. “The truth is that the robot industry stagnated. Now we are on the verge of real application breakthroughs because we are progressing on perception and intelligence.”
To spur new innovation, ROS-Industrial has established the ROS Industrial Consortium: “Industry can join, see our capabilities, and give us direction on where R&D efforts should be directed,” explains Edwards. SwRI is also funding a research program to accelerate ROS-Industrial development, which should bolster the technical needs of the Consortium.
Yaskawa Motoman began supporting ROS early on at a corporate level — not through third-party distributors of their robotics. Its software developers created an interface that lets ROS functions drive Motoman robots.
“Of interest to us is ROS peripheral technologies — 3D guidance, point-cloud processing, trajectory planning, and grasp planning for end effectors. This highlevel stuff is what we want to leverage, so we built a ROS bridge,” explains Nieves. “By tapping into ROS, we get first mover advantage.”
Nieves also cites his company’s offerings of two-arm robots as another reason for its support of ROS, as such designs will likely be at the forefront of automating finalassembly tasks that require high-level coordination (and are currently done manually.)
The ultimate goal for SwRI’s ROS Industrial Consortium is to integrate ROS designs with PLCs, HMIs, and OPC (originally the OLE for process control and now an “OPen Connectivity” interoperability standard for all industrial automation.) Designs will abide by standards: “Our current software doesn’t achieve safety, so when we’re interfacing with industrial robots, we always keep the controller, which contains the safeties,” notes Edwards.
Strengths and limitations of ROS
ROS certainly has other limitations, particularly in process control. “ROS is good for material handling because it tolerates dynamically changing environments as new obstacles are introduced. However, it was never designed for painting, spot welding, or arc-welding process controls,” Nieves explains. “For example, most industrial robot software can slope the voltage and amperage channels on a welder to ensure optimal wetting action in the puddle — which is something completely outside ROS’s realm.”
For applications such as painting, however, there’s synergy. If an engineer wants to paint items with geometry that the robot has never seen before, ROS can automatically generate the paths for the painting robot to follow using cameras.
Robotic controllers touted as having ROS capabilities are often capable of trajectory planning. “In simple pickand- place applications, we use teach pendants to train robots to follow certain trajectories — perfect unless it’s possible objects will suddenly get in the way of the robot’s path,” says Nieves. “To deal with stationary and moving obstacles, ROS-connected cameras scan the environment and dynamically calculate a new trajectory on the fly to reroute the robot.”
On the immediate horizon for production robots, and most likely enabled by ROS, is item recognition using point clouds to select and manipulate target objects, even when they’re initially in a jumbled environment.
No wonder ROS is destined to become an industry standard. “Part of our strategy is to open our platform and let third-party developers come up with robotic applications in other industries on our hardware platform. It makes sense for us to base our robot on a technology with which a lot of robotics engineers are already familiar and comfortable adopting,” confirms Rosenberg.
The electronics perspective: Why ROS is proliferating
by Bill Wong, Technology Editor on Electronic Design
Traditional hardware vendors provide set device drivers to avoid support headaches. So until recently, roboticplatform programmers geared their software to specific hardware and robots. Today, programming software typically runs on top of something else depending on what engineers want to support. If a company creates and sells a robot using ROS for certain functionalities, for example, it will be supporting that in some fashion. In contrast, a platform like Eclipse (an integrated development environment, or IDE) is supported by chipmakers in the Eclipse version they’ve developed.
Why has ROS surged ahead? Its compatibility with various operating systems is a key strength. ROS is comparable to Microsoft’s open-source Robotics Studio running on Windows, as their uses overlap. Studio running on Windows necessitates more computing power in the form of an X86 processor within an embedded computer. Intel’s low-power X86 based on the dual-core Atom processor allows use in smaller applications, but these chips are still bigger and more power hungry than Advanced Risc Machine (ARM) platforms, and are offered in fewer varieties.
In contrast, ROS can be used with microcontrollers associated with miniature robotic designs because ROS can run on Linux targetable to just about anything. Here, microcontrollers are often too small to accommodate beefier operating systems, though that’s been changing with ARM-based processors, Gumstix modules, and the like that are e‡ffectively as powerful as circa-2010 netbooks.
Higher power draw is no problem in designs with plentiful electric power, such as autonomous vehicle designs or Willow Garage’s PR2 (which runs dual multicore X86 processors.) Robots intolerant of large power draws include compact or battery-powered designs such as palm-sized UGVs or the iRobot, for example. The challenge is that manipulators and arms using sensors, multiple cameras, and video necessitate higherspeed data streams plus real-time image processing, and more computing power. This is where the partial convergence of processors gives ROS an advantage.
ROS makes sense for start-ups (like Rethink Robotics) because it o‡ffers myriad peripherals and access to middleware important to everything from image processing to planning to navigation. The downside is that robots delivering more than pick-and-place or repetitive motion are still in their infancy. Therefore, obtaining a navigation-planning system plus an imaging system plus other hardware is possible, but ensuring they work well together is a complex and challenging task that currently falls to integrators.
Also read: ROS-friendly sensor