ROS2: The evolution of Robot Operative System
Rivero, Jose Luis
In FOSDEM 2013, Open Robotics introduced an overview of the Robot Operating System (ROS), an open software integration framework for robots created in 2007. After more than a decade of great success, powering from Robocup teams to NASA robots in space, ROS2 was born to break any limitation detected previously by roboticians all around the globe. It's an exciting time. This talk will explain the design changes and technical motivations that lead to the creation of ROS2 giving a quick overview of new features present on it: multi-platform, embedded devices, real time, etc.
 Hello. Hello. Hi. Yeah. Hi. Can you hear me? Good morning, everyone. We are sorry. We are sorry. We are sorry. We are sorry. Yeah. Hello. Yeah. 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. So before we start the talk, I want to introduce the company I work for. So we are a small company called Open Robotics and we try to create open software and hardware, no more and no less than that, 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 inventing 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 with 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 laser on the top. The laser is connected to the main computational unit here. This is a Raspberry Pi 3. The Raspberry Pi is connected to a microcontroller. So the name is OpenCR. But this is a standard, quite standard, 32-bit ARM board. And the bottom of it, we have a couple of actuators, this time there are two dynamic cell servo motors controlling a couple of wells. So all the hardware, firmware 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, the spline rows. 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 remote controller so you can move the robot. So what's going to happen? I have the remote controller. Let's go into 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. We are there. 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 am 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 is going to publish a communication channel just bringing all the key strokes and information from the remote control into ROS via that communication channel. But that is not really useful to control a robot. I cannot send to the mobile base of the robot. 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 key strokes to something for the mobile base. So there is another ROS package for it. It is called the teleop twist joy. What it is going to do is it is going to read the key strokes from the joystick here. Yes. In that communication channel that it is going to discover it by asking the master. So it is going to just subscribe to it and receive this kind of information from it. And it is going to transform it into something that the mobile base can understand, which is a common velocity. So with this, this is the first principle ROS, which is what we call a distribution. We have a published subscribe service somehow. There is 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 will have two different processes that working completely isolated. 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 in a space map or we control something. And it is 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. So you can guess how is the format of the information and where is that defined. So ROS has something really nice, which is an intermediate language that allows us to define what is going on in communication channels. 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 bring 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 a form of vector. 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 in maintaining many different languages for you. 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, there'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 writer the ranges and the measures that it is going to take. Right. OK. 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 put inside Arvis? These 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 the 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, 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 different, 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 give 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 store world. So I'm not going to explain that in depth because you probably know about that. So what happened at some point in history that was 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 lab 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 remote controller. This time we are going to play with that computer because I want to visualize the laser scan. 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 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 custom 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 happened if I controlled my robot at home and it's in the direction of a wall, right? So I want to stop it before it crashes. 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 would happen 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 laser code on top of it. When designing ROS2, different things happen. Sorry. Oh, my God. Is this? Hello? No? Yep. I think we can continue. Can you hear me? Yeah. I cannot. There is something different, not the mic. Yeah. Sure. Yeah. No? Yep. Yep. So when designing the new ROS2, you are... Let me try to... That's all? 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... Sorry. Yep. Yep. No. No. Yes. No. No. Yes. No, yes. No problem. I have to speak louder, but again on the mic because otherwise it's extremely loud. 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 its sheet 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... A good part of our problems. So it's called the DDS standard that someone knows a little bit about it. DDS, right? So what happened with the DDS standard is it describes itself like public service, oh, family, communication for real time and bed assistant, oh, goals for Rosti. Nice. It uses extensive control of QoS parameters, including real-worldly, bandwidth, 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 list scan. So whoa, that's a big gain we have in the Rosti. 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. 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 Rostmaster? You can just name one of them as the leader and put the Rostmaster on it and what's going to happen is that runs out of battery. But the whole team is going to crash. So that wasn't nice. Some people try to just replicate the Rostmaster in the seven of them. That's part of fun. But that didn't work reliable at any point. So what happened for the Rost2? 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 Rostmaster? Oh, wow. That is cool. So we take out the Rostmaster from there. There is no master anymore in Rost2. So the standard is completely distributed and every of the nodes is taking care of node the information for the rest of the nodes and the communication channels. So we just magically just take out of the Rostmaster. 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 treating like normal Rost system like your laptop is running Linux. They have no problems of running Rost on this. So in the other hand, we have the three bits MCUs. So this is the one that we have in our robot. So that was the target for Rost2 as the smallest one, I believe, like a future work. But back to our diagram, we have a microcontroller and Raspberry Pi. So what's happening in Rost1 when we are running this? We are putting the Rost serial node. The Rost serial node is defining a protocol to communicate with the microcontroller. Rost 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 Rost information. That was Rost1. So yeah, Raspberry Pi is there. So the master and the whole Rost system was running there. So if we look into this, we have the Rost2 stack. We have the Rost2 stack and we want to run on microcontrollers. What changes we need to do? The first thing is the Rost 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 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. So from this, now we are going to have the Rost2 running on both. So we are going to have 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 Rost into your microcontroller, but it's able to run like any other node in Rost. So they are like first class citizens on Rost. 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. We finish 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. So yeah, we have the real time capabilities in Rost2. There were not present in Rost1, 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 VXworks or QNX, so it's large, super for that. Another powerful thing is security, because what happened in Rost1, if a friend of mine come to my Wi-Fi and connect the laptop to the Rost 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 Rost1 was thought with, like, research lab in mind. So there are some other really nice interesting features, life cycles, multiple nodes, single browsers and that. But I'm going to stop here. No more time. Hope you enjoy. Thank you. Thank you.
 Hello.  Hello.  Hi.  Yeah.  Hi.  Can you hear me?  Good morning, everyone.  We are sorry.  We are sorry.  We are sorry.  We are sorry.  Yeah.  Hello.  Yeah.  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.  So before we start the talk, I want to introduce the company I work for.  So we are a small company called Open Robotics and we try to create open software and hardware,  no more and no less than that, 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 inventing  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 with 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 laser on the top.  The laser is connected to the main computational unit here.  This is a Raspberry Pi 3.  The Raspberry Pi is connected to a microcontroller.  So the name is OpenCR.  But this is a standard, quite standard, 32-bit ARM board.  And the bottom of it, we have a couple of actuators, this time there are two dynamic  cell servo motors controlling a couple of wells.  So all the hardware, firmware 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, the spline rows.  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 remote controller so you can move the robot.  So what's going to happen?  I have the remote controller.  Let's go into 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.  We are there.  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 am 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 is going to publish a communication channel just bringing all the key strokes  and information from the remote control into ROS via that communication channel.  But that is not really useful to control a robot.  I cannot send to the mobile base of the robot.  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 key strokes to something for the mobile base.  So there is another ROS package for it.  It is called the teleop twist joy.  What it is going to do is it is going to read the key strokes from the joystick here.  Yes.  In that communication channel that it is going to discover it by asking the master.  So it is going to just subscribe to it and receive this kind of information from it.  And it is going to transform it into something that the mobile base can understand, which  is a common velocity.  So with this, this is the first principle ROS, which is what we call a distribution.  We have a published subscribe service somehow.  There is 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 will have two different processes that working completely isolated.  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 in a space map or we control something.  And it is 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.  So you can guess how is the format of the information and where is that defined.  So ROS has something really nice, which is an intermediate language that allows us to  define what is going on in communication channels.  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 bring 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 a form of vector.  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 in maintaining many different languages for you.  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, there'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 writer the ranges and  the measures that it is going to take.  Right.  OK.  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 put inside Arvis?  These 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 the 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, 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 different, 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 give 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  store world.  So I'm not going to explain that in depth because you probably know about that.  So what happened at some point in history that was 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 lab 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 remote controller.  This time we are going to play with that computer because I want to visualize the laser scan.  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 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 custom 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 happened if I controlled my robot at home and it's in the direction of a wall,  right?  So I want to stop it before it crashes.  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 would happen 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 laser code on top of it.  When designing ROS2, different things happen.  Sorry.  Oh, my God.  Is this?  Hello?  No?  Yep.  I think we can continue.  Can you hear me?  Yeah.  I cannot.  There is something different, not the mic.  Yeah.  Sure.  Yeah.  No?  Yep.  Yep.  So when designing the new ROS2, you are...  Let me try to...  That's all?  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...  Sorry.  Yep.  Yep.  No.  No.  Yes.  No.  No.  Yes.  No, yes.  No problem.  I have to speak louder, but again on the mic because otherwise it's extremely loud.  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 its sheet 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...  A good part of our problems.  So it's called the DDS standard that someone knows a little bit about it.  DDS, right?  So what happened with the DDS standard is it describes itself like public service, oh,  family, communication for real time and bed assistant, oh, goals for Rosti.  Nice.  It uses extensive control of QoS parameters, including real-worldly, bandwidth, 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 list scan.  So whoa, that's a big gain we have in the Rosti.  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.  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 Rostmaster?  You can just name one of them as the leader and put the Rostmaster on it and what's going  to happen is that runs out of battery.  But the whole team is going to crash.  So that wasn't nice.  Some people try to just replicate the Rostmaster in the seven of them.  That's part of fun.  But that didn't work reliable at any point.  So what happened for the Rost2?  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 Rostmaster?  Oh, wow.  That is cool.  So we take out the Rostmaster from there.  There is no master anymore in Rost2.  So the standard is completely distributed and every of the nodes is taking care of node  the information for the rest of the nodes and the communication channels.  So we just magically just take out of the Rostmaster.  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 treating like normal Rost system like your laptop is running Linux.  They have no problems of running Rost on this.  So in the other hand, we have the three bits MCUs.  So this is the one that we have in our robot.  So that was the target for Rost2 as the smallest one, I believe, like a future work.  But back to our diagram, we have a microcontroller and Raspberry Pi.  So what's happening in Rost1 when we are running this?  We are putting the Rost serial node.  The Rost serial node is defining a protocol to communicate with the microcontroller.  Rost 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 Rost information.  That was Rost1.  So yeah, Raspberry Pi is there.  So the master and the whole Rost system was running there.  So if we look into this, we have the Rost2 stack.  We have the Rost2 stack and we want to run on microcontrollers.  What changes we need to do?  The first thing is the Rost 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 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.  So from this, now we are going to have the Rost2 running on both.  So we are going to have 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 Rost into your microcontroller, but it's able to run like any other node in  Rost.  So they are like first class citizens on Rost.  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.  We finish 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.  So yeah, we have the real time capabilities in Rost2.  There were not present in Rost1, 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 VXworks or QNX, so it's large, super for that.  Another powerful thing is security, because what happened in Rost1, if a friend of mine  come to my Wi-Fi and connect the laptop to the Rost 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 Rost1 was thought with, like, research lab in mind.  So there are some other really nice interesting features, life cycles, multiple nodes, single  browsers and that.  But I'm going to stop here.  No more time.  Hope you enjoy.  Thank you.  Thank you.
ema_ros2_evolution_0_167.png ema_ros2_evolution_168_1295.png ema_ros2_evolution_1296_2807.png ema_ros2_evolution_2808_3563.png ema_ros2_evolution_3564_5135.png ema_ros2_evolution_5136_6179.png ema_ros2_evolution_6180_8507.png ema_ros2_evolution_8508_11867.png ema_ros2_evolution_11868_12287.png ema_ros2_evolution_12288_12671.png ema_ros2_evolution_12672_13463.png ema_ros2_evolution_13464_14027.png ema_ros2_evolution_14028_14339.png ema_ros2_evolution_14340_15059.png ema_ros2_evolution_15060_15515.png ema_ros2_evolution_15516_16835.png ema_ros2_evolution_16836_16919.png ema_ros2_evolution_16920_17303.png ema_ros2_evolution_17304_18935.png ema_ros2_evolution_18936_19199.png ema_ros2_evolution_19200_19439.png ema_ros2_evolution_19440_28019.png ema_ros2_evolution_28020_29087.png ema_ros2_evolution_29088_29195.png ema_ros2_evolution_29196_29279.png ema_ros2_evolution_29280_31583.png ema_ros2_evolution_31584_31631.png ema_ros2_evolution_31632_31727.png ema_ros2_evolution_31728_35435.png ema_ros2_evolution_35436_36839.png ema_ros2_evolution_36840_36983.png ema_ros2_evolution_36984_37295.png ema_ros2_evolution_37296_38675.png ema_ros2_evolution_38676_39023.png ema_ros2_evolution_39024_39140.png
Hello. Hello. Hi. Yeah. Hi. Can you hear me? Good morning, everyone. We are sorry. We are sorry. We are sorry. We are sorry. Yeah. Hello. Yeah. 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. So before we start the talk, I want to introduce the company I work for. So we are a small company called Open Robotics and we try to create open software and hardware, no more and no less than that, 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 inventing 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 with 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 laser on the top. The laser is connected to the main computational unit here. This is a Raspberry Pi 3. The Raspberry Pi is connected to a microcontroller. So the name is OpenCR. But this is a standard, quite standard, 32-bit ARM board. And the bottom of it, we have a couple of actuators, this time there are two dynamic cell servo motors controlling a couple of wells. So all the hardware, firmware 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, the spline rows. 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 remote controller so you can move the robot. So what's going to happen? I have the remote controller. Let's go into 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. We are there. 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 am 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 is going to publish a communication channel just bringing all the key strokes and information from the remote control into ROS via that communication channel. But that is not really useful to control a robot. I cannot send to the mobile base of the robot. 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 key strokes to something for the mobile base. So there is another ROS package for it. It is called the teleop twist joy. What it is going to do is it is going to read the key strokes from the joystick here. Yes. In that communication channel that it is going to discover it by asking the master. So it is going to just subscribe to it and receive this kind of information from it. And it is going to transform it into something that the mobile base can understand, which is a common velocity. So with this, this is the first principle ROS, which is what we call a distribution. We have a published subscribe service somehow. There is 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 will have two different processes that working completely isolated. 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 in a space map or we control something. And it is 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. So you can guess how is the format of the information and where is that defined. So ROS has something really nice, which is an intermediate language that allows us to define what is going on in communication channels. 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 bring 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 a form of vector. 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 in maintaining many different languages for you. 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, there'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 writer the ranges and the measures that it is going to take. Right. OK. 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 put inside Arvis? These 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 the 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, 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 different, 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 give 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 store world. So I'm not going to explain that in depth because you probably know about that. So what happened at some point in history that was 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 lab 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 remote controller. This time we are going to play with that computer because I want to visualize the laser scan. 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 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 custom 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 happened if I controlled my robot at home and it's in the direction of a wall, right? So I want to stop it before it crashes. 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 would happen 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 laser code on top of it. When designing ROS2, different things happen. Sorry. Oh, my God. Is this? Hello? No? Yep. I think we can continue. Can you hear me? Yeah. I cannot. There is something different, not the mic. Yeah. Sure. Yeah. No? Yep. Yep. So when designing the new ROS2, you are... Let me try to... That's all? 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... Sorry. Yep. Yep. No. No. Yes. No. No. Yes. No, yes. No problem. I have to speak louder, but again on the mic because otherwise it's extremely loud. 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 its sheet 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... A good part of our problems. So it's called the DDS standard that someone knows a little bit about it. DDS, right? So what happened with the DDS standard is it describes itself like public service, oh, family, communication for real time and bed assistant, oh, goals for Rosti. Nice. It uses extensive control of QoS parameters, including real-worldly, bandwidth, 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 list scan. So whoa, that's a big gain we have in the Rosti. 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. 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 Rostmaster? You can just name one of them as the leader and put the Rostmaster on it and what's going to happen is that runs out of battery. But the whole team is going to crash. So that wasn't nice. Some people try to just replicate the Rostmaster in the seven of them. That's part of fun. But that didn't work reliable at any point. So what happened for the Rost2? 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 Rostmaster? Oh, wow. That is cool. So we take out the Rostmaster from there. There is no master anymore in Rost2. So the standard is completely distributed and every of the nodes is taking care of node the information for the rest of the nodes and the communication channels. So we just magically just take out of the Rostmaster. 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 treating like normal Rost system like your laptop is running Linux. They have no problems of running Rost on this. So in the other hand, we have the three bits MCUs. So this is the one that we have in our robot. So that was the target for Rost2 as the smallest one, I believe, like a future work. But back to our diagram, we have a microcontroller and Raspberry Pi. So what's happening in Rost1 when we are running this? We are putting the Rost serial node. The Rost serial node is defining a protocol to communicate with the microcontroller. Rost 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 Rost information. That was Rost1. So yeah, Raspberry Pi is there. So the master and the whole Rost system was running there. So if we look into this, we have the Rost2 stack. We have the Rost2 stack and we want to run on microcontrollers. What changes we need to do? The first thing is the Rost 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 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. So from this, now we are going to have the Rost2 running on both. So we are going to have 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 Rost into your microcontroller, but it's able to run like any other node in Rost. So they are like first class citizens on Rost. 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. We finish 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. So yeah, we have the real time capabilities in Rost2. There were not present in Rost1, 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 VXworks or QNX, so it's large, super for that. Another powerful thing is security, because what happened in Rost1, if a friend of mine come to my Wi-Fi and connect the laptop to the Rost 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 Rost1 was thought with, like, research lab in mind. So there are some other really nice interesting features, life cycles, multiple nodes, single browsers and that. But I'm going to stop here. No more time. Hope you enjoy. Thank you. Thank you.
called Open Robotics and we try to create open software and hardware, no more and no less than about the origin of it. It was back in 2007, so not an operative system. So it's an SDK, an open provides different kind of features for all the control by something different in a space map or friend in ROS. This is the visualizer. It's and creation. The last of the things we have in this a bit later when we explain the ROS to perform some deep changes into ROS. ROS2 was that way from the remote controller up to the leader and put the Rostmaster on it and what's a Linux system anymore and we have a real time