THE GLUE THAT KEEPS COMPLEX SYSTEMS TOGETHER
By TOMMI TIKKANEN, M.Sc.(Eng.), Lead Robotics Engineer, Project Manager, Team Leader, Developer
Not even many engineers know what middleware is. There’s a simple reason for that — usually, it’s invisible. And normal users don’t care how Google Maps connects to its backend servers, they just want to see the map. Same in business — managers don’t generally worry about how things are connected, as long as everything eventually works.
Now is a good time to fix that kind of thinking. You actually should care quite a lot about the underlying technology choice — choosing the right one can save you a lot of money, and make your integrations to other systems much easier. And middleware isn’t just any tech choice. It’s the central system that keeps everything together. You mess this up, and all of your engineering teams suffer. But also, it’s an ecosystem and a common language that can provide you with massive opportunities, such as free, open-source software and fruitful partnerships with other companies.
Put yourself into Nokia’s shoes 10 years and ask yourself: should we keep maintaining our own Symbian ecosystem or jump into Android camp as soon as possible? The same is happening today with middlewares.
The early days
During the early days of GIM (Center of Excellence in Generic Intelligent Machines), the advantages of microservices connected via middleware were already obvious. Complex robots could have tens or hundreds of different sensors, several computers, microcontrollers, and actuators. But there were not many 3rd party solutions available at the time, so GIM had to come up with our own middleware, the GIMnet
ROS1
GIMNet wasn’t alone. Similar projects were being made in other robotics laboratories of the world, including for example Player/Stage. Clearly, the most popular middleware nowadays rose from Stanford University’s Personal Robotics Program. It’s called Robot Operating System (ROS).
Although technically very viable, GIMNet eventually had to be put aside, because ROS provided a superior ecosystem and tools that save a lot of effort. Visualization, diagnostics, data recording, and geometry utilities to name a few. Having these existing tools out-of-the-box is incredibly valuable for companies like GIM Robotics, who want to focus on state-of-the-art algorithm development. This way we can focus on what matters, and create more customer value faster than many competitors.
ROS2
While ROS1 has been a great solution for research, proof-of-concept, and pilot cases, it has to be admitted it has some limitations when making safety-critical systems. Although based on practical experience it is very reliable, it’s hard to get it certified, as it doesn’t meet various complex requirements from quality and safety standards. This is one of the key reasons why ROS2 was developed. The main benefit is that it changed the underlying communication protocol to DDS (Data Distribution Service). DDS enables easier compliance with standards such as ISO 26262 or IEC 61508 — and it’s already used in financial systems and space systems, among others. Read more on ROS2 design pages.
At GIM Robotics, we have been carefully looking into many, many options in the search of the perfect middleware. In addition to ROS1 and ROS2: ZeroMQ, RabbitMQ, Kafka, ZeroCM, plain DDS, and LCM have been evaluated. We have looked at things like pure technical performance, compliance, community support, and modularity. It looks like ROS2 emerges from this battle as a clear winner. It simply ticks all the boxes.
However, a robot’s brain is not the only place where ROS2 would be beneficial. We also learned when talking to many customers about their needs, that ROS2 actually solves quite many problems that people have in fields like logistics, marine, forestry, railways, and mining. It seems to suit many kinds of intelligent systems, better than many traditional alternatives.
Why is a newcomer like ROS2 beating old, proven standards like good old TCP/IP direct communication, that many industries are using? As discussed before, it’s incredible how much value good supporting tools and community bring to the table. Secondly, simple things are kept simple, and a developer doesn’t have to worry about how data is transported from A to B, it just magically happens. On the other hand, the solutions in traditional industries are prisoners of the past. For example, 20 years ago, supporting only Windows might have been a good idea. Well, today it’s not.
So the question you might be wondering now: am I suggesting you should throw everything old into the garbage, and replace it with ROS2? It cannot be that good! Well, in most cases it’s good but it doesn’t give you everything. ROS2 is still quite fresh, and technical solutions are built around land robots, focus on indoors. However, the community is growing fast and most likely we will see more tools and algorithms to support exotic use cases, like autonomous ships.
But don’t hold your breath, and wait for someone to make you a free autonomy solution for your industry.
The thing that most people don’t get, is that using ROS2 is not binary — it is very highly modular, and you can use the parts of it that suit your needs.
For example, some people could only use the middleware to connect software together. Some people might benefit from the visualization and data recording tools while using some other middleware. Some people are interested in open source algorithms.
Or, you could migrate one part of your system to ROS2 and keep others intact. For example, an autonomous work machine might have a perception system functioning with ROS2, and a control system using the CAN bus.
But at the end of the day, complex systems will remain complex. No matter how good ROS2 is, creating big robots is hard. So please drop a comment if you have any questions or concerns — we at GIM are happy to help you!
