Like the United Nations’ international delegates who use interpreters to understand each other, robots, machines and other industrial components from various vendors speak different computer languages and need translators to help them communicate.
Largely because of economics, companies manufacturing machine tools, robots, conveyors and the like use proprietary software for their operation and communication with each other and with components like sensors, drivers and PLCs. Machine makers want factory purchasing departments to stick with their brand of a total solution to create more revenue.
“The prevailing thought at one time was that if I’m going to invest my funds and provide solutions, I want to protect my sales,” said Matthew Robinson, program manager, ROS-Industrial (ROS-I) Consortium Americas, Southwest Research Institute. “If I’m providing machine tools, I would like customers to use all my products … my software, my hardware and interconnected technologies associated with them.”
When a plant owner decides to switch to a different brand, communication issues arise and impede integration, simulation and analysis that can increase production and quality.
Until now, the task of enabling communication among all the technology in a plant has fallen largely to systems integrators who create the computer-code translators, or bridges, from, say, a 3D camera to a robot or between two robots made by different vendors. It’s a process that takes a long time and costs a lot of money—so much that the price of engineering connectivity can exceed that of a machine itself.
“The engineering takes so long and is so costly a lot of companies won’t go the automation route,” said Juan Aparicio, head of the research group for Advanced Manufacturing Automation at Siemens Technology. “It doesn’t make sense for them because they don’t have a big budget that can justify automation.”
This scenario has led to a grand-scale problem: The time and expense associated with integration is hindering the adoption of automation in many shops—and stymying progress in American industry.
What manufacturers, and their hopeful integration problem solvers like Robinson, Aparicio and others, are experiencing now has precedent in another manufacturing realm.
About 30 years ago in the semi-conductor industry, wafer-processing equipment like etching lithography machines from different vendors also could not talk to each other. To combat impending atrophy in that case, the semi-conductor manufacturers formed a consortium and told the vendors they had to create a common standard. That’s exactly what happened.
“The question is, ‘Is the demand from customers powerful enough to drive the creation of a common standard [now]?” That is according to John Wen, head of electrical, computer, and systems engineering at the Rensselaer Polytechnic Institute. “It remains to be seen but there seems to be movement in that direction.”
Wen is also among those working on current efforts toward commonality and creating bridges that translate machine languages so a factory’s devices can talk to each other.
Their work is funded by the Advanced Robotics for Manufacturing (ARM) Institute, which is part of Manufacturing USA. The ARM Institute-funded projects include developing specific middleware—one from academia and another from the deep-pocketed entrepreneur Scott Hassan—to a higher technical readiness level so the middleware options are ready for general industrial use and can help get factories humming with actionable communication.
Wen is leading a project entitled “Robot Raconteur (RR): An interoperable middleware for robotics.” RR collects data and invokes function, like operating a camera, as well.
“Robot Raconteur … is an advanced, augmented, object-oriented middleware technology specifically designed to provide true plug-and-play interoperability capabilities for automation/robotics systems,” according to Wen’s research proposal.
RR is already versatile: It’s compatible with the Linux, Windows, OSX, iOS, Android, OpenBSD, QNX, Arduino and xPC Target operating systems. It has libraries for C++, Python, C#, Java, MATLAB, LabView, browser JavaScript and xPC Target.
The Raconteur middleware was developed in Wen’s Rensselaer lab by John Wason. After Wason earned his PhD, he spun off his own company, Wason Technology, focused on the middleware. Wason is participating in the ARM Institute-funded research with Rensselaer, as are the Southwest Research Institute and United Technology Corp.
In the meantime, users of industrial robots still rely on a teach-and-repeat process to put them to work.
The key to getting away from the teach-and-repeat paradigm is to use sensors, whether for vision, 3D, laser scanning, proximity, tactility or force, Wen said.
However, integrating and programming sensors in a robot adds complexity: They are an additional cost. And sensors can break. The more things that can break, the higher probability a line will go down, costing a plant money.
Wen’s solution is to develop RR into an open-source, plug-and-play system that would make programming and integration of robots, sensors, peripherals and simulation software from multiple vendors and platforms easy, rapid, and secure.
It would also open the door to using a wider array of sensors, including lower cost consumer-grade products, such as Azure Kinect and Intel RealSense 3D cameras, Wen said.
Inherent in Robinson’s job at the Southwest Research Institute is to work with and promote ROS-I, another open-source middleware similar to RR in the sense that you can connect diverse sets of devices but one that also facilitates visualization and simulation.
He knows the siloed paradigm of a vendor promoting one and only one solution is what got manufacturing into trouble in the connectivity arena in the first place.
So, Robinson has weighed the pros and cons and is frank about the negative side of its foundation, ROS (Robot Operating System), in the specific realm of the IoT.
“One of the big drawbacks of ROS is that it’s a lot of C++, which is a rapidly evolving and updated computer language,” he said. “It can be, for newcomers, intimidating and fraught with all kinds of problems. So, there’s a lot of entities and tools to insulate industry folks who just want to get their systems working from having to do all kinds of deep, hardcore C++ computer science software writing.
“RR seeks to lower that barrier to entry.”
Aparicio is another proponent of computer language diversity.
“I think it is unrealistic to say that there will be only one language in manufacturing, but if there are several—all with pros and cons—then we need a gateway” in the form of software that acts as an interpreter, he said.
Aparicio is principal investigator for an ARM Institute-funded project to create a plug-and-play, open-source software for interoperability and communication among automation systems, simulators, cloud platforms and a robot (which is controlled by ROS-I).
The gateway will work with three widely used standards and protocols in manufacturing: OPC-UA, MTConnect and DDS.
Joining Siemens and the Southwest Research Institute on the project are the software firm Real Time Innovations and the robot vendors Keba and Yaskawa.
“At the end, the secret sauce will be how easily you enable all these machines to talk to each other … to interoperate … to abstract all these low-level communications so you can program in your language of choice,” Aparicio said.
New machine tools and factory devices are equipped for connectivity and interoperability out of the box, and their owners should be able to take robust advantage of the work Aparicio, Wen and Robinson are doing.
But what about legacy machines?
“In general, if it’s got a network card, if it can support moving information over the traditional internet, we’re good to go,” Robinson said.
Even some legacy robots that are a decade or so old may be able to be put to work instead of gathering dust in a factory storeroom.
“If you have a 10-year-old-ish robot, it’s essentially a free asset at that point, so you’re just adding some sensors, leveraging some pieces of software,” Robinson said. “You may have to work with a contract partner unless you have a good internal team, but you can be up and running [at a] way lower [cost] than buying a whole new system from scratch.
“That return on investment becomes very compelling.”
Even with all the expertise and hard work put into the ARM Institute-funded projects, along with their successful outcomes, there’s still plenty of work to do to help U.S. manufacturing reach its full interoperability and connectivity potential.
There is also room for more participants.
“This is the kind of project that the more people who know about it, the better. We want to get more and more companies on board,” Aparicio said. “It’s not that we are totally solving the problem. We are solving a small roadblock. There will be some further projects” needed to solve the larger issue.
As Wen said of the projects’ results: “Everyone wants this.”
Some of the technology development projects funded by the Advanced Robotics for Manufacturing (ARM ) Institute leverage a lot of the content within ROS-Industrial software to further its capabilities and ideally harden the modules developed for general industrial use.
The history of ROS, the foundational software code of ROS-Industrial, is rooted in Silicon Valley.
The ROS code was developed by a team working at Willow Garage led by company founder Scott Hassan, a Silicon Valley billionaire who was the key software architect for Google, according to a bio posted on the website of his subsequent company, Suitable Technologies. ROS, and now ROS2, is currently developed and maintained by the nonprofit Open Robotics.
The commonly used name, ROS, is an acronym for “robot operating system,” but that sells its capabilities short.
“ROS is not an operating system in the traditional sense of process management and scheduling; rather, it provides a structured communications layer above the host operating systems … ,” according to an overview of ROS on the Willow Garage website.
Connect With Us
