►
From YouTube: ROS 2 Hardware Acceleration Working Group - meeting #14
Description
14th meeting of the ROS 2 Hardware Acceleration Working Group (HAWG).
We reviewed the progress made over 2022, reported on the current status of the group activities, and discussed our goals for 2023. We also touched on the strategic projects spearheaded by the Working Group including RobotPerf, Robotics MCU (robo-v-mcu) and the Robotics Processing Unit (RPU).
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
03:24 2022 progress review and dissemination report
10:14 Updates on Robotics MCU project (robo-v-mcu)
17:08 Updates on RobotPerf, robotics computing benchmarking suite
27:36 WG goals for 2023
29:47 Q&A
For more including commercial support on hardware acceleration topics in robotics, refer to https://accelerationrobotics.com.
A
A
Right,
fantastic,
thank
you!
So
hoping
everyone
had
a
fantastic
start
of
the
2023
year.
The
the
working
group
ended
up
last
year,
mid-December
with
last
meeting
that
was
successful,
we'll
be
discussing
today.
Some
of
the
results
obtained
last
year,
we'll
also
be
touching
on
some
updates
regarding
some
of
the
Strategic
projects
that
are
being
driven
by
the
working
group
and
that
will
include
a
small
update
that
includes
the
robotics
MCU
or
the
robot5
project.
That
is
a
collaboration
between
acceleration,
Robotics
and
plan
B.
A
So
we
have
Max
today
with
us
who
will
be
reporting
a
bit
on
on
What's
the
progress
there
and
finally,
we'll
touch
slightly
on
what
new
goals
for
the
working
group
for
this
upcoming
2023.
These
goals
are
not
set
in
stone.
I
asked
for
feedback
in
the
community
so
far
hasn't
haven't
gotten
lots
of
it,
so
do
feel
free
to
send
that
feedback
either
in
here
or
offline
again.
The
the
notes
minutes
for
everyone
to
come
in,
but
also
my
email
and
our
contact
is
always
open.
A
So
with
that,
let's
get
started
with
a
couple
pieces
of
news
which
I
think
are
worth
mentioning.
The
first
one
is
the
first
as
far
as
I
know:
Meetup
lost
developers
in
India.
This
was
successfully
organized
by
part
of
our
team
and
acceleration
robotics
in
Pune.
It
was
driven
by
pratik,
nagaras
angara.
A
They
did
a
fantastic
job
and
they
had
dozens
of
Ross
developers
in
India
and
as
far
as
I'm
hearing,
it
was
not
only
exciting
to
quite
a
bit
of
networking
and
business
opportunities,
so
encouraging
and
giving
kudos
to
garab
and
pratik,
and
also
mentioning
that
I
do
believe.
This
is
going
to
continue
and
keep
up.
So
if
you're
interested
in
the
Ross
community
in
India,
you
may
want
to
show
interest
and
being
maybe
pratikandarap,
who
are
part
of
the
working
group
as
well.
A
Now
that's
the
first
piece
of
news
as
a
second
piece
of
news,
I've
been
told
to
share
and
I'm
really
excited
to
do
so
that
there's
an
upcoming
robotics
competition
with
the
subject
of
Robotics
and
embedded
artificial
intelligence
around
adaptive,
Computing,
so
fpta
system
on
chips,
that's
going
to
be
running
in
HEX.
There
tell
us
links
and
announcements
will
come
up
very
soon,
I've
been
told.
This
will
get
posted
also
in
browse
this
course.
A
So
stay
tuned
and
I
very,
very
much
I
recommend
to
pay
attention
to
this
competition.
There's
gonna
be
free
boards.
There's
gonna,
be
a
nice
competitive
landscape
to
show
your
capabilities
for
building
robot
applications
and,
of
course,
Ross
will
be
at
the
center
of
everything.
So
stay
tuned
for
more
super
excited
to
be
reporting
on
this
now
with
all
of
this,
and
people
are
still
joining
the
meeting
we're
past
the
40.
A
five
person
Mark
already.
Let's,
let's
discuss
slightly
the
first
topic,
because
we
only
have
30
minutes
this
time,
and
the
first
topic
is
the
report
that
we
cooked
based
on
the
activities
last
year.
This
report
was
disclosed
both
in
was
this
course
as
well
as
in
a
ticket
within
the
Ross
acceleration
GitHub
organization.
A
A
A
The
year
is
listed
first,
you
can
see
that
we
pretty
much
achieved
everything
except
a
couple
of
goals
that
we
we
set
on
ourselves
last
year
and
we
were
pretty
ambitious
last
year.
I
must
admit,
but
still
the
goals
that
weren't
achieved
were
for
good
reasons.
I
would
say
the
first
one
we
didn't
manage
to
merge,
Hardware
acceleration
kernels
into
Upstream
packages.
A
So
maybe
they
are
just
busy
and
they
didn't
have
enough
time
to
dedicate
initiative.
So
this
failed
in
2020
retry
in
the
future.
So
do
a
stay
tuned
for
this
again,
the
work
is
done.
We
just
need
to
find
consensus
consensus
on
how
to
integrate
these
in
Upstream
packages.
Still
this
lives
in
a
fork
right
now,
which
remains
API
compatible
and
simplifies
integrating
Hardware
acceleration
in
your
computational
grass
from
a
perception
perspective
that
didn't
meet
our
expectations.
A
But
similarly
we
failed
to
organize
workshops
and
Robotics
on
Ross
to
Hardware.
Acceleration
and
I
must
admit.
I'm
totally
guilty
on
this
I
decided
pretty
much
last
minute
to
not
call
for
a
workshop
during
Roscommon,
because
there
were
lots
of
variables
in
Japan
this
year,
lots
of
organizational
things
to
take
into
account
with
copy
related
matters
and
related.
So
we
decided
to
postpone
this
and
neither
do
it.
We
might
do
it
in
upcoming
years,
so
definitely
something
also
that
we
might
rescue
on
the
road.
A
The
rest
of
it
was
pretty
much
accomplished.
There
is
still
a
work
in
progress
and
we'll
discuss
the
goals
for
next
or
for
this
year
soon
after
after
this
now
really
really
quickly
just
to
set
the
context
how
far
this
group
is
growing,
there
was
two
Hardware
acceleration
working
group.
Right
now
is
I
think,
arguably
the
biggest
working
group
in
the
robotics
Ross
to
community
purely
based
on
attendance
matters.
We
are
already
50
persons
today
and
we
have
meetings
wherein
we
got
really
close
to
100
persons.
A
We
have
lots
of
persons
viewing
our
recordings
offline
and
we
have
hundreds
of
subscribed
participants
on
every
meeting
in
the
announced
goals.
So
definitely
definitely
lots
of
interest
in
Hardware
acceleration
and
gpus
and
fpgas
super
exciting.
To
put
some
numbers
to
this
excitement.
We
have
grown
from
2021
more
than
3.7
times
at
least
outreach-wise,
so
the
amount
of
robot
assists
that
we
have
impacted
are
actually
accounted
Beyond.
One
million-
and
you
can
see
details
about
this
as
well
as
the
one
delivered
for
2021
in
again.
A
In
the
community
repo
of
the
working
group,
so
this
is
the
one
that
we
discussed
in
2021,
which
includes
all
details,
and
this
is
the
one
that
we
disclosed
earlier
in
January
for
2022
and
in
here
you
also
have
essentially
the
biggest
and
most
relevant
items
that
we
track.
There's
many
many
more
dissemination
and
communication
effort
that
we
just
don't
track.
A
So
the
impact
is
significantly
higher
than
what
we
are
reporting
in
here,
but
still
we
believe
that
for
a
humble
working
group
in
the
roster
Community,
reaching
out
about
a
million
robotices,
very
significant
numbers
so
great
to
know
Dave
is
that
you're
happy?
So
so
we
are
to
have
you.
Thank
you
so
yeah
that
is
for
setting
the
context
and
with
that
I
think
I
think
we
can
jump
into
the
next
topic.
A
Maybe
just
a
few
words
about
the
fact
that
another
great
success
that
I
think
we
achieved
as
our
working
group
is
the
fact
that,
thanks
to
our
work
together-
and
especially
thanks
to
those
of
you
who
voted
in
December
in
the
last
meeting,
finally,
we
got
approved
rep
2008.
So
this
is
as
of
now
the
first
robotics
standard
in
the
world
stream
community
that
defines
how
Hardware
acceleration
should
be
introduced
into
robotic
architectures
in
a
in
a
vendor,
neutral,
scalable
and
Technology
agnostic
manner.
A
So
this
paced
a
way
for
future
growth
in
a
vendor,
neutral
manner,
setting
down
some
Fair
rules
for
the
game
so
that
there
is
no
login
as
it
happened
in
other
areas
such
as
AI,
wherein
has
we
know
certain
GPU
vendors
essentially
got
overly
powerful,
so
we
are
very
much
looking
forward
to
see
how
this
can
grow
into
more
and
more
Norms,
more
and
more
standards.
We
are
working
on
a
few
more
on
our
side
and
I
definitely
encourage
people
to
keep
up
with
the
activity.
A
A
A
We
are
pretty
much
about
to
close
the
phase
number
two
and
then
we
will
dive
into
the
more
firmware's
last
software
layers
for
a
first
demonstrator
and
the
initial
Target
was
to
demonstrate
this
risk:
5
native
rtps,
interoperability,
capabilities
by
Irwin,
I,
sorry,
iron
airwinning,
which
is
May
2023.
So
that's
the
next
release
of
roster.
C
C
Just
for
you
for
information,
the
version
of
the
clicks
is
the
Core5
SDK,
which
you
can
download
on
the
open,
Hardware
group
download
page-
and
here
there
are
the
links
to
the
hardware
project.
It's
the
Core5
MCU
project
in
our
organization.
It
is
a
fork
of
the
open,
Hardware,
Core5
and
CEO
project.
We
are
developing
under
the
robo
5
MCU
branch
and
in
this
other
project
here
in
this
repository,
the
robot
5
MCU
demo.
C
C
So
if
the
project
gets
compiled,
open
OCD
is
connecting
to
the
risk
5
Core
on
the
board,
so
it
is
connected
now
and
we
are
ready
to
start
the
execution
of
the
program
here
at
the
play
button
and
if
I
see
here,
this
is
a
minicom
interface.
So
this
is
just
as
I
mentioned
in
hello
world
proof
of
concept
of
that
the
software
is
running.
C
And
basically,
it
is
interesting
because
there
is
the
free
artos
running
underneath
this
demo.
We
are
using
making
use
of
the
of
the
all
of
the
features
which
are
reasonable
for
for
such
a
simple
showcase,
so
we're
using
interrupt
and
and
similar
and
similar
features
yeah.
This
is
pretty
much
what
I
wanted
to
show
today
and
I'm
open
to
answer
your
questions,
whether
you
have
any.
A
A
Thank
you
so
much
for
giving
that
demo.
We
love
demos,
I
think
everyone's
afraid
in
robotics
to
give
demos
so
I
encourage
everyone
to
give
demos.
Please
fantastic
report
on
the
progress
and,
and
just
in
case
in
case
it
wasn't
obvious.
What
Max
has
shown
is
how
essentially,
within
the
fpta
there
is
a
soft
core
synthesized,
that's
at
least
five,
so
of
course
synthesized,
and
he
is
programming
it.
A
The
the
sorry,
the
the
soft
core
has
free
artos,
real-time
operating
system
inside
and
Max
has
shown
how
he
has
programmed
it
with
that
simple
program
that
hello
world,
and
essentially
this
is
the
Cornerstone
we
are
now
using
to
move
into
more
and
more
stages
right
now,
Max's
team
is
working
towards
integrating
an
Ethernet
block
so
that
we
can
have
communications
directly
from
this
risk.
5
Core
into
a
ross2
network,
direct
ones,
and
that's
going
to
be
an
exciting
next
move,
which
you
will
hear
from.
A
A
If
you
have
any
opportunities
that
you'd
like
to
exploit
with
him
directly,
okay,
so
going
back
into
the
minutes,
yeah,
oh
there's
someone
joining
welcome
so
going
back
into
the
minutes
and
again
just
for
the
sake
of
everyone
pasting
the
minutes
in
the
chat
so
that
you
can
follow
on
your
own.
The
next
thing
up
is
the
updates
on
the
robot
perf
robotics,
Computing,
benchmarking,
Suite
and
I'm,
happy
to
report
that
there
are
new
resources
available.
We
have
posted.
Finally,
an
update
again.
A
The
robot
first
project
is
accessible
in
this
URL
that
we
are
maintaining
it's
all
based
on
static
content,
hosted
in
GitHub.
So
thanks
GitHub
for
that
and
do
feel
free
to
send
contributions
if
you
catch
any
issues,
of
course
now
what
what
matters
right
now
is
the
fact
that,
besides
that
flashy
new
domain
and
website
there's
a
new
specification
that
we've
pushed
so
please
go
through
it.
A
So
the
source
code
of
Robert
birth
is
now
being
increasingly
completed,
so
you
can
now
have
a
sneak
peek
or
a
preview
into
the
first
implementation
of
the
benchmarks.
This
is
particularly
one
we'll
be
touching
on
today,
two
node
perception
example,
but
in
addition
to
that
one
we
created
another
repository
called
Ross
packs,
which
are
going
to
be
Rose
packs,
which
will
be
used
to
fit
and
and
execute
benchmarks
in
a
fully
reproducible
manner.
That
is
the
intent,
and
so
every
single
Benchmark
will
always
be
referring
to
a
particularly
a
particular
rosback.
A
Sorry,
so
that's
those
are
new
resources
for
you
to
consider.
Now,
as
an
ass
to
the
working
group
to
you
all,
please
do
review
your
specification.
I
pointed
you
to
there's
lots
of
Interest
information
in
there,
so
for
those
of
you
willing
to
try
this
out
I'm
happy
to
report
that
I
created
here
a
ticket,
sorry
there's
there
was
an
issue
and
I
know
we
discussed
this
before
the
meeting
Raisa
was
was
leading
this
efforts.
He
tested
things
out.
She
found
an
issue
and
reported
about
it.
A
So
hopefully,
those
issues
are
addressed
and
again,
I
I
took
the
liberty
of
closing
the
ticket
after
I
addressed
it,
but
do
feel
free
to
reopen
in
case
you
disagree
with
me
that
that's
perfectly
fine
and
we
can
iterate
as
many
times
as
needed
now
what
I
wanted
to
show.
You
is
this
effort
that
I
pushed
actually
a
few
hours
ago,
which
report
on
the
execution
of
this
first
Benchmark
in
our
internal
CI
CD
infrastructure
for
the
particular
case
of
an
Intel
x8664
workstation.
A
So
this
is
not
an
edge
device
or
an
embedded
platform,
which
is
just
in
my
Workstation
and,
as
you
can
see,
this
is
the
form
you
should
expect
data
to
be
reported
on.
So
we
will
have
the
ID
of
The
Benchmark,
the
computational
graph
that
yeah
probably
wrong
path.
Let
me
fetch
that,
for
you
guys
real,
quick,
the
computational
graph
once
again
here
it
is.
A
This
is
the
computational
graph
that
we
are
considering
in
here
for
this
case.
So,
as
you
can
see
in
this
context,
what
is
what
is
in
this
namespace
Benchmark
is,
what's
being
benchmarked
actually,
and
you
can
see
how
we
have
an
input
component
and
an
output
component.
Actually
they
are.
They
are
components,
technically
speaking,
so
not
nodes,
but
everything
uses
intra-precess
communication,
so
components,
and
then
we
are
benchmarking.
The
data
flow
that
goes
from
the
input
topic
all
the
way
into
the
output
component.
A
So
you
can
see
how
we
can
get
out
of
these
scripts,
not
only
the
trace
files
and
the
trace
information,
but
also
automation,
to
generate
these
fancy
plots
in
particular
in
here
you
can
see
the
the
stack
of
rust
to
each
one
of
the
trace
points
plotted
in
a
somehow
Tower
manner,
so
that
you
can
see
where
most
of
the
time
goes
and
we
we
are
doing
this
for
one
instance,
for
a
number
of
instances,
calculating
the
mean
values
and
also
the
maximum
one.
Again.
This
is
robotics.
A
We
are
interested
in
the
maximum
value
because
Robotics
are
real-time
systems
and
for
real
time
we
care
about
meeting
the
deadline.
So
worst
case
scenario
is
what
we
should
be
mostly
looking
at.
We
can
also
plot
things
in
this
other
way
where
you
can
see
in
multiple
Dimensions
how
the
data
flows
across
the
various
layers
in
the
ros2
stack.
So
there
was
middleware
layer,
there
was
client,
Library
layer,
RCL,
CPP
and
also
user,
and
then
there's
the
layer
of
the
Benchmark.
We
are
technically
measuring.
A
We
might
add
new
layers
in
the
future,
as
we
use
more
and
more
accelerators,
so
stay
tuned
to
that,
and
finally,
also
out
of
the
Benchmark
effort
and
through
some
of
the
scripts
provided
and
disclosed
already,
you
can
see
how
we're
getting
data
that
then
we
can
use
to
report
on
the
actual
measurement
collected.
For
now
again,
we
are
reporting
on
maximum
values.
A
We
may
add
a
bunch
of
that
to
the
reports
in
the
future,
but
I
think
for
now.
I
just
want
to
use
one
value
to
keep
it
simple.
One
thing
for
everyone
to
consider
is
that
I
have
encountered
significant
amount
of
issues
using
fast
DDS,
BDS
implementation.
I
I
spend
lots
of
hours
trying
to
come
up
with
a
workaround
trying
to
still
leverage
fast,
DDS
and
finally,
Frankly
Speaking
I
had
to
give
up
I
have
reached
out
actually
in
this
course
as
a
follow-up
to
a
Proxima.
A
Hopefully
they
can
react
to
this
and
they
can
help
out.
But
right
now
we
are
using
Cyclone
DDS
and
we
will
be
using
Cyclone
DDS
strictly
to
conduct
benchmarks
because
it
seems
to
be
the
most
reliable
implementation
right
now.
This
may
change
down
the
road
hopefully,
but
we
will
need
some
contributions
from
a
Proxima
and
the
fast
DDS
company,
I
I
believe
so
again.
This
is
regarding
the
preliminary
results.
A
Next
up.
So
what's
coming
next,
because
right
now,
you
can
literally
go
into
the
repository
and
reproduce
this
same
thing
in
your
work
stations
and
or
in
your
own
Edge
targets.
So
what
is
missing
right
now
in
robot
curve
to
start
scaling?
Of
course,
we
are
missing
lots
of
benchmarks,
so
feel
free
to
start
understanding
the
methodology
and
to
propose
your
own
benchmarks.
A
But
besides
that,
we
also
believe
that
we
are
missing
the
tools
required
to
add
new
data
in
a
somewhat
simplified
manner,
especially,
we
are
running
most
of
our
stuff
in
external,
continuous
integration
systems,
so
we
will
probably
make
an
effort
to
develop
some
CLI
tooling.
That
allows
you
to
list
the
available
benchmarks
and
also
add
additional
data
for
you
to
keep
in
mind
each
one
of
the
benchmarks.
A
For
example,
A1
is
a
start
on
its
own
directory
of
the
repository
and
then
what
matters
in
here
is
there
is
here
a
benchmark.yaml
file,
and
this
readme
you
can
see
in
here
actually
is
auto
generated
from
the
yaml
file.
This
yaml
file
is
what
needs
to
be
updated
if
you
want
your
results
to
somehow
get
disclosed
and
persist
in
The
Benchmark
reference
Suite
in
a
way,
so
what
you
would
need
to
do
is
send
a
pull
request
that
changes
and
adds
the
corresponding
results
for
your
own
experiment.
A
To
this,
and
as
you
can
see,
the
format
is
super
simple.
So
there
is
a
well-defined
format.
That's
actually
described
in
the
specification
that
I
asked
everyone
to
review.
So
it's
describing
here.
There
is
a
section
in
here
about
general
concepts
and
particularly
about
creating
a
new
Benchmark
and
how
you
should
describe
it
so
keep
an
eye
on
those
benchmark.yaml
files
which
are
part
of
each
one
of
their
boss
packages
and
also
keep
an
eye
on
the
extensions
we
will
hopefully
contribute
soon.
A
I
don't
want
to
commit
for
the
next
meeting,
but
maybe
which
will
add
yet
new
Ros
packages,
particularly
Benchmark
extension
to
the
Ross
to
CLI,
so
that
you
can
do
Ross
to
Benchmark
whatever
and
that
whatever
will
come
in
the
sense
of
subverbs
that
allow
you
to
list
benchmarks
to
add
value
to
Benchmark,
so
that
you
don't
need
to
deal
directly
with
these
yaml
files.
Everything
should
happen
in
a
simplified
manner.
A
So
with
that
Automation
in
mind,
now,
hopefully
you
know
what
is
coming
next.
Also,
we
might
do
some
preliminary
work
also
on
building
minimalistic,
CI
CD
infrastructure
in
the
robot
perf
benchmarks,
repo
to
validate
that
each
one
of
the
benchmarks
at
least
Fields.
We
we
don't
want
to
overcome
it,
because
maintaining
cicd
infrastructures
are
big
commitments,
but
at
least
we
can
automate
the
process
of
validating
that
it
builds
that
should
that
should
be
manageable
for
us.
A
There
hasn't
been
any
major
updates
due
to
time
restrictions,
but
we
will
put
time
into
this
in
the
coming
weeks.
Months
now,
I
know
we're
almost
at
the
top
of
the
half
an
hour
allocated,
but
I
wanted
to
briefly
give
you
guys
a
heads
up
of
what
are
the
new
goals
for
this
year.
You
have
them
described
in
here,
but
roughly
roughly,
there's
four
major
topics:
I'd
personally
like
to
propose
that
we
focus
on
the
first
one.
A
That's
the
number
one
priority
I
believe
the
number
two
is
increasing.
The
amount
of
vendors
participating,
silicon
vendors
and
Hardware
manufacturers
coming
up
with
accelerators
I'm,
very
much
pushing
for
getting
more
and
more
vendors
to
participate
and
we're
being
successful.
So
this
is
making
the
group
greater
and
making
our
activity
more
valuable
and
relevant,
so
stay
tuned
for
announcements
on
that
regard.
A
Third,
somewhat
connected
is
the
fact
that,
connected
also
to
the
Silicon
vendors.
There
is
an
increasing
amount
of
companies
that
want
to
leverage
Hardware,
acceleration
and
I
cannot
list
some
of
the
names,
because
some
of
these
discussions
are
ongoing,
but
I
can
tell
you.
There
are
some
big
names
in
the
roster
word
which
are
starting
to
build
on
top
of
our
work.
A
So
this
is
yet
another
reason
for
you
to
invest
your
time
in
this
working
group
to
contribute
to
get
involved
and
to
pave
the
way
for
what
I
personally
believe
is
going
to
revolutionize
robotics,
which
is
Hardware
acceleration.
So
this
is
something
we
will
put
efforts
on,
which
is
increasing
the
collaborations
with
industry
partners
and
the
adoption
and
embracement
of
what
we
have
created
and
pushed
forward
so
far.
A
Last
but
not
least,
the
Strategic
projects,
what
I've
been
discussing
on
the
problem:
5
MCU
project,
the
robot
perf
and
the
rpu
robotics
Processing
Unit
projects.
This
is
pretty
much
it.
What
we
had
sorry
for
the
extra
one
minute
and
for
those
of
you
that
want
to
stick
around
happy
to
take
a
q,
a
now
for
everything
that
we
discussed,
including
Max's,
demonstrator
and
or
any
suggestions
you
may
have
for
goals
for
this
year.
D
D
E
Go
ahead:
hey
so
I
just
wanted
to
mention
that
I
am
working
on
changing
the
infrastructure
of
rept
2014
as
to
I
forgot
his
name,
but
to
mention
that
it
should
be
in
a
way,
that's
more
similar
to
other
Ross
reps.
So
I
am
tackling
that.
If
anybody
is
also
interested
in
working
on
that,
just
send
me
an
email
ping
me
and
we
can
work
on
it
together.
A
E
A
That's
awesome,
thank
you
yeah,
so
so
I'll
make
sure
that
gets
at
it
and
maybe
in
the
next
call
we
can
have
a
short
discussion
around
this
and
you
can
drive
it
for
all
of
us,
but
that
is
just
let
me
say
thumbs
up
for
that
contribution.
I
haven't
had
the
time
to
look
at
it
and
Frankly
Speaking
I
think
this
rep
needs
fresh
eyes,
because
we
are
all
too
contaminated.
Writing
it.
So
I
think
your
blood
and
fresh
blood
in
here
is
gonna.
Be
super.
D
A
So
it
depends
very
much
of
which
parts
of
your
Edge
device
you
want
to
leverage.
Are
we
if
you
just
want
to
Leverage
The
HPS
and
the
hard
processing
system
or
the
PS,
the
processing
system,
aka
the
CPU
CPUs,
there's
nothing
you
need
to
do.
You
can
just
run
it
and
get
a
get
a
baseline
assets.
If
you,
however,
want
to
leverage
some
of
the
accelerators,
then
you
need
to
change
your
launch
file
into
one
that
somehow
captures
the
essence
of
your
accelerator.
A
Let
me
particularly
give
you
a
hint
towards
what
I'm
speaking
about
so,
for
example,
in
the
case
of
right
now,
the
A1,
which
is
the
only
Benchmark
available
again,
we
just
needed
one
for
demonstration
purposes.
You
can
reproduce
it
with
instructions
that
you
have
in
here
and
the
CPU
just
directly.
You
will
have-
and
you
can
note
that
essentially
it
goes
all
the
way
down
into
launching
this
launch
file,
which
is
living
right
under
here
right
now,
this
one.
A
Now,
if
you
want
to
launch
things
with
an
fpga
enabled
implementation,
which
is
going
to
split
the
computational
graph
into
CPU
and
fpga
acceleration
kernels,
then
you
need
to
change
your
launch
file
into
this
other
one,
and
so
what's
happening
in
here.
Is
that,
instead
of
launching
the
image,
proc
CPU
Centric
nodes,
it's
it's
launching
the
ones
that
come
from
essentially
from
the
image
pipeline.
Perception
stack
that
has
been
forced
and
enabled
for
fpga
capabilities.
So
that's
something
to
consider.
A
C
A
Yeah
I
would
just
I
will
just
quickly
just
checking
So
So,
eventually
Google.
Nevertheless,
we
will
post
somewhere
officially
the
amount
of
of
resources
split
by
by
type
of
resource,
meaning
the
loot
files,
the
flip
flops,
the
dsps
and
the
vrams
consumed,
but
but
yeah
I'm
sure,
I'm
sure
that
Max
and
and
his
team,
who
are
the
experts
on
on
risk
five.
A
Definitely
you
can
come
up
with
some
creative
ways
to
lower
the
the
use,
but
right
now
it
does
sound
like
we're
using
a
significant
amount.
If
you
Google
Elmore,
anyone
in
your
team
has
any
experience
with
alternative
risk.
5,
implementations
I
think
we
would
be
delighted
to
hear
maybe
other
opinions.
B
Oh
no
I
I
was
just
asking
in
the
sense
that
I
think
that's
a
great
work
because
I
saw
the
GitHub
it
has.
Different
interfaces
supports
APB
axi.
Whatever
interfaces
are
useful
for
an
MCU,
so
it
was
just
wondering,
but
yeah
no
I,
don't
think
that,
especially
if
you
want
to
create
a
silicone
piece,
you
can
go
lower
than
those
resources.
The
KR
260
is
not
a
big
device
so
that
that
is
fine
completely.
C
I
think
there
is
any
way
the
possibility
to
save
some
space
somewhere,
because
this
design
was
just
for
a
general
purpose.
Mcu
and
probably
we
don't
need
all
the
features
which
are
there,
so
there
is
room
for
for
saving
I'm,
quite
confident,
but
how
much
could
we
save?
It
is
a
bit
too
early
for
me
to
tell.
A
Yeah
I
I
agree
with
that.
Furthermore,
I
would
add
the
fact
that
we
are
still
missing
the
the
ethernet
piece,
the
RTL
ethernet
piece,
which
possibly
will
consume
more
resources,
but
but
something
I'm
personally
excited
about
is
how
this
this
working
prototype
is
going
to
lead
us
to
yet
maybe
take
this
step
forward
to
go
into
one
of
these
popular
fundrais
these
days,
which
seem
to
be
free
everywhere
and
maybe
manufacture.
A
A
few
Ross
native
microcontrollers
by
a
few
I
mean
maybe
I,
don't
know
a
few
dozens,
so
there
might
be
a
chance
actually-
and
this
is
something
Max
and
I
need
to
discuss
offline,
but
there
might
be
a
chance
that
maybe
each
one
of
the
members
of
the
working
group
might
be
able
to
get
their
hands
on
the
first
ever
ross2
processor.
It
will
be
an
microcontroller,
but
still
a
processor,
small
one,
so
yeah
this
is.
A
A
C
C
A
That's
what
I
was
looking
for
awesome,
so
I'll
get
this
pasted
guys
in
a
minute,
so
that
we
have
a
handy.
Thank
you
Max
for
for
passing
this.
This
is
super
useful
and
again
folks,
stay
tuned
for
updates.
We
will
continue
working,
please
reach
out
if
there's
any
further
ideas
that
needs
to
be
considered
and
other
than
that
have
a
fantastic
rest
of
your
day
or
night,
as
in
my
case,
I
think
and
yeah
stay
tuned
and
continue
contributing
to
Ross.