I wanted everyone’s opinion of using ROS in Industry. After working for about 3 years in robotics industry I have few questions popped up in mind and would like to hear perspectives and answers of others on this:
During my work with industrial robotic arms in industry I have seen very few sources using ROS. Most of the industry in robotic arms is dominated by PLC-Robot communication. My question is why do we need ROS if PLC -Robot is used in industry? What are advantages of using ROS compared to standard robot motion programming of industrial robots (which has motion planners integrated with their controllers)?
You can use ros to just send move commands to the controller, so you can use the same interfaces as PLCs.
If you just need to move from point a to point b, with no deviations, there is no point in using ros/moveit to control the robot on joint level. In fact, you will probably get better performance from the original controller in terms of speed.
However, if you need something more complex, e.g. mobile manipulators, collision avoidance, camera integration etc., you basically will need to build non-scalable systems with PLC, IPCs, which are hard to adapt when the system changes.
IMO Ros is a one stop shop for robot and peripheral capabilities to reduce integration effort.
Btw, you can also include PLC in Ros, e.g. with OPC UA servers, CtrlX plcs or ROSie from Bosch/Siemens. So they are not mutually exclusive.
I started using ROS in industrial applications after developing with proprietary languages like RAPID (ABB) and KRL (KUKA). After learning 2 different languages, and having to switch platform again made me want to try a more platform-agnostic approach, so I gave ROS a try.
Now I deployed the first real industrial application with and IT-only approach using ROS, and there are several pros and some cons.
PROS:
Platform agnostic: for example, I can write a very complex logic with ManyMove leveraging moveit2 and behaviortrees, and if I have to change the robot I just need to choose one with a functioning moveit2 configuration and to check for joint targets, and I’m good to go. The only thing that may need some work is the I/O as they don’t seem to be a standard across moveit configurations yet, but that’s not something huge and I’m trying to address this too in the near future (for example with an hybrid ROS-PLC approach). I created my own repo to handle the problems I had, but there are many available, and anyone can write its own.
Access to cutting edge software: while with classic automation frameworks you have a set of perfectly stable functionalities, it may take a long time to have new functionalities available, if the get to be available at all. Using ROS you have access to the latest and most advanced software packages almost in real time. This is also true if you directly program with C++/Python SDKs, but then you lose the cross-platform interoperability that you get with ROS.
Freedom (this extends the previous point): if there’s some package I want to use for some feature, I have a huge selection on many topics: motion planning, computer vision, logic and deliberation, AI, … I’m not tied to any vendor’s list of capabilities. Want to use behaviortrees for logic? I that robot’s vendor don’t have a package for it, then you can’t. And this goes on for any part of the application.
The huge community support and the use of standard programming languages: with proprietary language you have a far less extended community support. And let’s face it: it’s rare that some very skilled roboticist has the time and will to share its knowledge with you, possibly losing its advantage in its industry. And if you are willing to share your advanced features or use-cases, chances are that you’ll get to help a couple of developers at most. With ROS, you have countless extremely skilled researchers and professionals that contribute advancing the open-source world, and you get to share your advancements too with an audience that actually cares. It makes you really feel that we are “standing on the shoulders of giants”. Moreover, using some widespread programming languages means you can get some AI LLM to help out with your code, which is currently basically impossible with proprietary languages.
Current technological shift: the automation markets seems to be shifting heavily to embodied/physical AI. Being part of it would be way harder with classical frameworks, they are just too slow to keep up. In my opinion, the way physical AI works also leans too much towards the ROS/open ecosystem style of work to be usable with the classical automation rules and concepts. But that’s just my take.
CONS:
It may be harder to get the performance and stability of industrial systems. Having more freedom also means having to figure out more problems by yourself.
No direct support: you don’t get the direct, professional support you get with proprietary systems. On the other hand, there are many companies that can support professionally with ROS, just not for free, which seems quite fair by the way!
Documentation: in industrial platforms you usually get a near perfect documentation. This is also easier to do when you have a limited set of stable functionalities. On the contrary, in ROS the documentation is often partial or outdated. Given that the underlying code is changing at a way faster pace, and that the resources to distribute between coding and documenting are usually very limited (or none), this is also pretty understandable.
If there is some interest here in the community (I think there is based on the spontaneous overflown BoF session last year in Odense) we could do an online meeting to discuss those benefits and use cases with interested parties. Maybe this involves into a WG or does even fit into an existing format.
At least we from Siemens would love to hear voices from the community
Besides our interface ROSie, we are also working on some other topics to improve some pain points mentioned by @pastoriomarco . Having feedback on those topics is also crucial as it will result in a free accessible guideline that should be helpful and not out of touch with the actual users.
I agree two of the above posts illuminate the benefit for certain use cases and more and more industrial vendors are seeking to provide support to either ROS directly or via bridges to supported message protocols, such as OPC-UA.
The ROS-Industrial open source project seeks to provide resources, examples and work with OEMs to provide documented support for ROS interoperability. This is an ongoing journey and your mileage will vary depending on your hardware choices, but there is a path forward and you can get to performant behavior with practices and architecting your solution for what you really need.
You can learn more about the ROS-I open source project at rosindustrial.org, and under “developer” at the top are the various repositories. We also work to provide developer meetings where you can just get updates, listen/ping other developers and there is an industrial thread here at Discourse.
As you can tell there are a number of folks here in the community doing great industrial relevant work, so just post up and as you can see you will get the direction you are looking for.
