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