What is ROS?
The Robot Operation System (ROS) is a middleware which is deployed to cope the problem of integrity in the hardware and software level in a multimodular as well as in multiplatform robotic system. Theoretically, ROS is a collection of tools, libraries, and conventions that could be used to simplify the development process of robotic platforms which normally become tricky and complex with components from different manufacturers.
The actual problem in the development of multiplatform robotic system nowadays is there are no laboratories or research institutes as well as robotic developers who could master all of the robotic system competences all roundedly. Some institutes are having experts in mapping and could contribute a world-class system to get a robust and accurate mapping. While another group might have an expert for the robot controlling, which could deliver impeccable control system with least error. This motivation is the main motivation why was ROS developed. ROS was buit precisely in Standford University at 2007 to encourage collaborative robotic software development from all over the world.
Why ROS?
Before migrating to a new framework or system, people would probably ask, what are the benefits or the pros that they will get from the new system. Making a radical leap by switching the framework that we have used for several years is really a big decision and we need to strive more to shorten or accelerate the learn curve. I have started to learn ROS officially since November 2019 and I must admit that I could not compare my competences and experiences with many ROS experts worldwide. From my experience, I could encourage you that learning ROS is an investition. Because ROS is not specifically a programming language with some random structures. ROS has its own grammar which is really logic to be grasp when you understand how does it work exactly.
Here are the benefits of a ROS system as a framework to develop a robust robotic system (Keerthi Raj N):
1. Peer-to-peer communication:
Complex robotic systems with multiple links may have multiple on-board computers (for performing parallel tasks) connected via a network. Running a central master would result in severe congestion in one particular link. Using a peer-to-peer communication would avoid this issue. In ROS, a peer-to-peer architecture coupled to a buffering system and a lookup system (a name service called ‘master’ in ROS), enables each component to dialogue directly with any other, synchronously or asynchronously as required.
2. Free and open-source:
Being open-source platform provides reuse of already existing functions provided by the many other ROS users. Their code is supplied in repositories as “stacks”. Other people have developed amazing capabilities for robots that have been “open-sourced” and are relatively easy to add incrementally using the ROS development environment
3. Thin:
To combat the development of algorithms that are entangled to a lesser or greater degree with the robotics OS and are therefore hard to reuse subsequently, ROS developers intend for drivers and other algorithms to be contained in standalone executables. This ensures maximum reusability and, above all, keeps its size down. This method makes ROS easy to use, the complexity being in the libraries. This arrangement also facilitates unit testing and the developed systems can be completely independent of another system.
4. Multi-language:
ROS is language-agnostic, and can be programmed in various languages. The ROS specification works at the messaging layer. Peer-to-peer connections are negotiated in XML-RPC, which exists in a great number of languages. To support a new language, either C++ classes are re-wrapped (which was done for the Octave client, for example) or classes are written enabling messages to be generated. These messages are described in IDL (Interface Definition Language).
ATTENTION!
In the end, we could conclude that ROS is an open-source message broker which transmit the message from our programs that could be written with various programming languages. ROS also already has some prebuilt programs that we could integrate without problem with our problem. The only problem that could occur by using ROS is that ROS works only in Linux System and its distributition dependant. It means that you should make sure that you are using the right operation system version and the right dependencies version for your ROS. For the python developer, the current ROS is only integrated with the Python 2.7 interpreter, but this problem is solved with the ROS2 which is also able to run Python 3 Interpreter (pip3). Basic knowledges about Linux command, python as well as c++ are needed.
How does it work?
To give a better understanding about ROS system, it is really recommended to watch the video above. It is the core of the basis or the fundament of the ROS functionality. Like I mentioned in the last section, ROS is a message broker. In the end, at the lowest level communication a ROS node (ROS program elementary unit) will communicate with each other by subscribing or publishing specific information / messages in a form of topics. The simplest communication form is the ros topic where the published will only publish the messages constantly in the predefined frequency or rate. The subscriber node will only attach itself to a publisher node and take over the information directly.
The more advanced communication foms in ROS are service and action. In the ros service there will be again two agents that are involved in the communication. They are not publisher or subscriber, but the server and the client. The client is a node who will send a request to the server to process some specific informations for them. The client will send the input that should be processed in the server and the server will send the output of the computation or service to the client back. The function of the ros action is almost the same as the ros service, but in a ros action there is a constant feedback or communication between client and server. In other words the ros client will send the server some intermediate results that should be calculated until the main goal is reached.
It is a really abstract concept and personally, it took me some times to understand the core of ROS communication architecture. Let me simplify those points that I mentioned above by explaining you by the diagram below :
ROS Topic is a unidirectional communication in ROS between a publisher and a subscriber. It is used in continuous data exchange. And it is asynchronous, it means that we could run multiple action topics together without any need to wait one topic to finish its operation.
ROS Service is a bi-directional communication between a server and a client. A client will send the service request which will be proceed with the service response from the server side. The ROS service is synchronous, it means that its functionality should be finished to be able to run another data exchange or communication. Normally it is used when request processing request and reponds current states.
ROS Action is a bi-directional communication between a server and a client with feedback. Therefore the ROS action could be used in a scenario when it is difficult to use a service due to long response times after the request or when an intermediate feedback value is needed. The ROS action is the opposite of the ROS service, it means that it is asynchronous.
After learning about the communication architecture or the magic behind ROS, then we could proceed with the structure of ROS program. A ROS program is built in a wrapper or folder called package. This package represents a modularity of a robotic system in a ROS. For example we have a package for a serial manipulator with 2 DOFs and camera and we represent everything in a ros package. So, our ROS package will consist of a node to control or power the robot movement, a node to gather the image data from the camera and another specific nodes with different functionalities. A ROS package has its own specific structure tree. The picture below represents the structure of a ROS package :
The blue area represents the ROS package. A ROS package in a sub level has CMakeLists.txt, package.xml and some folders with different functionalities.
- The package.xml defines properties about the package such as the package name, version numbers, authors, maintainers, and dependencies on other catkin packages.
- The CMakeLists.txt is the input to the CMake build system for building software packages.
- The script and src folder are the place to put all of the source datas of the ROS nodes. Script for python and src for c++.
- The include folder for header datas of c++ ROS nodes.
- The launch folder to specify the location of launch datas which are used to launch ROS nodes, parameters, tools, etc.
- The msg,srv and action folders are used to specify the custom messages, services and actions.
What’s next?
In the next update, I will probably give an overview and guide how to install a ROS system in a Linux system and we will learn how to write a simple ros publisher and subscriber with python and c++.
One response to “ROS Introduction”
[…] of ROS, let us proceed to setup the development environment of ROS: Like I mentioned in my previous post before, ROS works only with the Linux environment and it depends also the Linux distro that we are […]