►
From YouTube: ROS 2 Hardware Acceleration Working Group - meeting #13
Description
Twelfth meeting of the ROS 2 Hardware Acceleration Working Group (HAWG).
We discussed a) Updates on the Robotic Processing Unit and Robotics MCU projects and b) discussion around standardization efforts. Particularly REP-2008, REP-2014 and and RobotPerf. The session also includes a guest talk provided by Piotr Rybicki and Adam Dabrowski from Robotec.ai telling us about their recent work around the RobotecGPULidar, a cross-platform (Windows and Linux), C/C++ library for simulating LiDARs on CUDA-enabled GPUs, accelerated by RTX cores if available.
For more including source code, check https://github.com/ros-acceleration. Minutes of the meeting available at https://docs.google.com/document/d/185Cy1xjpAOgJygEOnlf5OCgOQTywmF0qgSpS3GiW16Q
00:00 Welcome
01:23 Updated Robotic Processing Unit (RPU) mechanical design
03:27 Updates on Robotics MCU project
07:57 RobotPerf, benchmarking suite to evaluate robotics computing performance
14:25 Standardization effort updates
32:50 REP 2008 vote result
33:33 Guest talk: RobotecGPULidar, Adam Dabrowski
49:13 Q&A
For more including commercial support on hardware acceleration topics in robotics, refer to https://accelerationrobotics.com.
A
A
All
right,
some
someone
has
asked
to
be
removed
from
the
recording
and
I
just
got
a
message,
so
that
should
be
fine,
I
guess
all
right,
yeah.
So
welcome
to
the
meeting
as
usual.
There's
quite
a
bit
of
people
joining
so
please,
as
in
typical
remote
meetings,
keep
yourself
muted
if
you're,
not
speaking
and
be
mindful
of
whoever
is
taking
the
mic.
A
A
B
A
Thank
you
sure,
right
so
yeah.
First
topic
of
the
agenda,
all
business
and
progress
review
updates
regarding
the
rbu,
in
particular
the
mechanical
design.
So
you
can
see
the
project
link
over
there.
There's
been
some
feedback
from
some
of
you.
Thank
you
regarding
some
user
experience,
so
it
appears
that
more
and
more
people
is
building
their
own
rpu,
which
is
great.
That's
why
we
released
it.
A
One
of
the
criticisms
we've
been
receiving
is
that
there's
there
are
some
sections
in
the
rpu
which
are
hard
to
access
some
connectors.
Specifically,
that
can
be
I,
don't
know
if
you
can
say
it
very
well,
but
in
here
you
can
see
some
of
the
connectors
themselves
are
very,
very
close
to
the
borders
of
the
outer
box
of
the
exoskeleton
itself.
A
A
So
that's
one,
that's
one
beat
down.
The
second
beat
is
regarding
the
robotics
MCU
project,
as
some
of
you
who
have
been
following
the
project
and
the
group.
No,
this
particularly
aims
to
build
a
ross-2
Native
robotics
microcontroller
unit.
This
has
been
tracked
right
now
in
this
meta
ticket.
Right
now,
in
the
community
repository
and
in
the
last
meeting,
we
discussed
some
of
the
Milestones
that
are
expected
to
be
accomplished
as
a
short
kind
of
like
Target.
A
We
are
hoping
to
have
first
version,
first
working
version
of
the
robotics
MCU
by
the
next
official
Ross
release,
which
is
happening
in
May
next
year.
So
everybody
irony
we'll
do
our
best
committed
right
now
the
work
has
started.
We
are
working
on
essentially
the
hardware
side
of
things:
sporting,
the
existing
core
bmcu
into
the
kr260,
the
settings
or
AMD
kr260,
which
is
the
board
we're
using
for
reference
development
and
our
our
partners
from
plan.
A
V
are
taking
care
of
that
right
over
here.
You
can
see
a
small
report
that
I
just
submit
today,
based
on
the
feedback
that
I
got
from
and
some
others,
but
today
we
have
in
here
Mustafa
with
us.
So
most
of
us,
please
feel
free
to
maybe
tell
us
a
bit
more
of
what's
the
status
and
and
and
how
we
are
moving
forward
with
this.
B
Currently,
we
are
trying
to
implement
Corey
MCU
on
KR
260
and
we
are
a
bit
stuck
on
some
PLL
issues,
but
I
think
it
will
be
sold
quickly
and
I
personally
I'm
trying
to
add
an
Ethernet
Mac
to
the
Corey
MCU.
We
have
evaluated
a
couple
of
ips
and
we
decided
to
use
something
from
Alex
foreign
kick
I,
don't
know
how
do
you
spell
the
name?
How
do
you
pronounce
the
name
and
yeah?
Actually
that's
the
update.
We
can
give
right
now.
A
Thank
you
yeah,
that's
great,
so
I
would
say:
please
keep
up
with
the
good
work
and
I'll
I'll
continue
interacting
with
you
guys,
as
I
suggested,
if
you
guys
find
yourselves
kind
of
like
cornered
with
the
port
and
enablement
in
the
pl
within
the
KR
260
board
do
feel
free
to
raise
an
open
ticket.
Possibly
the
best
place
would
be
the
AMD
Forum
as
I
suggested
over
over
email,
mainly
because,
if
you
guys
do
file
an
open
ticket
and
provide
instructions.
A
Yeah
I
think
it's
sticking
a
bit
there.
It
goes
so
as
I
was
saying
as
a
refresher.
This
first
Milestone
should
first
tackle
the
Port
of
the
USB
core
to
to
actually
the
pl
of
the
kr260,
and
then
we
will
move
forward
into
enabling
free
artos
and
then,
on
top
of
that,
we're
going
to
use
an
open
source
networking
stack
and
then
possibly
we'll
be
leveraging
embedded
RPS.
A
So
this
is
nothing
new
for
those
of
you
who
have
been
following
the
working
group.
We've
been
speaking
about
it,
at
least
for
a
couple
of
months
already,
but
we
certainly
are
disclosing
more
and
more
importantly,
just
today
we
released
the
website
of
the
project
that's
available
in
here.
This
is
all
plain
HTML
which
lands
in
GitHub
so
feel
free
to
to
check
it
out
and
somehow
contribute
it
is
particularly
living
in
here
here
it
is
so
this
is
the
site
and
yeah.
A
As
I
pointed
out,
it's
just
a
matter
of
of
contributing
here
directly
the
project
itself,
formalizes
a
bit
more.
What
we've
been
saying
and
discussing,
as
we
said
last
time,
anyone
that's
interested
in
participating
should
be
doing
it,
and,
and
the
effort
over
this
last
month
has
been
pushing
specifically
to
try
to
enable
all
of
you,
organizations
and
individuals
to
somehow
have
a
way
to
start
contributing.
A
So
let
me
find
some
preliminary
categories
that
we
believe
makes
sense
for
partitioning
the
different
benchmarks.
Of
course,
we
are
emphasizing
very
much
the
why
and
why
we're
focusing
on
Boss
2
as
the
common
Baseline
in
robotics
these
days.
This
will
be
discussed
in
the
this
working
group,
if
not
every
single
meeting,
very,
very
often
and
again,
opening
up
the
door
for
many
others
to
participate.
C
A
Go
so
yes,
I
was
saying
super
open
to
receive
interest.
We
are
still
discussing
the
membership,
we're
going
to
try
to
set
only
some
soft
requirements
and
make
without
contributing
with
at
least
one
Benchmark
and
maintaining
it
the
actual
work.
The
actual
interesting
juice
is
in
Benchmark
repository
of
the
robot
perf
organization,
which
does
Define
the
objectives
once
again,
but
also
provides
some
preliminary
intuition
of
what
you
can
expect
out
of
this
benchmarks.
A
I've
summarized
this
all
these
resources,
a
bit
more
in
here,
I
think,
what's
more
interesting,
is
to
show
you
kind
of
like
how
you
can
get
started
contributing
and
what
you
can
expect
in
the
coming
weeks
months.
So,
first
of
all,
we
prepared
a
specification
that
defines
what
it
each
Benchmark
should
be
complying
to
again.
This
is
likely
to
evolve
in
the
following
weeks
and
months,
but
right
now
we
believe
it's
in
a
decent
stage
to
bring
it
to
your
attention.
A
So
there's
an
explanation
in
here
again
a
motivating.
Why
describing
some
general
aspects
that
we
believe
are
relevant
for
each
Benchmark
to
Define
metrics,
and
also
we,
we
put
quite
a
bit
of
focus
internally
while
discussing
between
hardware
and
ourselves
as
the
main
drivers
for
now
on
how
we
wanted
to
have
this
Benchmark
so
that
they
could
be
machine
readable,
but
also
somehow
are
usable
over
time.
A
So
what
we
landed
on
is
on
proposing
that
each
Benchmark
should
be
described
in
a
yaml
format,
so
maybe
some
basic
IDs,
which
should
make
each
Benchmark
essentially
unique
in
a
way
and
then
there's
a
definition
around
the
metrics,
a
description.
There
should
be
a
reproduction
section
within
the
yaml
which,
essentially
not
immediately
but
over
time,
I
presume.
We
will
use
this
to
validate
benchmarks
in
in
a
continuous
manner
by
using
cicd
infrastructure
which
we
will
set
up.
A
A
simple
cicd
job
is
going
to
check
each
one
of
these
files
use
the
corresponding
the
corresponding
markdown
files
out
of
those,
this
will
be
auto-generated
for
readability
purposes,
but
also
this
automatic
review
is
the
one
who
is
going
to
end
up
pushing
these
tables
that
will
summarize
all
of
their
resource
all
together.
So
that
is
how
we
envision
this
to
happen
so
that
it's
also
somehow
thought
for
integrating
it
with
with
automated
testing,
which
is
definitely
something
we
are
doing
internally
and
yeah.
A
This
is
pretty
much
still
earliest
pages,
so
very,
very,
very
open
for
criticism
and
input
and
feedback.
There's
the
skeleton
of
what
you
can
expect
again.
The
categories
that
right
now
we
have
proposed
are
this
ones,
which
means
across
the
most
popular
Ross
two
packages
and
was
two
stacks
based
on
the
surveys
that
we
have
been
conducting
for
the
last
year.
But
that
doesn't
mean
that
we
cannot
kind
of
like
go
thinner
into
Rush,
2
abstractions.
A
So
again
we're
trying
to
stay
a
bit
away
from
specifics,
because
robot
Perth
aims
to
grasp
the
complete
robotics
pipeline.
We
are
using
ros2
as
the
common
Baseline.
Indeed,
on
the
first
stage,
I
would
rather
focus
on
on
the
actual
Stacks
than
on
on
abstractions
such
as
inter-process
inter-processing,
their
Network,
intra,
Network
I
think
those
ones
will
come
down
down
the
road
later
so
yeah.
This
is
pretty
much
the
state
of
robot
perf
right
now
very
much
looking
forward
for
interest.
A
If
you
want
to
contribute,
you
can
start
doing
so.
You
can
pick
up
one
of
these
categories.
You
can
grab
one
of
the
corresponding
Stacks.
Possibly
there
was
two
implementations
of
those
and
decide
to
instrument
the
corresponding
section
that
you
wish
to
Benchmark
and
provide
and
propose
the
corresponding
Benchmark
through
a
pull
request.
So
that's
that's
a
possibility
right
now
and
of
course,
this
is
very
aligned
with
the
ongoing
standardization
effort,
alongside
rep
2014
So
reading.
A
Kernels
will
first
touch
briefly
on
rep
2008
and
very
excited
to
see
what
is
the
reaction
of
the
group
based
on
latest
developments
and
then
I'll
touch
briefly
on
Rec
2014,
because
there's
been
quite
a
bit
of
feedback
from
a
number
of
companies
and
I.
Think
at
this
point
it's
worth
collecting
your
input
so
so
yeah,
let's,
let's
do
that
so
there's
more
than
50
persons.
Today,
I
I
haven't
checked.
A
If
all
of
you
guys
have
been
following
all
the
meetings,
so
even
at
the
coast
of
being
a
bit
boring.
Allow
me
to
Super
quickly
just
go
through
web
2008
before
I
actually
asked
for
a
vote
on
whether
people's
happy
with
the
currency,
the
the
rep
itself
is
titled
ros2,
Hardware
acceleration
architecture
and
conventions
and
describes,
essentially
the
architectural
pilers
and
conventions
required
to
introduce
Hardware.
Acceleration
involves
two
in
a
vendor,
neutral
technology,
agnostic
and
scalable
manner.
A
Giving
aside
a
bit
of
the
motivation
which
you
guys
can
can
go
through
it.
What
I
will
highlight
is
what
is
the
value
for
stakeholders
so
specifically
for
you
as
Ross
users,
but
also
for
package
maintainers?
If
any
of
you
is
maintaining
a
package
and
finally
for
silicon
vendors
and
solution
manufacturers
for
maintainers,
essentially
they
can
use
these
guidelines
to
introduce
Hardware
acceleration
in
their
packages
in
a
in
an
accelerator
agnostic
manner.
A
They
can
use
some
cmake
macros
that
are
defined
that
allow
you
to
essentially
abstract
yourself
away
from
the
specific
accelerator,
whether
it's
a
GPU,
an
fpga
and
so
on
and
so
forth.
That
is
for
package
maintainers.
That
has
significant
benefits
overall,
but
also
package.
Maintainers
can
further
specify
if
they
want
to
feed
themselves
to
a
particular
accelerator,
they're,
also
cmake
macros
that
allow
them
to
fit
with
only
one
specific
solution.
So
there's
these
two
choices
without
what
this
rep
provides
right.
A
A
Finally,
for
silicon
vendors
and
solution,
manufacturers
does
provide
a
series
of
guidelines
on
how
they
can
fit
in
into
the
ross2
ecosystem,
as
opposed
to
Reinventing
the
wheel,
every
single
time
and
forking
across
two
packages,
forking
those
two
layers,
creating
further
fragmentation
and
further
complicating
our
lives
as
rush
to
developers.
So
those
are
the
main
objectives.
A
Are
you
are
free
to
do
so
at
the
same
time,
it's
not
the
the
intention
of
this
document
to
enforce
any
sort
of
Hardware
acceleration
on
maintainers
or
on
users
you're
totally
up
to,
and
the
abstractions
that
are
provided
in
here.
Allow
you
to
jump
from
one
to
the
next
one
without
having
to
actually
modify
your
boss
to
source
code.
There's
various
kernel
levels
for
Hardware
acceleration
defined
a
bit
more
in
here.
A
The
document
has
been
simplified
significantly,
even
if
it
sounds
very
long
trust
me,
we
got
more
than
half
of
it
and
I
I
do
believe
it's
in
a
very
decent
stage.
There's
also
a
methodology
on
how
you
can,
if
you
want,
create
your
acceleration
kernels-
and
this
has
proven
to
be
very
useful
for
onboarding
new
people
into
Hardware
acceleration.
This
is
something
we're
using
very
actively
in
our
group
and
and
also
while
mentoring,
some
of
our
customers
and
clients.
A
A
This
kind
of
like
formal,
Ross
announcement
proposal,
kind
of
like
standards
in
the
Ross
Community,
was
drafted
back
in
August
2021,
so
it's
been
around
for
for
quite
a
while
now,
I
counted
more
than
10
reviewers
and
contributors
from
various
organizations
and
many
of
which,
by
the
way,
are
active
participants
of
the
working
group.
So,
thanks
to.
A
You
in
here
various
iterations
of
community
feedback,
of
course,
and
this
was
presented
against
the
TSC
upon
the
request,
which
essentially
confirmed
that
what
we
were
doing
sounded
like
something
interesting
Beyond,
this
working
group
and
finally
were
pretty
much
in
the
latest
stages.
The
the
TSC
has
pretty
much
reviewed
the
document
and
shared
that
they
are
happy
to
move
forward
as
a
draft,
provided
that
there's
a
majority
of
you
that
confirmed
that.
Indeed,
that's
the
case,
so
I
will
call
for
a
vote.
A
A
We
need
a
no
and
an
answer
about
that,
so
feel
free
to
to
share
that
directly
with
me
or
directly
in
the
document.
If,
if
that's
something
you're
willing
to
do-
and
hopefully
I
did
prepare
this
property,
so
I'm
going
to
enable
it
right
now
and
all
right,
so
I
hope
that
some
of
you
are
getting
or
all
of
you
are
getting
right
now:
notification
at
the
bottom
right
and
you
can
vote
for
this.
Can
someone
confirm
you
can
see
it.
A
Yes,
yes,
so
for
those
of
you
that
may
have
missed
it,
because
I
was
trying
this
before
and
and
it
disappeared
very
rapidly
for
me,
you
can
still
find
it
if
you
press
on
the
on
the
bottom
right
of
the
screen.
There
is
an
activities
kind
of
like
section
which
is
represented
by
three
figures.
There
is
a
triangle,
a
square
and
a
circle
if
you're
pressing
there
and
then
there's
a
polling
in
my
screen
is
the
first
one.
A
So
if
you're
pressing
there,
you
should
see
how,
essentially
there
is
over
there,
the
polling
thingy,
so
so
yeah
we'll
let
that
run
for
some
time
so
that
you
guys
can
can
vote
on
it
and
you
have
the
the
information
is
out
there.
What
I'll
do
is
I'll
be
moving
forward.
If
that's
okay
for
you
and
once
everyone
has
voted,
we
will
stop
it
and
disclose
everything.
So
red,
2014,
Super,
exciting
topic,
benchmarking
performance
in
Boss
2..
A
It
was
very
well
received,
as
I
was
saying
by
a
number
of
users.
There's
been
various
positive
reviews
so
far,
and
this
document,
by
the
way,
is
not
that
old
I
would
say
so
it's
still
very
open
for
contributors
and
and
even
authors.
If
you
can
contribute
enough
to
make
space
for
that
so
far,
there's
been
some
interesting
and
major
feedback.
A
I
would
say
the
major
input
has
been
processed
already,
but
there's
some
additional
feedback
that
requires
additional
work,
which
I
hope
I
will
get
done
over
at
Christmas,
but
no
promises
there
very
interesting
ones.
I
must
admit.
I
do
have,
however,
some
concerns
about
some
of
the
feedback.
So
I
wanted
to
bring
it
up
in
here
and
kind
of
like
capture
your
brains
about
about
what
do
you
think
and
what
are
the
views
of
some
of
you
in
here
which
who
are
willing
to
share
it?
A
So
the
the
one
of
the
aspects
that
I
am
currently
a
bit
kind
of
like
hesitant
about
is
that
there
is
no
implementation
reference
implementation
for
this
rep
2014.
and
hopefully
by
intersecting
with
robot
perf.
We
can
address
part
of
that,
because
I
think
there
are
some
aspects
we
do
only
see
when
you
do
implement
it
so
I'm,
hoping
that
that
part
of
the
feedback
that
has
been
provided
will
be
processed
while
implementing
it
so
that
effectively
I
can
answer
more
or
better.
A
Let
me
see
if
this
gets
thrown
appropriately,
so
I
just
wrote
two
more
posts
to
you
guys
the
first
one
touches
on
how
should
input
data
be
provided
to
benchmarks
and
the
reason
why
I'm
bringing
this
up
is
because
there's
been
a
an
interesting
suggestion
in
the
community
around
whether
we
should
be
focusing
on
receiving
input
in
the
benchmarks
from
one
or
another
mechanism.
So
far,
we've
been
pursuing
an
Avenue
wherein
we
have
info
using
simulation,
casible,
essentially,
but
I.
A
Think
there's
Merit
in
some
of
the
other
suggestions
that
came
around
such
as
for
systematically
reproducing
always
the
same
result.
There's
also
some
voices
pointing
out
about
real
Hardware,
so
yeah
just
curious
about.
What's
gonna
come
out
there
and
and
we'll
see
that
I'll
leave
that
running
for
a
while
as
well.
The
second
piece,
actually,
let
me
just
explain
the
second
one
and
then
I'll
open
up
the
mic,
because
I'm
really
interested
in
hearing
some
answers
that
I'm
seeing
in
here,
such
as
other.
A
So
the
second
question
itself
is
about
how
how
should
we
require
people
to
execute
this
benchmarks?
There's
there
was
a
previous
discussion
last
meeting
around
whether
we
should
allow
or
enforce
source
code
to
be
visible
or
we
can
accept
binaries
or
we're
just
fine
with
the
results,
and
we
accept
that
someone
just
run
it
in
their
machines
and
results
are
used.
Fair
enough.
A
There's
been
some
very
direct
feedback
about
this
from
from
Cellcom
vendors,
particularly
from
Nvidia,
regarding
the
fact
that
they
they
don't
accept,
or
they
wouldn't
accept
kind
of,
like
open,
open
source
code
like
requirements
that
they
they
would,
they
would
require
just
the
results
to
be
pushed
and
I.
Think
Frankly,
Speaking
I
think
there
is.
There
is
Merit
in
what
they
are
asking
because
often
the
case
the
implementation
might
be
proprietary
at
the
same
time.
A
I
know
how
the
Ross,
Community
works
and
I
know,
there's
a
clear
bias
towards
disclosing
the
source
code,
so
so
again
just
interested
to
capture
people's
opinion
in
here
so
yeah.
Anyone
that
wants
to
share
her
or
his
views
around
these
two
questions
regarding
rep
2014
I'm,
particularly
very
interested
about
those
two
persons
that
answered
other
in
the
first,
the
first
question
around
how
should
data
be
provided
to
benchmarks?
So
if
someone
can
comment
on
this
girlfriend,
Adam
all.
E
So
so
you
know
it
needs
this
simulation
and
at
other
times
we
just
benchmarking
time
to
compute
certain
outputs
I
believe
so
then
it's
better
to
have
rolls
backs
so
so
these
are
my
thoughts
but
I
I
I,
admit
I,
might
not
be
deep
in
you
know:
What
rep
2014
is
about
so
apologies.
If
that's
the
case
well,.
A
No,
no,
no
worries
and
I
think
I
think
your
your
answer
definitely
has
married
I.
So
one
thing
to
keep
in
mind
is
that
we
we
want
to
compare
performance
Computing
in
in.
From
that
perspective,
we
want
to
be
as
Fair
as
possible
and
it
should
be
reproducible.
It
should
be
as
reproducible
as
possible
and
and
one
criticisms
that
I've
heard
is
that,
even
though
casiwo
is
fantastic
and
possibly
some
say,
I
may
say
the
best
simulator
out
there.
A
The
reality
is
that
when
it
comes
to
reproducibility,
unless
you
have
a
super
simple
scenario,
that's
kind
of
like
looping
around.
If
you
have
like
interactions
in
the
environment,
they
may
not
always
reproduce
in
the
exact
same
manner,
and
so
I
think
there
is
Merit
in
saying
that
maybe
I
was
back.
Would,
for
example,
give
us
that
kind
of
like
determinism
that
might
be
required
for
comparing
things
further.
E
A
A
A
To
be
frank,
when
it
comes
to
comparing
benchmarking
computations
in
Ai
and
machine
learning,
so
hopefully
we'll
learn
from
all
of
those
lessons
and
get
things
right
in
robotics
having
it
in
a
roast.
Eccentric
manner
is
fantastic,
so
again
encouraging
everyone
to
reach
out
to
contribute
to
be
proactive
on
this
and
and
we'll
be
looking
forward
to
hear
from
you
in
this
regard
regarding
the
polling
and
the
results
so
far,
I'll
be
again
digesting
and
sharing
the
percentages.
A
I'm
super
happy
to
see
that
the
first
poll
regarding
the
acceptance
of
red
2008
has
turned
out
into
all
positive
votes,
so
very
happy
about
that,
and,
and
just
a
reminder.
The
fact
that
this
may
lead
to
getting
the
draft
accepted
doesn't
mean
it's
kind
of
like
set
in
stone
as
any
rep
out
there.
You
can
send
for
requests.
You
can
actually
contribute
it
further
and
you
can
improve
it,
and
actually
you
should
try
to
improved.
A
A
A
super
nice
guy,
a
good
friend,
someone
I,
know
very
well
and
super
super
excited
to
see
what
he
his
team
are
up
to
using
this
essentially
Robotech
GPU,
lighter
they
they
came
up
with
Peter
and
and
Adam
I
would
love
to
see
out
of
you
guys,
maybe
a
contribution
for
a
benchmark
that
could
land
in
in
robot
purse
I
think
there's.
Definitely
ground
for
this
work
and
with
that
looking
forward
to
hear
you.
E
All
right
thanks
thanks
a
lot
for
for
this
super
nice
introduction,
Victor
and
I
I
I'll
just
start
to
present
I
guess
you
can
see
my
slides
right
now.
Just
someone,
please
confirm
all
right.
So,
let's
get
it
going,
then
all
right.
So
our
company,
you
know,
deals
with
modern,
Ross
and
simulation
with
robotics.
E
E
I
will
be
talking
a
little
bit
about
that
in
regards
to
gazebo-
and
here
we
are
talking
about
GPU
acceleration
and
namely
Cuda
based
for
lidar
simulation
and
while
I
contributed
to
this
project.
It's
leading
Alpha
is
with
us.
It's
capture,
bitsky
and
I.
Understand
that
this
group
has
a
broad,
interesting
acceleration.
This
part
is
about
accelerating
simulation,
so
it's
it's
a
bit
specific,
but
but
I
understand
still
within
the
interest
of
this
group.
E
A
simulation
I
think
is
quite
crucial
are
to
robotics.
So
just
a
brief
introduction.
Of
course,
there
are
many
application
fields
for
simulation
and
we
have
at
least
three
different
categories
of
goals,
so
it's
it's
it's
very
different
for
for
many
users,
how
they
see
a
simulation
and
what
they
need
from
simulation.
E
As
long
as
you
can
kind
of
guarantee
that
it's
still
useful,
it's
not
as
far
removed
from
the
real
data
to
be
to
not
be
useful.
This
can
be
of
great
value,
and
then
we
have
many
simulators.
Of
course
everybody
knows
gazebo
and
ignition,
but
we
also
have
plenty
of
simulators
which
are
based
on
game
engines.
We
have
Carla,
which
is
based
on
unreal.
We
have
autoware
all
Sim,
so
outdoor
simulator,
based
on
Unity
3D.
E
E
It's
always
a
little
bit
of
a
different
problem,
but
also,
as
it
turns
out,
for
simulating
sensors,
there's,
there's
matching
common,
which
can
be
abstracted
into
a
common
Library,
so
why
game
engines
are
used
so
often
it's
because
of
performance.
Often
that's
the
major
major
issue
with
other
types
of
simulators
and
also
with
gazebo,
especially
where
we
have
large
areas
to
simulate.
E
So,
of
course,
we
are
looking
at
some
use
cases
which
deal
with
many
robots,
for
example,
autonomous
cars
equipped
with
sensors
that
are
quite
performance
demanding
and
if
it
needs
to
happen
in
real
time
as
well,
many
strong,
even
strong,
desktops
can
be
challenged
by
by
such
performance
needs.
So
these
setups
that
actually
pose
this
Challenge
and
make
discussion
about
what
Hardware
is
good
for
a
simulation
platform.
You
know
these
are
quite
common.
E
Actually
and
large
performance
is
not
just
kind
of
user
experience,
but
it
also
makes
simulation
less
useful.
You
can
always
use
this
real-time
Factor,
if
it's
available
for
your
solution,
but
yeah,
it's
it's
degrading.
How
fast
you
can
process
things,
how
how
fast
you
can
validate
and
so
on
so
acceleration
matters
and
for
lidar.
We
will
talk
about
our
solution,
open
source
solution,
which
has
been
just
released
and
presented
already
at
roscom
in
Kyoto.
E
A
good
example
of
this
performance
issue
is
comparing
our
library
to
another
open
source.
Lidar
simulation,
it's
a
bit
apples
to
oranges.
So
it's
a
very
light
comparison
because
of
also
different
features
and
different
approach,
but
we
have
1000
1000
times
more
Rays
per
second
than
the
other
solution,
so
Robotech
GPU,
lidar,
a
nice
race,
trade,
race,
Trace
logo
by
alcoholic
and
some
features.
What
are
we
looking
at?
We
are
looking
at
a
library
which
is
c
c
bass.
E
It
has
a
c
API,
so
it's
quite
easy
to
buy
and
plug
in
into
different
simulators.
It's
Apache
2.0
it's
for
Linux
and
windows.
Why
Windows?
Because
these
game
engine
simulations,
they
are
typically
better
running
better
at
windows
and
people
make
advantage
of
this.
You
know
running
this
simulation
on
Windows
and
robotic
stack
on
Linux
right.
So
this
can,
of
course,
Network
send
the
data,
and
sometimes
it's
the
case
that
that
this
is
needed.
E
E
You
have
this
diagram
here
that
visualizes
so-called
Pipelines,
it's
quite
modular.
In
a
way
you
can
compose
the
computational
pipeline
and
determine
what
kind
of
pre-processing
post-processing
you
want
to
have.
So
you
you
can
decide,
you
don't
want
to
visualize
or
you
want
to
save
the
data
to
your
to
your
PCD
file.
For
example,
you
are
using
it
to
prepare
a
map
of
environment
right,
so
you
would
like
that
you
can
even
determine
that
you
want
to
publish
this
to
our
roster
topic
right
away.
E
So
we
don't
want
to
return
this
data
to
the
simulation.
Then,
then,
again,
you
know
publish
it.
You
want
to
save
some
performance
here
and
publish
already
using
the
library.
So
this
is
quite
useful.
The
feature
with
Ross
to
integration
is
already
in
current
version
for
Ubuntu
for
Linux
for
Windows
we
have
a
kind
of
fix
that
is
actually
a
patched
to
RCL
CPP.
E
E
E
Even
what
we
did
was
reply,
replaying
actual
firing
pattern
recorded
from
a
device,
so
so
exactly
the
firing
pattern,
which
was
you
can
determine
how
large
of
a
sample
you
want
to
use
and,
for
example,
have
a
file
of
80
something
megabytes
as
a
as
we
did
right,
which
only
saves
the
pattern
and
then
yeah
the
bottom
left.
One
I
think
it's
it's
quite
beautiful.
It
shows
the
performance
and
you
can
notice
this.
These
are
automotive
use
cases.
You
know
there.
E
C
C
E
Is
always
an
issue
when
you
are
streaming
something
that's
supposed
to
be
running
smooth
and
you
want
to
demonstrate
that
it's
running
smooth
right,
because
the
streaming
itself
make
it
make
it
appear
not
so,
but
under
the
link
you
actually
can
see,
this
gives
operational
and
you
can
use
the
repository
itself
and
reproduce
this
all
right.
So
we
have
some
examples.
We
already
have
plugin
for
all
Sims,
so
we
started
with
autoware
for
these
who
do
not
know
what
outdoor
is.
E
This
is
the
largest
open
source
roster
based
stack
for
self-driving
vehicles,
so
so
we
are
all
also
a
part
of
it,
and
this
is
where
it
comes
from.
But
aside
from
these
examples
that
you
so
we
are
also
working
in
different
fields
of
application
of
Robotics
and
you
here
you
can
see
a
nice
image
from
apple
orchard
use
case
which
we
actually
presented
as
a
demo
and
it's
available
as
a
demo
also
online.
E
So
here
we
are
integrating
Robotech
GPU
lighter
as
a
plugin
into
all
3de
open,
3D
engine,
and
we
have
some
nice
screens
also
from
real-time
operation
in
our
Sim,
as
well
as
application
where
it's.
Actually,
it
has
been
used
to
produce
this
nice
Point
cloud
map
and
then
what's
the
current
plan,
we
would
like
to
add
intensity.
We
have
interest
in
machine
learning
data
and
we
want
to
pursue
how
our
intensity
channel
can
be
used
to
improve
detectors.
There
is
much
unresearched
area.
E
We
are
preparing
preparing
two
plugins
which
will
be
available
shortly,
so
all
3D
plugin
it's
in
works,
it's
expected
already
by
the
end
of
the
year.
So,
quite
soon
there
is
a
thing
like
all
3D
Ross
to
gem,
which
it
plugins
into
basically
it's
an
game
engine
which
is
open,
source
right
and
it's
available
for
robotic
simulation.
So
we
target
it
because
we
believe
it
will
be
impactful
in
the
future
and
then,
of
course,
gazebo
plugin,
which
I
think
could
be
quite
impactful
for
Community
as
well.
E
E
So
summarizing
you
can
find
I
will
share
this
presentation,
of
course,
and
you
can
find
useful
links
here
to
the
GitHub
repo
story,
or
we
also
described
this
on
our
blog.
You
can
expect
plugins
to
come
soon.
We
are
also
cooperating
with
a
couple
of
people
from
gazebo
and
we
would
love
to
have
your
feedback
and
feature
suggestions
and
would
love
to
have
this
become
also
a
part
of
Robotics
community
and
to
to
have
contributions
actually
right-
and
that
concludes
my
presentation.
E
A
Was
fantastic?
Thank
you
so
much
Adam
and
Peter.
This
is
this
is
very
exciting
and-
and
let
me
just
make
a
quick
comment
by
saying
that
this
fits
perfectly
fine
with
this
working
group
when
we
we
created
this
working
group
way
more
than
a
year
from
now,
we
did
Define
the
mission
as
driving
the
creation,
maintenance
and
testing
of
Hardware
acceleration.
It
was
to
Placebo
and
and
by
that
we
wanted
to
Embrace,
robotic
operating
systems
with
us
and
assimilation
with
casibo.
A
So
a
definitely
very
fitting
I
would
say-
and
hopefully
some
of
us
will
have
a
chance
to
get
a
look
at
this
and
and
do
fulfill
that
that
ask
that
you
just
made
about
contributions
and
comments.
So
super
exciting
I
do
have
one
question,
but
any
questions
from
from
any
of
you
guys
about
this
or
the
previous
discussion.
E
So
basically
we
are.
This
is
based
on
Cuda
and
Optics.
So
it's
an
implementation
Choice,
which
you
know
it's
it's.
It
will
be
quite
a
lot
of
work,
I
guess
to
support
other
architectures,
but
correct
me
if
I'm
wrong.
This
is
this
is
a
choice
to
kind
of
get
the
most
of
performance,
but
you
kind
of
need
to
I
need
to
have
this
device,
so
I
think
it.
E
C
D
A
But
for
those
of
you
are
interested,
particularly
in
Thailand,
you
asked
on
poor
English
to
other
platforms
living
aside
Optics,
which
is
a
bit
of
a
different
thing,
but
on
the
Cuda
side,
actually,
you
may
find
that
some
other
Frameworks
for
Hardware
acceleration
can
can
ingest
Cuda.
Currently,
for
example,
amd's
rokem,
which
is
the
framework,
has
historically
a
way
to
ingest
Cuda.
A
So
you
can
actually
leverage
the
same
piece
of
code
that
you
may
run
on
Nvidia
gpus,
also
in
in
AMD
gpus,
while
leveraging
the
same
piece
of
Cuda
code
again
again.
Leaving
aside
the
Optics
thing,
which
is
yet
a
different
discussion,
but
at
least
part
of
the
work
is
is
pretty
much
at
rest
already
so
yeah,
a
good
starting
point,
I,
would
say.
A
That
is
the
objective
of
this
group
yeah.
Hopefully
that
happens.
I'll
definitely
keep
that
in
mind
and
try
to
forward
the
AMD
guys
to
to
speak
with
you
guys
that
that's
gonna
happen.
Hopefully
something
Sparks
in
here
good.
So
maybe
a
quick
question
from
my
side,
but
to
you
guys,
Peter
and
Adam
you,
you
shared
some
data
regarding
the
capabilities
you
have
obtained
based
on
the
introduction
of
Hardware
acceleration,
you
have
any
CPU
Baseline.
A
E
So
so
this
is
a
complex
question,
as
all
of
you
quite
well
known,
so
it's
no
matter
how
how
things
are
compared.
You
know
they're,
if
you're
trying
to
sell
something.
You
can
always
pick
access
of
comparison
that
make
your
product
look
better.
We
kind
of
try
to
avoid
that
I
made
just
one
comparison
to
another:
open
source,
CPU
lighter
solution,
but
I
I
I,
said
that
this
very
these
are
different
libraries
realize
kind
of
different
things.
E
The
comparison
was
like
we
can
simulate
1000
times
more
Rays
per
second,
which
is
a
huge
number.
However,
of
course
this
is
not
the
same
process,
not
the
same
output
and
so
on,
and
you
know
it
would
be
unfair
to
kind
of
stop
there
for
for
comparisons
we
are.
We
did
kind
of
compare
early
with
the
GPU
lighter
in
gazebo,
the
one
that
that's
there,
so
we
are
faster,
but
you
know
it's
kind
of
again.
E
It
would
be
great
to
to
have
this
in
a
with
a
methodology
with
a
proper
several
platforms
and
so
on,
and
so
on
right
now
to
to
avoid
any
kind
of
bias,
and
it's
it's
always
again,
not
about
performance,
because
these
are
different
things.
Gazebo
plugin
uses
depth,
camera
and
not
raycasting,
which
is
a
very
different
approach.
So
you
know
in
terms
of
geometries,
in
terms
of
like
360
degree,
a
lidar
simulation,
so
you
have
four
depth
cameras.
E
There
is
kind
of
lack
of
smoothness
in
the
solution
where
we
have
right
pricing-
it's
you
know
it
looks
better
and
so
on
you.
So
we
can
discuss
this
kind
of
soft
features.
Aside
from
you
know,
hard
numbers
and
comparison
is
quite
complex,
I
would
say,
but
we
have
comparisons
which
are
based
on
physics,
Engine,
recasting
versus
GPU
array
casting
again
yeah.
This
is
like
not
as
big
as
the
Helios
example,
but
also
at
least
an
order
of
magnitude.
E
E
A
D
Hey
hi
Adam,
so
I'm
not
sure
whether
even
my
question
is
correct
or
not
so
I
just
wanted
to
understand
like
have
you
measured
like
the
accuracy
or
like?
Is
it
functionally
correct
the
simulation
or
like
because
in
the
environment
like
how
close
like
the
points
are,
so
how
is
the
actual
data
coming
so
do
you
have
that
data
also
measured
that.
E
So
this
is
again
a
very
complex
question,
because
if
you,
if
you're
asking
about
realism
of
so
so
one
big
framework
question
is
realism
of
simulation
of
anything
right
and
you
can
ask
about
how
realistically
would
this
simulation
represent?
You
know
the
actual
sensor
given
these
and
these
and
these
conditions
of
weather,
whatever
whatever
whatever
and
and
there
are
many
factors
right
so
so.
E
We
have,
for
example,
noise
statistical
noise
models
which
are
not
per
device
or
specific
noise
models
which
can
be
determined
by
studying
or
outputs
of
device.
We
do
not
have
influences
of
weather
and
so
on.
So
we
don't
simulate
the
physics
of
diffraction
and
so
on,
but
Ray
raycasting
is
I
would
say,
has
much
more
potential
than
the
depth
camera
right.
E
So
so,
if
you're,
comparing
which
one
it
can
be
better
used
for
actual
simulating
actual,
lighter
behavior
and
then
array
casting
has
has
an
upper
edge
here.
But
of
course
there
are
different
kinds
of
simulation
in
Industry.
If
you
want
exact
physical
simulation
of
how
things
happen,
you
typically,
you
won't
get
real
time
anytime,
soon,
like
even
with
a
very
small
kind
of
sensors.
E
So
from
my
experience
for
simulation,
you
want
it
to
provide
value,
so
you
want
only
to
be
realistic
enough
as
to
actually
inform
you
about
the
behavior
of
your
robotic
stack.
So
what
you
are
trying
to
validate
here
right,
you
don't
need
to
be
any
more
realistic
than
that
than
to
provide
plenty
of
value.
E
F
I
just
wanted
to
I,
don't
want
to
focus
on
the
RTX
but
and
the
Nvidia
environment
itself.
Are
you
maybe
planning
to
to
try
that
with
with
igpu
instead
of
D3
GPU,
because
this
great
GPU
in
general
you
need
like
a
Abyss
or
from
from
Nvidia
side,
you
have
a
chloridex
or
Hollow
scan
and
then
we
need
to
use
like
quite
not
easy
to
have,
and
my
question
is:
are
you
planning
to
use
the
igpu
at
some
point
from
the
Nvidia
like
platforms.
C
E
B
F
No
worries,
thank
you
very
much.
Do
you
need
a
specific
like
Coda,
like
version
with
the
old
dependency
with
the
GPU,
because
in
with
RTX
Nvidia
release
the
open
RM
driver,
this
is
open
source
and
then
you
don't
have
the
same
features
as
the
property
code.
Then
maybe
you
need
to
be
careful
here,
but
I.
E
A
A
Regarding
the
polls
that
happened,
data
will
be
anonymized
and
we
will
share
the
results
of
those
in
the
corresponding
ticket
of
this
meeting
which
all
right
in
the
discourse
thread
of
this
meeting,
which
I
believe
is
this
one
that
I
just
shared
in
the
chat
and
yeah
I.
Think
that's,
that's
pretty
much
it
any
any
final
comments
from
everyone.
Otherwise,
I
wish
everyone
a
very,
very,
very
happy
rest
of
the
year
and
we'll
meet
next
year.