 Yeah, so everyone, I will try to keep it shorter than the original time, because yeah, we are running very late. So hi everyone, I'm Luca and I am a simulation person. And why am I a simulation person? Because robotics are painful. So personally, I started with drones and I found that so many times that maybe you are trying to test an algorithm and then a connector comes loose or you lose GPS and then your drone falls from the sky, crumbles into a thousand pieces or decides to fly into a trip. So it's just very painful when you're trying to test some algorithm and then you need to deal with all these problems in the real world or when you just want to isolate your variables and just test your algorithm. So I think that there are benefits to simulation, which is making life simpler than the real world when you don't need the accuracy of the real world. And together we're also doing CI testing. So if you want to make sure that your algorithm didn't break anything, that you can run around some series of simulations and make sure that your system supports. And this was probably mentioned by my colleague Yalu before already. And the idea is that we can use the same code in simulated world, in our simulator guest info and in the real world to make the transition as simple as possible. So like the product that Yalu mentioned before, our open source simulator, I will actually focus on any of our new iteration of the simulator, which we call like GZ, where we call the old one Casio Plastic. And the new version of the simulator is designed to be much more modular so you can plug and play different rendering libraries or physics libraries depending on how accurate you want your simulation to be. Let's say you want very accurate physics simulation or like very accurate rendering or if you want something that is faster but that's accurate. But the cool thing about this new version of the simulator is that it also uses this paradigm, which is the title of the talk, it's like ECS or Entity Component System coding paradigm. So what is this ECS, this Entity Component System paradigm? It's very popular in game development and that's where it was born. And the idea is to structure all your code base and all your logic into three different structures. Let's say you have entities which are identifiers for each object and usually it's just an integer. And then you have components which are containers for data or markets assigned to entities to like model properties or like specific abilities of entities. And finally you have systems and systems are just functions that act on entities just based on their components. So let's say if an entity has a specific component it will do some operation and otherwise it will not. The classic example there is even on let's say game development is that, let's say if you want to model like a player then you will maybe have a health component. So now let's say there is in your video game there is like some explosion and you want to like change the like apply damage to all the living things then you will just look at like all the health components and you will like update that singularly. So this is what like a system will do. We will just look at these data storage components and like will apply functions to that. What are the benefits? So the benefits is first of all like you know extensibility and encapsulation. So the idea is that every single component models a single behavior like you know you can have health or you can have like you know gravity or you could have like you know player components or anything like that. And then like if you want to like add a new behavior you just add a new component and that doesn't affect any of the pre-existing logic. So like you know the rest of the system is more confusing and changed. Which makes it very easy to like extend your simulation or your software and also like it encapsulates things very nicely because again like a component is like a standard of structure. It's also great for performance usually because it's free or too parallelized because let's say you want to use the player health example I used just now. Let's say I'm going to update the health of all the players. We'll just update, we'll just work on a specific component that is maybe very different from I'm going to make things fall from the sky that is affected maybe by the mess component of every of them. So the idea is that because all your systems can act on different types of data they can be trivially parallelized because they never have to like it's very easy to detect whether they need to access the same data or not and to make them parallel if that is not the case. And then because and then like you know from a performance point of view it's a bit more of our implementation detail but usually it's much more cash friendly so that it can like perform a lot better than like normal object oriented programming but this depends more on the implementation. So what are the drawbacks? Well the first drawbacks is that I'm sure that none of you in this room or I actually feel that none of you in this room have ever heard of this paradigm before so it's very unfamiliar and it can get some time to get used to it and like how to use how to write code that follows it and like that rips all the benefit of this paradigm. And then also because it's usually very heavily parallelized there is both a benefit and a drawback because sometimes it can be a bit unclear what the ordering of operation is so if you need like specific order like I want to update the player health because before I update like you know objects falling or anything like that that could like you know require some further thought so it can be tricky from the point of view. But anyway enough abstract talking I will just like illustrate like a very simple use case that we ran into in the OpenRMS project of like a traditional object oriented approach and like where the limitations were and how using this paradigm helps overcome these limitations. But the sample use case is simulating doors in the RMS so a door is a very simple object it can either be open or closed and then we want to simulate that with RMS so we want to be able to track their state so that robots can know where the doors are open or closed and then we want to be able to command doors so we want RMS to be able to tell the door can now open or close so those are the capabilities of a door and how does it work when let's say you have like let's say you have a hundred doors like each door would have a simulation plug-in where it receives commands that it does some logic let's say it was requested open and starts opening and so on and then it publishes its state and then you would do this like once for each door object that you want to simulate now what are the issues with this approach so the main issue generally speaking is scalability so as you move let's say we want to simulate like very large facilities let's say hundreds or even thousands of doors as you duplicate these objects like thousands and thousands of times you might reach bottlenecks and say every time you update your simulation you need to like run through every single update of every single door like in check if they receive any commands like you know check if they need to publish state and so on and then probably the most critical one it's a much more ROS-specific issue which is due to the usage of publishing and subscribing because now it means that every single door will have to listen to the commands and they will have to receive commands and check whether it applies to them or not and then publish the state but this is more of a ROS-specific issue but it's actually the main one that created some havoc because what happens is that because we are using simulated time then all the doors will be initialized at exactly the same time and then all of them will publish the state at exactly the same time and this actually creates a fair bit of issues or let's say your queues become full, you lose message and so on and like you know we can get around but like just like doing some like random initialization and so on but they really doesn't solve the... doesn't really help with the... it's more of a heck rather than like a proper fix so because of all these scalability issues let's try to take this video game industry paradigm there is also extensively using a Zivo and use it to see if we can scale out this problem and now so this is what an architecture would look like so it's the same, you would have 100 or 1000 door plugins but all they do is that they create a component so they would just say okay every plugin will just run once at start up and you will say okay I am a door and then it will not do anything anymore so these are all out of the window and now the only thing you need to run on every iteration is your system and now the system will just iterate through all the components and then like you know like do the actual logic so the main benefit here is that now you have like first of all you have a single publisher and a single subscriber that makes it that decreases a lot the overhead of like you know receiving messages and like deserializing messages and also like in raw terms it also decreases the complexity of like you know all the publishers discovering all the subscribers and so on but generally speaking it's a much simpler and much more like cash friendly and like much more performing, much better performing approach and here like you know screenshots of code but like don't really need to look at the code but in general like what you do is that again you create a component to say okay this entity is a door then you create a component to say okay this door has been told to do this operation which is closed or open or closed sorry component and then you create a component to say whether the door is open or closed and once all this data is created and populated all like all the logic is implemented in a single system that will execute logic based on these components which will look something like that let's say so for example something that needs to like you know a lot of code but the details don't matter so let's say something that needs to process commands you will look at all the all the command components and based on the command components you will command a door to be developed or closed on the other hand like you know let's say something like the system that needs to update the states you will just look at all the door components and then you will just you will just update the door state component based on what the state of the door is so now the real question is okay there was a lot of like you know like a lot of added complexity and it's like you know very weird like way to write code and like you will be populated somewhere and you have come to the data somewhere else and it's like very unclear so the question is should you do it I will use my friend here so someone would say yes yes yes yes yes I hope I hope like this is familiar to some people but to the people who are familiar with this they would know that the follow-up is also no no no no what some people might not might not know is that there is a software engineering version which is the independent version so the answer is that it depends on your use case of course so it's very useful if you want to re-scale up re-scale up your simulation which is the reason that this whole coding paradigm was born in the video game industry because in that case like performance is super critical and you need to like be able to handle like very complex words and like timing is very important because you must not drop the frame rate or like you know the player would be very frustrated so if scalability of performance is what you're looking at it's a very useful paradigm but on the other hand or like if scalability is not an issue and you just want to like you know simulate one or two robots and like not very complex it might probably not be worth it to like restructure your whole code base but for cases like you know OpenRMF where we want to like you know do very large scale simulations with like you know large business, large number of robots we want to like you know run them over long periods of time to make sure that everything works the answer is probably which brings me to my last slide I don't see it I don't feel it would be a complete talk in 2023 if you were not talking about Rust and how it's awesome and how much you love it and how like the world would be better with more Rust so we on the left you will see like you know the traffic editor that Yadu showed before but we are looking into like the next generation of our like traffic editing and traffic map generation of pipeline that actually is based on this paradigm on this entity component system paradigm is written in Rust it's based on a game engine it's 3D, it's awesome so if you want to play with it or keep an eye open and that was the end of my randomly gone entity component system and why it's awesome so thank you very much thank you very much Luka you guys have any questions for Luka alright so with these ACS like with model and is there any means you can broadcast to multiple objects like for example if you could like broadcast and play like PidMask like door space so all instances of door if that would say what we thought yeah so let's say if you wanted to broadcast everything to like a command to every door then you would just have a system that looks for all entities which have a door component and then you will like you know send the information to them this filtering you already like pre-select what they are only then it is that you care about and then if you want to do some additional filtering you can do it based on like what type of door it is or like you know on a PidMask in the door as you mentioned already any more questions you had the problem of multiple publishers subscribers right so in that like did you consider using service or action to not have so much I think it gets even more complicated in that case because like let's say what a service does behind the scenes is that you will like publish publish a request and then receive a response so it's actually even more traffic going on the wire but in this case like you know we are okay with the send and forget approach that topics give you but then like you know the moment you need to implement like you know hundreds or a thousand of them they're like all they're all published on the same topic at a very high rate it's like very easy to start losing message and so on how is the how is the surrounding support related to the ECS for example like document generation even testing like if I switch my OOP into an ECS like would they all involve learning support those no it's a different coding paradigm you probably have to restructure your test but then being said I personally find it also very convenient for testing because again you know you can like create a whole world but then let's say if you only want to test doors then you only look at the behavior or like you only iterate on this door component so maybe you can even like only create like basically it gives you like very fine control and it makes it very easy to like select the data that you're interested in and like you know either read or write it will also put you in testing purposes I understand it depends on a lot of factors but do you have a quantitative measure of how much the performance has improved using this paradigm over the traditional yeah so this is the million dollar question I think in this case it probably doesn't like actually improve the performance that much what it does is like it solves the root problem of like the scalability issue which is like you know the which is basically like the horrible hack and work around that we had to do because now like you don't need to like find new magic numbers to say okay now I have a hundred doors that will create queues of like 10 messages and it will be fine but next time I do thousand doors and now I need to increase my queues I need to make sure that there's nothing wrong with whatever so this at least like address that at the root cause but performance wise like at least for this very simple use case it doesn't matter too much because it's just a very small application of the whole simulation like the whole simulation like the performance is heated the main performance heats are due to other parts like you know simulating physics or like the robot projects and so on but in general like at least from the experiments from the experiments that we have been doing with this like rough space game engine the performance is very great so like you know you can easily run like 60FPS on your browser like as a web assembly have a full like real time without any problem but it's still a bit early to say that we like we have not run like you know large scale large worse if on the web assembly version yeah I would say