We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Programming ROS2 Robots with RCLAda

00:00

Formal Metadata

Title
Programming ROS2 Robots with RCLAda
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
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
The Robot Operating System (ROS) is one of the chief frameworks for service robotics research and development. The next iteration of this framework, ROS2, aims to improve critical shortcomings of its predecessor like deterministic memory allocation and real-time characteristics. RCLAda is a binding to the ROS2 framework that enables the programming of ROS2 nodes in pure Ada with seamless integration into the ROS2 workflow.
RobotComputer programmingMultiplication signRoboticsSystem administratorCASE <Informatik>Computer programmingKeyboard shortcutComputer animationXML
Content (media)Context awarenessMessage passingArchitectureStandard deviationVertex (graph theory)Demo (music)DisintegrationFormal languageLetterpress printingRoboticsCASE <Informatik>AreaLevel (video gaming)Library (computing)Computer animation
Real numberLocal GroupRoboticsTelecommunicationMathematical optimizationRoboticsRight angleArithmetic meanAlgorithmSoftwareLattice (order)Multiplication signPhysical systemRow (database)Context awarenessComputer animation
AlgorithmSoftware developerPhysical systemRobotOperations researchDevice driverRoboticsSoftwareOperating systemRoboticsComputer programmingAlgorithmPhysical systemGame theoryTelecommunicationComputer animation
RobotRoboticsLaserProjective planeNeuroinformatikComputer animation
Programmer (hardware)Information retrieval
VideoconferencingRoboticsCirclePoint cloudLevel (video gaming)Projective planeDemosceneProcess (computing)Computer animation
Library (computing)Projective planePoint cloudProcess (computing)RoboticsRevision controlComputer animation
Embedded systemReal numberStandard deviationRoute of administrationImplementationRevision controlAlgorithmReal-time operating systemMemory managementUniform resource locatorData miningComputer animation
Vertex (graph theory)Process (computing)Service (economics)Client (computing)TelecommunicationSocial classImpulse responseLevel (video gaming)InformationSet (mathematics)Endliche ModelltheorieRight angleComputer programmingWater vaporAbsolute valueComputing platformCodecProcess (computing)Vertex (graph theory)Connected spaceDifferent (Kate Ryan album)Computer animation
SummierbarkeitInternet service providerEmailCartesian coordinate systemAngleRange (statistics)Maxima and minimaMessage passingInternational Date LineMeasurementPlanar graphMaß <Mathematik>Latent heatFloating pointPort scannerSubject indexingVector spaceMatrix (mathematics)Data typeBound stateTupleDimensional analysisAerodynamicsMessage passingInformationRow (database)Type theoryComputer fileDescriptive statisticsBitData typeFormal languageRight angleField (computer science)TelecommunicationComputer architectureLevel (video gaming)Computer animation
Route of administrationClient (computing)CodeSkeleton (computer programming)IDLTelecommunicationBuildingLibrary (computing)Level (video gaming)Client (computing)Computer programmingCodeReal-time operating systemBitConnectivity (graph theory)Process (computing)Physical systemRight angleSocial classECosMessage passingComputer animation
Software testingService (economics)Client (computing)Function (mathematics)Physical systemCompilerMessage passingComputer programmingBitFunctional (mathematics)Compilation albumMessage passingCodeClient (computing)Expected valueLibrary (computing)Sampling (statistics)Formal languageINTEGRALRow (database)Complete metric spaceWritingComputer animation
Process (computing)Configuration spaceDirection (geometry)Process (computing)SubsetConsistencyMultiplication signScripting languageFunctional (mathematics)WebsiteBuildingDemosceneArchaeological field surveyRow (database)Water vaporComputer fileFreewareSet (mathematics)Formal languageLibrary (computing)Flow separationBitCompilerRight angleCompilation albumDescriptive statisticsProjective planeComputer animation
Revision controlSource codeStandard deviationLatent heatFunction (mathematics)Integrated development environmentVertex (graph theory)Message passingComputer fileTheoryCuboidSummierbarkeitPeer-to-peerComputer animation
Range (statistics)Interface (computing)Computer configurationKeyboard shortcutCore dumpComputer fileComplete metric spaceConsistencyFunction (mathematics)PrototypeKeyboard shortcutTheoryLimit (category theory)MereologyPoint (geometry)Axiom of choiceLevel (video gaming)Library (computing)Metropolitan area networkCASE <Informatik>Formal languageCodeProper mapPointer (computer programming)Computer animation
Simultaneous localization and mappingLogical constantLoop (music)Vertex (graph theory)Library (computing)Keyboard shortcutCodeProcess (computing)BuildingCompilation albumLatent heatLevel (video gaming)Disk read-and-write headMetropolitan area networkFunctional (mathematics)MereologyComputer-assisted translationProjective planePoint (geometry)Computer animation
Function (mathematics)Interface (computing)Source codeLemma (mathematics)Vertex (graph theory)Backup
Vertex (graph theory)InformationBuildingProcess (computing)Right angleSubsetLibrary (computing)Lie groupServer (computing)Complete metric spaceNeuroinformatikTelecommunicationBeat (acoustics)Sampling (statistics)DemosceneSoftwarePresentation of a groupClient (computing)Local ringComputer animation
Service (economics)Server (computing)Demo (music)Turtle graphicsClient (computing)Presentation of a groupServer (computing)TelecommunicationSampling (statistics)Computer simulationMultilaterationBitBridging (networking)Vertex (graph theory)Turtle graphicsComputer programmingRoboticsDifferent (Kate Ryan album)Row (database)Error messageComputer animation
MathematicsPerturbation theoryAnnulus (mathematics)Message passingSoftwareVertex (graph theory)SequenceScripting languageLinearizationWindowCirclePresentation of a groupRoboticsServer (computing)CASE <Informatik>Client (computing)FeedbackComputer simulationSource codeJSON
Function (mathematics)DisintegrationVertex (graph theory)Formal languageResource allocationKeyboard shortcutLibrary (computing)CurvatureAlgorithmProjective planeRoboticsDynamical systemSource codeEqualiser (mathematics)Surface of revolutionUniform resource locatorFormal languageVapor barrierCategory of beingProgrammer (hardware)Forcing (mathematics)Point (geometry)Computer programmingGaussian eliminationSpecial unitary groupVideo gameBuildingRevision controlClient (computing)Open sourceMemory managementComputer animation
Message passingMathematicsSoftware maintenanceMereologyProcess (computing)Metropolitan area networkSynchronizationMixed realityReal numberControl flowGroup actionProjective planeKeyboard shortcutBuildingWhiteboardLecture/ConferenceMeeting/Interview
Core dumpPoint cloudFacebookOpen sourceComputer animation
Transcript: English(auto-generated)
Okay. Gentlemen, please sit down. Oh, we still have a lady. Come on. Thank you for being here. Our next speaker is Alejandro Mustillo from Spain. So please.
Okay. So thank you for being here. I'm going to talk about programming robots with binding that I have created. So I'm going to go from starting talking about what's Ross 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. 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. Well, what's Ross 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 transmit in real time. So on. Right now, programming robots at least in some research contexts means using Ross, which is robot operating system.
It's not an operating system. Sorry. This is when I ask if somebody has used Ross before. Okay. Great. 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.
With that, you gain access to many sensors, actuators, algorithms. There is a communication infrastructure. So 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. Here, it's doing a mission, critical mission which is retrieving, you'll see in a second, retrieving beer for the programmers. Okay. So you see, well, if you go shopping for parts,
you will also find robots that come with raw support. So it's expected in certain circles right now. So it's interesting to make Ada available for Ross. Somehow the video is interfering. Okay. When you jump in the Ross one back on,
you have access to many leading research projects for cloud processing and so on, mostly leading robotics research. There's also push to make Ross 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 Ross 2 and not Ross. The thing is that the new version is on the works and this one is trying to fix the problems of the past. Basically, Ross was not designed with high real-time in mind.
It's more high-level algorithms. So right now they are paying attention to real-time capabilities, dynamic memory allocation, and things that will make Ross easier to use in industrial setups. There is where traditionally Ada is excellent. So why not have Ada for Ross 2?
Well, what's a Ross 2 program or Ross program in essence? It's basically a set of different processes or threats. 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 Ross 2, 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. With that, you can create your own mess if you know what you are doing. Basically, some nodes publish information, some other nodes consume this information. What information travels through those topics?
Essentially, there is a way to define data types with text files which get translated into records. 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 textual description.
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 bound checked and so on. Going back to the whole Ross architecture, this is what Ross is doing right now at the low level, we have the communication facilities. In Ross 2, there is a standard for real-time communications,
embedded communications which was not available in Ross. Then on top, we have the low level client library and the high level client libraries. So RCL Ada, what those 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 packages 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 Ross 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 data code in the whole compilation infrastructure.
We have the message support and finally, the client API that is intended to write programs. On top, there are a couple of samples so people can check that things work as expected. There is a tradition in Ross that when you do a new client library you implement the same programs,
the same example programs than in other languages, so they can interoperate and you can check them easily. Talking a bit about the building process, Ross and Ross2 have gone through several two sets. I'd say that this is something that most people in
my laboratory hates about Ross 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 executories for use. 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 ROS2 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 Ada 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 node that talks. He says something, and there's another node which is listening. Here for this first example,
I will use the C++ node, talking to the Ada node. So I would go to where I have the library with my code. I would issue Colcom 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, but, yeah. So those are totally fine warnings
that do not affect the demonstration. And for that, here I'm going to launch the C++ node. As you can see, it's ROS2 invocation run within the demono C++ package, run the talker executable, and it starts talking.
In 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 ROS 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 ROS, 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 skip 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 ROS2,
but also to ROS1, because we can use a special node that is a bridge between the both versions. So here, I will have a program commanding the simulator that comes with ROS, which is the, it's 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++ node, and we will see what happens.
Okay, so here, since this requires launching several things, the ROS1 ROS core, the bridge, and so on, I have everything scripted. Hopefully, everything will work. And first of all, here we have the ROS 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 Ada 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 ROS 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 ROS2 node. And well, that's it, it's finished. Now it's starting to go around in circles. So as conclusion, presentation is here.
The project, the conclusion is that ROS2 is in, on kind of equal standing for Ada programmers. The whole point is to eliminate barrier of entry
for Ada programmers to ROS and ROS2. There is, well, the next revolution may be that of robotics, it's here. So not being able to easily program with Ada seems counterintuitive. You can do that. Also, the library has some special properties
that the other client libraries don't have. For example, thanks to the Ada superior stack management, there is no dynamic allocations in the Ada part, so everything can be allocated in the stack if you want. This also might simplify using Spark verified algorithms
more easily with ROS robots. And well, everything I have shown you right now is done for the bouncy version of ROS2, which is end of life. But yesterday I got confirmation that I got a small grant
to work on porting this to the latest ROS2 version and keep it up to date and integrate it into the build farm of ROS2 so it should leave moving forward and be kept up to date and have fully integrated as a first-class language even
if the Open Source Robotics Foundation is willing. And that's it. Thanks.
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 area?
Please repeat the question for the monitor. I think it's, what's the maintenance? Repeat the question or the word, it's not recorded. Ah, 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 ROS2 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 of the 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 ROS2 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.
Okay, thank you.