Thank you so much for this warm welcome.
So I'm Julia Nock, so I have to protect our data scale and commit there on Eclipse
Zeno and yes, I am here with my colleague, you are on our rune.
So you are also at data scale is the main developer of RZ, the project we will demonstrate today
and you are also of course maintainer on MWZ no for RZ.
So what's journey we had to go to RZ, right?
We started working on Zeno of course, I guess a lot of you have already a but the no right
or what we use it using it and we developed MWZ no for RZ 2 with the help of Intranciac,
we collaborate with Intranciac for this with UME.
And first let's have a dive into the lasagna plates as HSTV call it, the big lasagna of
RZ 2 with all the layers that we have, your application on top, based on several different API
in different language, C++, Python, Java, the RCL API which is a command layer for
high level concept in the in-house like actions, parameters, names and the R&W which is an
abstraction of MW and we have the MW implementation, traditionally based on DDS, starting with
fast DDS, being the default currently, cyclone DDS as another option and in the last
year we worked on Zeno, MW based on Eclipse Zeno and Eclipse Zeno is the lock in RZ, right?
So we have RZ at the very bottom on this architecture and because all the RZ stack starting
with R&W are developed in C and C++, we leverage in R&W Zeno, Zeno, C and Zeno, Cpp and
the core of R&W Zeno is the lock in C++.
How is it developed using Zeno?
It's quite simple, Zeno provides pubs sub, provides queries based on what we name key expression,
key expression is just a string with slashes as separator, so Ross need a convention to use
Zeno in the way to express all the ross concept in Zeno.
So topic service and names are mapped on key expression in this key expression you can find
the domain ID which is still used, you can find the namespace, you can find the topic name
that you can find also the topic description with the type name, string for instance, and
I type hash.
That's the way R&W Zeno is mapping all the ross concept into Zeno.
For graph declaration, when you declare a node to be discovered by all the nodes and
pubs share sub fiber to discover by all the nodes.
We are using live nestocone, so live nestocone is a concept in Zeno where you can declare
a simple R&W, this key expression is tied to the Zeno session declaring the live nestocone,
and as soon as there is a disconnection or there is a loss of communication with the
session, the client is a live nestocone, every other session can receive an notification,
the live nestocone is gone.
So we can build a full discovery and also a monitoring for totally distributed between all
the nodes using live nestocone.
Once you have this, you need to send data in it, so data are just saying like in the DS with
CDR encoding as a payload as a buffer, and we add some attachments for the second number
to attach funds and the group ID.
So why I'm explaining this, it's because already any Zeno application, any user developing
Zeno can do exactly the same to be interoperable with R&W Zeno and with us too, right?
That's actually what did a company named UBQT robotic, the leverage or Deno product for
embedded, which is named Zeno Pico, and on top of this there will pick us, because it's just
a thin wrapper on Zeno Pico, using the same pattern, and then you can have Mico controller
communicating with your Rost2 stack using R&W Zeno.
And then we wonder, okay, we have this big Lzanya plate with Rost on the bottom, and we
would like to have, of course, Rost API.
So what about a pure Rost stack, right?
If you look at what the Rost2Rost project is doing, and no, don't get me wrong on this,
I have a good respect for what they are doing, and it's really important because it's
open all the Rost ecosystem for a complete Rost stack, but the constraint is that they need
to cope with the existing Rost2 ecosystem, and to add up to also the existing middleware,
right?
Anyway, they need to have this FFI, this Interface between the RostCode, and the C-Code,
because all the core of RCL and R&W, some middleware, like FSDDS or Cyclone, are developing
C, right?
But when you go to use R&W Zeno, you will come back to Rost.
So you will cross the FFI at a second time from C to Rost, and we were wondering, is it
a PTE?
What can we gain if we have a complete Rost stack from the user application down to Zeno?
And that what we are trying to achieve with RostZ, a complete Rost stack, implementing, for
no, it's a very basic Rost2 concept, such as actions, purposes, services, discovery, but
also type the adaptation, right?
Because you want to use Rost type with your application, and to have Executory Stalkio,
which is a famous Async and quite used with Rost, still maintaining the Interoperability
with R&W Zeno.
So what does it open?
As I still mention, it opens the safety of the core, because you are fully in Rost, noise,
signal, and safeguard in here.
It opens also the possibility in the future to certify, or the stack, right, and to certify
from end to end, from the middle way up to the user application.
And it will open a lot of the Rost case, as we will discuss in the next slide.
So the main goal was to have a 100% Rost stack using Builder Patents for Avalu TVT, so the
Builder Patents are traditionally used in Rost in order to expand an API without breaking
the backward compatibility.
Cargo build, so because the stack is full of Rost, right?
We don't need to have dependency on other packages like C package, so we don't need
any more core currency resultant, so we can use just Cargo.
Rost that if Rost to application, so prep serve service action, and Rost discovery,
that's a minimum minimum we would like.
But we included, meaning zero Rost to dependency requires, meaning implying that you can deploy
Rosts on any target supported by Rost.
So any Rost platform, and of course, interoperability with RMW Zeno, but also we wanted
to open the possibility to have alternative encoding, because a lot of people want to
explore, probably using, for instance, protobuff, c-bore, or maybe JSON in some time, if
you want to communicate with a UI, JSON might be also some time, a good solution.
So let's dive into the details with UUAN.
Okay.
Let me go.
I already have one.
Okay.
I was all nervous.
Okay.
Hi, everyone.
So although I will dive in, but I will make it very easy to understand.
So let's read the three main pillars of Rostset, the left-hand side is the current one,
I'm the original CPP, let we cooperate with Intrinsics, I'm the original C++ binding,
I'm top of the Xeno C++ binding, I'm top of the Xeno Rost, Xeno is ready in Rost.
And the right one is our new POC, let we use the Rostset, which I'm the features enabled,
and then we can, I'm top of it, have a Rost version of W, okay.
And then we also support RCO and the UUU Rost 2X.
And in the middle one, it's a less text, let's use the Rost and use Rostset as a framework,
then we can build any Rostset on top of it, with the R&W-Zeno C++ binding, okay.
So this is a very overview that I'm getting, okay.
In case this audience is not familiar with how R&W works.
So R&W in Rost is some easy way to switch the underlying transportation layers.
So for example, you want to talk her and listen her, they would like to communicate
with each other and you want to customize the transportation, then you set an environment
variable to switch R&W you want to set, like here, R&W-Zeno Rost, okay.
But in Rostset, we have more, like, is somehow like RCO layer.
So you can spawn a node like this one, this is Rost English, and you can use a builder
pattern, like with some specific QOS, lift the others, use a default values,
and you can customize your service.
If you want to use a CDR, you don't need to use it because it's by default.
But if you want to use PoloBuff, we also support it.
So the Rost message build with Rostset, you can build with PoloBuff support, directly.
It's just a feature-flake, okay.
And for a more, if someone already used CDRs and they used to use Deno Pronging DDS, Rost2DDS,
or Deno Brig Rost2DDS, they used two different schema, or I call it key expression backend.
In Rostset, we also support easy switch to support it.
So if you still want to use CDRs and also leverage the power of Deno, in Rostset,
you can direct switch it by with backend.
So we have a very strong compatibility, okay.
And in Rost, we have very ergonomic ACing API.
So in Rostset, you can call D-pop publish, or D-pop ACing publish.au,
but you need an ACing runtime.
Then you can leverage the ACing I-O to not block the ACing schedule.
And also we support two patterns of subscriber co-peck.
One is a co-peck, and another one is a pouring style.
So this one is common one using the Rostset or CBP.
You build with a co-peck and feed in a function.
Another way is PoloSile, let you can hear that, okay, and until you receive some message.
And this receive could be an ACing code as a function code.
So you can say sub.acingReceive.au.
So you can have a streaming style, very easy to write a code.
Okay, and we also support action service, like server and client here,
also very easy to use.
But there's something I want to highlight this one, co-co-tock.
So why we want to use RostEnglish?
Because you can have a very detailed documentation, or this one.
In Rostset, you can build up this.
For example, you can query the definition of Z-pop builders,
and then you can know what's the type on it.
So let you can select, I want to use CDR, or PoloPath.
And you can know the fields, these Christians here,
I want to attach something, or enable share memory.
Okay, so for example here, I demonstrated,
you can customize per publishers, share memory like this.
This is not even possible in RostEnglish.cpp.
You can customize each node, each publishers,
a very fine-grained control, and send it with your customized share memory.
So every detail can be found in the cargo duct.
Okay, and for the more Python API is also supported.
So you can write easy Python code with the same patterns, build up a context,
and build out a node from the context, and build out the publishers,
and the subscriber, also a very easy polling style.
So receive and then do a processing.
CodeBag is also supported.
And this one might be very cool.
If you follow RostEnglish course,
there's a recent discussions on the SEO native's buffer,
and developers may want to leverage the CUDA tensor,
or use the CUDA IPC, but the buffer needs to be
aware of the transportation and best transportation for CUDA,
for other GPU buffers.
So in RostEnglish, we try to provide another solution
to possibly achieve it.
So the left hand side is a point-out definitions in Rost,
which contains a lot of headers, but there is a U8 array data.
This one could be very huge, right?
And in RostEnglish, while we do the code generations,
we will wrap it in general buffer.
And this general buffer respects the share memory.
So you can use this, I can customize my share memory provider.
This one is so far, it's just a passage share memory,
but it could be extend to CUDA or GPU device
aware providers.
And then they will respect the area or the device to send it.
If you find the data is in the same area or in the same group,
you will send over the share memory.
OK, so there's a little things we do.
We will translate the important data like this,
could be huge, and we wrap it as share memory buffer.
OK, and then I also want to demonstrate a cool features
that is called RostEnglish.
OK.
Is it Peri?
This no network here.
So it forced me to do a live demo.
Don't worry, I have backup plan.
Yeah, so just a quick call on this,
rights, because we are in rust and because rust are such a rich ecosystem, maybe you heard
about right at U.A., which is a very nice cool framework to build in the shell consoles.
And what you and did is really using right at U.A., to incongruption with us, to have something
to explore our system.
Thank you so much.
Okay.
So this lifetime moment demonstrated.
You'll spawn a usual general router.
And then I'll spawn the talker.
Let's repeat the published laser scan.
And then as you can see here, I can have about three versions.
Okay.
And then I can select it to major, major, major, major, and then boom.
Yeah.
And I can press record to store it in a SQLite database and also filter to find out
your interesting topics.
Yeah.
Okay.
So it is a quick demo session.
Okay.
But I still have time.
So I want to show you something more interesting.
I'm not sure you guys know what is type description and dynamic subscriber.
So in Rust, it's possible to create a dynamic subscriber, right?
But a dynamic subscriber could be once in very interesting set.
If you support the type descriptions, you can pass the message schema already.
We only have it in Rust.
There's no Rust package dependency.
You can even run in MegaOS.
And I try to pass it.
And you will print out the message here.
So as you can see here is, oops.
Okay.
I can even do something like this along.
Oops.
I can do something like I even disabled a co-com.
So remove any Rust to dependency.
But it still can print it.
Dynamic pass it.
So you can, I can provide a standard loan.
Cancel.
Let work on any platform.
Okay.
So let's go back to the slides here.
And then they will attack, that doesn't work well.
So, so about this, I want to quickly go through this one.
So this is so far our benchmark with the others.
Maybe you, you guys will be interested in this one is Rust set.
Python by the, Rust API in general.
And Rust set, that is our characters.
And as you rust, and as you see,
both of them use general.
And that is for small messages.
And as you can see, Rust set is the best.
For.
Hi for conces, small panels.
Hi for conces, middle panel.
Hi for conces, what make up, bite.
And.
The streaming test, with economic advice.
Okay.
So that is Rust set.
This one.
Okay.
Yeah.
So.
But you can.
There are something interesting here is as you can see,
our Rust set Python by the, is quite efficient.
It's just a little overhead compared to Rust by the,
for example, here almost equivalent.
But we, we, we still need to improve low serializations,
because our Rust API is still worse than our Rust by the,
a lot.
But better than Rust API.
Okay.
So if you want to use a Python by the,
I suggest you to use Rust API.
Okay.
So finally, let us have a wish list.
The goal by the, we are coding working on,
because we found sponsors.
And the next one is,
many people want us to implement
Lakuda.
Poverse or support the Python sensors.
Okay.
So we also know it's the features to make it run and embedded devices.
It's also possible.
And for scarves support a better lunch and systems in Rust,
more efficient with Rust set.
Yeah.
So let us, the end of our talk.
Any questions?
I think we have a few more slides just,
some acknowledgement slides.
Sorry. Yes.
Because.
Yes.
We have some, some sort of right.
We are participating in some European projects.
And so they know is partially funded with,
by all those European project, right?
And the last one.
Yeah.
Also the, the code here.
Oh.
The QR code to test the node to test host Z.
And the last one is the Coscop.
Yeah.
Coscop is our open source Taiwan foundations.
And we are called for.
Talks in August of this year.
We're coming to Taiwan.
If you, you guys want to visit.
Yeah.
Yeah. And so thank you.
No, please start our project.
Yeah.
And thank you Coscop to finance the.
Yeah.
To first them.
A lot of them.
Pondigion support me to come here.
Yeah.
Any questions?
Thank you.
Hi. Thank you for the talk.
It was really interesting.
I'm wondering if you're not.
If you can run with us dependencies.
How do you under.
Uh, message generation going from.
There is a question.
Actually, we almost.
Hack.
Love.
Message schema.
La Cogian.
The message generations.
And the, the rich for trade systems.
Let can easily support the go by things.
And the price and buy things.
And the, the trade like the polo path.
Any serializations.
Comedy using rust.
Framework.
So we almost have all the season.
So just basically it's.
Uh, implementation of what's ideal, but in rest with.
Uh, back ends that we can plug.
Yeah.
Question one more question.
Um, I think we finally fix.
Roth.
And the only thing I think we really should get rid of CDR.
And then just go to Fledberg or something that's serial copy.
And then I guess we can outperform Dora and the corporate even.
Yes.
Thank you.
Um.
Uh, just one more.
One.
Yeah.
Just out of curiosity.
You said you're missing.
Uh, a fox club format support.
What do you mean by that?
It's like M caps or something else.
Uh, is open for discussions.
Of course, we can make it support the the rust to fall back.
But I'd like to put a provided support for native.
First graph message.
I would I would like to do so.
Thank you.