WEBVTT 00:00.000 --> 00:10.880 The interviews are next speaker, it's going to be Jose Luis Rifiero, probably but you're 00:10.880 --> 00:14.760 in your name, but that's okay. Hope it's a co-founder of Honour Robotics, but he's also a 00:14.760 --> 00:19.160 PEC member of the infrastructure team and gazebo team, and it's been around with 00:19.160 --> 00:24.440 open robotics for a really, really, really long time. And luckily he has voted me in as a 00:24.440 --> 00:29.040 mentee committee in the infrastructure team, so very happy. Thank you Jose, and thank you for 00:29.200 --> 00:34.680 my welcome. So you're all maxed up, here you go, all right, you're all right, you're all right, 00:34.680 --> 00:40.320 you're all right, you're all right, so whenever you want to start, go ahead. Sure. Thanks 00:40.320 --> 00:46.720 people for coming, thanks for the welcome, thanks to the committee for letting me to speak 00:46.720 --> 00:53.200 here 45 minutes, we are going to be 45 minutes together, so I don't see any coffee in this 00:53.200 --> 01:02.200 room, you should, so let's speak a little bit about Casivo, starting from the beginning, 01:02.200 --> 01:11.200 why I'm here, I'm, I have been working for open robotics for the last 13 years, since 2013, 01:11.200 --> 01:16.480 I have been part of the open solar robotics foundation, open robotics, and now they open 01:16.480 --> 01:24.080 source robotics alliance, so I've been here for a while, I'm a member of the Casivo PMC inside 01:24.080 --> 01:30.680 the Osgra, I'm also a member of the infraBNC, and I am the co-founder of a small consulting 01:30.680 --> 01:39.320 company, Coljono, where we usually try to put this experience of the core team into our clients' 01:39.320 --> 01:48.160 projects, so let's try to do something real and not meet with the keyboard the whole day. 01:48.160 --> 01:52.880 Let's start for the beginning, this is, we are speaking about Casivo simulator, the Casivo 01:52.880 --> 02:01.080 simulator is at 24 years old, Simulator, it was created in 2002, in the University of 02:01.080 --> 02:07.880 Southern California, by Andrea Ojova and Made Kidding, we have nights still in the PMC group 02:07.880 --> 02:14.760 today, so the phone there is still with us, it was built as an extension of a project like 02:14.760 --> 02:21.600 what's called stage player, someone in the room has to teach player a whole voice, but better 02:21.600 --> 02:29.200 I'm in the room, at the beginning, Casivo was implemented using ODI, this is open dynamic 02:29.200 --> 02:36.080 engine, and there was no render engine behind, so while directly using OpenGL, I have put 02:36.080 --> 02:44.040 some images for you people, this was the stage to the Simulator, but at the time, I really 02:44.040 --> 02:48.960 had 20s, and this was one of the first pictures that we have from Casivo, as you will see 02:48.960 --> 02:59.160 the point five, was like this, so it didn't change that much, right? 02:59.160 --> 03:06.560 So on that moment of being a university product, there was a couple of key milestones in 03:06.560 --> 03:14.760 the history of the Simulator, the first one was, Willowaraj was at his carap, it's 03:14.760 --> 03:21.320 famous for being like the place where the process was created inside it, Willowaraj had 03:21.400 --> 03:28.520 night cleaning, so it was in the same place, you have different kind of software projects 03:28.520 --> 03:34.600 together, and one of the first things that Casivo is famous for is to be the Simulator 03:34.600 --> 03:44.600 the PR2 robot, PR2 robot is that one, this is Casivo 1.4, this was inside Willowaraj, 03:44.680 --> 03:52.760 this was an important moment for Casivo, maybe because the fun in, also because in the same 03:52.760 --> 03:59.160 place, you have other projects like Ross and the project of growing together, but what's 03:59.160 --> 04:09.320 happening there, the other key milestones in 2012, we have in 2012, part of the group of the 04:09.320 --> 04:15.400 Willowaraj developers created what is called, or what's called, before it's called, it's still 04:15.400 --> 04:23.880 just, the open server robot expansion, so the open server foundation focus, the funding for 04:23.880 --> 04:30.680 the foundation was to focus on having external projects to be done by the foundation, so Casivo was 04:31.240 --> 04:38.440 driven by the time by those spreads, so one of the first period that we had for the Simulator 04:38.440 --> 04:44.440 Gasivo was the DAR robotic challenge, and it was a competition for human rights, so in 04:44.440 --> 04:52.680 rescue situations, so that's a picture of a human driving a golf car inside the Casivo, 04:52.680 --> 05:02.040 and at that time, so by that moment we had Gasivo versions 3 and 4, we started with the 05:02.360 --> 05:10.920 semantical version bumping bumps, in Gasivo, so by 20, 14 we have Gasivo 3 and 4, one of the first 05:10.920 --> 05:17.320 important things that happened by that time is that Gasivo was able to support different physics 05:17.320 --> 05:25.240 engines, so that time we had, whatever we also had, Symbari Dardan Ballet, another interesting 05:25.240 --> 05:30.200 interesting point is the addition of supporting digital elevation models, those one are the ones 05:30.200 --> 05:38.360 that the law was to create realistic terrains in San Casivo, and this is an image of that 05:38.360 --> 05:43.960 about that moment, this is 2013, this is my one of our college, Morgan Gellie, this is first 05:44.760 --> 05:51.240 so I think it's the first time that Gasivo was shown, and first of them, this is probably La Fontaine 05:51.320 --> 05:59.080 auditorium, yeah, and we were showing the human rights that we were working on at that moment in 05:59.080 --> 06:09.560 the USA, these two don't see, but that is me, as many present in the simulation, the testing that 06:09.560 --> 06:18.040 we did for having this human rights simulation competition, the class this was 2016, and we have 06:18.920 --> 06:25.000 Gasivo simulator was running with the Dalparovori Challenge, but that more, aside from the Dalparovori Challenge 06:25.000 --> 06:36.440 in 2017 we have the NASA program called Space Robot Challenge, it was about using human rights, 06:36.440 --> 06:44.520 this is the Baikiri robot assisting in a Mars mission, but that time what we have Gasivo versions 06:44.680 --> 06:51.080 in San Sanite, so we improve the human dynamics, we have had a good sense of integration, 06:51.080 --> 06:56.040 but at the moment we also implemented the Baikiri planning, I remember correctly, and there were many 06:56.040 --> 07:04.920 competitors that were put in together external controller, all goreens, for BIPET working, 07:07.000 --> 07:13.000 more things, we are getting to the end of the first step of Casivo, or the first stage of Casivo, 07:15.480 --> 07:22.280 laser releases for what we call the Casivo Classic, Casivo version 9 was a good one, we were working 07:22.280 --> 07:27.240 with the NASA in different projects, in the Space Robot Challenge, was one, but we have already 07:27.240 --> 07:35.160 been in the moon with the NASA, so at that time Casivo 9 was a huge improve in silos, 07:35.160 --> 07:40.680 we implemented the Kamaran lens flare, so you see the objects and the sun coming through the 07:41.320 --> 07:46.520 objects, when they have just passed through the sun, it's an amazing video call that you 07:46.520 --> 07:55.960 will render the moon, don't mind my co-workerian, he was just rendering, we were working mainly 07:55.960 --> 08:07.160 in things relating to this space, explorations, moon, the latest version that we have with Casivo 08:07.160 --> 08:14.600 using numbers, this Casivo 11, we finally see some of the some interesting changes in SDS, 08:14.600 --> 08:20.840 SDS, it's the language that we use to define the robots, so we had some friends and 08:20.840 --> 08:27.480 antiques, we have like a skeletal animations, but that moment and also track it vehicles and the 08:27.560 --> 08:38.520 sun are sensor was there by this time, so there was a moment where the core thing was having 08:38.520 --> 08:45.240 problem to maintain the level of the simulation and the level of projects with the existing 08:45.240 --> 08:50.760 architecture of Casivo, that was the creation of the ignition libraries, ignition libraries 08:51.080 --> 08:58.440 were there before, because we were using them in Casivo 8 or Casivo 7 probably, but the 08:58.440 --> 09:05.160 core thing just failed the necessity of changing the architecture, so a weekly idea it was called 09:05.160 --> 09:11.400 ignition gas, and it just libraries, you probably some of you probably know it, but there was a 09:11.400 --> 09:18.120 problem with the copyright of that name, so we rebelled that to call the new generation of Casivo 09:18.200 --> 09:26.680 the new generation, I was quite original, I know that this is causing pain for the people 09:26.680 --> 09:34.040 going to do in searches, but believe me that you cannot imagine how amount of words you need to just 09:34.040 --> 09:43.080 rename the whole project at the whole co-op. So one of the things that that moment was popular 09:43.080 --> 09:50.200 in the gaming engine was an architecture called entity components system, the easiest, so this is 09:50.200 --> 09:57.640 the core of the new Casivo, and it's like how the different steps that coordinate so the components 09:57.640 --> 10:03.480 of the simulator are done and are defined, so apparently then from the data that are going with 10:03.480 --> 10:09.080 the different tasks that the simulator needs to do, so we implemented an entity component system, 10:10.040 --> 10:15.240 by that time we split the whole simulator in different libraries, I know that you guys probably 10:15.240 --> 10:21.960 don't like that, but what was the moderate approach that we used to have the simulator in that sense. 10:24.200 --> 10:30.440 One of the things that we started to see is let's try to have the simulation the simulator to run 10:30.520 --> 10:39.160 only the pieces that you need, so we converted the whole rendering system and the whole physics system 10:39.880 --> 10:47.960 into what we were planning based systems, so you can load on own load whatever you want to use 10:47.960 --> 10:55.560 with the Casivo at that time. The other reason to change the whole simulator is like we really wanted 10:55.560 --> 11:04.200 to use new versions of the server, it was like this is 2019 and the old Casivo was tied to 11:04.200 --> 11:12.360 part of this thing, so we took that advantage of the providing to bump many of these versions. 11:14.600 --> 11:21.080 This is a video of one of the first versions that we have, this is probably a mission 11:21.160 --> 11:26.760 agorobolis, the mission blueprint, we were working by that moment in a different project, 11:26.760 --> 11:33.240 this called the soup, the running and challenge, but was a huge mining complex and there was like 11:35.080 --> 11:40.120 the competitors need to go with their robots inside that mine, you have been, you have seen 11:40.120 --> 11:47.960 smoke in there, we were simulating particles, we were simulating things smoke in there and the robots 11:48.040 --> 12:01.720 went into this big cave, so the one to stand in touch here, this is how we come to what we have 12:01.720 --> 12:08.120 to take, this is the current Casivo, we did more than 10 different releases, the new Casivo has 12:08.920 --> 12:13.800 nice interesting rendering capabilities, we bump the over version to the next generation of 12:14.120 --> 12:19.160 the factory in there, in the various of the garden, we have the bull can support, there is 12:19.160 --> 12:24.840 physically based rendering, it's probably a nice rendering capabilities, we have two stances, 12:24.840 --> 12:33.480 particle feds, lens flares and a bunch of different things for rendering, we have the physics, 12:33.480 --> 12:40.600 we implemented another physics engines, a valid feeder stone, different from the valid original 12:41.240 --> 12:47.240 we created a trivial physics engine for the speed up simulations that are big and we have like 12:47.240 --> 12:54.040 out on a national collision in harmonic and finishing with what we have in the Guillaume Casivo, 12:54.040 --> 12:59.800 there is not the goal of this talk, we have a nice growth to integration, this is probably 12:59.800 --> 13:05.560 not the most popular features that we have in Casivo, we have the build directional breach 13:05.640 --> 13:11.880 operating, we added composable nodes, to avoid like the memory copies of the message passing, 13:12.440 --> 13:16.600 we added in the last release, the national similarity interfaces, so it's this year to change 13:16.600 --> 13:24.600 between Casivo and other simulators, and it's a simulator that is using a large variety of the 13:24.600 --> 13:31.880 mains, so we have a good marketing support, there has been a use in all kind of brown vehicles, 13:31.880 --> 13:42.600 and there are people using an ideal space in Casivo, we have manipulation, so this is a short history 13:42.600 --> 13:53.400 of Casivo, so now the question is we now have the mother times, so what I understand by the 13:53.400 --> 14:01.640 mother and times, say the last five, six year, how many things has changed and what did this 14:01.640 --> 14:08.280 mean for Robert X in the last four or five years, so the first thing that that this has changed 14:08.280 --> 14:14.440 and it's obvious for you guys probably is the computational power, so we have more powerful 14:14.440 --> 14:20.680 computers and laptops, we want to run a simulation, we have more computational power now in 14:20.680 --> 14:31.320 every single device, and we just assist to the rise of this twin GPU, I put this, it's a graph, 14:31.320 --> 14:37.880 more of the mother times, so one, one together, one, that graph is the Nvidia hardware, the 14:37.880 --> 14:46.600 Nvidia shares between the years, so in the last five years GPU is everything, probably 14:46.680 --> 14:54.040 only because the rise of the AI and machine learning in these last years, but there was before 14:54.040 --> 15:02.280 to improve the computations in robotics, so that's changed a lot, one more thing is we have 15:02.280 --> 15:08.120 been changing these years, the programming language is, so we have new C++ standards of price, 15:08.120 --> 15:14.840 this is not new, but some of them are out, we have seen the popularity of go, 15:15.800 --> 15:21.880 sometimes more popular, sometimes less, and we just assist to the types that I just discovered 15:21.880 --> 15:30.440 this being creating, that's like, is that the most useful language left here, but let's focus on 15:30.440 --> 15:36.040 the simulation and robotics, we have two important ones that I want to mention here, the first one 15:36.120 --> 15:44.440 is Python, Python was there from before, but it's like, it's been used, we have seen some questions 15:44.440 --> 15:53.000 about that before, like the high level logic applications inside the C++, inside the robotics space, 15:53.000 --> 16:00.280 and one thing that happened to Python lately is like, it's been used by the AI community, 16:00.600 --> 16:09.400 and this is probably not a surprise for you, if I put rust in the list, so it's like the 16:09.400 --> 16:18.040 big trend that appeared here, it's a efficient language, there are many different projects 16:18.040 --> 16:24.360 between nice things and rust, it's already present in some mature projects, like the kernel, 16:24.440 --> 16:29.400 in the second language, been approved by the kernel, change kernel, or even in Firefox, 16:31.000 --> 16:35.720 but things that have changed and I think they are going to be important for the last part 16:35.720 --> 16:44.200 and how we apply them to C++, package manager, real systems, we have seen the creation of this 16:44.280 --> 16:51.640 had a medic, some boxes, built system probably basel, is the most popular one, some others, 16:52.680 --> 16:59.080 we have seen the creation of the package manager using a function, language, this is quite impressive 16:59.080 --> 17:04.360 to my eyes, the doppelades in the border of building and deploying things, I'm speaking about the 17:04.360 --> 17:12.120 next, you probably guys also know about it, we have seen some others like not so complex, 17:12.760 --> 17:17.720 but they work in an environmental isolation, light recovery isolation, file path isolation, 17:17.720 --> 17:24.440 speaking here about conda, we have seen the creation of nice tools, that operates on conda 17:24.440 --> 17:31.000 packages like Pixie, that can create reproducible, fully reproducible build for you using a 17:31.080 --> 17:41.960 log file, what things we have seen in these last five years, this one is important, optimize data 17:41.960 --> 17:48.760 communications, so we have seen the evolution of the DDS frameworks, particularly in cyrosh, 17:50.040 --> 17:59.640 fast DDS, cyclone DDS, with that evolution there was a focus put in something that we usually call 17:59.720 --> 18:06.920 cyroshobby, cyroshobby straight to avoid to create unnecessary copies in memory, when we generate 18:06.920 --> 18:12.360 some data and we pass some data to others consumers inside the same machine or in different machines, 18:13.480 --> 18:18.520 we have to talk about these eyesorex, it's the implementation of a 18:18.600 --> 18:29.960 serum memory for bi-synthaway DDS cyclone, a bi-migal late today, in 2020, we are situation of 18:29.960 --> 18:41.320 you know, that change also the way of seeing that they previously communication that were 18:41.400 --> 18:48.200 mainly DDS based in the space of the rust, so a single is writing in rust, it's a mother 18:48.920 --> 18:54.600 published as a scriber, but you can also do some queries, it supports lots of mid-word topologies 18:55.400 --> 19:03.720 and it's able to work in in backwind in badwill limited networks, so there's a talk today, Julian and 19:04.680 --> 19:11.240 are talking about the integration of Sinoa with Ross Cintras, see that later today, 19:11.240 --> 19:19.320 want to come, more things that change, we have already seen this morning, something about this, 19:20.680 --> 19:26.040 there were a lot of sprangers, so there is no value Ross now, we have Dora, Dora was creating 19:26.120 --> 19:33.400 2020, I've seen for the first time hearing the Ross Cintras, Dora is writing in rust surprise, 19:34.840 --> 19:39.160 and the first time I listened to it, I say, oh, it has everything I really want to have in 19:39.160 --> 19:45.880 a row of different, so it's like it's using Sinoa, Cinoa bi-local communication, it's using open 19:45.960 --> 19:53.160 telemetry, which is really nice, superb multi-a-a agents and multi hardware applications, 19:53.160 --> 20:00.760 and it uses Sino to do the communication, so it's one of the frameworks that it's operating now, 20:00.760 --> 20:08.920 and it's coming, more popular, we have Sinoa talked about this morning, so copper, I think it was 20:08.920 --> 20:16.680 creating in 2024, I know, around, it's also writing in rust, and what it makes, 20:17.480 --> 20:25.160 copper different from Dora, it's using a rendering engine, and it is using a physics engine, 20:25.160 --> 20:31.720 so we are approaching to the simulator space here, baby, it's a rendering engine in rust, 20:31.800 --> 20:39.720 native and rust, baby and radiation are rust, native physics engine, so the way that copper 20:39.720 --> 20:45.800 works is you're going to have a declarative file, it's been able to just create a whole system for you, 20:46.520 --> 20:55.400 but it's full developers, we have Sinoa before here, we're getting closer, 20:56.360 --> 21:03.720 what we have seen in robotics, simulators in the last five years, in the last ten years is like 21:04.760 --> 21:10.600 new ones, I mean it's not that so price for anyone, if I put here and be a isaxin, 21:11.320 --> 21:15.400 I just put all the trademark things like that work, I promise that they were in the, in the 21:15.400 --> 21:20.680 web page, so I know it's not like I want to put any emphasis in that, yes, copy-based, 21:21.640 --> 21:29.080 video isaxin was released in 2019, not that long, and it's built on top of something called 21:29.080 --> 21:39.320 Nvidia omniverse, it's a digital as a platform that allows the isaxin to use many nice three features, 21:39.960 --> 21:46.520 the physics are implemented using something called Nvidia phi, phi, x, phi, x, 21:46.600 --> 21:53.320 x, property, it's not a property that is an open source Nvidia physics engine, 21:54.040 --> 21:57.960 designed to work well with Nvidia cards, and it's integrated with the Nvidia isaxin lab, 21:57.960 --> 22:05.000 that is one of these labs to spawn 100,000 subsimulation at the same time, so this really 22:06.040 --> 22:15.800 impacted the ecosystem where the civil was operating before, the other the player that we have here 22:16.600 --> 22:24.280 of 3D, of 3D, is rendering, it's a very mean engine, it was created for the, from the old 22:24.280 --> 22:31.480 Amazon lumber car, someone knows that before, and it's relatively new, it's 2021, it's here, 22:32.200 --> 22:40.680 it's using the same physics engine that the Nvidia isax, and it has, it uses its own rendering, 22:40.680 --> 22:46.280 which is a really nice one, and there is an extension to connect it to gross, and it's 22:46.360 --> 22:52.280 and it's more in the game in the space where you have a GUI and many utilities to create your 22:52.280 --> 22:59.960 simulations, your simulations or your animations, the third thing that I want to put here is not 22:59.960 --> 23:07.080 a simulator, it's more of physics engine here, but the thing is relevant to go to here, 23:07.560 --> 23:17.880 it's a Google, a physics library, they didn't create it, but they acquired it at some point, 23:19.160 --> 23:26.840 so they made it open source it wasn't at the beginning, and it has an incredible dynamics support 23:26.840 --> 23:33.120 It's able to simulate many of the dynamics that are crazy for simulators, like tendons. 23:33.120 --> 23:40.920 So what are the good things that we have with Mujogo and Google behind is it has like 23:40.920 --> 23:51.960 nice GPU support, but not only designed to work with Nvidia version, but also the Mujogo 23:51.960 --> 23:59.280 MJX, this is able to work with any of the GPUs that we have in the market. 23:59.280 --> 24:07.400 Google and Mujogo has its own render, it's quite ugly, if you have seen it, it's 24:07.400 --> 24:18.960 based in Nopenzia, it comes to like offline renders, using EGL technique, this to finish 24:18.960 --> 24:26.120 and just the last section of it, what has changed really changed the last year is the 24:26.120 --> 24:34.400 machine learning AI, so it's not new to you, if I mention here the rise of the deep learning 24:34.400 --> 24:41.280 frameworks, PyTorzware, TensorFlow, they are both from different companies, they are supporting 24:41.280 --> 24:48.080 GPU and TPUs to create like neural networks, doing there are many people using them to 24:48.160 --> 24:54.720 nowadays to create all kinds of robotics learning teaching, the second point here is this kind 24:54.720 --> 25:01.280 of robotics gems, we have seen it scarce to me a little bit, where they would like like human 25:01.280 --> 25:08.880 edge failing thousands of them moving around and to generate synthetic data for training, 25:08.880 --> 25:15.920 so I think this is what we have here until here and now we are going to with the interesting 25:16.800 --> 25:23.440 one, so this is the context where gazebo is nowadays, we have a long time simulator operating 25:23.440 --> 25:33.600 and we have all the context has changed in the last years, so what are we doing in the 25:33.600 --> 25:41.200 courting, what is being planned with all these context on the table of this rust, so we're 25:41.280 --> 25:47.280 coming, these new simulator coming, what are the decisions we are taking on what are the developments 25:47.280 --> 25:56.160 that we are doing, first thing, so when the people is approaching to me nowadays, oh, I see, 25:56.160 --> 26:04.240 I see, it's okay, but it's not photo reality, I see, oh, yeah, okay, yeah, you just put 26:04.320 --> 26:12.880 that box and for fears that needs moving, it's not photo reality, okay, this is the first, 26:12.880 --> 26:18.960 one of the first things that happen, so stop here, this is a personal, this is a personal take 26:18.960 --> 26:27.600 a personal opinion of mine is how, what you are looking into a nice, realistic world, 26:27.680 --> 26:35.360 how important is the rendering, so I have this question here for you guys, so what just 26:35.360 --> 26:41.760 try to open off with the ISAC and create a route without being like a 3D model for the 26:41.760 --> 26:50.320 signer, how that looks like, it's like magic, it's like you need like you need the work or 26:50.320 --> 26:57.200 a model designer, you're rendering engineer tweaks, to put this kind of text, this kind of 26:57.200 --> 27:06.480 lights in the world, so to be able to display this realistic environment, so it's not only the rendering, 27:06.480 --> 27:14.720 the rendering is important, don't take me like that, but this thing for me is the key important point, 27:14.800 --> 27:20.240 the second important thing, I was discussing with my coworker Ian, friend Ian, and I say, hey, 27:20.240 --> 27:28.240 I have this feeling, and he's a rendering expert, and Ian told me, yeah, that's kind of true, 27:28.240 --> 27:35.680 I mean, rendering engineer is important, but there is also an important point is how many features 27:35.680 --> 27:42.080 you are enabling by default, like when you open a zero, so much here is developing a zero in 27:42.080 --> 27:49.920 a laptop, yeah, so on, no, yeah, so on, have you ever tried to open ISAC sim in a laptop? 27:51.760 --> 27:58.000 Okay, yeah, so it's like, Ian was explaining me that this is like this kind of rendering features 27:58.000 --> 28:03.680 that I'd consume in memory and resources, that we don't want to put that in the default run of 28:03.760 --> 28:13.920 Kasey. So, I'm going to show one as light, I have it since two days ago, and it was 28:13.920 --> 28:21.360 proprietary confidence, yeah, so please, though, I think, I get this probably the most interesting 28:21.360 --> 28:28.400 one in the whole presentation, this is showing the same world, the same spirits, being run 28:28.480 --> 28:35.840 in a zero, off-ready, and I succeed, so I think the I succeed, the solution is no good, so 28:36.640 --> 28:42.800 don't take it like that, because you know how operate I succeed, the people in here is, 28:44.160 --> 28:50.320 I don't think there may be, there are better, but I don't think I like Kasey, it's not terrible, 28:50.480 --> 29:01.680 but the point is you put time into just a configurational world. So, now I'm going to bring here 29:01.680 --> 29:08.800 the court in decisions and plans. The first one, we have expected in the next release, in Gasey 29:08.800 --> 29:14.480 of Cuba, this is, this is in the primary goal in the roadmap, we have the improved the rendering 29:14.640 --> 29:21.120 quality. So, from the courting, we explained that we are aware that there are other rendering 29:21.120 --> 29:26.560 engines that are good, we want to use them, I see, but we want to create a proof of concepts, 29:26.560 --> 29:35.360 integrating the whole rendering will be a difficult job, and you can comment and ask me, 29:35.360 --> 29:40.640 okay, run maps, I mean, I have a roadmap for everything and never get into the real, 29:41.120 --> 29:47.840 there was a hackathon done by the friends of intrinsic, where the Gaseo members of the Gaseo 29:47.840 --> 29:54.400 courting were participating, so there was an analysis, so this is real work, there was an analysis 29:55.040 --> 30:00.960 of the different existing rendering alternative we have in place, which is the Kodot, 30:01.840 --> 30:07.600 filament and berry, and the goal was to create a proof of concept from that hackathon. 30:08.480 --> 30:17.840 So, they finally selected berry, which is a rust, we just descend from baby before, it's a rust 30:17.840 --> 30:27.440 base rendering engine, I think it's easier to integrate. It appears in 2020, it's a rendering 30:27.600 --> 30:32.320 and it's been powered by something under the hood, which is going to be important here, it's 30:32.320 --> 30:40.640 something, it's going to appear again, called WGPU, WGPU is also a rust thing, and it's an 30:40.640 --> 30:50.320 graphic API, that graphic API has the magic of being able to call all other different graphics API 30:50.400 --> 30:57.840 depending on the platform, so it's a powerful tool that allows us not to have to write 30:57.840 --> 31:07.920 different code depending on the platform. This is the first proof of concept of a different rendering 31:07.920 --> 31:19.040 using Gaseo, so the video down is running a simple simulation and the image above is a 31:19.040 --> 31:26.240 baby render static image, so it's not like it's working, like a rendering engine, but with a 31:26.240 --> 31:32.320 couple of hours of work, we were able to take a civil war and put that in baby to create a rendering, 31:32.320 --> 31:42.960 maybe you can see that it has a bit more of contrast, maybe, so things are been done in this 31:43.040 --> 31:51.920 aspect. More things in this rendering change, this is a bold work was created by the Gaseo 31:51.920 --> 32:00.000 project lead, in the global design, this is our repository where we put designs and ideas and 32:00.000 --> 32:07.760 architectural changes, he's proposing to use to connect baby with Gaseos, are we seeing before, 32:07.760 --> 32:15.600 but not integrating baby inside Gaseo, but creating like a connection from Gaseo to baby, 32:16.400 --> 32:23.280 here we plan to use Cino for serve memory communications between these two pieces and also to create 32:23.280 --> 32:29.520 flat buffers that help us to avoid like this set of copies that we were speaking before the 32:29.520 --> 32:36.240 modern approaches are used, so there's a lot of activity in the rendering side, let's see if we 32:36.240 --> 32:44.320 can come with something interesting in there, speaking about Cino copy communications, what is 32:44.320 --> 32:50.880 the transport layer in Gaseo, the transport layer in Gaseo is called Gaseo transport, Gaseo 32:50.960 --> 32:58.400 transport is no more than a lot of up with the good old Cero and Cue and some code to handling 32:58.400 --> 33:10.640 all together. This custom code helps us to not create extra copies in memory when we are running 33:10.640 --> 33:17.520 in intra-process mode, using Gaseo transport, so it's been working pretty fine, I'd say. 33:18.400 --> 33:24.000 One of the features I will have, this is already released and you can use it in the latest version 33:24.000 --> 33:30.960 of Gaseo, is the Cino integration inside Gaseo transport, so instead of using Cero and Cue, 33:30.960 --> 33:41.520 you can now select to use the Cino transport in when you are using Gaseo, so we did, I think this 33:41.680 --> 33:49.520 is from the first them, from the very arrozcon, this is a comparison of how it works, the Cino 33:49.520 --> 33:57.040 CmCue integration, I think that for intra-process we expect both of them behaves mostly the same 33:57.040 --> 34:09.440 that's true and we have a problem with C, you know, we were growing inter-process, this is another 34:09.440 --> 34:16.000 point in the road map, we believe it's like we are not using Cero memory in Cino, and this is an 34:16.000 --> 34:21.680 interesting feature and important features, so this is a point in the primary road map about the 34:21.680 --> 34:30.240 implement in the Cero memory capabilities of Cino, so the Gaseo transport can use them, I press the 34:30.320 --> 34:41.760 button, more interesting things happen in physics engines, so the problem that we have with the 34:41.760 --> 34:48.080 physics engines that are valid is that they are usually a single only project, so it's not being 34:48.080 --> 34:55.200 developed by the group of people or funding, so the development is not going extremely fast, we are happy 34:55.280 --> 35:03.840 with them but not going easily, so in the Gaseo PMC there is a wood open source candidate that we 35:03.840 --> 35:11.200 can integrate, that wood open source candidate is Mujogo, we have seen that before, so it has been 35:11.200 --> 35:18.000 selected as the four physics engines to be supported by GC physics, is in the road map, 35:18.800 --> 35:28.480 so then the road map the next question is, is going to be done, oh I think I have a video here, 35:29.520 --> 35:36.960 I can play that thing, it's going to be probably the most interesting video in your lives, 35:38.000 --> 35:43.840 so this is the wood upcoat, we have coat and simple shapes and Mujogo, 35:44.800 --> 35:51.840 and it's been integrated, we have simple shapes, we have meshes, this is a problem with the 35:51.840 --> 35:57.920 burn, but there is a no-pumped wood that was done in the Gaseo that intrinsic, the members of the 35:57.920 --> 36:12.560 because it was indeed an intrinsic, so it seems to be happening, I come, this one is my favorite, 36:13.280 --> 36:18.960 this one is funny, so this is not mine, this is from my colleague Arjo, 36:21.520 --> 36:28.720 this was, I mean in the Gaseo court, we are a fan people, this was presented in the Roscoe 36:28.720 --> 36:42.000 this year, so the rendering inside Gaseo happens slow, so we are aware of that, so before we go into 36:42.080 --> 36:47.840 the details, a bit of theory, is there any rendering in the room that can jump in and explain what 36:47.840 --> 36:53.920 this is, I'm going to try to do it, seems like when you are creating a rendering, there are 36:53.920 --> 36:59.440 two main approaches, probably three, but let's focus on two of them, but this rustillization, 36:59.440 --> 37:06.960 so if I understood correctly from a rustillization, we go with the 3D world and go with all the 37:07.040 --> 37:12.160 entities that we have in a simulation and translate that using mathematical operations 37:12.160 --> 37:17.600 into the 2D render of your screen, maybe, or a camera, or the render that you want to create, 37:17.600 --> 37:24.240 so this is, this is, this is, this is the true computational power, 37:25.920 --> 37:31.520 and it's highly dependent on how big is your work, so you need to go with all the entities and see 37:31.520 --> 37:38.400 if they're projecting to the rendering, and the second approach, this is not so modern, but it's 37:38.400 --> 37:44.320 trending, I would say it's happening in the new GPUs, it's the right racing, and right racing 37:44.320 --> 37:52.880 each state of going from the world, we go from the render and cast a ray, and they're like 37:53.600 --> 37:59.600 data structures that are going to tell us if they object is being predicted in the render or not, 37:59.680 --> 38:06.400 and after that apply in the light sources, so if you see the difference, like the realistic 38:07.120 --> 38:15.040 impact is more interesting in the right racing, how can we use the right racing? 38:16.960 --> 38:23.840 We already spoke about the WGPU, WGPU has experimental support for right racing, 38:23.920 --> 38:32.960 and the good thing for me, it's different from all other APIs that we have in mind, 38:32.960 --> 38:38.480 I mean we have bull can elenos, but you want to use bull can, you probably need to be a complete 38:38.480 --> 38:44.880 PhD in graphic operations, render theory, write thousands of lines to make it work, 38:46.240 --> 38:51.840 with WGPU, we have the experimental support that can run in all the platforms. 38:54.400 --> 39:04.480 So, this is a project that has an argyo word doing during the last summer of code, 39:04.480 --> 39:12.560 it's a real interesting project of implementing ray tracing for a light or sensor in Casivo 39:12.560 --> 39:22.160 on a camera sensor, so they were putting together the rust part of it together with the 39:22.160 --> 39:29.520 code of Casivo, you can just compile it with Colcommer Simic and works on compile, and we are 39:29.520 --> 39:36.080 gaining this different approach of how the these sensors work. 39:38.080 --> 39:45.200 This in the left is Casivo running this new ray tracing sensors, it's a couple of 39:45.200 --> 39:53.360 car models, car light models, in the right, this is that we run application, probably familiar 39:53.360 --> 40:01.120 but to some of you guys, this is a rust visualizer of data, so how it's working it's in the 40:01.120 --> 40:06.160 plugins they are converting, the Casivo format for the entities, they are they are cycling 40:06.160 --> 40:12.640 the entities in Casivo, translating them into the format, it is a triangle format, expecting by 40:12.640 --> 40:22.240 WGPU and just make it work through the the right tracing in WGPU with a very few lines of code. 40:26.560 --> 40:33.280 This is quite impressive, we explained it before that you are using a like rust 40:33.280 --> 40:37.840 authorization, that rust is an ancient technique needs to go over all the entities in a 40:37.840 --> 40:44.800 assimilate that code, so the cost for the sensors when they are working it's in prison, 40:46.400 --> 40:51.120 when we are more vertices in the scene, this is the size of a scene in in this axis, 40:51.840 --> 40:59.360 and if you see in the fix line we start the right tracing sensors, they are both 40:59.440 --> 41:06.960 seems like a stable with a scene size, so this is a really interesting approach, 41:10.160 --> 41:16.000 another interesting change is not only in the Casivo court team, but this in the open store 41:16.000 --> 41:26.720 robotics alliance, we had last year an investment on to 150K dollars, 150K dollars is a lot of 41:26.800 --> 41:40.720 money or not a lot of money, so Juno is one step, this is a classic, this is one of the most famous magic 41:40.720 --> 41:49.760 they are either in cards in the history, it was sold by that price in 2020, I mean there has been 41:50.640 --> 41:57.280 probably expensive, a more expensive approach of selling cards, but this one is not that 41:57.280 --> 42:04.880 money, two things with that money that the open store robotics alliance decide to do with it, 42:05.440 --> 42:13.040 the first one is to work on how we are going to integrate this whole new 42:13.360 --> 42:20.640 ecosystem into the build fund, it's mainly designed for the rose build fund, but not only, 42:20.640 --> 42:26.640 I mean I keep in my eyes in this because in Casivo we are going to need it, so we are looking 42:26.640 --> 42:32.640 the way that we can best way that we can do together with the rust community, the best way 42:32.640 --> 42:39.440 of integrating that into our build fund, so we can distribute it's binary form in a right way, 42:39.440 --> 42:45.760 in a way that we can update the dependencies and everything is coming, so this is going, 42:45.760 --> 42:54.480 this company contracted for doing this and work is being done, not yet done, but it's going, 42:55.360 --> 43:00.240 we have another big big project of improving all the documentation, this is going to 43:00.240 --> 43:04.960 affect rose, Casivo, all the projects that we have in the osurah, but it's really interesting, 43:04.960 --> 43:08.880 we already have some millions with the company that is doing this, like how the people approach 43:08.880 --> 43:13.200 to the documentation, but profile, so people approach the documentation, how it should be organized, 43:14.160 --> 43:22.800 which I think is a common topic here, in packaging and building, I think it's not as surprises, 43:22.800 --> 43:28.400 if I tell you that we have conda forge packages, being built for all the stable distributions, 43:28.400 --> 43:34.320 every time there is an update, we have a conda forge package update here, this is already working 43:34.800 --> 43:44.560 thanks to the friends of Robostack and Sylvia, that is this, we are also using Pixie in the Casivo 43:44.560 --> 43:50.560 Quoting, so Pixie is our standard tool when we go to Windows, and it's what we recommend 43:50.560 --> 43:59.120 to the people that is installing, going back to the roadmap, a bit more of Pixie 43:59.760 --> 44:08.800 is planned, so we are planning on replacing Brue with Pixie, initially only in our internal 44:08.800 --> 44:13.920 CI, let's see what's happening, but the effort of maintaining Brue has been huge for the 44:13.920 --> 44:20.720 recording, so it could happen that we change, that's what we're going to do. More toys are 44:21.680 --> 44:30.640 we have some basel files inside the Casivo libraries, it's a warwin push by the intrinsic 44:30.640 --> 44:38.560 folks, we already have in the latest version of Casivo that work changes, that was a basel mode migration, 44:38.560 --> 44:44.720 and we are starting to push packages into the basel central register, so if anyone is using basel, 44:44.800 --> 44:52.320 not everything is working, but a good bunch of Casivo can be built, in the PMC who have 44:52.320 --> 45:01.120 about this next week, about adopting that basel, does it work in your CI, this is an interesting 45:01.120 --> 45:06.240 topic for many people, how to use that simulation, we are finishing, we had the headless rendering 45:06.240 --> 45:10.160 supporting the civil when you want to create that CI, you are probably interested in not to run 45:11.120 --> 45:16.480 the simulation, to run the simulation without an screen, that is, can be done in Casivo sense 45:16.480 --> 45:23.920 long, that's in fortress, we have an interesting repository, this is a GitHub action, it can 45:23.920 --> 45:33.600 install Casivo elinous macro windows, any of the versions for you, this is a project that I copy from 45:33.600 --> 45:39.440 my co-worker saying in rows, so we are generating something that is missing in Casivo, it's 45:39.440 --> 45:46.000 the Docker images, we are building, we are working on having them officially, but I have a repository 45:46.880 --> 45:57.600 grave, so finish with it, this is a server only installation here, this is the last slide I'm going 45:57.600 --> 46:05.280 to put here, this is an example of integrating all the AI into Casivo that way, that's one, 46:06.240 --> 46:12.480 finish, yes, that's one, the people is approaching me, yes, finishing the second, 46:12.480 --> 46:18.720 approaching me, so Casivo we focus on something specifically, like low fidelity simulations, 46:18.720 --> 46:25.120 local, and my personal take is, it's an open surprise, it's been there for a while, it's been 46:25.120 --> 46:31.040 pushed by many different interests from the people, so it's not a product, we don't have a product 46:31.120 --> 46:36.960 manager, so we don't know what the future of the plug, the future of the software is going to be, 46:37.840 --> 46:42.560 that's it, thanks so much for listening to this video,