ROS Resources: Documentation | Support | Discussion Forum | Service Status | Q&A answers.ros.org

ROS hardware for industrial applications

Traditionally, PLCs have been used in industry to map inputs (sensors) to outputs (actuators) based on the software developed for the application.

Some of the reasons behind using PLCs are the following:

  • It can run 24/7, non-stop.
  • Robustness to harsh conditions like vibrations, temperature or electromagnetic radiation.
  • Real-time behavior.
  • Ease of programming (e.g. ladder language) allows maintenance people to understand, debug and modify the program to solve some of the issues that might occur during production.
  • Unfortunately, the SIEMENS & company monopoly.

I believe this can be enough for simple behaviors, like the control of simple, sequential industrial processes or devices. However, for more complicated applications like any kind of robot used in industry, there are a lot of cons:

  • There’s a specific IDE for each brand.
  • OOP is barely used in PLCs.
  • Code is probably saved in a binary file, preventing any kind of version control and all its benefits.
  • There are no common standards to be used.
  • There are no such things like automatic documentation, testing, formatting, community resources…
  • Basically, it lacks everything we take for granted in software engineering.

With all that in mind, I’d like to know how or even if it is possible to substitute a PLC with any other hardware that can use ROS 2. Ideally, I’d like a device:

  1. That can be reliable for industrial applications.
  2. Where ROS 2 is used for software development.

If you think this is not possible yet, or worse, that getting rid of PLCs is a bad idea, I’d appreciate if you could explain your reasons as well.

Hope I’m not asking for a dream. Software development in PLCs really sucks, and using it to power your robots is probably a serious disadvantage against your competitors.

Disclaimer: I work for Xilinx.

Shortly:

  • For 1., have a look at Xilinx’s Kria Adaptive SOM portfolio. It answers specifically this demand with industrial-grade hardware that leverages both CPUs and FPGAs giving you flexibility to build different compute architectures to deliver low latency, determinism, real-time, security and high throughput to industrial robotic setups.

  • Regarding 2., look at the Kria Robotics Stack, a ROS 2 superset for industry. Currently in alpha, it is based in Foxy and looking to continue providing support around ROS 2 LTS releases.

In case lead time for Kria SOMs is an issue for you, there’re other Xilinx’s based SOMs that the community is bringing up as community-supported (e.g. Ultra96v2). We’re meeting every few weeks in the Hardware Acceleration Working Group. Learn more about community progress, objectives and contributions in past WG meetings and posts (e.g. proposal for HAWG, meeting #1, meeting #2).

1 Like

FYI, the ultra96v2 has a 52 week lead time as well.

2 Likes

Disclaimer: I used to work for Keba.

Modern PLCs aren’t as bad as the old dinosaurs. Used properly they can simplify your life, and they support more modern coding methods. But I can see why you’d dislike them if all you’ve dealt with are the giant dinosaurs.

PLCs and PC based controls aren’t mutually exclusive. Let the PLC deal with the boring but difficult task of communication with IO via one of the dozens of fieldbuses. Use something nice like OPCUA to communicate with the PLC. That is the primary way I use PLCs these days. ROS <-> OPCUA <-> PLC <-> Anything.

One of the most powerful things a PLC can provide is communication with a realtime fieldbus in a consistent way. There are a bunch of different things like EtherCAT, Ethernet/IP, Profibus, etc. Some of these have open source libraries available, with different levels of reliability and quality, but none of them really compare to being able to connect a device, hit scan, give names to the IO endpoints, and get back to work. You don’t have to read the full spec and become an expert at mapping PDOs and reading packet traces just to turn on a digital output.

Now that basically everyone supports OPCUA, interacting with PLCs from a PC is fairly standardized. You don’t have to replace your industrial PC based controller with a PLC just to access IO. They can happily coexist.

More modern PLCs from companies like Beckhoff and Keba run on actual operating systems like Windows 10 and Linux. They both have realtime extensions where the PLC runtime lives, and both allow you to write native code in the OS, with ways to interact with the PLC runtime.

Keba is a full-blown robot controller combined with a PLC. It runs Linux and operates on a mix of PLC and C++ code. The actual robot kinematics and control are written in C++, while things like motor drive communication and regular end user applications are done in the PLC runtime. I did several ROS integrations when I worked at Keba, including running ROS directly on the controller.

Beckhoff provides a similar setup, minus the premade robot controller. The Windows 10 OS has a realtime extension where the actual PLC runtime lives. I haven’t done as much with Beckhoff, but they also have a ton of ways to combine C++/dotnet and PLC code. You can even turn a regular PC with Intel based network cards into a controller, which sounds very interesting with ROS2 being able to run on Windows. You can use the ADS library from your ROS2 nodes for tighter integration.

There’s a specific IDE for each brand.

Yeah. You’re buying an integrated platform, not just a computer. Ones that are based on Codesys will at least have a similar look and feel. Keba, and many others, use Codesys. Beckhoff kinda does but it lives inside Visual Studio Shell. I was still able to get up and running immediately with it based on Codesys experience.

OOP is barely used in PLCs.

Codesys 3/Twincat 3 support OOP. Classes, inheritance, interfaces, etc. You can do fun things with pointers too.

Code is probably saved in a binary file, preventing any kind of version control and all its benefits.

Beckhoff stores it in loose files and supports git. While at Keba I wrote a git integration that would use the built-in project comparison tools.

There are no common standards to be used.

They use the beautifully named IEC 61131-3 standard. All that really matters is Structured Text. You can write actual code. Changing vendors won’t be as easy as compiling with clang vs gcc, but a lot of stuff is portable.

There are no such things like automatic documentation, testing, formatting, community resources…

Depends on the platform but there are a lot of public resources for Beckhoff and meaningful google results. There is open-source support for unit testing with TcUnit. You can get decent results for Keba by googling questions about Codesys, but when you pay for a platform, you can contact support too.

My background was Comp Sci, and I was used to writing C/C++ on microcontrollers and PC based controls to make custom welding robots. Working with older PLCs was truly miserable and frustratingly limited. When more modern tools like Codesys 3 came around it felt like actual programming again.

5 Likes

@vmayoral Kria Adaptive SOM looks like a really nice option to what I’m looking for. I also look forward to the development of KRS. Hope lead time improves soon! :slight_smile:

I’ve also found some other hardware platforms such as NVIDIA Jetson, Qualcomm Robotics RB5 Platform or micro-ROS supported boards. With this in mind, I have the following questions:

  1. Is this hardware somehow certified to be “industrial”? I mean, do they have to follow some ISO or pass some kind of test (e.g. the board has to run 500 hours non-stop without any errors)?
  2. Do Xlinx customers sometimes have to choose a more traditional option (a PLC or any other kind of board) in order to get or finish some project with their respective clients?

The reason I make these questions is the following: from a technical point of view, probably Xlinx SOM and the boards I’ve mentioned previously are more than enough to design and build complex industrial systems. In my experience, the problem is that sometimes customers want you to use hardware platforms they are familiar with and won’t trust new ones.
That’s because they will have to maintain the new system after it’s installed (and thus learn how it works), and they fear that the new system will introduce a prohibitive downtime, which surely won’t be the case with the traditional system.
This is the case sometimes in the automotive sector, I’m not sure if it is the same in other sectors.

  1. What is the difference between Kria Adaptive SOM and say, Jetson or Qualcomm platforms? Why would I choose one over the others? What can KRS offers that I can’t have with the open-sourced ROS packages available?

@dougsmith Thanks for the info and your pro-PLC point of view! After your answer, I see Beckoff as a really interesting option for PLC software developement.

You say that ROS <-> PLC communication can be fairly easy. However, I do not understand completely why would you make a system composed of both a SOM/PC and a PLC when using only a SOM/PC is simpler.

One of the most powerful things a PLC can provide is communication with a realtime fieldbus in a consistent way. There are a bunch of different things like EtherCAT, Ethernet/IP, Profibus, etc. Some of these have open source libraries available, with different levels of reliability and quality, but none of them really compare to being able to connect a device, hit scan, give names to the IO endpoints, and get back to work. You don’t have to read the full spec and become an expert at mapping PDOs and reading packet traces just to turn on a digital output.

I can’t completely follow this. Could you please expand on that, perhaps with a dummy system like 2 actuators, 2 sensors and the controller, or similar? What would you have to do if your controller is a SOM + PLC versus only a SOM?