WEBVTT 00:00.000 --> 00:13.000 So Julian is going to talk to us about Sino, Sino, it's been presented as a nice improvement 00:13.000 --> 00:16.000 to a pretty good rough-stool ecosystem. 00:16.000 --> 00:20.000 He comes from a set of scale, but he has experienced working in many things, including 00:20.000 --> 00:21.000 DDS. 00:21.000 --> 00:25.000 So I think it's a great person to teach us how Sino is going to make everything better. 00:25.000 --> 00:26.000 Thank you very much. 00:26.000 --> 00:31.000 Thank you. 00:31.000 --> 00:32.000 Hello, everyone. 00:32.000 --> 00:36.000 I'm really happy to be here for my first thoughts of them, and moreover, in this first 00:36.000 --> 00:38.000 forum for robotic consumptions. 00:38.000 --> 00:40.000 So thank you for the organizer. 00:40.000 --> 00:46.000 And so I'm in Sino Project today. 00:46.000 --> 00:48.000 I will introduce you Sino. 00:48.000 --> 00:51.000 It's characteristic with regard to the protocol. 00:51.000 --> 00:54.000 And the potential it can give to your robotic. 00:54.000 --> 01:01.000 But I first let you act quick overview of what kind of architecture exists in 01:01.000 --> 01:02.000 an robotic software. 01:02.000 --> 01:05.000 I mean for the software development part. 01:05.000 --> 01:10.000 Of course, you know all about layered architecture, right, with different 01:10.000 --> 01:17.000 layer of software components, going from the very basic one, close to the hardware, 01:17.000 --> 01:22.000 capturing all the sensor information, activating the motor controllers, 01:22.000 --> 01:25.000 controlling the robot layer already. 01:25.000 --> 01:31.000 And then you have other layer like the skill layer or navigation layer or decision layer 01:31.000 --> 01:34.000 and soon maybe probably some AI layers, right? 01:34.000 --> 01:39.000 So you can decompose all your architecture of your robots in those different 01:39.000 --> 01:42.000 layer, which are all intercommunicating with each other. 01:42.000 --> 01:44.000 You can see here there are some ARPC code. 01:44.000 --> 01:48.000 There are also barbys and messaging passing between each. 01:48.000 --> 01:54.000 So that's the very original architecture that was existing. 01:54.000 --> 02:00.000 Then for some particular part of the robots, you have data pipelines, right? 02:00.000 --> 02:04.000 You need to have some pipelines of different components, 02:04.000 --> 02:08.000 that are getting information from the very basic sensor, 02:08.000 --> 02:13.000 radar, cameras, and then are iterating over the incoming data, 02:13.000 --> 02:16.000 transforming those data, extracting some information, 02:16.000 --> 02:21.000 refining, to come eventually, to add decision on what the robot shall do. 02:21.000 --> 02:29.000 Again, that's a flow of data depending on different software components. 02:29.000 --> 02:32.000 Data flow is another evolution, right? 02:32.000 --> 02:37.000 You can feel it's similar to data pipeline, but actually it's a very more 02:37.000 --> 02:40.000 high-level composition of different data pipeline. 02:40.000 --> 02:44.000 And in some data flow, for instance, you can have some loops, which are supported. 02:44.000 --> 02:49.000 So here, for instance, it's a data flow, made with a demo flow on a stand, 02:49.000 --> 02:54.000 which is something coming from ARDOS ecosystem, 02:54.000 --> 03:00.000 which is about driving or to almost driving of vehicle. 03:00.000 --> 03:04.000 So there is a full set of pipeline, which are combining with each other 03:04.000 --> 03:09.000 to come to decision to drive the automotive. 03:09.000 --> 03:15.000 So what are the most common point in all those architecture? 03:15.000 --> 03:21.000 Well, it's obvious, it's modular architecture with multiple software components. 03:21.000 --> 03:24.000 And that makes a lot of sense, right? 03:24.000 --> 03:27.000 Because there are a lot of benefits in such architecture. 03:27.000 --> 03:30.000 You first one is, of course, code reliability. 03:30.000 --> 03:33.000 You can take one component and use it in another robot, 03:33.000 --> 03:38.000 you can switch, compose them, and then this leads to faster developments. 03:38.000 --> 03:43.000 There is your testing, because you can test all your components as a black box. 03:43.000 --> 03:47.000 You simulate some inputs, you test your outputs, and then it's all over 03:47.000 --> 03:50.000 and improves the quality of your software. 03:50.000 --> 03:53.000 It's easier to maintain, it's easier to make it evolve. 03:53.000 --> 03:57.000 You can just replace a component with a new version of your components. 03:57.000 --> 04:02.000 Of course, you need to comply with all the expectations with regard to input messages. 04:02.000 --> 04:10.000 But still, you can make evolve only partial parts of your full software stack. 04:10.000 --> 04:13.000 And scalability is another important point, right? 04:13.000 --> 04:17.000 When you add a new sunset to your robot, well, you just add a new component. 04:17.000 --> 04:20.000 You plug it to the rest of your architecture. 04:20.000 --> 04:26.000 You add some more incoming data, and you can make this evolve your robot. 04:26.000 --> 04:30.000 The dynamic cities are also a good one, because you sometimes, for instance, 04:30.000 --> 04:34.000 if you have a pipeline for visualization for a night vision, 04:34.000 --> 04:38.000 well, you don't need to start this pipeline during the daylight, right? 04:38.000 --> 04:40.000 So you just turn off some components. 04:40.000 --> 04:45.000 And when the night come, you turn on this new night vision pipeline. 04:45.000 --> 04:48.000 And also, is this input for tolerance? 04:48.000 --> 04:53.000 Because if you have all your components deployed in a same single process, 04:54.000 --> 04:57.000 if one component crush the full process crushes, 04:57.000 --> 05:01.000 why if it's separating different processes, which are intercommunicating, 05:01.000 --> 05:05.000 you can have one crush on still all the rest of the system can 05:05.000 --> 05:11.000 continue to work in a degraded mode probably, but still you don't use everything. 05:11.000 --> 05:15.000 So, when you have a distributed system with various components, 05:15.000 --> 05:21.000 which communication patterns are you using for, in exchange information between all your components. 05:21.000 --> 05:25.000 Nowadays, the most obvious one is per cent, right? 05:25.000 --> 05:28.000 It has proven to bring a lot of benefits. 05:28.000 --> 05:31.000 The first one being independence between all the components, 05:31.000 --> 05:35.000 I could be sure, doesn't need to know that there is a subscriber, 05:35.000 --> 05:36.000 it's just delicious. 05:36.000 --> 05:39.000 There is no synchronous communication between the two. 05:39.000 --> 05:44.000 And it can also provide some nice data, like one to one or one to many. 05:44.000 --> 05:48.000 One to be sure to one subscriber, but also one to be sure to save all subscriber, 05:48.000 --> 05:52.000 and each subscriber decide what to do with the incoming data. 05:52.000 --> 05:53.000 It's a synchronous. 05:53.000 --> 05:56.000 Still, you need to come on the robots. 05:56.000 --> 05:59.000 You need to get information from your robots. 05:59.000 --> 06:01.000 You need to supervisor status. 06:01.000 --> 06:05.000 So, you also would like to have some service code. 06:05.000 --> 06:09.000 And the service code is usually, you can collect LPC, remote processor code. 06:09.000 --> 06:13.000 It's a one to one pattern, you call a service, you get a reply. 06:13.000 --> 06:16.000 It's synchronous, and you get only one reply. 06:16.000 --> 06:21.000 But actually, it wouldn't be nice if you can stop all your robots all together, 06:21.000 --> 06:25.000 or instruct all to your robots to go home all together. 06:25.000 --> 06:29.000 So, what about having a service code, which is one to many? 06:29.000 --> 06:30.000 Right? 06:30.000 --> 06:32.000 I have a filter for both. 06:32.000 --> 06:36.000 Just one request to make them all to start. 06:36.000 --> 06:39.000 Of course, you will get several replies. 06:40.000 --> 06:45.000 And so, last one, which in rows two is named actions, or we can call also, 06:45.000 --> 06:49.000 this mission is a kind of long-standing service code. 06:49.000 --> 06:50.000 Right? 06:50.000 --> 06:52.000 You have, it's usually you are asking, can you? 06:52.000 --> 06:58.000 You inscript a mission to start, or I go to be sent to, for the mission to start. 06:58.000 --> 07:02.000 You get one reply, but you can also on the fly during the mission. 07:02.000 --> 07:05.000 A lot of feedbacks to know the status of your action. 07:05.000 --> 07:08.000 And at the end, you get a final result. 07:08.000 --> 07:13.000 So, that's really useful pattern also in robotic, when you can send mission for our 07:13.000 --> 07:16.000 robot to make a long move. 07:16.000 --> 07:18.000 Okay. 07:18.000 --> 07:22.000 A lot of communication patterns, but what about deployments? 07:22.000 --> 07:26.000 What about the communication transport for your deployments? 07:26.000 --> 07:27.000 Right? 07:27.000 --> 07:32.000 Most simple one, you can localize everything in the same process. 07:32.000 --> 07:36.000 I'm actually that's the most profound one, because you can then benefit from direct 07:36.000 --> 07:39.000 function code from one component to another. 07:39.000 --> 07:45.000 Or you can just use message queue, actor patterns, and so on, inside the same process, 07:45.000 --> 07:47.000 and that's very efficient. 07:47.000 --> 07:52.000 If you do this properly, you can also do this with zero copy, actually. 07:52.000 --> 07:53.000 So, that's the most efficient. 07:53.000 --> 07:59.000 The problem is that if one of your component crashes, the full process crash with it. 07:59.000 --> 08:04.000 So, another possibility of deployment in the same host is to be post-collective 08:04.000 --> 08:06.000 realization with several processes. 08:06.000 --> 08:11.000 So, one process per component, or maybe some time a few component collocalizing the 08:11.000 --> 08:15.000 process, but still separate from other critical component. 08:15.000 --> 08:19.000 How do you communicate in a single host? 08:19.000 --> 08:24.000 You can use shared memory, unique spikes, or just a look back in their face. 08:24.000 --> 08:27.000 You use TCP, UDP, whatever you want to wear a look back. 08:27.000 --> 08:33.000 In bigger robots, usually there are multiple bolts, like in the curve, for instance, you 08:33.000 --> 08:36.000 have one issue or some time more issues. 08:36.000 --> 08:42.000 And a lot of microcontrollers to bring all the sensor information. 08:42.000 --> 08:43.000 How do they communicate? 08:43.000 --> 08:49.000 Well, it could be ethernet, it could be serial, it could be canvas for vehicles, a lot of different 08:49.000 --> 08:50.000 possibilities. 08:50.000 --> 08:54.000 And, finally, multi host, you have several hosts, which are communicating, 08:54.000 --> 08:56.000 either via ethernet, right? 08:56.000 --> 09:00.000 When you have an onboard, in a factory, usually it's not over Wi-Fi. 09:00.000 --> 09:05.000 You have ethernet between the controller and the robotic arm. 09:05.000 --> 09:11.000 Or you can use Wi-Fi, 5G, 4G, even Bluetooth for some robots. 09:11.000 --> 09:13.000 Okay. 09:13.000 --> 09:17.000 All of these constraints, which we do have to use? 09:17.000 --> 09:19.000 There are a lot of possibilities, right? 09:19.000 --> 09:20.000 Are you on IP? 09:20.000 --> 09:21.000 Why? 09:21.000 --> 09:25.000 You can use TCP, UDP, or more high-level, middleware, 09:25.000 --> 09:28.000 like the RMQ, MQT, DDS. 09:28.000 --> 09:32.000 But if you need a request reply, GRTC might be a better choice. 09:32.000 --> 09:35.000 If you still want to be in the same process, you need some shared memory. 09:35.000 --> 09:43.000 So, again, it would be another middleware, or your own shared memory solution. 09:43.000 --> 09:48.000 So, what we would like to achieve with actually Zeno, 09:48.000 --> 09:53.000 that I'm introducing here, is to have a single protocol for all those patterns, 09:53.000 --> 09:57.000 all those deployments, and all those use cases. 09:57.000 --> 10:00.000 So, first of all, actually Zeno is a protocol. 10:00.000 --> 10:04.000 It's a middleware also, because we provide all the full API to, 10:04.000 --> 10:06.000 for you to implement your application. 10:06.000 --> 10:10.000 But it started really as a protocol. 10:10.000 --> 10:13.000 It's an open source project. 10:13.000 --> 10:16.000 It's managed by the eclipse foundation. 10:16.000 --> 10:20.000 So, Zeta's scale is the original contributor, and still the main contributor. 10:20.000 --> 10:24.000 But it's a transparent and merit-procati governance. 10:24.000 --> 10:28.000 So, anyone can come and do some contribution, 10:28.000 --> 10:32.000 and eventually be elected as a cometer to eclipse Zeno. 10:32.000 --> 10:36.000 And the eclipse nation is a grant that also IP licensing 10:36.000 --> 10:42.000 are well managed from Zeno, where there are provenance. 10:42.000 --> 10:46.000 So, eclipse Zeno is a purpose-up query protocol that unifies that 10:46.000 --> 10:49.000 in motion that are twice uncapitation from embedded 10:49.000 --> 10:52.000 comical controller app to the data center. 10:52.000 --> 10:56.000 Its location transparency and has a high performances 10:56.000 --> 10:58.000 for purposes and distributed queries. 10:58.000 --> 11:01.000 And it supports shared memories. 11:01.000 --> 11:04.000 That's kind of a complex definition. 11:04.000 --> 11:06.000 So, what does it mean? 11:06.000 --> 11:10.000 First, they know provide two different parameters, 11:11.000 --> 11:13.000 and query a play. 11:13.000 --> 11:16.000 And that's essential, as we saw for all your, 11:16.000 --> 11:19.000 this with the application. 11:19.000 --> 11:22.000 So, in Zeno, all data is named with a key, 11:22.000 --> 11:25.000 which is represented with some slashes, 11:25.000 --> 11:26.000 and a value. 11:26.000 --> 11:28.000 The value can be any buffer. 11:28.000 --> 11:30.000 You choose your encoding. 11:30.000 --> 11:32.000 Zeno doesn't require it to know the encoding, 11:32.000 --> 11:35.000 it's just transports byte buffers. 11:35.000 --> 11:37.000 It supports query replies in a smart way, 11:37.000 --> 11:40.000 because, actually, you can query civil query 11:40.000 --> 11:41.000 about at the same time. 11:41.000 --> 11:44.000 You will get all the replies. 11:44.000 --> 11:47.000 And it's not built over a perf sub, 11:47.000 --> 11:51.000 which may make this solution far more efficient 11:51.000 --> 11:54.000 that are the query reply best on perf sub. 11:54.000 --> 11:56.000 I can explain why later. 11:59.000 --> 12:02.000 And Zeno supports some matching on key expression. 12:02.000 --> 12:05.000 Meaning, for instance, that you can have some subscriber 12:06.000 --> 12:09.000 using specific star characters for here. 12:09.000 --> 12:11.000 That's subscribe to several key expression. 12:11.000 --> 12:14.000 And the same for query reply, right? 12:14.000 --> 12:17.000 Using star character, you can address several query 12:17.000 --> 12:19.000 and query will go to several query available 12:19.000 --> 12:21.000 and you will get all the reply. 12:21.000 --> 12:26.000 So, you can build very complex pattern with such matching query expression. 12:26.000 --> 12:29.000 On the protocol stack, Zeno, 12:29.000 --> 12:31.000 as only one requirement is to have a transport 12:31.000 --> 12:34.000 that is able to send one buffer from A to B, 12:34.000 --> 12:38.000 and Zeno will take care of all the characteristics 12:38.000 --> 12:39.000 of the transport. 12:39.000 --> 12:40.000 We eat all of that. 12:40.000 --> 12:43.000 So, it makes that Zeno out of the box support 12:43.000 --> 12:46.000 TCP, UDP, quick, but also serial. 12:46.000 --> 12:49.000 We may experiment on Bluetooth on a bunch of colleagues. 12:49.000 --> 12:51.000 We have unique socket transport, 12:51.000 --> 12:53.000 and we have shared memory, of course. 12:55.000 --> 12:58.000 One of the characteristics of Zeno, for instance, 12:58.000 --> 13:00.000 it supports automatic fragmentation. 13:00.000 --> 13:03.000 You can have a one gigabyte payload to be sent 13:03.000 --> 13:04.000 to be published. 13:04.000 --> 13:06.000 Zeno will automatically fragment it, 13:06.000 --> 13:08.000 adapt to the network M to you, 13:08.000 --> 13:11.000 depending on which transport you use. 13:11.000 --> 13:12.000 You will use M. 13:12.000 --> 13:15.000 It will send fragment per fragment, all your data. 13:15.000 --> 13:16.000 And on the search driver side, 13:16.000 --> 13:20.000 it will reconstruct the full data from those fragments. 13:20.000 --> 13:24.000 But Zeno can also do automatic batching. 13:24.000 --> 13:26.000 When you have small messages, 13:26.000 --> 13:28.000 which are smaller than the M to you, 13:28.000 --> 13:31.000 it's actually far more efficient to batch them 13:31.000 --> 13:34.000 in a single frame to improve the throughput. 13:34.000 --> 13:36.000 Reduce the network overhead, 13:36.000 --> 13:41.000 but also reduce the system call and CPU utilization. 13:43.000 --> 13:45.000 And, because, of course, 13:45.000 --> 13:47.000 batching will add some latency. 13:47.000 --> 13:51.000 Optionally, you can still use a next-place publication 13:51.000 --> 13:54.000 that's just an option when you call a publication. 13:54.000 --> 13:56.000 To bypass all the batching, 13:56.000 --> 14:00.000 and then the message you go directly to your transport. 14:01.000 --> 14:05.000 Zeno can also do priority for nature scheduling. 14:05.000 --> 14:09.000 So, we provide seven different priority levels. 14:09.000 --> 14:12.000 You can use how you want. 14:12.000 --> 14:16.000 And, so Zeno doesn't do any preemption, 14:16.000 --> 14:20.000 meaning that if one fragment with low priority is about to be sent, 14:20.000 --> 14:23.000 it sends, but still, in the waiting queue, 14:23.000 --> 14:26.000 you can have reorganization of the messages, 14:26.000 --> 14:28.000 depending on the priority. 14:28.000 --> 14:30.000 So, here, for instance, a big message, 14:30.000 --> 14:32.000 where this one has to be sent anyway, 14:32.000 --> 14:34.000 so it's about to be sent, we send it. 14:34.000 --> 14:37.000 But, behind all the different fragment, 14:37.000 --> 14:41.000 are reorganized, depending on the priority. 14:41.000 --> 14:44.000 So, this avoids head of light blocking. 14:44.000 --> 14:46.000 But, you will say, okay, still, 14:46.000 --> 14:49.000 it goes to a network where there could be still congestion, 14:49.000 --> 14:51.000 right? It goes to a specific buffer, 14:51.000 --> 14:54.000 where there can be head of light blocking also. 14:54.000 --> 14:56.000 So, Zeno's support also multidix. 14:56.000 --> 14:59.000 And, defined different specific connection, 14:59.000 --> 15:01.000 with different range of priorities. 15:01.000 --> 15:04.000 And, then, you will have multiprolink, 15:04.000 --> 15:07.000 which have, each of one may have head of light blocking. 15:07.000 --> 15:10.000 But, at least, if you dedicated this one for highest priority, 15:10.000 --> 15:14.000 for instance, there will be no head of light blocking on this connection. 15:14.000 --> 15:24.000 So, one of the key characteristic of Zeno is the topology that it supports. 15:24.000 --> 15:27.000 Here, all the peers are the no application 15:27.000 --> 15:29.000 that you can interconnect with each other. 15:29.000 --> 15:32.000 Zeno supports peer-to-peer communication in a click model, 15:32.000 --> 15:35.000 all the peer-colon communication with each other. 15:35.000 --> 15:37.000 But, also, in mesh topology, 15:37.000 --> 15:40.000 when one peer can hold all the data between two hotels 15:40.000 --> 15:43.000 that cannot directly connect to each other. 15:43.000 --> 15:48.000 In Zeno, you can also deploy your application as a client. 15:48.000 --> 15:52.000 What is a client is just a change of the configuration for your application. 15:52.000 --> 15:56.000 A client only has one single connection. 15:56.000 --> 15:58.000 And, hence, it doesn't do routing. 15:58.000 --> 16:00.000 So, hence, it doesn't embed all the code, 16:00.000 --> 16:03.000 all the memory used for routing the routing table, 16:03.000 --> 16:04.000 also, and so on. 16:04.000 --> 16:07.000 So, it's more lightweight version for your application. 16:07.000 --> 16:09.000 Again, it's just a configuration. 16:09.000 --> 16:11.000 You can change dynamically. 16:11.000 --> 16:15.000 But, Zeno also provides an interesting thing, 16:15.000 --> 16:17.000 which is a router. 16:17.000 --> 16:20.000 So, it's a software router, just a process. 16:20.000 --> 16:22.000 You can deploy it everywhere. 16:22.000 --> 16:26.000 It runs on Linux, macOS, Windows, on a Raspberry Pi, 16:26.000 --> 16:30.000 even on Raspberry Pi 0, we deploy some hotels. 16:30.000 --> 16:34.000 And, the router can intermediate all the communication 16:34.000 --> 16:38.000 between the clients, between different hotels. 16:38.000 --> 16:40.000 So, you can have broken communication, 16:40.000 --> 16:42.000 and router communication. 16:42.000 --> 16:45.000 You can interconnect a lot of hotels in different ways. 16:45.000 --> 16:49.000 Some hotels on your robots, some hotels in a laptop nearby. 16:49.000 --> 16:52.000 Some other one in a cloud, for instance, different clouds, 16:52.000 --> 16:54.000 for different questions. 16:54.000 --> 16:57.000 Interconnect all together, and you have a full system. 16:57.000 --> 16:59.000 And, all those connections, 16:59.000 --> 17:01.000 between routers, PS, and so on. 17:01.000 --> 17:03.000 You can choose, you can use TCP, TLS. 17:03.000 --> 17:07.000 You can have shared memory in a further peer-to-peer communication, 17:07.000 --> 17:10.000 but still have TCP, which are outside the robot. 17:14.000 --> 17:16.000 Zeno is mainly developed in rest. 17:16.000 --> 17:18.000 All the curves, Zeno is developed in rest. 17:18.000 --> 17:24.000 But, we are binding for C, C++, Python, Kotlin, Java, JavaScript, 17:24.000 --> 17:27.000 TypeScript, which is just what is the version. 17:27.000 --> 17:30.000 And, for embedded platforms, 17:30.000 --> 17:35.000 we have a Cpursi implementation, which is MISFASC compliant. 17:35.000 --> 17:40.000 And, we are also working for certification of this stack. 17:40.000 --> 17:46.000 It's named Zeno Pico, and it's also available on GitHub. 17:46.000 --> 17:50.000 You can have some tests with it. 17:50.000 --> 17:55.000 Zeno is already largely used for a botic, 17:55.000 --> 17:58.000 but not only for a botic, but in a botic, at least. 17:58.000 --> 18:02.000 Zeno has been recently selected as an alternative middleware 18:02.000 --> 18:04.000 to DDS in ROS 2. 18:04.000 --> 18:07.000 So, it's already available for ROS JZ. 18:07.000 --> 18:11.000 And, there is a roadmap to have it supported in tier 1 18:12.000 --> 18:16.000 for a kilted version, which is coming in May. 18:16.000 --> 18:18.000 So, we are still working on it. 18:18.000 --> 18:20.000 The first feedback are really good. 18:20.000 --> 18:24.000 We are currently using the middleware, 18:24.000 --> 18:27.000 and doing some tuning, and doing more tests, 18:27.000 --> 18:30.000 to be sure to be ready for tier 1 in May. 18:30.000 --> 18:34.000 FASC use is another framework, which actually is 18:34.000 --> 18:37.000 introduced to use Zeno as the core middleware. 18:37.000 --> 18:40.000 But, it's developed all of our robotic framework in C++. 18:40.000 --> 18:44.000 It's made by two companies from Germany and Switzerland. 18:44.000 --> 18:47.000 Dora, there was a talk yesterday about Dora. 18:47.000 --> 18:50.000 It's a data flow oriented robotic architecture, 18:50.000 --> 18:52.000 developed in ROS. 18:52.000 --> 18:55.000 Mainly using their own shared memory, 18:55.000 --> 18:57.000 but for external communication, 18:57.000 --> 19:00.000 they are using Zeno for PAP sub for external communication. 19:00.000 --> 19:03.000 Copper is something quite new. 19:03.000 --> 19:07.000 It's also a ROS native software engine for robotics. 19:07.000 --> 19:09.000 They don't use Zeno yet, but at least they are 19:09.000 --> 19:12.000 writing on the roadmap that they would like to use Zeno 19:12.000 --> 19:16.000 for swarm of robotics for external communication. 19:16.000 --> 19:20.000 And the last one, it's a project we write also at data scan, 19:20.000 --> 19:22.000 which is also an eclipse project. 19:22.000 --> 19:24.000 It's Zeno flow. 19:24.000 --> 19:26.000 So, that's a run, a rest native, 19:26.000 --> 19:29.000 declarative data flow programming framework. 19:29.000 --> 19:33.000 So, I have no time left to explain more on this, 19:33.000 --> 19:34.000 but you can watch, 19:34.000 --> 19:40.000 I look directly on GitHub and also on the data scale YouTube channel. 19:40.000 --> 19:43.000 There are a lot of presentations about Zeno flow, 19:43.000 --> 19:49.000 which is really nice to do distributed data flow programming. 19:49.000 --> 19:54.000 Okay, I need to mention that Zeno benefited 19:54.000 --> 19:58.000 from funding from a different European project, 19:58.000 --> 20:00.000 so funding from the European Union. 20:00.000 --> 20:04.000 And actually, what's good to notice in this is that 20:04.000 --> 20:07.000 almost north of those projects are in robotics. 20:07.000 --> 20:10.000 They are all mainly about edge computing, 20:10.000 --> 20:12.000 eco mobility, 20:12.000 --> 20:15.000 edge-y cloud and IoT, 20:15.000 --> 20:18.000 because actually Zeno can not only be using robotics 20:18.000 --> 20:21.000 and can be used in any distributed system. 20:21.000 --> 20:24.000 And for this, we also provide plugins 20:24.000 --> 20:27.000 to integrate with existing IoT system, 20:27.000 --> 20:29.000 for instance, we are plugin for MPTT, 20:29.000 --> 20:31.000 to interpret with MPTT, 20:31.000 --> 20:35.000 with DDS, with rest API and so on. 20:37.000 --> 20:39.000 Thank you for your attention. 20:39.000 --> 20:44.000 I think we have still some time for some questions. 20:45.000 --> 20:47.000 Thank you. 20:56.000 --> 20:58.000 So you have a router? 20:58.000 --> 20:59.000 It's really nice. 20:59.000 --> 21:04.000 How is the addressing and the namespacing done in routing tables? 21:04.000 --> 21:06.000 Third, namespacing, yes. 21:06.000 --> 21:11.000 Well, how do you address for a message going from one note to the other? 21:11.000 --> 21:13.000 It's all based on the key expression. 21:13.000 --> 21:15.000 If you have a key expression, which is 21:15.000 --> 21:20.000 bot one slash speed slash some sync, 21:20.000 --> 21:21.000 for instance, 21:21.000 --> 21:23.000 also a thing will be made on the key expression. 21:23.000 --> 21:27.000 So it means if on one link you have another router, 21:27.000 --> 21:31.000 which declared to have a subscriber on bot one slash anything, 21:31.000 --> 21:32.000 the message will go here. 21:32.000 --> 21:36.000 If on another link there is no key expression matching, 21:36.000 --> 21:39.000 it will not be going here. 21:39.000 --> 21:43.000 So it's also the one thing is based on the key expression. 21:45.000 --> 21:50.000 I was wondering if you could talk in terms of the Ross middleware, 21:50.000 --> 21:56.000 what that means for the difference in user experience compared to DDS. 21:56.000 --> 21:57.000 Okay. 21:57.000 --> 22:01.000 So with a new R&W Zeno, in terms of experience, 22:01.000 --> 22:06.000 first there is something which is a router, which comes back. 22:06.000 --> 22:11.000 So you can compare the router to the old Ross one master 22:11.000 --> 22:16.000 that was here to do all the discovery between all the peers. 22:16.000 --> 22:21.000 But actually in R&W Zeno, the Zeno router is more than just 22:21.000 --> 22:22.000 as discovery service. 22:22.000 --> 22:26.000 Also, notes that you are starting are connecting to the robots. 22:26.000 --> 22:31.000 Zeno problems are go seed protocol that allow to 22:31.000 --> 22:36.000 change the IP address and the port number between the peers. 22:36.000 --> 22:39.000 So they are establishing peer-to-peer connection. 22:39.000 --> 22:45.000 But then the router is also able to route all the data outside the robot. 22:45.000 --> 22:47.000 But only what is the required, right? 22:47.000 --> 22:51.000 If you don't subscribe to anything inside the robot, nothing get out. 22:51.000 --> 22:55.000 But you can choose to do some done sampling, 22:55.000 --> 23:00.000 to do some access control on the router to decide what is going 23:00.000 --> 23:05.000 out of your robot. 23:05.000 --> 23:11.000 Sorry, so you talked a little bit about establishing multi-links 23:11.000 --> 23:13.000 by priority. 23:13.000 --> 23:18.000 Are you able to do that by any other kind of things like your key expressions 23:18.000 --> 23:22.000 or topics, or is it just a priority? 23:22.000 --> 23:23.000 So it just priorities. 23:23.000 --> 23:24.000 Yeah. 23:24.000 --> 23:27.000 Also, the routing then it's up to the Zeno routing engine to decide 23:27.000 --> 23:30.000 which link would be used depending on the priorities. 23:30.000 --> 23:34.000 But not the link, I will not choose peer-to-peer expression. 23:40.000 --> 23:41.000 Hello. 23:41.000 --> 23:46.000 Can a client or a node can start a disconnect from the main network 23:46.000 --> 23:49.000 and discover what it's connected and the disconnection 23:49.000 --> 23:50.000 reconnection. 23:50.000 --> 23:51.000 So yes, absolutely. 23:51.000 --> 23:53.000 Say, then also port all of the reconnection on zone. 23:53.000 --> 23:56.000 If you have one process crashing or one network crashing, 23:56.000 --> 23:59.000 the Zeno will automatically periodically 23:59.000 --> 24:02.000 or try to restabish the connection. 24:02.000 --> 24:06.000 And there is a decreasing period to avoid the fluid network. 24:06.000 --> 24:09.000 There is a decreasing period in terms of number of 24:09.000 --> 24:15.000 interconnection, a frequency of interconnection. 24:15.000 --> 24:18.000 Is there a redundancy in the network? 24:18.000 --> 24:23.000 Like if you have two routes pointing to the same one and a 24:23.000 --> 24:26.000 link goes down, it starts to take the other. 24:26.000 --> 24:29.000 So it's not only redundancy, it's just real adaptation. 24:29.000 --> 24:33.000 So Zeno routing protocol is using a tree to decide 24:33.000 --> 24:38.000 also routing pass and establishing tree based on the 24:38.000 --> 24:39.000 on some algorithm. 24:39.000 --> 24:41.000 I don't forget the name of the algorithm. 24:41.000 --> 24:45.000 But it's still a routing trace and it choose always 24:45.000 --> 24:50.000 the shortest pass from up to up to the destination. 24:50.000 --> 24:54.000 And if one link goes down, also tree are automatically 24:54.000 --> 24:55.000 recomputed. 24:55.000 --> 25:00.000 So the pass is always reorganizing. 25:00.000 --> 25:04.000 And it takes just a few minutes to reorganize. 25:04.000 --> 25:08.000 Do the messages have acknowledgement for reliability? 25:08.000 --> 25:10.000 Excuse me, I didn't get it. 25:10.000 --> 25:13.000 Do the messages have acknowledgment from reliability? 25:13.000 --> 25:15.000 For reliability? 25:15.000 --> 25:18.000 Yes, so you know if your message got to the end result. 25:18.000 --> 25:22.000 So at the protocol level, yes, well, there are two 25:22.000 --> 25:23.000 flavorings. 25:23.000 --> 25:26.000 Here we rely on the transport reliability. 25:26.000 --> 25:29.000 So if it's TCP, TCP will take care of the reliability. 25:29.000 --> 25:31.000 And then we have end-to-end reliability. 25:31.000 --> 25:35.000 And for this, yes, the protocol is taking care of all 25:35.000 --> 25:39.000 the messages loss with the help of seconds number, 25:39.000 --> 25:41.000 retransmission and so on. 25:41.000 --> 25:46.000 What we will not get is a callback at the API level to say, 25:46.000 --> 25:48.000 OK, you missed a message. 25:48.000 --> 25:51.000 But you can see it for the next message. 25:51.000 --> 25:53.000 For instance, if you check the seconds number, 25:53.000 --> 25:56.000 you can see that you missed one. 25:56.000 --> 26:00.000 So this is a last question. 26:00.000 --> 26:06.000 Not if client has been disconnected and reconnect. 26:06.000 --> 26:10.000 In that case, you don't have the missing messages. 26:10.000 --> 26:12.000 It depends on the session list. 26:12.000 --> 26:15.000 You can have a very big session list. 26:15.000 --> 26:17.000 It's a one minute for instance. 26:17.000 --> 26:20.000 And in this case, it will survive to do a disconnection 26:20.000 --> 26:21.000 and reconnection. 26:21.000 --> 26:23.000 Because that's where connection, 26:23.000 --> 26:26.000 we will know that this session ID is still the same. 26:26.000 --> 26:29.000 And so the state, all the message, 26:29.000 --> 26:30.000 are still the same. 26:30.000 --> 26:36.000 And we can resume all the communication and the reliability. 26:36.000 --> 26:37.000 Thank you. 26:37.000 --> 26:38.000 Thank you. 26:38.000 --> 26:40.000 Thank you.