Kapernikov enables Umicore to increase plant capacity
Kapernikov helped Umicore to make its precious metal recycling processes more efficient. This enable ...
Large systems nowadays are generally divided into many small components, “microservices”, that are easy to isolate, replace or integrate into other solutions. Those components often need to run on different hardware architectures and may be written in different programming languages: C++, C and Python are among the most popular options in the embedded world.
The question is then, how do you connect those components together? More importantly, how can you avoid losing sleep over the often tedious debugging & optimization of custom messaging infrastructures?
In this article we’ll look at one possible solution called ROS (short for Robot Operating System). We believe that ROS provides not only a fast and reliable messaging system but also access to a huge ecosystem of building blocks that will easily interface with your own components.
ROS has been adopted in the products of different companies in the industry. For instance, Sony embraced the use of ROS in the Aibo project. Another example is the Spanish company Robotnik, which designs and creates mobile industrial ROS-based robots. Fetch Robotics, which offers a range of warehouse robots for automation in manufacturing and warehousing operations, also employs ROS in its products.
Principles
Despite its name, ROS is not an operating system. At its core, it’s rather a communication backbone along with a lot of higher level tools that are suited for robotics.
Communication infrastructure
Communication endpoints in ROS are called nodes. Nodes exchange structured data over two types of channels:
Topics provide a publish/subscribe pattern where some nodes emit data over a named bus and other nodes listen over the same bus to receive the data. It’s conceptually similar to a radio broadcast where subscribers “tune in” to the right frequency according to their interest, with the difference that multiple nodes can publish over the same topic without signal degradation. Thanks to the use of multicast, adding subscribers to a topic doesn’t generate any additional traffic over the network.
Topics are great for data flow, where for example some component may regularly publish updates on a ship’s position or the progression of some background task to be consumed by other components, like a user interface or a path finding algorithm.
Services, on the other hand, are a request/response mechanism where a single node handles requests from one or more clients.
This is better suited for control flow: operations that change the state of the system. For example, a user interface may request a system reboot or load a different configuration using the appropriate service.
In both cases, messages exchanged between nodes are structured according to message definition files which are user defined and domain specific. Both topics & services are created and removed at runtime and can be dynamically discovered using standard ROS requests.
Ecosystem & tools
On top of this communication infrastructure, ROS provides tools to help build robot applications efficiently. These tools accelerate the progress of software development and include debugging, visualization, and logging functionalities.
For instance, the software tool Rviz provides support for 3D visualization of data from your robot application. It allows the combination of data from different sensors and the robot’s current state into a combined view. Rosbag2 also provides an interesting functionality allowing the recording of data from the system. This recorded information includes data from sensors and the robot’s trajectory and can be further used in debugging and data analysis. For an overview of the system, illustrating the ROS nodes and topics, the Rqt_graph can be used. This tool provides a GUI plugin for visualizing the ROS graph and can be especially useful for large systems with several nodes interacting with each other.
Benefits
Robustness
Since 2007, ROS has been used everywhere, from robotic arms to underwater vehicles. By default, ROS uses eProsima Fast DDS as a communication backend. That open source implementation has been used in safety critical & high performance scenarios such as self driving cars, planes and battleships. At Kapernikov, we’ve used ROS aboard a robotic ship and inside food sorting machines.
Why reinvent the wheel? Even using ROS as a simple communication backbone considerably reduces development time, allowing you to focus on your core business and making your product stand out from the competition.
Large ecosystem
One of the benefits of using a standard communication interface is to be able to communicate with 3rd party components. Some hardware manufacturers even support ROS out of the box, making it easy for both experimental or production code to interface with their products.
For example, Basler provides cameras alongside a ROS driver that directly exposes the raw image captured by the sensor on a ROS topic, allowing any software with a ROS interface to access the image pixels.
The ROS community has also developed hundreds of algorithms that are presented as ROS components and solve usual problems seen in robotics, such as path finding and geometry transformation.
Programming language independence
ROS nodes communicate with each other using clearly defined interfaces that are language independent. As a result, it is very common to see systems based on ROS use a combination of Python and C++, and this brings additional benefits at every step of the development process:
- During the research phase, prototypes can be quickly developed in Python if users are more familiar with that language or if they want to benefit from the huge number of helper packages that are available. If needed, those parts can then be rewritten in C++ without altering the other components.
- Python can be used to develop integration tests (with a framework such as pytest-bdd) that test your components (no matter in which language they are written) using the exact same interfaces that runtime clients will use.
- Your deployed solution may consist of a heterogeneous set of nodes written in C++ or Python, depending on the type of problem they solve or on which framework they are built.
- It’s future proof! No matter what programming languages will be used in a few years, chances are there will be a binding for ROS that enables interfacing with today’s components. While C++, Python and even Lisp are officially supported, a quick Google search brings client libraries for the usual suspects such as Java, Rust & C#.
Architecture flexibility
Using ROS means that your components don’t need to know on which computers their communication peers are running. While some early deployment of your product may run two nodes together on the same machine, a need for more processing power or a different hardware architecture later in development can most of the time be addressed by simply moving one node to another system. The code of both components should stay exactly the same. And it will always be easy to replace a node (or multiple nodes) by a new implementation, e.g. to quickly test a new reasoning engine.
Conclusion
ROS provides a robust, flexible framework for applications, robotics and other. It supports a wide range of programming languages, comes with a ton of modules to connect to existing hardware or provide common functions and allows a flexible application architecture.