After you installed ROS2, you will learn how to actually use ROS2. Therefore, this page will give you an overview of what ROS2 does for you and how it works.
The Robot Operating System (ROS) is a meta-operating system that is installed on top of your actual operating system. In this case, you installed Ubuntu as your operating system.
ROS is released in different versions that go along with the current Ubuntu versions. The version discussed on this website is ROS2 Foxy which has been released for Ubuntu 20.04.
About ROS2
ROS2 is the second major version of ROS. It features some significant changes that seek to address some of the shortcomings of ROS. The two biggest changes are that ROS2 uses a single library, called ROS client library, or rcl, to enable all the features of ROS2. The C++ and Python libraries build on top of the rcl which means they use the exact same code. In ROS, the libraries roscpp and rospy were both completely independent. This means that both libraries needed to be maintained in parallel. With this new design, ROS2 allows to easily create more client libraries for other languages, such as Rust, Java or C# without rewriting all of the ROS2 functionality. The second most significant change is that ROS2 has been developed with multi-robot systems in mind. Unlike ROS which uses a single ROS maser for the robotic system, in ROS2, every node can be seen as its own ROS master that allows communicating with other nodes. As such, multiple robotic systems can easily interact with each other, without being limited to a single ROS master.
To simplify things, you can see ROS2 as a tool-box including libraries and programs to develop and run robots. Some of the libraries are the OpenCV library for computer vision tasks and the tf library for frame transformations. Some of the tools that are included are Gazebo for robot simulations and RVIZ2 for visualization of your robot. In addition to that, there are software packages that have been created for specific tasks such as robot navigation or motion planning which you can simply install as they are openly available. For more information about ROS2 Foxy, you can have a look at the ROS2 documentation pages.
ROS2 Structure
Programs within ROS2 are not simply started like other programs. Each ROS2 program is called a ROS2 node. Each node is usually built for one specific task such as navigation, reading sensor data or managing data and tasks. The nodes can communicate with each other to provide data to another node. The nodes can run with different frequency rates and they can even be executed asynchronously, which means one node can wait for the output of another node depending on the application. Having several nodes has the advantage that a failure that may crash a single node will not affect other nodes.
As an example, imagine the robotic arm will have an error and causes its node to crash, the navigation and the vision nodes will still be running. Furthermore, ROS can then restart the single node that crashed and send a warning to an operator and write the crash into a log file.
The implementation of having nodes run in parallel is also a very easy way to implement multi-threading which means the processor can run many tasks at the same time instead of one task after another.
Communication between Nodes
When several nodes want to exchange data, they need to communicate with each other. ROS2 has three main methods of implementing communication between nodes: Topics, Services and Actions.
Topics
Topics are the most important type of communication in a ROS2 system. They provide a constant flow of data from one node to another. This can be compared with broadcast radio where there is a constant signal with audio information. The radio doesn’t wait for the radio station to send a signal and the station doesn’t care how many radios are listening.
In ROS2, such a broadcaster is called a Publisher node which is publishing to a Topic. A node that is listening to that Topic is called a Subscriber which subscribes to this Topic. The Topic is the actual data stream containing a specific type of information such as camera data or movement data.
In other words, Topics send data from a Publisher to a Subscriber in form of a data stream. This is important for applications that require constant data input. These data streams create a lot of data traffic within the ROS2 network which needs to be kept in mind when creating another Topic.
The most prominent Topic used in a robot is the /cmd_vel Topic that contains the velocity commands for the robot. These commands tell the robot where to go and at what speed.
For more information about Topics, you can have a look at the ROS2 documentation page.
Services
Services are less frequent than Topics but they can be very handy to reduce the overall data flow. Services do not provide a data stream, but instead, they work with asynchronous data requests similar to a web server hosting a website. When a person is calling a website, the computer sends a request to the server for receiving the website content. After the web server has executed its task, it will send the requested data to the user and the communication is finished.
A Service is also implemented by setting up a Service Server which will wait for a call while the Service Client will call this Server. The Server will then perform its task once and send a signal back to the Client to tell if it finished successfully or failed. That’s it, there is no more communication between both sites. Also, the Client will wait for the response from the Server and will only resume its task when it received a response.
An example of when to use a Service would be a drone that is taking of, or even landing. When taking off, the drone simply needs a single signal to start the takeoff process and it doesn’t require constant input from the controller. When the drone is up in the air, it will send a quick response to the controller to say that it has succeeded.
For more information about Services, you can have a look at the ROS2 documentation page.
Actions
Actions can be seen as a middle ground between a Topic and a Service. Just like a Service, there is an Action Server and a Client. Now the difference to a normal Service is that a Service Client is waiting for a response from the Server while an Action Client will continue with another task. On the Action Server, the task will be executed and the Action Server will send regular updates to the Client. These updates are less frequent than a Topic but they occur at a user-determined frequency.
In other words, with Actions, the Client doesn’t need to wait, but similar to a Service it will get a response when the Server has finished its task.
A good example of using an Action would be the action of a mechanical gripper. While it is closing, it will provide you with information on whether it is closed or not. Also, Actions are ideal for tasks that do not need a constant data stream but yet take more time which makes it impossible to simply wait for the result. If your robot shall drive and perform another task, you cannot allow the robot to wait for the feedback of a Service, therefore, an action would be ideal in this case as the robot is still capable of observing its environment while waiting for the result of the Action.
For more information about Actions, you can have a look at the ROS2 documentation page.
Combination of Topics, Services and Actions
Usually, you take the tools that are best suited for the job. In the case of ROS2, you have to choose whether to use a Topic, a Service or an Action. In a complex system, there are usually many different ways of communication used at the same time.
For example, then you want to control an autonomous drone, you will simply use a Service for a takeoff command while you will have a Topic that gives you information on the position and height of the drone. Once you worked with some ROS2 packages, you will get a feeling of when to use which type of communication.
Software Management
In ROS1, the entire ROS system is managed by something called the roscore which observes all the active nodes and manages all the communication done through Topics, Services and Actions. The roscore manages all the tasks in the background.
Since ROS1 is limited to a single roscore in the entire system, it only allows multiple robots when they share the same roscore. If two robots wanted to have their own roscore, it was necessary to connect them through third-party packages which adds complexity and decreases the overall stability of the platform.
Instead, ROS2 does not have a single central point that oversees the ROS communication but allows every single node to act as a roscore allowing to have multiple ROS2 nodes in a single system. This makes multi-robot systems much more simple and doesn’t require third-party packages anymore.
To enable communication between nodes, ROS2 uses the Data Distribution Service, short DDS, to allow multiple nodes to share and receive data messages within a single computer but also across the entire network. There are different DDS implementations, but this is a more advanced topic. The default system works fine for most use cases.
Programs in ROS
ROS2 has been rewritten as the ROS Client Library, short rcl. The rcl has been implemented in the C programming language. There are special libraries built on top of the rcl that allow using ROS2 in other languages as well such as the rclcpp for C++ programs and the rclpy for Python programs.
Before, ROS1 had two entirely separate libraries called roscpp and rospy. As a result, if there was a change made in the C++ version, the Python version needed to be updated separately, making it a double work. ROS2 avoids this as both, C++ and Python, use the exact same underlying code.
As an additional feature, the use of the rcl also allows to easily create more libraries for other languages such as Java, Go or Rust, without rewriting the entire library.
C++ is more resource-efficient and the code runs faster as it is a rather low-level programming language and because it is compiled (this means, the source code is converted into machine code) before the execution. Python on the other hand is slower as it is an interpreted language but this makes it faster to test the code as no compilation is required. If you want to learn more about how to program with Python, have a look at this programming guide!
The examples on this website are all in Python to make it easier for beginners to get started.
Packages in ROS
ROS2 is built to be modular. This means that the software is split into several packages that can interact with each other. usually, there are packages for navigation, sensing the environment, mapping the environment, computer vision and general control of the robot. Having several packages makes it easy to share the functionality of one package across several different robots. At the same time, when you create a new package, you only need to program the parts that are not already implemented in another package. To increase reusability, it is important to keep your code robot-agnostic which means the code should work for all situations and not only for this very specific robot. If the package works despite it doesn’t know which robot it is running on, it is more modular and can be shared with colleagues across the world or simply within the robotics group that you are working with.
In the next section, you will learn how to handle ROS2 packages.