►
From YouTube: ROS 2 Hardware Acceleration Working Group - meeting #1
Description
In this first meeting of the ROS 2 Hardware Acceleration Working Group (HAWG) we provided introductions, remarked the objectives of the group and presented the initia architecture. A few examples of acceleration were provided with ROS 2 Nodes obtaining a 3x acceleration by using some simple HLS pragmas to optimize the dataflow.
For more including source code, check https://github.com/ros-acceleration.
0:00 Introduction
12:25 Objectives, rationale and hardware reference platforms
16:40 Initial hardware acceleration architecture
22:10 Short demonstration
26:44 Community hardware platforms
29:48 Q&A
43:00 Final remarks
For a discussion about this meeting, refer to https://discourse.ros.org/t/announcing-the-hardware-acceleration-wg-meeting-1/20826.
A
Everyone
officially
to
the
hardware,
acceleration
working
group
or
hack
for
for
essentially
short,
this
working
group
aims
to
drive
the
creation,
maintenance
and
testing
of
acceleration
kernels
on
top
of
open
standards,
particularly
c
plus,
plus
and
opencl
for
optimized
ross,
two
and
gazebo
interactions
over
different
compute
substrates.
This
includes,
of
course,
fpgas,
but
also
gpus.
The
minutes
of
this
meeting
will
be
posted.
Actually
you
are
seeing
them
right
now
in
the
screen.
Let
me
get
this
link
into
the
chat
there.
A
A
So
before
we
dive
deeply
into
the
acceleration
topics
prepared
for
today
and
the
agenda
items,
I
wanted
to
go
around
the
table
and
hear
a
bit
about
everyone
willing
to
participate
and
give
you
a
chance
to
quickly
introduce
yourself
and
tell
us
what
you're
working
on
or
what
you
intend
to
do
with
acceleration,
since
I'm
at
it
I'll.
Just
kick
it
off
myself,
hi,
I'm
victor.
A
B
A
C
A
F
G
Yeah
sure,
hello,
everyone,
I'm
jaluka
kayatsa.
I
am
a
postdoctoral
research
at
kafasco
university
and
my
expertise
is
in
security,
so
I've
been
working
on
cyber
security
for
robotic
application
for
a
while
and
I'm
interested
in
other
acceleration
also
for
security
applications.
That's
why
I'm
here
cool
good
to
have
you.
A
I
I
G
Yes,
hi
everyone,
I'm
yuri,
yes,
it's
I'm
a
senior
innovation
engineer
at
fugra,
the
netherlands,
so
we
are
developing
some
remote
and
autonomous
systems
for
maritime
industry.
It's
unmanned
surface
vessels
and
remote
operated
underwater
vehicles
and
part
of
our
systems
already
build
it
around
rost2
and
I'm
really
wondering
because
we
need
to
go
more
towards
autonomy,
I'm
looking
for
all
these
kind
of
like
options
how
to
switch
computational
burden
from
the
cloud
infrastructure
towards
the
local
computation.
So
that's
why
just
interesting
to
hear
and
participate
in
the
discussion.
J
Hi
everyone-
this
is
just
vinder
working
with
xilinx
as
a
subject
matter
expert
for
graphics,
rendering
acceleration,
particularly
but
recently
I
have
been
working
in
various
interesting
projects
like
benchmarking
of
neural
network
performance
on
fpgas
and
gpus,
and
also
accelerating
computer
vision,
functions
on
fpgas,
I'm
new
to
ros
community,
but
really
excited
to
be
part
of
this
group
and
looking
forward
to
contribute
to
the
best
of
my
knowledge.
Thank
you
all
and
nice
to
connect
cool.
Thank
you
jorge.
K
L
M
A
N
Hi,
I'm
from
apex
ai,
I'm
a
software
developer
there.
We
are
a
company
that
mainly
specializes
in
automotive
solutions
based
on
our
on
some
some
kind
of
ross
version.
You
could
say,
and
we
are
providing
also
some
kind
of
we
integrate
zero
copy
middleware
in
this.
That's
where
I'm
currently
working
on,
and
we
think
about
yeah,
adding
hardware
acceleration
support
to
to
our
yeah
data
or
messaging
framework.
N
O
P
Q
Hello,
I'm
nicolai,
I'm
a
phd
student
at
the
university
of
southern
denmark
and
I
work
on
a
project
called
transfer
safety
and
we're
quite
interested
in
hardware
acceleration
both
for
rus
and
rus2,
but
also
in
general,
for
for
ai
and
stuff
because
of
the
constraints
of
onboard
compute
on
a
drone
yep
awesome.
Thank
you
so
much
pedro.
R
S
F
T
A
W
A
Okay,
you
can
see
it
now
great,
so,
as
I
was
saying,
the
objectives
essentially
in
the
community
repository
of
the
ros
acceleration
organization
reflect
the
short-term
goals
that
we've
set
ourselves,
but,
of
course,
this
is
open
to
input
and
contributions
from
third
parties.
Our
focus
essentially
will
first
be
on
tools
to
facilitate
acceleration
flows.
A
Now,
after
that,
we'll
survey
the
community
to
capture
additional
interest
of
what
people
actually
demands
in
terms
of
acceleration.
Finally,
we'll
produce
demonstrations
with
real
robots
now
to
steer
the
development
of
this
working
group.
We
have
selected
this
reference
hardware
platform.
This
is
what
I'm
using
and
what
most
of
us
are
using
on
our
daily
basis
for
development,
essentially
we're
using
the
k26
adaptive
system
on
module
through
the
korea
kv.
A
260
kit-
and
this
is
described
in
the
repo
having
a
well-defined
reference
hardware
platform-
is
key
to
ensure
reproducibility
and
good
user
experience,
as
well
as
performance
in
the
beginnings
of
this
group,
and
this
will
hopefully
empower
many
of
you
to
reproduce
their
work
to
make
contributions
and
make
your
own
accelerators,
for
whatever
your
use
case
is,
of
course,
having
one
official
reference.
Hardware
platform
doesn't
mean
we
can
have
more
in
the
future,
and
this
is
actually
at
the
very
core
of
our
architecture.
A
C
A
I'll
I'll
I'll
essentially
explain
more
about
that
when
we
reach
the
fourth
item
in
the
agenda.
Looking
at
it
right
now,
because
there's
already
been
a
request
from
the
community,
so
so
definitely
count
on
that
all
right.
So
speaking
now
about
the
architecture,
so
the
architecture
builds
on
top
of
three
pilots.
A
A
A
A
So
these
are
the
extensions
we
propose
for
essentially
the
amend
roster
build
system
to
integrate
some
of
the
capabilities
for
hardware,
acceleration
so
happy
to
receive
your
input
on
that
now,
let's
dive
into
an
actual
walkthrough
on
what
this
is
from
a
code
perspective,
real
quick,
given
the
time
we
have
so
right
here,
you
can
see
the
amendments
source
code.
These
are
just
simple
series
of
macros
which
extend
the
ros
to
build
system
to
include,
in
this
case
the
vitis
unified
software
platform.
A
In
a
nutshell,
what
this
cmake
logic
adds
is
the
capability
to
within
your
cmakelist.txt
files
on
each
one
of
your
ros
packages,
to
literally
by
just
adding
this
block
by
just
using
this
macro
and
adding
this
block
defining
on
your
packages
kernels
directly.
So
it's
that
easy.
The
rest
happens
automatically
if
the
structure
is
kept.
That
way,
we
put
so
much
effort
into
ensuring
that
this
architecture
is
consistent.
A
Now,
within
the
macros,
you
can
define
the
name
of
the
accelerator,
the
source
code
involved
with
it
the
corresponding
platform
and
technology,
it's
targeting
headers
and
finally,
the
build
targets.
We
are
initially
proposing
three
different
build
targets.
These
build
targets
are
the
ones
that
come
from
our
vitis
technology
and
without
getting
into
too
many
details.
For
the
sake
of
time,
we
do
provide
two
build
targets
for
emulation,
one
where
you
can
simulate
the
programmable
logic,
the
fpga
and
you
simulate
it
within
an
emulation.
So
it's
a
simulation
within
an
emulation.
A
Second,
one
where
you
can
emulate
the
programmable
logic,
the
fpga
again,
also
within
a
chemo
emulation
and
third
and
last
but
not
least,
is
of
course,
the
typical
hardware
targets
to
run
it
in
your
boards.
Now
the
importance
of
this
first
shoe
was
discussed
in
one
of
the
threats
of
this
course
and
and
essentially
connects
to
the
fact
that
typically
building
hardware
accelerators
takes
a
bit
of
time
depending
on
the
complexity
of
your
accelerator.
A
So,
with
this
first
two,
you
can
accelerate
literally
your
development
significantly
because
it
takes
much
less
time
and
it
helps
you
keep
up
closer
to
the
typical
software
development
flow.
You
probably
will
have
in
your
workstations
now.
This
is
all
it's
needed.
Let's
now,
look
at
an
example
of
what
source
code
looks
like
this
is
a
a
publisher,
just
a
simple
publisher
that
is
trying
to
publish
at
10
hertz.
That's
what
this
wall
rate
is
here
for
the
result
of
a
vector
at
operation.
A
We
are
on
every
iteration
of
this
loop
randomizing
these
vectors
and
then
adding
them
in
this
function.
Now
this
function
looks
like
this.
It's
a
silly
function
that
has
been
purposely
made
computationally
expensive
to
illustrate
this.
This
acceleration
silly
example.
So,
as
you
can
see,
it's
just
adding
the
vectors,
that's
pretty
much
it
nothing,
nothing
much
more
complex!
Now.
What
we
will
see
is
that,
due
to
computational
expensive
function,
we
will
not
be
able
to
essentially
meet
the
objective
of
publishing
at
10
hertz.
A
So
that's
where
acceleration
triggers
that's
what
it
comes
in
and
that's
where
we
propose
this
second
example
and
again
we're
working
really
hard
at
signings
to
disclose
this
asap.
It's
right
now
in
legal
and
it'll
get
to
your
hands
as
soon
as
we
can
and
and
again
this
is
just
the
same
publisher
using
the
same
ros
logic.
A
You
can
see
here
that
we
are
instantiating
the
node,
creating
the
wall
raid
and
then
here
we
are
initializing
the
environment
for
opencl,
so
we
are
using
opencl
here
to
as
pointed
out,
c,
plus,
plus
and
opencl
are
the
core
baselines
of
this
working
group
and
that's
what
we
will
be
focusing
on.
So,
besides
that
we
are
creating
the
buffers
to
map
memory
between
the
programmable
logic
and
the
ps
and
then
we're
getting
into
the
main
loop,
where
all
we
are
doing
is
exactly
the
same.
A
A
These
mixins,
which
are
generated
automatically
out
of
the
firmware
provided
for
each
one
of
the
particular
boards
and
tie
and
connect
directly
to
the
amend
and
qualcomm
extensions,
is,
as
is
everything
you
need
to
do
by
just
passing
this
flag.
A
call
con
is
automatically
going
to
reconfigure
itself
to
know
it
needs
to
build
for
the
embedded
platform
in
the
mixing
that
is
cross-compiling.
A
It
also
knows
which
platform
for
acceleration
it
should
select,
and
it
also
knows
essentially
what
type
of
accelerators
it
needs
to
generate,
because
it's
going
to
look
into
the
corresponding
cma
files
with
the
macros
that
I
just
showed
before
so
in
this
case,
we're
just
essentially
building
a
very,
very
silly
vector
publisher
example,
but
we
can
see
how
essentially
so
it
did
cross-compile.
In
this
case,
we
don't
have
any
acceleration
whatsoever,
because
this
one
doesn't
include
it.
A
But
if
we
look
into
the
accelerated
version,
for
example,
we'll
see
how
it
has
also
generated,
in
this
case
a
software
emulation
target
that
I
did
before.
But
we'll
see
it
now
in
in
the
in
the
real
hardware.
So
again,
pretty
straightforward,
very
easy,
and
it
only
needs
you
to
literally
select
which
parts
of
your
code
you
want
to
push
into
the
hardware
you
want
to
push
into
an
fpga
or
to
an
to
a
gpu
as
well
in
the
future.
A
Now
to
the
examples
I'm
going
to
run
first,
the
vector.publisher
and
as
promised,
you
can
expect
it
not
to
meet
the
corresponding
target
in
terms
of
publication
rate
now,
of
course,
in
in
industrial
applications.
Our
advice
would
be
for
you
to
instrument
your
source
code
using
proper,
essentially
instrumentation
tools
such
as
lt
tng,
and
out
of
that,
get
your
baselines
and
benchmark
information.
Of
course.
A
A
You
will
see
how
essentially
it's
loading
the
the
kernel,
and
we
will
now
do
exactly
the
same
one
subscribing
to
atopic,
where
the
accelerated
version
is
publishing
and
you
can
see
how
from
two
hertz
we
jumped
directly
into
more
than
three
times
above
now.
The
beauty
of
this
is
that,
if
you,
if
we
look
back
at
the
changes
we
made
in
the
source
code,
they
were
these
three
and-
and
I
say
beauty,
because
really
we
haven't
fully
optimized
this.
A
This
function,
the
the
actual
the
actual
changes
we've
made
with
this
pragmas
are
just
selecting
actually
which
ports
are
used
within
the
rtl
model
that
gets
created.
To
give
you
a
bit
of
additional
insight.
The
hls
interface
specifies
how
rtl
ports
are
created
from
the
function.
Definition
during
the
interface
synthesis
now
sharing
ports,
which
is
what
happens
by
default
with
hls
means.
A
Essentially,
you
save
fpga
resources
by
eliminating
axi
interfaces,
but
this
also
limits
the
performance,
so
essentially
the
mxc
port
allows
for
independent,
read
and
write,
but
this
case
we
want
to
read
simultaneously
from
two
different
vectors,
and
so
what
we
do
essentially
in
this
case
is
create
different
bundles.
We
separate
two
different
bundles,
creating
two
axis
interfaces
and
obtaining
the
boost.
We
just
saw
there's
no
further
optimization
in
this
particular
piece
of
code,
there's
no
loop
and
rolling
or
pipelining.
A
Nothing
of
that
and
all
those
will
lead
to
further
essentially
upgrades
into
the
kernel
itself
now
this
co.
These
examples
give
you
a
quick
intuition
of
how
easy
it
is
now
to
use
hardware
acceleration
in
ros
with
silencers
tools
and
technically
what
we've
done
is
integrate
the
divide,
this
unified
software
platform
in
ross
as
a
first-class
participant.
Now
let
me
dive
directly
into
the
fourth
topic
of
the
agenda,
which
I
think
it
was
requested
as
well,
which
is
how
do
we
extend
this
to
other
boards
right
and
that's
something?
A
We
paid
lots
of
attention,
as
we
said
not
just
because
it
was
requested,
but
at
the
very
beginning,
because
we
ourselves
use
different
boards
for
our
development.
You
can
see
here
listed
some
unofficially
listed
boards
because
again
in
our
team,
there
are
many
other
people
using
it
and
we
definitely
want
to
open
up
the
door
for
this
to
happen.
Now,
there's
a
section
here
in
the
community
repository
which
says
adding
your
board,
and
this
should
satisfy
most
of
your
needs,
we're
working
on
this
right
now.
A
In
a
nutshell,
this
will
be
translated
to
a
series
of
artifacts
that
you
need
to
place
into
a
repository.
This
repository
will
fit
into
the
third
piler.
I
explained
the
firmware
piler,
so
just
by
having
that
repository
into
your
workspace,
you
are
pretty
much
done.
The
rest
of
the
logic
is
is
done
by
our
architecture
and,
of
course,
we're
working
right
now
to
try
to
translate
this
into
a
series
of
instructions.
A
It's
it's
essentially
taking
a
bit
for
two
reasons:
first,
because
of
internal
processes
in
silence,
and
second
because
we
want
to
coordinate
this
also
with
open
robotics.
So
essentially
we
don't
go
crazy.
We
start
getting
forks
or
forks
and-
and
we
go
well
crazy
before
even
we
got
started,
so
we
are
trying
to
formalize
this
as
part
of
a
formal
ros
announcement
proposal.
So
if
you
want
to
help
with
this
reach
out
to
me
now,
it's
a
great
moment
we're
doing
this.
A
Nevertheless,
for
pedro's
request
on
the
ultra
96
version
two,
you
definitely
can
count
on
our
support
and
help
and,
as
I
said,
the
instructions
will
be
pushed
to
the
community
repo
asap
as
soon
as
as
we
are
ready
pedro.
You
raised
this
topic,
so
I
wanted
to
open
the
mic
to
you
real
quick.
If
you
want
to
add
something,
did
I
cover
your
request.
R
A
Now,
you're
right
and
an
apologies
for
for
the
delay,
I
mean
too
many
people
is
trying
to,
but
to
buy
too
much
from
us.
I
guess
that's
good
news,
but
anyhow
the
popularity
is
well
deserved.
I
can
absolutely
assure
you
that,
but
but
yeah
apologies
for
that
and-
and
the
request
is
very
well
understood-
pedro-
so
definitely
count
all
my
help
for
doing
that.
A
A
A
So
right
now
we
are
developing
on
top
of
foxy
okay,
so
that
is,
that
is
pretty
much
the
the
assumption
we've
made
internally
in
silence.
Now
it
doesn't
mean
it
won't
work
into
other
distributions.
However,
right
now
all
of
the
packages
need
to
be
built
from
swords.
We
haven't
pushed
this
into
the
bill
farm.
We
definitely
have
the
intention
to
do
so,
but
again,
step
by
step.
So
right
now
I
would
say
matthias.
A
N
A
It
will
work
with
business
thanks
I
mean
I
I
can,
I
can
just
say
that's
good
information
and
if,
if
you
have
a
good
use
case
and
a
strong
use
case
for
us,
then
reach
us
out,
let
us
know
and
we'll
consider
jumping
into
galactic.
I
I
I'm
not
pushing
towards
one
or
the
other.
I
just
I
just
think
fox
is
the
lds,
and
so
that's
why
we
stick
with
it.
C
A
Now,
of
course,
this
comes
at
the
cost
of
of
having
to
also
use
opencl.
We
could
literally-
and
if
this
is
a
a
request,
then
I'd
like
to
hear
it,
but
we
could
directly
kind
of
like
template
how
the
acceleration
is
going
to
be
shipped
and
literally
by
using
templates.
We
could
remove
much
of
the
hurdles
of
using
certain
opencl
aspects
and
literally
just
make
it
even
simpler
for
people,
but
this
would,
of
course,
put
boundaries
on
what
type
of
accelerators
users
will
end
up
being
producing.
A
Now
we
reviewed
literature
quite
extensively,
I'd,
say
and
most
of
the
past
approaches
which
are
impressive
and
awesome
tend
to
make
like
design
choices
in
this
direction.
We
we
would
prefer
at
this
stage,
not
to
make
them,
and
that's
also
what
we
would
encourage
both
across
fpgas
and
gpus,
because
again,
every
use
case
in
robotics
is
different
and
and
and
potentially
we
want
that
choice
to
be
made
by
the
architect,
not
ourselves.
Now,
while
designing
the
tools.
C
Yeah,
maybe
maybe
to
share
from
a
you
know
in
a
video
perspective.
So
what
I
I'm
I'm
particularly
interested
in
is
accelerating
an
execution
graph,
so
I'm
interested
in
in
finding
ways
to
not
accelerate
a
single
node,
but
a
graph
of
nodes
that
are
performing
functions
that
are
needed
for
robotics
and
a
good
example
of
that
would
be
most
robots
need
to
have
some
perception
pipeline
that
has
to
be
performed
and
each
of
the
individual
nodes
today
have
a
lot
of
you
know
in
ros2.
C
There's
a
lot
of
fixes
to
superfluous
memory
copies,
so
data
can
be
moved
as
long
as
we're
within
the
same
processor
thread
without
having
a
cost,
but
that
isn't
designed
well
for
hardware
acceleration.
So
we're
really
looking
for
a
way
to
split
up
computation
across
multiple
nodes
in
a
way
that
makes
sense
from
a
functional
perspective,
but
allow
that
such
that
we
can
use
hardware
acceleration
in
those
nodes
across
that
execution.
Graph.
A
So
that's
interesting
and
I
like
to
hear
that
a
lot
because,
that's
kind
of
like
I
pointed
some
of
the
nvidia
folks
in
the
past
towards
that
direction,
and
essentially
this
is
very
important.
We
get
it
right
from
the
very
beginning.
The
the
actual
impact
of
acceleration
is
going
to
happen
at
two
levels.
First,
at
the
application
level
by
sewing
stuff,
like
what
I
showed
today,
just
a
simple
publisher,
accelerated.
A
The
second
one
is
accelerating
the
computational
graph
and
that's
what
you
have
just
described
now,
accelerating
the
computational
graph
requires
you
first
to
accelerate
or
optimize
the
under
layers.
There
was
200
layers
that
means
going
from
the
link
layer,
app
to
layer,
7
of
the
osi
stack,
considering
dds,
and
then
it's
behind
that
the
networking
stack
and
so
on
and
so
forth.
C
Maybe
give
a
a
concrete
example
right.
I
can
imagine
that
on
an
you
know,
one
of
your
fpgas.
Maybe
somebody
implements
a
visual
odometry
function
and
before
you
can
run
the
visual
odometry
function,
you
need
to
do
some
image
processing,
so
you
have
one
node
that
wants
to
do
image,
processing
and
another
node,
that's
doing
visual
odometry,
and
if
I
were
as
I
links,
I
would
want
to
not
have
to
copy
memory
out
of
my
fpga
when
I'm
done
with
color
space
conversion
and
then
copy
it
back
into
my
fpga
to
red
visual
odometry.
N
Just
expanding,
maybe
on
this
a
bit
we
are
in
the
process,
it's
an
early
prototype
of
adding
something
like
the
set,
but
not
for
accelerators,
but
we,
we
began
to
to
add
our
zero
copy
middleware,
which
essentially
avoids,
under
certain
circumstances,
unnecessary
copies
in
the
in
the
under
layers,
of
course,
but
the
key
question,
of
course,
for
you
is
then
how
to
make
this
also
work
for
accelerators,
and
this
I
cannot
answer
this.
I
do
not
know,
but
that's
that's
why
I'm
essentially
here
to
maybe
get
some
ideas
or
explore
this.
N
Yes,
that's
that's
yeah,
that's
an!
I
would
call
it
an
early
prototype
said
the
integration
that
it's
not
the
iso
system
itself,
but
the
isolate
system
itself
operates
on
posix
shared
memory
and
is
not
able
to
interface
with
accelerators,
as
of
now
would
be
cool
if
it
if
it
would
be
in
the
future-
and
maybe
this
is
possible-
maybe
not
if
yeah.
A
No,
I
think,
I
think,
definitely
and
technically
it's
viable.
We
just
need
to
find
time
and
motivation
to
to
work
on
it,
but
definitely
leveraging
the
capabilities
either.
It's
promises.
I
haven't
tested
it
myself,
but
I
read
the
documentation.
The
micro
second
level
interactions,
the
intra
and,
inter
is
definitely
something
we
we
do
want
and
we
should
consider.
A
I
think
I
think
we
shouldn't,
though
stay
at
that
stage
from
at
least
from
science's
perspective
we're
looking
at
this
holistically,
meaning
we
want
to
accelerate
interactions
between
nodes
in
a
computational
graph,
using
inter
process
intra
process
and
also
intra
network,
because
many
many
robots
actually
do
work
in
a
full
distributed
way,
think
about
fleets
or
even
think
about
just
one
robot
with
distributed
components,
communicating
over
different
networks.
So
so
definitely
we'll
get
back
to
that
mathias
and
thank
you
so
much
for
racing.
A
A
A
The
current
the
current
prototype
that
I
showed
is
based
on
on
beta
linux,
which
is
yokoto
open,
but
for
those
of
you
not
so
familiar
with
with
it,
but
definitely
we're
looking
forward
jorge
taking
tackling
your
question.
We're
looking
forward
to
also
consider
other
file
systems
beyond,
essentially
this
embedded
file
systems
based
on
peta
linux.
So
so,
if
you're
interested
on
this,
I
think
you'll
have
tools
in
the
future.
A
So
a
short
answer,
because
we
really
are
out
of
time-
and
it's
a
bit
late
here
in
spain
short
answer-
is
the
platform
is
defined
by
the
mixing.
You
pass
on
the
call
con
on
the
qualcomm
build
argument,
so
essentially
the
platform
is
defined
by
the
firmware
repository
you
you
have
in
your
workspace
now.
A
As
for
the
actual
platforms
that
are
used
in
the
different
accelerators
in
the
in
the
vision,
kit
of
kv-260,
that's
beyond
this
discussion,
but
what
we
are
doing
is
using
one
particularly
tied
for
the
robotics
use
cases,
so
that
one
anyhow
will
be
included
within
the
firmware
repository
we're
working
to
to
disclose
so
you'll
have
everything
you
need,
and
with
that
I'm
going
to
thank
everyone
once
again
for
this
extra
15
minutes
as
well.
I
think
it's
it's
surprising.
A
A
If
you
have
cool
use
cases
and
are
interested
to
know
more,
I
would
say
reach
out
to
me,
or
any
of
my
colleagues
privately
will
study
the
opportunity
of
giving
you
access
to
our
early
access
launch,
where
you
will
find
information
ahead
of
these
meetings
and
with
that
once
again,
thank
you
all
and
we'll
see
each
other
in
the
next
meeting.
If
you
decide
to
to
come,
thank
you
and
have
a
great
one.