Robot operating systems are taking over the world of robotics by storm. This open-source software sensation offers a standardized way to program robots, making it easier and more efficient to develop complex robotic systems. With its wide range of capabilities, customization, integration and user-friendly design, it’s no wonder it’s being considered the future of robotics. So how does it work, and why should you consider it? Let’s take a look together!
Let’s start by clearing out two main misconceptions about the Robot Operating System (ROS). First of all, it’s not an operating system (OS) and it’s not just useful for robots. But since a ‘Not-Only-For-Robots Not-An-Operating-System’ isn’t quite as catchy, let’s refer to it by its original community-accepted name. Secondly, in this blog we’ll only refer to the robotic mechanical devices and NOT to robotic process automation software.
ROS, what?
What is ROS then? It’s actually a middleware. This means that it’s supposed to be placed between software logic and hardware. It’s similar to a real operating system but needs an operating system platform to run on (usually a Linux distribution). It can’t simply run directly on basic hardware. Moreover, devices need an ROS-specific interface to make use of their power, similar to how operating systems need drivers to access hardware resources.
So if it’s not just for robotics, why does it have ‘robot’ in the name? Because it was developed by the robotics community to be used with robots. Even though it can be used with applications that are not robots, most of the development efforts are directed toward perception, navigation and manipulation tasks. This means that highly complex robotic functionalities are already available in the ROS ecosystem.
ROS, how?
Let’s discuss the core power of ROS: nodes and topics. Nodes are somewhat the atomic pieces of software that implement a desired logic, like retrieving sensor data, capturing images, processing input data or sending input to an actuator. Topics are the communication links between nodes, independent entities that nodes can write or read data from – imagine them as lists of messages like internet chat rooms. These simple mechanisms allow the creation of complex distributed and robust architectures, where the overall system isn’t entirely dependent on the individual. As long as the system design allows it, the entire system is sensor and actuator-agnostic. Imagine a random vacuum cleaner robot: the navigation module doesn’t care if the localization uses lidar, ultrasonic or camera data, or if it’s using wheels, tracks or a propeller to move around.
These components should be easily replaceable, the only necessity is the right ROS node to take the hardware input and offer a standardized output on a specific topic (a driver-like piece of software, as we mentioned before). And here’s another very cool thing: each node can be on a separate computing platform or as many nodes as possible can share the same computing platform at the same time. It’s all up to the application architect to decide. The only prerequisite for ROS is to have a special ‘master’ node running that can be accessed by every other node. The drawback is that if the computing platform running the ‘master node’ disconnects from the system, then the entire system fails.
ROS topology example and in an autonomous car application ©VERHAERT
Above you can find an example of such a topology, as well as applied to a simplified autonomous car application. Keep in mind that each one of these nodes can be on the same or different computer as any of the other nodes. You can even deploy this system on multiple autonomous vehicles and then simply add topics that connect multiple vehicles. The limit of the scalability is set only by the computing or networking resources available.
ROS, why?
‘Standardized’ is another keyword for ROS. Its main goal is to offer a base for true rapid robot prototyping. In 2006, Eric and Keeman decided to create a standard framework for all robots (not yet ROS) when they noticed that in software projects there’s little time left to innovate because most of your time is spent simply making the sensors or actuators work with your system or setting up a communication architecture. The ROS is the successor to their initial framework and it fills the shoes perfectly. No more reinventing the wheel. Once a sensor, actuator or algorithm is successfully interfaced by a developer (or a group), it gets an ROS package made available for everyone to use!
Source: Eric and Keenan pitch deck
We’ve mentioned ‘true rapid prototyping’ before, which might have triggered your spider sense if you’ve spent some time between demonstrators, prototypes and products. Some people tend to oversell the former as the latter, but that’s not the case here. ROS is indeed a prototyping system: it’s not robust enough, doesn’t have real-time capabilities and is easily hackable. Moreover, the master node is required to function at all times.
ROS, next?
ROS2, on the other hand, has a completely different low-level implementation of ROS. It’s still based on nodes and topics, but is far from being a prototyping project and aims to be an industry-ready fully-distributed framework. It has more complex robotic libraries for navigation and manipulation that implement state-of-the-art algorithms and is designed so you can’t develop your packages without abiding by proper software engineering rules. It’s now harder to just create ‘something dirty that works for now’.
Other major changes include the ability to encrypt topics and time synchronization is being handled by the Data Distribution Service, a software framework to reliably and securely communicate in real-time. Furthermore, ROS2 doesn’t have a master node, meaning the application can be entirely distributed across multiple devices without having the inherent critical component. Pretty neat I would say.
Let’s reiterate the key aspects of ROS:
- Core simplicity
- Standardization of components
- Native compatibility with distributed systems
- Industrial readiness (on the way with ROS2)
- Available for embedded systems (on the way with ROS2)
It’s clear that ROS is a software to watch. Whether you’re developing a fleet of drones, robot vacuum cleaner, robotic manipulation application, coffee machine or smart beer dispenser, make sure to add this awesome open-source framework in your trade-offs!
Hungry for more? Check out our other blog posts to see how ROS connects hardware with AI!
