ROS2: The evolution of Robot Operative System
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 490 | |
| Author | ||
| License | CC Attribution 2.0 Belgium: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/47465 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
RobotPhysical systemTime evolutionBitCoefficient of determinationEvoluteRule of inferenceOperator (mathematics)Computer virusRoboticsSoftwareGoodness of fitComputer animation
00:51
GoogolOpen setRoboticsRoboticsOpen setSoftwareComputer animation
01:11
Single-precision floating-point formatOpen sourceRoboticsOperator (mathematics)BitMultiplication signCodeComputer programFrequencyComputer animation
01:52
AbstractionDistribution (mathematics)Software development kitOpen sourceSoftwareRobotGoogolPhysical systemBit rateSoftware frameworkPrincipal idealComputer programOpen sourceArmData miningRevision controlOperating systemSlide ruleFrame problemRoboticsReal numberComputer animation
02:22
WeightCoefficient of determinationSoftwareRevision controlCovering spaceRoboticsArmMultilaterationField (computer science)Multiplication signLaserMicrocontrollerMereologyExecution unitHydraulic motorOpen source32-bitStandard deviationFrame problemWhiteboardComputer animation
03:25
DistanceLocation-based serviceSlide ruleGoogolGame controllerRow (database)Focus (optics)BitRemote administrationRoboticsGame controllerMereologyDevice driverDemosceneComputer animationLecture/Conference
03:52
Game controllerSoftwareGoogolImage registrationInternetworkingDevice driverMultiplication signOptical disc drivePhysical systemStandard deviationRemote administrationRoboticsTelecommunicationRhombusEmailJoystickDifferent (Kate Ryan album)InformationRemote procedure callMereologyService (economics)Image registrationRow (database)Dynamical systemUsabilityProcess (computing)SubgroupCASE <Informatik>Source codeComputer animation
05:40
Distribution (mathematics)Component-based software engineeringEmailMessage passingMeasurementHidden surface determinationSemantics (computer science)AbstractionGeneric programmingInterface (computing)Message passingIntermediate languagePhysical systemTelecommunicationDiagramSpacetimeLevel (video gaming)2 (number)VelocityFile formatJoystickInterface (computing)Component-based software engineeringMereologyLinearizationProcess (computing)Form (programming)Point (geometry)Software developerCodeDifferent (Kate Ryan album)InformationRemote administrationMathematicsTask (computing)Game controllerFormal languageCausalitySmith chartBinary fileSemantics (computer science)Uniformer RaumComputer animation
07:54
DistanceLocation-based serviceSoftwarePort scannerMereologyProcess (computing)InformationSpecial unitary groupCASE <Informatik>MeasurementRoboticsType theoryBitBootingBelegleserComputer animation
08:58
GoogolCartesian coordinate systemGraph coloringVisualization (computer graphics)Endliche ModelltheorieResonatorDependent and independent variablesRight angleComputer animation
09:21
Slide rulePoint (geometry)Reading (process)Physical systemLaserMicrocontrollerError messageInformationGame controllerComputer animationSource code
10:02
Message passingPhysical systemGraphical user interfaceCommon Language InfrastructureGoogolSoftware developerPhysical systemMicrocontrollerLine (geometry)RoboticsComputer animation
10:31
Physical systemMicrocontrollerOrder (biology)Right angleSerial port
10:54
SoftwareSlide rulePeg solitairePrice indexPhysical systemHydraulic motorBitMicrocontrollerMathematicsSerial portDevice driverCuboidComputer animation
11:32
CodeVapor barrierGoogolPrice indexMultiplication signCASE <Informatik>Point (geometry)MathematicsDifferent (Kate Ryan album)Computer animation
12:26
System programmingTelecommunicationFormal verificationImplementationPhysical systemDeterminismComputer networkSoftwareRoboticsCASE <Informatik>Physical systemMultiplication signNeuroinformatikRemote administrationVelocity
12:48
GoogolNeuroinformatikRobotRemote administrationArmComputer animation
13:13
GoogolAnwendungsschichtTransportschichtInformationDiagramTelecommunicationRoboticsDirection (geometry)CodeHand fanComputer animation
13:56
GoogolRight angleRow (database)Direction (geometry)Port scannerLogic gateRoboticsMultilaterationSoftware crackingPhysical systemLaser scanningVelocityPoint (geometry)Computer animation
14:48
GradientMicroprocessorMathematicsRight angleTheorySoftwareReal-time operating systemExterior algebraBitTelecommunicationSign (mathematics)Programming languageLibrary (computing)Different (Kate Ryan album)MereologyComputing platformRoboticsGame controllerFormal languageStandard deviationPoint (geometry)Route of administrationCodeComputer animation
18:03
Service (economics)Distribution (mathematics)System programmingParameter (computer programming)Band matrixLimit (category theory)Standard deviationControl flowRoute of administrationSlide ruleVelocityLimit (category theory)Extension (kinesiology)Quality of serviceElectronic mailing listGame controllerTelecommunicationGame theoryMetropolitan area networkStandard deviationImplementationLine (geometry)Computer animation
18:41
Route of administrationArchitectureAbstractionStandard deviationDifferent (Kate Ryan album)AbstractionTelecommunicationImplementationPhysical systemPoint (geometry)Computer animation
19:24
Group actionRobotSlide ruleCASE <Informatik>Group actionStorage area networkRoboticsMereologyReading (process)Dynamical systemPoint (geometry)Computer animation
20:08
AbstractionRoute of administrationPhysical systemInformationStandard deviationFunctional (mathematics)TelecommunicationCASE <Informatik>Cartesian coordinate systemFile formatComputer cluster
20:57
System programmingGoogolArmSlide ruleTouchscreenCASE <Informatik>Physical systemNormal (geometry)Standard deviationSlide ruleWhiteboardLaptopMicrocontrollerAreaProcess (computing)Computer animation
21:53
Slide ruleCommunications protocolFamilyRule of inferenceDiagramSerial portPhysical systemMicrocontrollerCommunications protocolReading (process)Right angleCoroutineInformationComputer animation
22:32
Vertex (graph theory)Raw image formatSlide ruleGoogolRoute of administrationStack (abstract data type)MathematicsJava appletIntegrated development environmentTelecommunicationConstraint (mathematics)MicrocontrollerMereologyProcess (computing)ImplementationInformationMultiplication signBoss CorporationControl flowGame controllerGoodness of fit
23:37
GoogolInformationMicrocontrollerCodeHuman migrationSingle-precision floating-point formatPhysical systemSocial classComputer animation
24:10
GoogolCASE <Informatik>Client (computing)Server (computing)Physical systemGame theoryRight angleReal-time operating systemMathematicsConnected spaceImplementationComputer animation
24:33
SequenceProcess (computing)Vertex (graph theory)Slide ruleChi-squared distributionGoogolRoute of administrationRaw image formatReal numberInformation securityAuthenticationCryptographyZugriffskontrolleMathematicsPhysical systemReal-time operating systemMultiplication signPoint (geometry)Row (database)LaptopInformation securityWhiteboardVideo gameOvalSingle-precision floating-point formatMultiplicationRoboticsComputer animation
25:47
Point cloudFacebookOpen sourceMultiplication signComputer animation
Transcript: English(auto-generated)
00:22
Hello. Hello. Yeah. Hi. Can you hear me? Good morning, everyone. Yeah. Hello. Yeah. Good morning, everyone. My name is Jose Luis, and I'm here to speak a little bit about the robots,
00:40
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
01:03
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
01:24
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
01:44
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, and the first surprise for those of you that don't know about ROS before is like,
02:03
the robot operative system is not an operative system. So, it's an SDK, an open source SDK or framework to program real 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
02:22
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,
02:42
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 there. The Raspberry Pi is connected to a microcontroller. So, the name is OpenCR, but this is quite standard 32-bit ARM board.
03:05
And in the bottom field, we have a couple of actuators. This time, there are two dynamic servo motors controlling a couple of wells. So, all the hardware, software is completely open source in this robot. So, if you want to buy it, it's a nice thing. So, let's go
03:26
into focus on a couple of parts, just playing in 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 a remote controller so you can move the robot. So, what's going to happen? I have the remote
03:44
controller. Let's going to 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
04:02
internet for it. So, you will be surprised 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
04:20
the rest 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 this 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
04:46
channel just bringing all the keystrokes and information from the remote control 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 robot is
05:03
going to say, all right, this means nothing to me. So, you need to translate somehow the keystrokes, do something for the mobile base. So, there is another ROS package for it, and it's called a teleop twist joy. What it's going to do is it's going to read the keystrokes from the joystick here, yes, in that communication channel that it's going to discover it by asking
05:25
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
05:41
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
06:06
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
06:23
different in a space map or Wii controller or 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
06:43
defined, right? So, ROS has something really nice, which is an intermediate language that allows us to define what's going on in 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
07:05
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 common has a linear velocity and angular velocity
07:26
in a form of 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 this message translated into a Python
07:44
code that I can use. So, that's going to be done for you. So, no real pain into maintaining many different language for it. So, let's continue with our small friend. Probably the most interesting part is the 360 laser on top of it.
08:03
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, this is a process to control it. We call them ROS nodes, and to put the information in that channel,
08:22
this scan, we are going to call it the 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 boot in this rider, the ranges, and the measures that it is going to take, right?
08:42
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 to you another nice friend in ROS.
09:01
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 a 3D model, and these colors and the bars of colors you see there, they are the axis for the resonance of the robot, right? And what can you put inside
09:22
ARVIS are those red points. These are the readings from the lasers. 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.
09:45
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 debug the problem. So, with this,
10:04
we reach the third principle in mind. For ROS, 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.
10:22
The last of the thing we have in the robot are the wheels. So, wheels are connected to an actuator. This is a dynamaxial. The dynamaxial is connected to a microcontroller, and the microcontroller is not running ROS. The microcontroller is connected to the Raspberry Pi,
10:40
which is the system running ROS here with the ROS master. So, you can guess how can ROS help me to make all this kind of weird connection, right? No worries. There's another interesting ROS package called ROS serial, which is going to make some magic for you and communicate
11:02
the different, the microcontroller with the motors and the ROS system. We will see this a bit later when we explain the ROS2 changes. So, we have the ROS serial package. We have the PS3, we have laser drivers, and there are many, many, many more in the ROS
11:24
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
11:41
world. So, I'm not going to explain that indeed 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
12:06
because there, at that time, there was ROS running from reset lag to the industry from underwater vehicles up to the International Space Station. So, that was no joke,
12:20
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
12:41
when there is an unstable network or high latency system. So, back to our friend, we have the DARTEL bot, 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
13:05
DARTEL bot 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
13:24
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 custom code called vcpros and udpros, that code
13:46
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,
14:03
right? And you say, oh, I want to stop it before it crashes. It's 1,000 euros in the robot, no 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 happens
14:25
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 happens if the Wi-Fi is busy trying to transmit all the laser scan? You don't want to visualize things,
14:41
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 until the user code on top of it. When designing ROS2, different things happen.
15:05
Oh, sorry, is this, hello, no, yep, oh, what, I think we can continue, can you hear me?
15:25
I cannot, I think it's something different, not the mic, yep, yep, yep.
15:47
So, when designing the new ROS2, yep, well, I think we need to continue with this
16:01
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? So, the first thing that we did for
16:24
ROS2 was to refactor the different libraries using the different programming languages. So, the first thing, yep, yep, no, no, no, yes, no, no, yes, no problem.
17:10
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
17:24
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
17:44
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 a DDS standard that someone knows a little bit about it, DDS, right? So, what happened with the DDS standard
18:05
is it described itself like public service, oh, familiar, communication for real-time embedded system, oh, goals for ROS2, nice. It uses extensive control of QoS parameters,
18:21
including reality, bang-wise, delivery deadlines, and resource 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 ROS2.
18:41
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
19:05
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 BOSH are going to come to talk about Eclipse ISORX. This is a nice, nice, nice efficient system they made for communications.
19:24
So, more use cases, how to manage a group of robot. So, you won the lottery, and you buy one, two, three, four, five, six, 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,
19:48
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 was not nice. Some people try to just replicate the ROS master in the seven of them, but that's part of fun, but that didn't work
20:05
reliable at any point. So, what happened for the ROS2? We have this stuff 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 endpoint. So, the transport layer is
20:26
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 ROS2. So,
20:44
the standard is completely distributed, and every of the nodes is taking care of 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,
21:04
let's go to the embedded and a small system. So, how for ROS is a small system? So, this is a slide from my colleague, he likes to name this kind of boards like laptop without the screens. These are the standard X6 boards like the Intel NUC. The next one are the one that
21:28
we have for the Raspberry Pi, BeagleBone, and some others, and they are treating like normal ROS system, like your laptop, you're running Linux. They have no problems of running ROS on this. So, in the other hand, we have the 3-bit MCUs. So, this is the one that we have in
21:44
our robot tube. So, that was the target for ROS2 as the smallest one, like a future work. But back to our diagram, we have a microcontroller and a Raspberry Pi. So,
22:00
what's happening in ROS1 when we are running this? We are doing 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 transform all
22:20
these readings into ROS information, right? That was ROS1. So, yeah, Raspberry Pi is in there. So, the master and the whole ROS system was running there. So, if we look into this, we have the ROS2 stack. Whoa. Let me take this back a little bit. Yeah.
22:47
We have the ROS2 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.
23:00
We don't have Python or Java anymore. You can guess why. They've changed something in their 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 processed first? So, we didn't have determinism in that. So, they are changing
23:20
that, making some changes in that, and the good part of it is, whoa, 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 ROS2 running
23:43
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 special code, custom code, from ROS into your microcontroller,
24:04
but it's able to run like any other node in ROS. So, they are like first-class citizens of ROS, right? But this is really happening under the hood. I don't want to stop too much on this. It's the DDS. It's using a server-client connection, but this is in the transport
24:21
layer implementation. So, we don't need to take care of that. So, the people implementing the XRC DDS is taken care of. 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 a bit fast, but if we stop here, there is a nice change in there. So,
24:45
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 2. They were not present in ROS 1, so all kind of funky things were done at that point. Not only it's running in NATX,
25:04
but people just reported that they are working on Free ER POS. 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 ROS 1, if a friend of mine come to my Wi-Fi and connect the laptop to
25:25
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 1 was thought with like research lab in mind. So, and there are some other really nice and interesting features
25:44
like cycles, multiple nodes, single process, and that. But I'm going to stop here, no more time. Hope you enjoy. Thank you.
Recommendations
Series of 5 media