ROS hardware for industrial applications

ROS-Industrial
1

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.

2

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
3

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

2 Likes
4

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.

7 Likes
5

@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?

6

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.

This really depends on what you’re doing. If you’re turning a couple things on/off and reading a few inputs via GPIO then it’s fine to do however you want. If you’re making a higher volume product and need to bring BOM cost down it makes sense too. If you’re working on a project that involves connecting to industrial manipulators, dozens of remote IO modules, and servo drives, you’re going to need an industrial fieldbus with rock solid reliability.

I’ve made some of the work I’ve done on internal projects with OPCUA and PLCs available. The code isn’t the cleanest and it’s not well documented, but it might help explain things. There is also a presentation I gave when other ROS developers at SwRI were asking the same questions as you. The project is titled pushcorp_opcua, but it’s more generic now and is a template for talking ROS1 to opcua to anything.

ROS part
PLC part
Presentation

The code was developed around controlling a servo driven spindle and force control device from Pushcorp. The only interface I had available was Ethernet/IP. As it was only 1 component in a system, I didn’t have time to read the entire spec and implement Ethernet/IP code that would run on a PC. Having never used Ethernet/IP or Beckhoff before, being familiar with Codesys was enough to get things communicating effortlessly. I was able to begin the real work right away instead of wasting time trying to get things to talk.

The presentation shows some images of the process, but basically you right click in the device tree and pick add, maybe fill out a few fields. For nice protocols like EtherCAT you just hook everything up and tell it to scan and it will add all the devices for you. After mapping the variables, you can just read and write to them everywhere without having to worry about copying them from the field bus at the start of a cycle and writing it back to the fieldbus at the end.

The ROS code will create topics and services automatically for structs defined on the PLC. Your ROS nodes can interact with local/remote devices on different networks the same way. OPCUA is much simpler to deal with than worrying about mapping PDOs on Ethercat and setting up implicit IO connections via CIP.

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?

I started writing a specific response to this, but it got really long and sounded too much like a sales pitch. Basically, if you’re hooking a couple ins/outs directly to GPIOs in a product, just use your SOM. But try and think of everything that would be involved in communicating with multiple industrial devices over multiple realtime industrial networks, and what the goal of your project really is. This is something that has been solved well in PLCs.

If you wanted more details I could possibly do a phone call.

5 Likes
7

Disclaimer: barely working

Hi Marticres,

You pose some good questions. My 50 cents would be to say that industrial/manufacturing/PLC user companies care much more about the brand of the PLC than the actual computing system inside.
SIEMENS, BOSCH, ABB, Yaskawa, Schneider Electric, all these companies are over 100 years old with millenia of cumulative experience on the floor. It’s all about availability and reliability, we must remembers that PLC were invented to replace electromagnetic relays. But now, as our KEBA colleague mentioned, they can control 6DOF robots and control your own custom made kinematic chain.
Today you can buy a Rasberry Pi with EtherCAT motion control master/slave, OPC UA server, for $50 that would do the same job as of a SIEMENS CPU or an Allen Bradlley. Machine builders prefer a “partnership” with a large company that has spent millions on developing certifying that PLC. ROS community is very different.

There are a lot of isotation, electromagnetical induced noise, vibration, heat dissipation testing needed to pass the respective national testing and get the corresponding CE, UL, TUV labels; that cost a lot of money.

As already discussed here IO/control fieldbuses are key. But also haveing actual industrial devices. Major automation companies do not sell only PLCs but complete control systems. They have huge product lines of industrial devices: AC motors, actuators, Variable frequency drives, pumps, Servomotors, etc. They the experience to connect and control those devices from the PLC.

Back to robots. Even if SIEMENS builds no robots, they spend millions of Euros each year perfecting their PLC based robot control library based on PROFINET. They dedicate thousands of hours working with each major robot brand to make sure one library contains all the expected robot functionality. This library is based in IEC61131-3/PLCopen.

Back to the present, many modern PLCs or IPCs are complex SOCs, that are built on reused (Re-sold) knowlege and allows them to become not only PLCs but CNCs, motion controllers and robot arm controllers. Many of these SOCs run a layer of VxWorks SDK (by windriver). This SDK supports many embedded targets and have standard interfaces to hook your implementation to the real time fieldbus. In theory, you could buy this SDK from companies like 3S-Codesys or Phoenix Contact software, and develop your own “ROS PLC”. But those current platforms do not have the hardware acceleration muscle mentioned by @vmayoral.

3 Likes
8

Hi Marticres,

I understand your frustration with PLC. Having worked with both PC and PLC, it feels like 2 completely different system. Furthermore, most PLC specific IDEs run on Windows and a lot of us still like to use ROS on Linux.

However, I think PLC is here to stay due to the hardware ecosystem around it. Devices used in manufacturing industry are built with PLC in mind and therefore the 24VDC control signals and fieldbuses. SOM uses 3.3V or 5VDC and communication interfaces like USB, USART, I2C etc. Switching to SOM will affect the hardware selection downstream, which people are hesitant about it.

To get the best of both worlds, or till both worlds converge, I would use PC for robotics, computer vision, and AI related tasks; and PLC for real time operation and interfacing with industrial sensors and actuators.

1 Like