ROS2 is a second version of The Robot Operating System (ROS), which is a set of software libraries and tools that help robotics engineers build robot applications. ROS2 is open source, commonly used in robotic projects and robotics engineers should have at least basic knowledge about it. In this article, you will find out why ROS2 is so popular and how useful it is — we’ll start with the ROS2 history, ecosystem, architecture and next will tell you how we use ROS2 in legged robots. Looks great, right? Let’s get down to the details!
History of ROS2
It all started with two robotics freaks — Keenan Wyrobek and Eric Berger at Stanford. They decided to boost the software development process in robotics, where too much time was absorbed by re-implementing the software infrastructure and too little time was dedicated to building intelligent robotics programs. They were not the first to notice the problem, at that time there have been projects that have tried to change the robotics world eg. URBI, Open-R and YARP. But, none of them wasn’t ideal — their main issues were high prices and the lack of community.
Keenan and Eric had a better idea and started their project in 2006, received a 50k$ grant, and built a demo. The idea has been confirmed and they needed bigger funding for development. Soon, in 2008 they met the investor and started to develop their vision inside Willow Garage. In 2009 the first distribution of ROS was released and began to spread rapidly. ROS got a big community and it became very popular in robotics. Both hobbyists and companies implemented it in more and more projects. Willow Garage worked on this project until 2013 when they dissolved the company. After that ROS is under the Open Source Robotics Foundation (nowadays Open Robotics) umbrella. Fortunately, this change didn’t decrease ROS’s popularity in the robotics world.
ROS wasn’t perfect — In 2014, the biggest disadvantages are the roscore, lack of security, and no real-time support — that’s why at that time ROS wasn’t a standard in commercial products and was applied mainly in research and hobby projects. To avoid this issue in 2015 ROS2 was introduced.
I should start an introduction to the Robot Operating System 2 with information on what it consists of — the graphic below shows it best.
Plumbing — when you build a robot one of the first crucial things is communication — not only on the software level but also interaction with robot hardware. In ROS2 we have a message-passing system, what we call “plumbing”. ROS2 defines message formats standards and good practices in software that help us use and maintain third-party software&hardware, interface is clear and fault-tolerant which saves development time.
Tools like launch, introspection, debugging, visualization, plotting, logging, and playback — helps in the development and maintenance process.
Capabilities — ROS2 has everything you need to develop robot software and allow you to focus on your application.
Community — ROS2 has a large, diverse, and global community which is a powerful tool. No matter what type of robot you are building, you’ll certainly find on the web a lot of helpful information, you can easily acquire knowledge and experience.
I think there isn’t necessary to understand how ROS2 works on the deepest layers, but it might be helpful to have basic knowledge about it. The graphics below illustrate what ROS2 architecture looks like.
ROS2 is divided into two layers of architecture ROS client layer (RCL) and the middleware layer (RMW). The RCL is a user-facing interface that provides high-level functionalities which are described in detail in the next paragraph. RMW is the deepest part that provides real-time publish/subscribe protocol. Thanks to this any low-level communication protocol might be easy to use and different protocols can work with each other.
Furthermore, layer architecture has big advantages in ROS2, and there aren’t time-consuming underlying details but only focus on the bigger picture of our solution. The architecture allows for some interesting tricks like the cooperation of a real robot with simulation, distribution of tasks to several computers, or using sensors (real or virtual) by multiple robots.
ROS2 — a little about the user code
Now I’m going to tell you more about using part of ROS2. From the user level, we don’t have to worry too much about what is going deep inside the system. We can focus on the user code part and functionality of our application.
The basic part of the system is a node and the system is built from many cooperating nodes. Each of them has one specific task to do e.g. control robot actuators. We have defined a template for creating nodes, thanks to this we focus on performing tasks, not implementation. Important information there is, each node in the system can exchange information with other nodes, which creates a communication network. This is possible with the use of several tools such as services, topics, and actions — which I will briefly discuss. Everything is accessible for users from the terminal interface or dedicated ROS2 application for a more pleasant visualization.
Let’s start with topics — a node can create several topics and publish data through them. The data from topics can be read by all nodes in the network. We can view them in a console or open a data visualization program such as plotjuggler. An important feature to remember is that a topic publishes data continuously and exists until we stop the node. You can see below the simplest example of this. There are two topics: Publisher which sends messages to the network and Listener which receives information.
The second method of data exchange is a service, the main difference from topics is that the service does not transfer data continuously. It’ll only publish data from a node requested by another node (directly and only to them) — a classic request/response mechanism. One service can be connected to several nodes, but communication is always point-to-point, from the publisher to the requester. We use them in situations where we don’t want to occupy the communication channel with unnecessary data, e.g. instead of transmitting a continuous stream from the camera, we send a request for a photo when we need it.
Last but not least are actions — more complex services which provide long-term tasks with regular results. Services consist of three parts: a goal, feedback, and a result. An example can be triggering the action of reaching the given position by the robot. The action would use the nodes responsible for navigating and controlling the robot to bring it to a given point. During operation, the action would inform about the current location and inform when the task is completed.
This structure makes the development process of applications easier and faster. The important thing is that we can divide the whole system into smaller parts and develop them independently, and then connect everything quickly and easily. Furthermore, users can easily use third-party software e.g. for an AHRS sensor.
ROS2 in legged robots
In the video below you can see a walking robot that executes a complex set of movements. The robot is one of the prototypes made by the MAB Robotics team. The quadruped’s software is based on ROS2
At the beginning of the video, you can see something like animation — this is a real-time physics simulation made in PyBullet Simulator which allows us to use an accurate 3D model of the robot (made in CAD software), connect with our control software, equip the virtual robot with sensors (like IMU) and test everything in the chosen environment. The simulation takes into calculation external factors affecting the robot, such as gravity or the coefficient of friction between the robot’s feet and the ground.
The software development process for the robot was divided into parts where one team focused on hardware utilization (sensors and actuators) and the second team was focused on control software — making the robot move steadily. The robotic system was designed and tasks were divided into responsible nodes. Requirements of data exchange between nodes with the use of topics and services were designed. Despite the separation of work, ROS2 assured that there were no problems with integrating everything. ROS2 is also great for debugging — the robot-state is continuously accessible by a viewer of topics and we can easily find what is going wrong.
In the further part of the video, you can see the same set of movements as before but launch on the real robot. Thanks to ROS2, the transition from the virtual to the real robot was smooth, and the Sim-To-Real gap is minimized to the inaccuracy of the model. We could use the same, well-tested control software because it doesn’t matter to the controller whether the data comes from the robot or the simulation. If you are interested in how we programmed walking, read Legged robots: Keeping legs moving.
In the middle of the video, you can see in the right corner the virtual robot again. But this time it is the digital twin which reflects the real robot behavior. Although not very well synchronized through lazy video editing :). This powerful function enables the visualization of the robot for the operator (even if the robot is out of sight) or saves data and recreates a specific behavior multiple times. It’s extremely useful during the robot development process, as well as at the stage of its later use.
ROS2 is a very advanced tool that has many advantages. I hope this has been shown well on the MAB Robotics walking robot example. If you want to get started with ROS2, it’s best to do one of the online courses and go deeper into the documentation on the ROS.org website. The beginning might be tough, but the results will be worth it. ROS2 is useful in many branches of robotics, from mobile robots, through manipulators, to AI applications. Knowledge of ROS2 will surely help you to take full advantage of MAB Robotics actuators and build your fantastic constructions. If you want to know more, feel free to consult with MAB Robotics experts or leave a comment.
Co-founder, Robotics Engineer in MAB Robotics