 Okay. Gentlemen, please sit down. Oh, we still have a lady. Thank you for being here. And our next speaker is Alejandro Mostillo from Spain. So please. Okay. So thank you for being here. I'm going to talk about programming robots with a binding that I have created. So I'm going to go from starting talking about what's ROS to how it can be used from ADA. And hopefully, if all goes well, I will do a small live demonstration. In a nutshell, in case I run out of time, this is what this is about. Louder. Louder. Okay. Basically, right now with this library, you can program robots with the same as easily as in other languages like C++ or Python. There is a small print, which I put not so small, so you are not mislead. And, well, what's ROS does and why I'm using this? I belong to a robotics laboratory. So we do from high-level algorithms, distributed algorithms to low-level things like taking care of the network medium to transmitting real time, and so on. And right now, programming robots, at least in some research contexts, means using ROS, which is a robot operating system. It's not an operating system, sorry. This is when I ask if somebody has used ROS before. Okay. Great. And so you know what it is for those that don't know. It's basically a lot of things that work on top of Ubuntu. And with that, you gain access to many sensors, actuators, algorithms. There is a communication infrastructure. Essentially, it's a big ecosystem to program robots. Just to get an idea of what kind of robots we could be talking about. This is the original robot that was presented with the project. It's, as you can see, a big robot. It has several embedded computers, several cameras, several lasers. Here's a demonstration that's oddly appropriate for FOSDEM. It's quite impressive when it becomes bigger. And here, it's doing a mission-critical mission, which is retrieving, you'll see in a second, retrieving beers for the programmers. Okay. So you see, it's, well, if you go shopping for parts, you will also find robots that come with ROS support. So it's kind of expected in third-time circles right now. So it's interesting to make Ada available for ROS. And somehow the video is interfering. Okay. And when you jump in the ROS one-bagon, you have access to many leading research projects for vision, cloud processing, and so on. Mostly leading robotics research. There's also push to make ROS industrial ready. Actually, I will talk about any project at the end of this talk. But in the title, if you paid attention, it says ROS2 and not ROS. The thing is that the new version is on the works. And this one is trying to fix the problems of the past. Basically, ROS was not designed with hard real-time in mind. It's more kind of high-level algorithms. So right now, they are paying attention to real-time capabilities, dynamic memory allocation, that will make ROS easier to use in industrial setups. And there is where traditionally Ada is excellent. So why not have Ada for ROS2? And what's a ROS2 program or ROS program in essence? It's basically a set of different processes or threads. Each of them is called a node. And it can communicate with other nodes. There are nodes for accessing sensors, for moving robotic platforms, to perform algorithms, and so on. In ROS2, there's an API which is low-level, which is in C. There are two officially supported C++ and Python high-level APIs. And there are third-party APIs like the one I'm presenting today. The simplest way of communication is to connect nodes via topics, which is simple publish and subscribe model of communication. And with that, you can create your own mess if you know what you are doing. Basically, some nodes publish information, some other nodes consume disinformation. And what information travels through those topics? Essentially, there is a way to define data types with text files, which get translated into records. And these records can be used to create new records. So it's basically the same thing that we do in all languages, but starting from a textual description. And now, moving a bit into how this looks in Ada. Well, this is how you would use a message in Ada. So you access the fields by name right now. You specify the type that you must know, although you can do introspection, and everything in Ada Spirit is type checked and bounce checked, and so on. Going back to the whole ROS architecture, this is what ROS is doing right now. At the low level, we have the communication facilities. In ROS 2, there is a standard for real time communications, embedded communications, which was not available in ROS. And then on top, we have the low level client library and the high level client libraries. So RCL Ada, what does is to provide the equivalent to the C++ Python libraries, but for Ada. Also with some examples of user code. Going a bit more in detail on what the package is that RCL Ada provides, we have those on the right. The binding is structured in several components that address several of the needs of the ROS ecosystem. The building process, access to messages, and finally the programming of actual programs. Looking a bit more into detail, those that are in green are the main packages provided by RCL Ada. We have the CMake functions that allow to integrate the Ada code in the whole compilation infrastructure. We have the message support, and finally the client API that is intended to write programs. And on top, there are a couple of samples, so people can check that things work as expected. There is a tradition in ROS that when you do a new client library, you implement the same programs, the same example programs in other languages, so they can interoperate, and you can check them easily. Talking a bit about the building process, ROS and ROS2 have gone through several tool sets. I'd say that this is something that most people in my laboratory hate about ROS, because they have changed things several times. Right now, things seem to have stabilized in Colcon, which is a tool that takes descriptions of packages in XML files, where you say what depends on what, and so on, and it can compile things in many languages. Things described with CMake, things described with Python configuration scripts, and so on. What we have done for this project in Ada is to use a few CMake functions to call GPR build. So basically, there is no reinvention of the wheel of compilation process of Ada in CMake, but CMake redirects to the GPR build, and so you get all the consistency checks of the Ada compiler for free. And at the end of the build process, you'll find the libraries or executables for use. Sorry. How does this look in practice? We have a few new directives all starting with Ada something, and for example, here you say that you are going to provide an executable with some GPR file. So it's as simple as that. You specify where is your GPR file, and everything should work out of the box. Of course, this is the theory. And for the final part of the library, we have the binding proper. When we have to interface with other languages, we need to write a binding if there is nothing before. And here we have the choice between automated bindings or manual bindings. Manual bindings are better because in theory they are written by a human who knows what he's doing. Automatic bindings have limitations just as we saw. And we can get pointers and things that we don't deal with in high-level user code. And in this case, what I did was to try to get the best of both worlds, also because Rust 2 is relatively young and so it's still evolving. So during the building process of the whole thing, what happens is that first, a low-level binding is automatically generated. And so we have the guarantee that we are using the actual existing C functions. And on top of that, it's the high-level manually written binding. So this way, users have a comfortable AIDA binding. And I can detect immediately if something has changed underneath and instead of getting mysterious segmentation faults, you get a compilation error because there is a mismatch between specifications and clients. Well, now moving into the final part, which is using the library, I'm not going through detailed code because that's too boring. So instead, I'm going to show you just two examples, hoping that everything works. The first example is just a basic note that talks. He says something and there's another note which is listening. Here for this first example, I will use the C++ note talking to the AIDA note. So I would go to where I have the library with my code. I would issue call-con-build and hopefully everything gets compiled fine. We'll see that. This is a backup copy. Nothing. If it goes wrong, there is no problem yet. There are some warnings that I have still to fix. So those are totally fine warnings that do not affect the demonstration. And for that, here I'm going to launch the C++ note. As you can see, it's Roast 2 invocation run within the demo note C++ package around the talker executable. And it starts talking. On the other side, I will... If that completion works, that's a good signal. And here, the listener. By integrating the building process with CMake, we gain this, that we get all the same features from Roast that other client libraries have. And now when this starts listening, well, whatever this says is heard to the other side. This could be local raw, local computer, over the network, or whatever. And for something a little bit... Well, if anyone is interested, there are other samples in the presentation that I just skipped for the client server communication. And for the final demonstration, which is a bit more involved, I will show that you gain access not only to Roast 2, but also to Roast 1, because we can use a special note that it's a bridge between the both versions. So here I will have a program commanding the simulator that comes with Roast, which is going back to our early days like a logo turtle. It's a differential drive robot. It can go forward and rotate, but it cannot move laterally. So I will send commands, and those commands will travel through the bridge and reach the simulator, which is written in a C++ note, and we will see what happens. Okay, so here, since this requires launching several things, Roast 1, Roast Core, the bridge, and so on, I have everything scripted. Hopefully everything will work. And first of all, here we have the Roast name server. Here I'm going to launch the simulator. Here it is that I'm going to put on top. Here we have... Well, it's kind of difficult to see. I realize, but okay. So now I'm going to launch the Aida client, and the robot should start moving. I cannot change the size, because that's a fixed size window. Here we are seeing the messages as they go through the network with the Roast topic echo. And, well, this is a pre-programmed sequence of linear speed and angular speed. There is no feedback. Anything could go wrong, but in a sense you have access to all the facilities of any Roast 2 node. And, well, that's it. It's finished. Now it's starting to go around in circles. So as conclusion, the presentation is here. The project, the conclusion is that Roast 2 is on kind of equal standing for Aida programmers. Two points to eliminate a barrier of entry for Aida programmers to Roast and Roast 2. There is... Well, the next revolution may be that of robotics. It's here. So not being able to easily program with Aida seems like counter-intuitive. You can do that. Also, the library has some special properties that the other client libraries don't have. Like, for example, thanks to the Aida superior stack management, there is no dynamic allocations in the Aida part. So everything can be allocated in the stack if you want. This also might simplify using Spark verified algorithms more easily with Roast robots. And, well, everything I have shown you right now is done for the bouncy version of Roast 2, which is end of life. But yesterday I got confirmation that I got a small grant to work importing this to the latest Roast 2 version and keep it up-to-date and integrate it into the build farm of Roast 2 so it should live moving forward and be kept up-to-date and hopefully integrated as a first-class language, even if the open-source robotics foundation is willing. And that's it. Thanks. Thank you. Sorry, I didn't have the last part. What do you need to do now that you have the board up and running to keep sync with the changes that are going into the RCL layer? Please repeat the question. Yeah, I think it's... What's the maintenance? Repeat the question of the word it's not recorded. Yeah, so the question is that what's the maintenance needs to ensure that this keeps in sync with the rest? Well, thanks to the automatic binding, I already know that for the latest Roast 2 version there are some breaking changes. The first step is going to be to fix those changes. Hopefully, RCL will be stable in the future with only new features. So the maintenance work will be to add those new features. For example, actions are still not implemented. That's another milestone of this new project. Yeah, what was the part that required the most work to create the library? For me, it was integrating the CMake building process that was really complex to understand because Roast 2 works with templating of messages and there are many hidden dependencies between packages that are not explained anywhere because for a normal user, it's not necessary to know. Then the binding, of course, is more work because it's quite big API, but it's more mechanical. So the more difficult was to get to understand how the build process worked with CMake, with Python, sometimes on the mix. Yeah. Okay, thank you.