 Hello? Hello? Yeah? Hi? Can you hear me? Good morning, everyone. My name is Jose Luis, and I'm here to speak a little bit about robots and how was the evolution of the robot operative system, which is a piece of software called ROS. Before we start the talk, I want to introduce the company I work for. We are a small company called Open Robotics, and we try to create open software and hardware, no more and no less than doing that for the robotics world. So, let's start from the beginning for the people in the room. Who knows a little bit about ROS, the robot operative system? Oh, cool. So, you probably know about the origin of it. It was back in 2007, so there was a lack of common resources, and there was no open source code or a little bit of it. For the people just trying to program a robot in that time, so what was happening is that in every single research lab in the world, they were reinventing the wheel every time, and you know that we in the open source world don't want to reinvent the wheel every time. So, ROS was created with these four principles in mind. The first surprise for those of you that don't know about ROS before is like the robot operative system is not an operative system. So, it's an SDK, an open source SDK or framework to program wheel robot systems. So, with these four principles in mind, I thought when creating the slides that it's going to be more fun if I try to show you them using a small frame. So, please meet my small friend. This is the Tartelbot version 3. It's a robot. It's about this size, 20 centimeters. The good thing of it is that we are going to find, in this small frame, the usual parts of a robot. So, starting from the top, there is a laser, 360 LiDAR laser on the top, and the laser is connected to the main computational unit here. This is a Raspberry Pi 3, and the Raspberry Pi is connected to a microcontroller, so the name is OpenCR, but this is a standard, or quite standard, 32-bit ARM board. And the bottom of it, we have a couple of actuators. This time there are two dynamic servo motors controlling a couple of wells. So, all the hardware finger and software is completely open source in this robot. So, if you want to buy it, it's a nice thing. So, let's go into focus on a couple of parts to explain the rules. So, the laser and the wheels and the good thing is like we are going to put a bit of fun. So, let's go into a remote controller so you can move the robot. So, what's going to happen? I have the remote controller. Let's start with the easy part of it. How can I put this into ROS? So, the first thing that we are going to need is go to ROS.org and look for if there is an existing package that can work as a driver and support all the ROS internals for it. So, you will surprise that there is a package for this one. So, we are going to start the ROS system. The first thing in ROS 1 is to start the ROS master, which is a common diamond or service that provides different kind of features for all the risks of the pieces in the system. So, in this case, naming and registration mailing. So, how the remote controller is going to be inside ROS? I'm going to just run a part of the package, which is the blue bubble. There is a standard POSIX process, which is going to control the remote control. Sorry. And it's going to publish a communication channel just bringing all the keystrokes and information from the remote controller into ROS via that communication channel. Right? But that's not really useful to control a robot. I cannot send to the mobile base of the robot. Like, I press the red button and the mobile is going to say, all right, that means nothing to me. So, you need to translate somehow the keystrokes to something for the mobile base. So, there is another ROS package for it, and it's called the teleop twist joy. What it's going to do is it's going to read the keystrokes from just here, yes, in that communication channel, that it's going to discover it by asking the master. Right? So, it's going to just subscribe to it and receive this kind of information from it, and it's going to transform it into something that the mobile base can understand, which is a common velocity. Right? So, with this, this is the first principle of ROS, which is, we call it distribution. We have a published subscribe service somehow. There's a discovery, dynamic discovery of the different parts of the system that is done using the ROS master for it. We can isolate the components fully. In the sense, like, we'll have two different processes that working completely isolated. Sorry. And they are communicated only by the communication channels. So, there is no use of API or something. So, we have, like, isolation at this point here. Obviously, that allows us to have, like, independent development for the different packages. So, different developers. We can change the remote control by something different, SpaceNAP or Wii controller, something. And it's going to keep working the same way. So, with this diagram in mind. I said that we have a couple of communication channels in there. But you can guess how is the format of the information and where is that defined. Right? So, ROS has something really nice, which is an intermediate language that allows us to define what's going on in every, in a communication channel. So, these are the ROS messages. So, this is the way we define it. And with these ROS messages, we bring the second principle of ROS. So, we have, like, well-defined interfaces. This is the main central point for the change of the information. These messages brings us some semantics. You can see, like, the joystick node has put on an axis. And the velocity command has a linear velocity and angular velocity in the form of a vector. Right? And you say, oh, this is nice. But how can I use this from C++ or Python? This is the task of the ROS build system. So, when you are going to build your system, you will say, hey, I'm using Python. And I want these messages translating to a Python code that I can use. So, that's going to be done for you. So, no real pain into maintaining many different languages for it. So, let's continue with our small friend. Probably the most interesting part is the 360 laser on top of it. There is another nice ROS package for it to control it. So, only you have to download it or install the packages and just put it to work. So, in this case, it's a process to control it. We call them ROS nodes. And to put the information in that channel, we are going to call it scan. And the type of information is defined here. So, it's a bit more complex than before. And the main interesting thing is the laser is going to put in this a writer the ranges and the measures that it is going to take. Right? Okay. And you can say, all right, what can I do with a laser scan? You can do many different things. But probably the first thing you want to do is to be sure that your laser scan is working properly with respect to your robot. So, let me introduce you another nice friend in ROS. This is the visualizer. It's called Arvis. It's one of the most powerful tools probably we have in ROS. And this is the 3D model of our small friend. So, there's no laser scan yet in there. So, this is the 3D model and these colors and the bars of colors you see there, they are the access for the resonance of the robot. Right? And what can you do inside Arvis are those red points. These are the readings from the laser. So, with that, you are able to do something really powerful. That is, be able to diagnose your system if it's working fine and how it's working. Another interesting tool is the diagnostic itself. It's inside a GUI and it can tell you if there is a kind of error on the microcontroller. So, the microcontroller is publishing the information and this tool is helping you to know if there is something bad in the system before you get crazy trying to develop a problem. So, with this, we reach the third principle in mind. For us, we have all the important data on the bus and we are providing tools for the people to know what's going on in the system. So, make things easier for development and creation. The last of the things we have in the robot are the wheels. So, wheels are connected to an actuator. This is the dynamaxel. The dynamaxel is connected to a microcontroller and the microcontroller is not running ROS. The microcontroller is connected to the Raspberry Pi which is the system running ROS here with the ROS master. So, you can guess how can ROS help me to make all these kind of weird connections. Right? No worries. There is another interesting ROS package called ROS Serial which is going to make some magic for you and communicate the microcontroller with the motors and the ROS system. We will see this a bit later when we explain the ROS to changes. So, we have the ROS Serial package. We have the PS3 UA. We have laser drivers and there are many, many, many more in the ROS in this. So, there are a lot of things that you have ready to be run out of the box for you in a ROS system. So, this gives us the four of the principle which is the Federation. I think this is no different than any other Federation of packages we have in the open-source world. So, I'm not going to explain that in detail because you probably know about that. So, what happened at some point in history that was in 2019, after 10 years of ROS use and development, we found many problems in different use cases because at that time there was ROS running from recent lead to the industry from underwater vehicles up to the International Space Station. So, that was no joke and we need to perform some deep changes into ROS. ROS2 was created with these principles in mind. I don't want to bore you with the principles again, so let's try to review them through use cases. So, the first of the use cases is what happened for the robot when there is an unstable network or high latency system. So, back to our friend, we have the Tartelbot, we have the remote controller. This time we are going to play with that computer because I want to visualize the lasers. All this is connected using the Wi-Fi at your house. Nothing special here. So, I can set the velocity commands that way from the remote controller up to the robot and get the laser scan back to the screen. Nothing really special. So, this is the diagram of the nodes and information and the communication channels for it. Nothing special, too. But what it could be more interesting is to know what's going on under the hood of this. So, what kind of transport layer is doing this magic communication? So, there was some Houston code called TCP ROS and UDP ROS. That code was written when ROS1 was created and it's the one taking care of moving the things. So, what happens if I control my robot at home and it's in the direction of a wall, right? And you say, oh, I want to stop it before it cracks. It's 1,000 euros in the robot node joke. So, the system is going to behave like this. The robot is going to put a lot of laser scans on the Wi-Fi. Laser scan is not as small as the velocity command. So, what happened at some point is, oh, another laser scan, oh, another laser scan, oh, another laser scan. And you try to send a velocity command to stop the robot. But what happened if the Wi-Fi is busy trying to transmit all the laser scans? You don't want to visualize things. You want to stop the robot. So, is there any way of saying this in ROS1? It wasn't. So, when creating the ROS2, this is the software stack. We are using from the microprocessor and the user code on top of it. When designing ROS2, different things happen. Sorry. Oh, my dear. Hello, no? Yep. I think we can continue. Can you hear me? I cannot. There is something different. Not the mic. Yep. Yep. Yep. So, when designing the new ROS2, you are... Yep. Well, I think we need to continue with this noise. Sorry. When designing the ROS2, from the beginning, it was using the third platforms, Linux, Mac, and Windows. Not really relevant to this talk. On the top of it, we still have the user code and the master, right? Thank you. So, the first thing that we did for ROS2 was to refactor the different libraries using the different programming languages. So, the first thing... Yep. Yep. No. No. Yes. No problem. We don't have to speak louder, but again, on the mic, because otherwise the stream won't hear you. All right. So, let's... Yep. We need a bit of silence, please. The main change here in that part of the programming language was to create a common layer writing in C, so it helps to have the common code inside it. Nothing really special for the transport problem that we have for the robot that is going to crash to the world. So, the main change that was done at this point in ROS was changing the transport layer, right? And during our research about looking for the best alternative, we found that there is a nice standard that is covering all or a good part of our problems. So, it's called the DDS standard that someone knows a little bit about it, DDS. So, what happened with the DDS standard is it describes itself like public service... Oh, family. Communication for real-time embedded system. Oh, goals for ROS2. It uses extensive control of QoS parameters, including real-time, really, bang-wise, delivery deadlines, and resort limits. So, we have quality of service here that can be used to say, oh, my velocity command should be sent first than my latest scan. So, whoa, that's a big gain we have in the ROS2. So, back to this, we have a standard there, but a standard is not an implementation, right? So, what happened with that standard is that we will find in the world different people doing implementations of this standard. So, we just use an abstraction layer to help those vendors to go into ROS, and we were using that. So, at this point, I want to make like a spoiler of the next talk. The friends of both are going to come to talk about Eclipse isorics. This is a nice, nice, nice, efficient system they made for communications. So, more use cases. How to manage a group of robots. So, you want the lottery, and you buy one, two, three, four, five, six. Well, seven. Seven of our small friends. So, my question for you is, where are you going to put the ROS master? You can just name one of them as the leader and put the ROS master on it, and what's going to happen if that runs out of battery? That the whole team is going to crash. So, that wasn't nice. Some people try to just replicate the ROS master in the seven of them. That's part of fun. But that didn't work reliable at any point. So, what happened for the ROS two? We have this stack here. We have the master over there. And at some point, reading the DDS standard, it says, requires dynamic and reliable discovery of public subscriber endpoints. So, the transport layer is doing exactly the same that we want to do in our application layer. So, what about delegating that function to the transport layer and we don't have a ROS master? Oh, wow. That is cool. So, we take out the ROS master from there. There is no master anymore in ROS two. So, the standard is completely distributed and every of the nodes is taking care of nodes, the information for the rest of the nodes and the communication channels. So, we just magically just take out of the ROS master. More use cases. This one can be interesting. So, let's go to the embedded and small system. So, how for us is a small system? So, this slide is from my colleague Smolankigli. He likes to name these kind of boards like laptop without the screens. These are the standard X6 boards, like the Intel Nook. The next one are the one that we have for the Raspberry Pi, Bigelbone and some others and they are treated like normal ROS system, like your laptop is running Linux. They have no problems of running ROS on the... So, in the other hand, we have the three bits MCUs. So, this is the one that we have in our robot chip. So, that was the target for ROS two, as the smallest one like a future work. But, back to our diagram, we have a microcontroller and a Raspberry Pi. So, what's happening in ROS one when we are running this? We are putting the ROS serial node. The ROS serial node is defining a protocol to communicate with the microcontroller, right? ROS serial is being run inside the Raspberry Pi. So, it's communicating with the microcontroller using a special protocol and it transforms all these readings into ROS information. Right? That was ROS one. So, yeah, Raspberry Pi is there. So, the master and the whole ROS system was running there. So, if we look into this, we have the ROS two stack. Whoa, let me take this back a little bit, yeah. We have the ROS two stack and we want to run on microcontrollers. What changes we need to do? The first thing is the ROS microproject, the people want to change something in the RCL layer. We don't have Python or Jam anymore. You can guess why. They've changed something in the RCL layer to make predictable execution. For example, if I have one process with two communication channels, and information is receiving at the same time, which one is going to be processes first? So, we didn't have determinism in that. So, they are changing that, making some changes in that. And the good part of it is, whoa, we have, in VDS, they have a special implementation called extremely resource constrained environment. So, that sounds like a microcontroller, right? So, from this, now, we are going to have the ROS two running on both, right? So, we are going to have, like, one single node publishing the information directly from the microcontroller. This is really cool. So, that is the way, obviously, you need to just download the code, special code, Houston code from ROS into your microcontroller, but it's able to run, like, any other node in ROS. So, they are, like, first class citizens on ROS, right? What is really happening under the hood, I don't want to stop to mention this. It's the VDS, it's using a server client connection, but this is in the transport layer implementation. So, we don't need to take care of that. So, the people implementing the XRCE VDS is taking care of it. Let's go into finish. We have more and more features. With the use cases, we have real-time capabilities. We just, I think, I just go with fast. But if we stop here, there is a nice change in there. So, we don't have a Linux system anymore, and we have a real-time system, not X, right? So, yeah, we have the real-time capabilities in ROS two. They were not present in ROS one, so all kind of funky things were done at that point. Not only it's running in not X, but people just report that they are working on free R TOS. It's able to work on VX works or QNX. So, it's large, super for that. Another powerful thing is security, because what happened in ROS one, if a friend of mine come to my Wi-Fi and connect the laptop to the ROS and sending commands. Yeah, the robot is going to just obey that command because there was no security of any time. So, that was really a feature. The ROS one was thought with, like, research lab in mind. So, and there are some other really nice and interesting features, life cycles, multiple nodes, single process, and that. But I'm going to stop here. No more time. Hope you enjoy. Thank you.