►
From YouTube: ROS 2 Security Working Group (2021-01-12)
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
All
right
thanks
so
yeah
today,
I'm
gonna
present
some
some
high
level
details
about
move
it
and
about
the
problems
about
securing
move,
address
and
communication.
So
move
it
at
this
point.
It's
definitely
not
not
secure.
So,
let's
see
what
what
can
go
wrong
with
move
it
and
how
exactly
we
might
be
able
to
secure
it
a
little
bit
more
so
first,
I
will
just
highlight
the
main
features
and
interfaces
that
move
it
provides.
This
is
not
an
extensive
list,
but
the
main
ways
how
to
interact
with
move.
A
A
So
well
in
general,
for
those
who
might
not
know
move
it,
it
is
an
open
source
framework
for
interacting
with
robots,
doing
motion
planning,
executing
motions
on
a
robot
interacting
with
sensors,
and
that
in
a
really
easy
way,
so
that
you
can
run
your
robot
on
a
remote
node.
For
instance,
using
move
group
run
it
in
your
own
c,
plus
plus
application
using
move
it
cpp
or
doing
online
comment
streaming
using
the
movid
server
interface.
A
Those
re-interface
down
here
interfaces
down
here
are
the
main
ways
to
interact
with
move.
B
A
And
those
three
are,
I
think,
the
most
important
ones
when
it
comes
to
securing.
B
A
It
versus
communication
as
well
so
the
move
interface
is
probably
the
the
oldest
interface
that
everyone
is
aware
of
and
has
already
played
around
with
when,
when
playing
with
move.
B
A
Here
you
see
the
arvis
motion
planning
panel.
You
can
drag
around
your
your
robot
and
effector,
and
the
robot
will
plan
and
execute
the
motion
depending
on
on
the
goal
state.
A
So
behind
the
curtains
there's
a
move
group
node
running,
which
is
a
single
node,
maintaining
the
robot
state,
the
the
scene,
which
includes
the
world,
the
geometry
in
the
scene
and
a
bunch
of
capabilities.
So
the
the
critical
parts
and
the
move
group
node
are
rust
control
interactions.
So
in
movie
two,
it's
using
rest,
two
control,
of
course,
so
they're
the
bunch
of
message:
interfacing
interfaces
providing
the
join
state
or
allowing
to
run
trajectories
or
position
commands.
A
Then
there
is
a
bunch
of
sensor
input
topics.
For
instance,
the
point
cloud
to
octa-map
perception
pipeline,
which
allows
just
feeding
on
a
collision
map
into
the
scene,
which
is
then
used
for
collision
checking
and
also
move
group
uses
tf
a
lot.
It's
it's.
It
allows
changing
the
scene
geometry
using
different
services
or
message
topics
and
it
allows
updating
the
joint
state
using
the
the
normal
joint
state
topic.
A
It
does
a
bit
more,
but
those
are,
I
think,
the
most
important
parts
of
the
movement
node
move.
B
A
Capability,
which
I
already
mentioned
here,
the
capabilities
a
capability
is
a
plugin
that
allows
running
actions
or
services
that
implement
certain
behavior
for
move
it.
So
the
most
common
used
one
is
the
move
group
action
which
just
provides
an
action
interface
for
planning,
motions
for
the
robot
and
executing
them
using
the
ros
control
interface.
A
So
it
is
basically
a
client
node
of
move
group
that
implements
all
the
actions
and
services
that
we've
got
provides
and
it
implements
the
default
capabilities
that
are
also
available.
Like
the
move
group
action
planning
scene
changes,
everything
that
moveco
provides
can
be
done
in
a
really
easy
way.
A
Using
the
move
group
interface,
it
is
also
possible
to
run
multiple
instances
of
those,
so
you
can
run
an
arbus
instance
with
a
move
interface
then
have
you
another
application
code
running
different
calls
on
the
move
group
node
from
from
remote,
and
this
will
all
work
really
fine
together,
but
it
adds
to
the
system
complexity.
A
Here
you
see
a
very
simple
draft
of
the
architecture
of
a
whole
movement
instance.
So,
on
the
left
side
you
have
the
user
interface
side,
which
basically
right
now
is
the
move
group
interface.
There
has
been
a
move.
C
A
Python
interface
and
in
ross
one,
but
in
mover
two
we
don't
have
it
ported
yet
and
then
there's
the
gui
rvs
plugins
that
allow
interacting
with
moveit
as
well.
Here
you
have
the
move
group
note,
with
a
bunch
of
classes
that
are
depending
on
rus,
providing
all
the
service
and
action
interfaces
to
interact
with.
A
Most
of
those
are
capabilities,
and
then
there
is
the
move
it
core,
which
wraps
all
the
features
that
move
it
has
like
collision
checking
planning
the
the
planning
scene,
everything
that
is
actually
doing
the
hard
stuff
is
implemented
here
and
is
accessing
mostly
to
plugins.
So
those
those
things
don't
really
use
for
us
a
lot.
The
only
rust
interactions
from
moved
core
with
rust
components
to
other
nodes
are
the
the
robot
sensor
or
rust
control
interactions.
So
you
have,
for
instance,
the
joint
trajectory
action
to
controllers.
A
B
A
Using
tf
for
updating
the
transform
of
the
of
the
scene
geometry
as
well,
so
those
other
things
that
actually
interact
the
world
and
those
are
the
things
that
actually
interact
with
any
user.
C
A
Or
any
any
application
code,
possibly
on
on
remote
machines
as
well
any
question
for
for
this
slide,
maybe
because
I
well,
I
will
get
back
to
it
later,
but
maybe
at
this
point
it
might
be
a
bit
confusing.
B
A
To
move
on
all
right,
then
there
is
the
second
interface,
the
movement
cpp
api.
Here's,
your
very
simple
motion,
just
an
example
of
that
it
can
do
anything.
The
movie
cpp
is
basically
like
move
group
just
without
the
remove
remote
move
group
interface.
So
it
is
a
c
plus
library
that
wraps
all
the
core
components.
A
You
can
do
anything
with
it.
It
just
doesn't
provide
move
group
interface
access
and
it
doesn't
implement
any
capabilities.
You
can
just
add
your
application
code
to
the
same
class
that
uses
movietpp,
but
it
still
uses
all
the
robots
facing
interfaces.
Although
all
the
world-facing
interfaces
like
tfrost
control,
planning,
scene
maintenance
is
possible,
sensor,
input
and
so
on,
and
then
third
is
movement
servo,
which
is
another
library
for
running
streaming,
motions,
mostly
cartesian
input,
and
this
one
is
also
only
based
on
movement,
core
components.
A
You
can
run
it
with
ros
messages
or
in
c
plus
only
mode,
so
both
are
possible
and
it
also
uses
the
same
rust
channels
as
movement
cpp,
so
dfrost
control,
planning,
scene,
maintenance,
sensors
and
yeah.
So,
let's
take
a
look
at
move
good,
because
that
includes
all
the
rust
communication
that
we
use
in
movie.
A
So
we
had
the
move
group
interface
interactions.
Then
we
have
all
the
capability
interactions
which
are
based
on
what
kind
of
plugins
you
load
in
move
group.
Then
we
have
a
rust
control,
interaction
which
includes
commands
like
joint
trajectory
position
commands
or
the
joint
states.
Topic
is
also
accessible,
using
rust
control
and
then
tf
and
any
sensor
input
that
you
have
in
your
application.
A
A
Can
be
called
by
a
third-party
node
and
then
robot
will
plan
and
execute
a
motion
that
has
not
been
validated
so
well
right.
Now
anyone
can
just
execute
any
action.
So
there's
no
preventing
that
the
planning
scene
monitor
is
a
really
central
core
component
of
move
it,
which
maintains
the
world.
It
maintains
the
robot
state,
the
transforms
of
the
robot
or
any
attached
collision
objects,
so
you're
free
to
modify
this
internal
wave
presentation
as
you
please.
A
So
anything
that
changes
this
world
will
change
how
the
robot
will
behave
and
plan
and
move
in
this
world.
So
there's
a
lot
that
can
go
wrong
by
yeah
invalid
access
to
this
and
then,
of
course,
rust
control.
Just
faking.
The
joint
state
message
can
do
a
lot
of
harm
around
executing
motions
from
a
third
party
move.
B
A
Or
a
separate
node
this
these
are
things
that
should
be
possibly
prevented
in
a
secure
system
and
then,
of
course,
this
hardware,
all
of
the
things
above
were
mostly
talking
about
the
movement
communications,
but
when
it
comes
to
hardware,
there's
some
more
things
to
consider.
A
So
how
do
we
know
what
hardware
we
are
talking
to?
So
if
we,
if
we're
running
rust
control,
we
have
no
way
to
tell
if
it's
really
the
robot.
C
A
Are
talking
to
or
is
it
maybe
some
other
simulation?
Is
it
the
the
right
sensor
instance
that
we
are
accessing
right
now
using
a
message
topic,
so
those
things
are
not
really
considered
yet
in
movement
at
all.
We
need
to
be
able
to
trust
rust.
Control
interactions
in
reverse
rust,
control
might
only
be
accessible
from
a
certain
movement
instance
could
be,
and
then
right
now,
there's
not
a
lot
of
rust
to
support
and
and
yeah
well
hardware
support
and
rust.
A
Two
at
all,
so
we
are
just
right
now,
starting
to
to
improve
that
situation
and
getting
started
with
the
first
full
stack,
ros
setups.
A
A
Options
to
to
test
any
security
features
also,
we
are
right
now
working
on
implementing
the
rescue
driver
for
ur.
So
if
we
want
to
set
up
a
demo
for
any
any
srs
related
examples
on
the
your
driver,
we
should
also
be
able
to
do
that
really
soon.
I
think
the
first
demos
are
already
running
specific
to
hardware.
A
A
B
B
So
I'll
go
ahead
and
get
started,
because
I
got
a
bunch
of
questions
here
on
my
list,
but
the
biggest
one
I'm
curious
about.
You
had
a
really
nice
list
of
security
items
that
you've
gone
through
and
thought
about.
Can
I
ask
you
to
what
what's
the
interest?
What's
the
motivation
that
that
drove
this
is
there?
Is
there
interest
in
the
community
and
the
folks
that
you
work
with
and
the
customers
and
actually
solving
these,
or
is
this
more
of
an
uphill
battle.
A
Well,
right
now
most
of
these
weren't
really
a
consideration,
because
there
wasn't
a
lot
of
support
for
securing
these
channels.
So
I
think,
if,
if
you
want
to
have
a
robot
in
production
and
you're,
not
completely
sure
about
that.
Well
that
your
that
your
system
is
contained
in
a
secure
environment,
then
those
are
the
things
that
I
would
like
to
secure.
A
I
think
the
the
highest
priority
should
be
hardware
access,
but
the
hardware
access
is
not
necessarily
an
item
of
like
move
it
of
the
movie
repository
or
move
it
to
in
general.
So
if
hardware
is
hardware
accessory,
secure
and
rust
controls,
xs
is
somehow
secure,
then
anything
that
relates
to
executing
things.
So
all
the
capabilities
are
definitely
worth
securing
and
and
those
those
are
really
the
things
where
you
can
yeah.
A
Let's
say
you
have
a
subnet
of
mobile
robots,
maybe
multiple
of
those
and
those
are
publishing
usually
to
to
private
topics
that
are
somehow
unique
to
their
own
instance.
A
D
Talking
about
when,
when
a
robot,
when
a
swarm
of
robots
have
a
collection
of
shared
and
pride
private
topic
spaces,
and
you
want
to
verify,
there's
like
there's
no
crosstalk.
A
A
D
And
maybe
another
question
I
had
is:
do
you
have
any
scenarios
right
now
where,
like
move,
it
is
used
in
the
field
and
non-controlled
settings
like
maybe
something
a
little
more
exotic
than
your
factory
floor
or
your
warehouse.
D
A
Yeah
I
mean
most
most
setups
are,
of
course
secured
by
their
by
the
subnets.
Either
they
run
in
a
vpn,
or
only
through
the
direct
connections
that
should
be
secure.
But
then
again
we
have
scenarios
where
we
might
want
to
allow
remote
access
using,
for
instance,
the
move
interface
in
arvis.
A
And
if
this
connection
was
like,
if
the
move
interface
excess
was
secured
by
default,
then
we
would
be
a
lot
more
flexible
with
maybe
adding
like
changing
changing
access
devices
like
laptops
or
changing
the
location
from
where
we
access
the
robot
things
like
that
are
easier
to
set
up
if
yeah.
If
we
don't
depend
on
on
this
on
the
on
the
subnet
per
se,.
A
B
Are
you
familiar
with
sros,
2
or
dds
security,
or
what
the
what
the
capabilities
are.
C
Sure
I
don't
know
if
you
guys
can
hear
me.
A
C
Okay,
perfect
so
so
astros
2
is
like
one
of
the
projects
that
the
security
working
group
is
working
on
and
and
so
the
main
goal
is
to
make
it
easier
for
users
to
leverage
the
security
features
provided
by
dds,
and
so
the
main
goal
of
that
is
to
provide
a
set
of
tools
that
allow
you
to
secure
communication.
C
So
this
is
really
focused
on
russ
communication
and
not
necessarily
tackling
the
other
bits
like
hardware
access
all
these
kind
of
things,
and,
and
so
the
goal
is
to
provide
you
with
enough
granularity
so
that
you
can
specify
exactly
what
topics
parts
of
your
system
are
allowed
to
access
or
things
like
that
or
what
nodes
are
allowed
to
connect
to
your
ros
network
and
and
based
on
that,
you
can
basically
define
rules
exactly
this
node
is
allowed
to
publish
on
this
call
that
service
whatever
and
and
then
this
will
be
enforced
by
the
dds
middleware
by
the
features
provided
by
dds
security,
and
so
that's
what
is
provided
today
to
various
level
of
usability
and
and
the
things
we've
been
like
thinking
of
exploring
that
are
on
our
to-do
list
is
still
allow.
B
C
Flexibility
in
both
the
ways
how
you
secure
specific
topics,
so,
in
a
sense
like
maybe
you
may
want
some
topics
to
be
encrypted,
because
anyone
on
your
network
that
can
sniff
packets,
you
don't
want
them
to
get
any
like
to
be
able
to
understand
the
information
but
and
what
seems
to
be
more.
Your
case
sometimes
you're
more
interested
in
being
sure
that
the
message
both
comes
from
the
right
person
and
hasn't
been
tampered
with
more
than
protecting
the
privacy.
The
content
of
the
of
the
data.
C
C
True,
and
so
then
part
of
the
tools
we've
been
exploring
is
also
like,
as
you
can
see
here
on
the
simple
diagrams
you
made,
you
already
have
quite
a
few
like
connections
in
your
graph
and
there
was
a
very
simplified
one
and
so
writing
by
hand
all
these
connections
and
all
the
things
that
are
allowed
to
like
talk
to
each
other
can
be
very
cumbersome.
C
All
this
all
these
notes
spoke
on
all
these
topics,
and
these
are
the
connections
you
need
for
your
system
to
run
properly.
Then
there
is,
it's,
never
ensure
that
it's
gonna
be
everything
you
might
ever
need
in
that
system.
So
it's
not
a
guarantee
in
a
sense,
if
you
have
a
lot
of
fallback
behaviors
a
lot
of
new
topics
created
in
some
scenarios
or
things
like
that,
you
may
not
catch
that
in
this
audit
mode.
D
D
D
D
Be
optimized
for
various
use
cases
so
that
you
know,
if
you
don't
need
encryption
on
all
your
particular.
A
D
A
Yes,
yes,
yeah
well
from
the
user
interface,
there
can
be
multiple
instances
there.
You
can
have
all
of
these
excess
per
arvis
and
also
by
moving
group
interface,
node
and
maybe
also
by
another
node
running
on
running
the
same
channels
pretty
much.
But
all
of
these
are
not,
I
mean
they're,
definitely
not
performance,
critical
they're
like
single
called
services
or
actions
that
that
don't
really
include
a
lot
of
data
either.
A
So
when
it
comes
to
performance,
critical
topics,
most
of
them
are
really
just
one
to
one
and
yeah,
which
would
all
also
include
like
the
sensor
data,
mostly
point
code
data,
laser
scanner,
data
things
like
that.
D
A
separation
of
concerns:
how
how
decouple
is
the
nodes
in
the
code
base
that
are
core
to
move
it
from
the
client
or
user
facing
application
code?
Is
there?
Is
there
a
strong
segmentation
or
do
like
consumers
need
to
bind
plugins
into
the
running
compose
nodes.
A
Yeah
well,
move
it
rose
and
move
it.
Core
is
not
as
decoupled
as
it
should
be,
but
the
capabilities
are
pretty
well
decoupled,
so
you
can
run
them
dynamically.
If
you.
B
B
C
I
guess
that's
a
good
segue
to
mention
what
sid
was
saying
like
guys
if
you
want
to
introduce,
or
if
anyone
from
canada
wants
to
talk
a
bit
about
no
dl
and
like
how
this
could
like
interact
with
this
idea
of
capabilities.
There
are
small
bits
of
features
that
have
their
own
like
interfacial
needs.
B
Yeah,
this
is
actually
yeah,
you're,
really
quiet,
oh
yeah.
This
is
actually
a
pretty
perfect
example
of
where
an
odl
can
come
in.
We
don't
have
support,
for
you
know,
setting
up
permissioning
yet,
but
well
automatically
generating
permissioning.
At
least
that
is
something
on
the
roadmap
for
the
near
future,
but
just
including
descriptors,
for
you
know
what
these
default
topic
names
are
and
what
message
types
they're
dealing
with
should
allow
like
a
nice
automatic
generation
of
keys,
automatic
generation
of
permissions
documents.
A
So
with
permissions,
are
you
talking
about
like
permissions
based
on
on
topics
or
interfaces
like,
for
instance,
move
group
interface
could
have
all
access,
but
then
you
could
have
like
a
read
interface.
That
only
gives
you
get
access
to
the
to
the
getter
capabilities.
Exactly.
D
So
you
can
have
this
duality
of
for
all
the
various
paradigms
that
ipc
has
over
ross
and
then
those
are
scoped
to
the
namespaces
of
those
topics,
services
and
actions,
and
we
can
be
as
narrow
and
fine
grain
even
over
them.
The
low
level
dds
topics,
those
mapped
to,
or
we
can
kind
of
be
sort
of
high
level
to
like
glob
over
an
entire
domain.
D
So
you
know
if
all
your
move
at
topic
were
name
spaced
under
like
slash
move
it
and
you
want
to
be
fairly
relaxed
but
just
make
sure
that
no
one
else
could
like
read
or
write
into
that
namespace,
that's
something
you
can
do
or
you
could
go
to
the
other
extreme
and
just
lock
down
everything.
But
there's,
like
you
know,
engineering
trade-off,
yeah.
D
A
Well,
I
would
find
really
interesting
with
that
would
be
like
a
monitoring
permission
where
you
would
have
something
like
an
obvious
instance
running
remotely.
That
is
only
allowed
to
read
topics
that
but
not
allowed
to
change
anything
in
the
move
group
states,
so
it
would
be
like
just
made
for
from
monitoring
or
watching
the
the
robot
state,
but
not
for
interacting
with
it.
D
A
That
that
would
be
really
interesting
in
that
yeah
in
that
that
use
case.
A
C
So
I
guess
one
idea
of
like
what
what
is
a
nodem
thing,
so
we're
trying
to
abstract
some
of
the
notions
of
security
in
in
dds
to
make
it
more
accessible
for
us
users.
So
that's
related
to
what
raffin
was
saying
like
you
could
like
write.
C
A
document
saying
this
note:
can
access
to
like
and
call
that
service
and
then,
like
srs2,
will
take
care
of
like
understanding
what
that
means
in
the
dds
world
and
and
the
idea
of
movier
is
to
be
able
to
specify
you
know
like
per
package
and
per
node
basis
like
that
you
can
describe
okay.
C
This
node
is
allowed
to
do
this
and
then,
when
you
integrate
multiple
nodes
into
your
system,
it
could
like
read
these
individual
files
provided
by
like
the
maintainers
of
each
component
and
then
be
able
to
like
generate
a
set
of
like
all
the
connections
that
that
need
to
happen
and
like
generate
all
the
security
material.
C
You
need
to
to
make
those
work,
and
so
that's
pretty
neatly
connected
to
the
idea
of
capability
in
a
sense
that,
like
a
movie,
like
instance,
with
like
a
ton
of
capabilities
in
it,
may
expose
a
lot
of
interfaces,
but
some
interfaces
may
be
specific
to
some
capabilities,
and
so
for
one
like
one
setting
where
you
just
send.
I
don't
know
like
group
trajectories
or
like
even
even
simply
only
like
position
commands
to
rust
controls.
C
Then
you
don't
necessarily
need
to
expose
all
the
velocity
or
acceleration
or
anything
else
that
could
expose.
But
in
this
case,
doesn't
need
to.
B
B
A
Yeah
yeah,
actually,
sometimes
we
we
deal
with
like
a
lot
of
remote
diagnostics,
and
I
think
that
in
that
way,
logging
is
really
important,
not
necessarily
from
a
security
standpoint.
B
A
Technically,
if
something
runs
in
protection,
we
definitely
want
to
have
that
secured
as
well,
and
then
encryption
is
also
really
important
right
I,
but
for
but,
but
this
is
right
now
not
really
a
move.
It
default
feature,
so
we
don't
have
any
remote
logging
capability
in
built
into
into
the
move
it
or
move
group
node.
B
It's
is
how
to
actually
simulate
it
and
what
work
we
can
do
without
the
real
robot
it
looks
like
this
is
pretty
well
decoupled
so
that
it's
all
the
way
on
the
right
side
of
the
interface.
Everything
else
works,
whether
you're
running
against
a
robot
or
a
simulated
robot
is
that
is
that
true.
A
Yeah
well,
basically,
for
movement,
it
doesn't
really
matter
if
we
run
a
real
robot
or
a
simulated
robot.
We
we
only
work
with
the
worst
control
interface.
We
have
some
some
sensor
topics.
Sensors
could
be
eros
controllers
as
well,
and
behind
that
we
don't
have
any
any
means
to
to
know
what
is
actually
running
there
and
with
movement.
C
A
Also,
don't
really
know
if
we
are
running
in
a
simulated
world,
for
instance,
or
if
we
have
simulated
sensor
data
or
if
it's
a
real
device
this
well.
This,
of
course,
is
a
it's
an
advantage,
but
it
might
be
a
disadvantage
as
well.
If
it
comes
to
security
but
yeah,
as
I
said
on
the
last
slide,
I
would
say
that
move
it
would
depend
on
rust,
control
to
be
secure,
and
that
might
be
different
use
case.
After
all,.
D
Yeah
in
a
deployment
scenario
where
you
have
you
know
the
oem
or
vendor
of
the
platform,
and
then
you
have
your
core
stack
and
then
you
have
the
user
base
code.
D
Constraints
on
on
who
is
delegated
or
responsible
for
billing
permissions,
like
maybe
move
it
and
the
vendor
coordinate
on
what
their
minimal
footprint
is
and
then
move.
It
coordinates
with
the
consumer
and
what
their
minimal
footprint
is.
And
so,
then
you
have
this
sort
of
very
controlled
setting
where
the
consumer
can't
accidentally
mess
up
with
the
hardware
and
are
these
these
stackers,
interconnected
and
controlling
for
each
other.
A
Yeah
so
well,
we
had
a
lot
of
intro
discussions
about
running
continuous
integration
and.
A
Time
and
I
think
for
for
yeah
examples
like
this
is
it
would
be
really
important
to
give
some
users
read
access
at
least
or
to
to
certain
to
certain
data,
or
maybe
maybe
write
access
to
services
that
run
the
basic
ci
test.
But
no
no
admin.
B
A
For
for
changing
the
world,
but
state
or
world,
or
anything
really
critical,
so
I
think
for
examples
like
that
are
for
yeah
for
for
warehouse.
Logistics
setups
also
would
be
really
important
to
be
able
to
grant
permissions
or
to
have
well
at
least
secured
node
access
to.
B
D
They
buy
the
robot
from
the
oem
and
they
put
their
ip
on
top
of
it,
and
the
oem
and
the
the
ip
owner
have
like
different
certificates.
D
Yes,
they're
only
responsible
in
securing
what
they
have
and
then
you
and
the
customer,
the
ipowner
and
the
customer
interact
on
their
certificates
and
how
they
want
to
exchange,
and
so.
A
Yeah
I
mean
that
sounds
like
it
would
require
some
like
custom
capabilities,
but
I
I
think
that
would
definitely
be
a
use
case
like,
for
instance,
if
we
have
a
certain
camera
device
mounted
on
an
arm.
This
also
happens
a
lot
and
those
really
need
to
register
that
you
actually
have
the
real
camera
device
publishing
to
the
right
arm
for
any
kind
of
visual
serving
or
so
then
yeah.
I
think
it
would
be
use
case
to
to
match
those
up.
B
So
this
has
been
really
fascinating.
For
me,
I
think
for
everybody
else
as
well.
Is
anybody
just
in
the
in
the
security
working
group?
Do
you
have
any
any
more
thoughts
on
you
know
what
our
next
steps
might
be
anything
else
that
we
need
to
explore,
or
you
know
where
we
go
from
here
I
mean
we'll.
Take
it
we'll,
take
a
look
at
you
know
another
system
or
two,
but
any
other
thoughts
on
on
where
we
get
from.
B
D
Is
there
a
the
demos
you
showed
those
are
like
minimal,
viable
examples
running
with
the
simulator
and
rost2?
What's
that,
yes,.
A
Yes,
they
are
all
available
in
the
main,
repo
and
move
it
too.
So
you
can
run
all
of
these
three
demos
with
a
launchpad
provided
in
there.
I
can
post
the
link
here
if
you
need.
A
C
And
so
I
guess
on
our
side
the
minimum,
like
the
minimal
thing,
we
would
need
to
do
to
confirm
that
it
can
work
would
be
to
enable
security
for
simulator,
rust,
control
and
move.
It
stack
on
top
of
it
and
confirm
that,
like
if
we
have
a
novice
with
admin
access,
we
can
use
the
move.
Group
interface.
Is
that
correct,
or
is
there
something
smaller
like
even
smaller,
that
we
could
do.
A
Yeah,
I
think
I
would
focus
on
one
thing
at
a
time
and
it's
it
well.
It's
definitely
different
use
cases
to
secure
the
movement,
interface
or
the
robot
interface,
and
I
I
think
the
the
easiest
way
to
get
started
would
be
to
just
focus
on
maybe
just
having
the
the
arvis
instance
be
secure
to
monitor,
move
group
topics.
A
So
I
I
think
this
would
also
be
the
most
interesting
use
case
for
the
start,
because,
most
of
the
time,
your
robot
and
the
move.
B
C
A
Be
on
the
same
machine,
so
you
could
have
secured
connections
between
like
on
the
same
system,
but
arvis
might
be
running
on
a
remote
machine
and
there
you
really
need
to
make
sure
that
you
don't
have
access
from
any
other
machines
that
might
interfere
with
the
internal
state
and
when
it
comes
to
iris
or
the
move
interface.
C
A
Action,
the
move
action
is
really
important.
I
think
that
would
be
one
one
thing
to
start
with:
not
all
capabilities
need
to
be
enabled
from
the
start,
they
can
all
be
disabled,
but
the
move
action
is
really
important
and
the,
for
instance,
the
get
pending
scene
service.
So
so
I
would
just
pick
like
one
or
two
things
and
start
with
that
and
see
how
it
works.
C
So
I
guess
I
I
didn't
get
a
chance
to
look
at
your
link
yet,
but
do
you
think
you
have
like
a
one
of
these
demos
that
expose
only
like
a
minimal
set
of
capabilities
like
that
would
be
like
a
few
just
a
few
actions.
That
would
be
like
the
minimum
viable
thing
to
like
ask
for
like
plan
a
path
or
like
monitor
our.
D
D
That's
like
all
monolithic,
they
just
bring
up
everything
you
would
possibly
need,
or
is
that
like
navigation
like
that,
but
maybe
might
be
looking
for
something
smaller.
B
A
Starts
the
the
harvest
demo
from
from
above
that
I
showed
in
the
beginning,
so
you
should
be
able
to
just
play
around
with
with
this
motion
planning
panel
and
there
you
will
see
well
everything
running
for
for
move
it
to
to
plan
and
execute
successfully.
A
But
it
includes
a
lot
of
default
capabilities
that
can
be
configured
but
right
now
they
all
are
enabled.
D
D
It's
a
little
more
of
a
detailed
question,
but
do
you
have
any?
Are
there
any
quirks
in
dealing
with
different
rmws?
D
A
D
One
thing
we've
had
with
the
navigation
is:
there's
just
so
many
topics.
The
discovery
takes
a
little
bit
longer
and
also
because
of
the.
If
you
try
to
put
all
the
permissions
for
the
entire
stack
into
one
document,
it
ends
up
being
slightly
too
large
for
the
maximum
permission
size.
So
what's
the
scale
like
about
how
many
topics
and
services
and
actions,
or
did
you
gauge
like
in
the
hundreds.
A
This
one
500.,
not
necessarily
I
mean
it,
really
depends
on
what
robot
you're
running.
If
you
run
this
arm,
then
it's
really
not
that
much.
But
if
you
run
a
full
like
two-minute
humanoid
robot
with
a
lot
of
sensors,
then
you
you
easily
get
into
the
hundreds,
but
for
a
really
basic
setup,
it's
well.
I.
A
So,
of
course,
sensors
scale
by
device,
sometimes
there's
a
factor
with
like
multiple
topics
per
sensor,
like
especially
cameras,
have
always
multiple
topics.
Different
different
resolutions,
different
like
camera
info,
is
added
to
their
death
images,
so
those
might
be
replicated
for
hardware
well,.
A
Much
you
have
the
join
states.
You
have
topics
per
controller
interface
control
manager.
Well,
I
can,
I
can
maybe
launch
something.
I
will
launch
the
move
group
demo
and
see
how
many
topics
we
have
that's,
maybe
easier.
D
Whether
I
I
can
imagine
like
the
the
interfaces
into
the
robots
might
be
duplicated.
Like
the
controllers,
I
was
wondering
if,
like
the
control
at
the
core
planner
like
there's
a
node
for
running
the
planer,
if
that's
like
duplicated
for
every
arm
or
is
it.
A
A
In
as
plugins,
so
it
and
there's
actually
not
a
lot
of
not
a
lot
of
topics
running
by
default.
B
C
Guess,
that's
that's
a
difference
from
roswell
to
ross
too.
I
guess
the
action
topics
don't
show
up
on
the
topic
list,
so
you
may
have
actually
a
lot
more.
I
guess
because
I
guess
move
it
is
using
mostly
services
and
actions
right.
A
C
Okay,
okay,
so
I
get,
I
guess
what
could
be
the
the
next
step
for
us
so
yeah?
We
would
try
to
run
one
of
these
demos
so
and
like
identify,
so
I
guess
the
two
things
we
would
need
to
to
know
to
explore
a
bit
further.
C
C
And
and
then
like
the
things
we
would
like
need,
I
guess
is
that,
like
an
exact
description
of
like
what
arvis
should
be
allowed
to
do
so,
my
understanding
is
that
like
it
should
be
able
to
like
listen
to
everything,
but
only
call
specific
some
specific
services
or
actions.
A
C
D
One
thing
we
haven't
really
taken
advantage
of
in,
like
policies,
we've
usually
been
affirming
plowing
rules,
but
we
haven't
really
done
negating
rules.
So,
if
that's
the
case,
like
a
particular
thing,
you
want
to
allow
just
everything
in
this
particular
move:
it's
name
space
and
reject
it
particular
services
that
would
affect
the
state.
You
could
revoke
permissions
as
well.
A
D
A
A
Run
motion
plans
to
execute
them
right,
so
in
that
case
there
needs
to
be
a
way
to
handle
this
gracefully
and
the
plugins
are
loaded
dynamically.
So
when
we
start
arvis
and
then
launch
a
plugin,
then
there
needs
to
be
a
way
to
know.
Well,
you
might
be
able
to
plan,
but
you
might
not
be
able
to
execute
something
or
something
like
that
is.
Is
there
a
good
interface
to
to
take
take
care
of
these
permissions.
D
That
that
might
be
a
use
case
of
actually
you
can
use
wildcards
and
permissions
yeah.
So
in
the
case
like
you're,
mentioning
where
you
have
a
maybe
a
single
console
of
the
factory
and
it's
you
know:
visualizing
multiple
robots.
B
C
Yeah,
so
we
have
the
ability
to
whitelist
our
blacklist.
We
took
mostly
a
whitelist
approach
so
far,
but
you
could
you
could
do
a
blacklist
approach
for
sure
and
that's
something
we
haven't
leveraged
too
much
then.
As
far
as
gracefully
is
concerned,
it's
not
really
like
graceful
so
far
in
a
sense
that,
like
right
now,
basically
what
we
do
is
like.
C
Okay,
when
you
start
your
note,
it
will
like
instantiate
some
plugins
in
the
middleware
that
will
like
load
the
rules
and
know
for
like
what
are
the
things
allowed
in
the
future,
and
so
if,
in
these
roles
you
load
that,
like
I
don't
know
like
your
office,
configuration
has
rules
for
the
plugins
you're
planning
on
using.
Then
when
you
start
these
plugins,
even
if
you
load
them
dynamically,
it
will
work.
C
But
then,
if
you
try
to
yeah
create
publishers
that
are
not
allowed
in
these
roles
that
you
loaded
in
the
first
place,
then
it
will
like
fail
to
create
the
publisher,
so
rclcpp
or
whatever
would
fail
to
create
that
publisher.
And
so
then
it's
a
matter
of
like
how
that
exception
is
handled
in
movie
code.
D
So
how
often
would
it
be
if,
like
arvis
like
you,
you
unload,
the
plugin
harvest
is
like
hey?
I
can't
really
do
this
like
it.
It
gets
it
gracefully
fails
back
from
our
cpv
and
just
like,
I'm
not
allowed
to
do
this
and
it
like
opens
up
a
file
dialogue,
and
please
point
me
to
the
certificate
that
would
allow
me
to
do
that.
A
Yeah
that
that
would
be
nice,
I
mean
it
needs
to
be
implemented
in
the
plugin
then,
but
but
handling
the
exception
of
studies
that
should.
B
A
Well,
maybe
one
other
interesting
issue
with
move.
It
is
that
we
are
using
like
a
separate
private
note
in
one
class
that
is
taking
care
of
certain
services.
A
It's
it
shows
up
as
a
separate
node,
and
it
adds
a
bit
of
like
redundancy
in
the
node
list
like
like.
Basically
there's
this.
Some
notes
are
shown
twice
because
of
that.
A
A
We
are
also
using
yeah.
We
we
are
using
that
that
with
movement
servo.
So
if
there's
something
specific
to
compose
nodes,
then
move
with
service
would
be
a
nice
example.
For
that.
A
D
A
C
So
I
guess
we
could.
We
could
look
at
that
separately,
but
move
it
server
is
interesting
as
well.
So
what
it's
doing
is
that,
like
it's,
it's
using
the
movie
framework
to
analyze
the
planning
scene
and
see
if
the
motions
that
are
streamed
are
doable
or
not,
but
it's
not
necessarily
doing
specific,
like
it's
doing
just
ik,
and
if
there
is
no
obstacle
it
moves.
A
Yeah
so
yeah
you
can,
you
can
publish,
join
states
or
joint
velocity
and
effective
velocities.
Both
will
be
accepted,
so
you
there
it
is,
and
then
it
runs
in
an
inverse
jacobian
internally
smoothes
it
does
some
collision
checking
on
it
and
then
forwards
the
result
to
rust
control.
A
So
so
you,
you
can
have
like
those
two
ras
communication
channels,
the
input
and
the
rust
control
rush
control
communication
and
then
it
also
uses
movement,
core
components
like
the
planning
scene,
monitor,
which
is
pretty
much
like
a
rus
interface
for
for
maintaining
the
the
world,
the
collision
world
of
the
of
the
robot
and
the
transforms
of
the
scene.
So
those
are
also
accessible,
but
I'm
not
sure
I
mean
that
that
class
is
really
complicated.
So
I
wouldn't
start
with
that.
One.
B
So
I
think
this
has
been
really
helpful.
I
think
we
got
a
kind
of
a
way
forward.
Some
ideas
sure
we'll
talk
about
it
more
when
we
next
get
together,
I
think,
are
you
able
to
afford
the
slides
by
chance
yeah
sure
you
can
do
that
yeah?
If
you
could
do
that,
then
I'll
upload?
Those
with
with
the
link
to
the
video
when
that's
published.
B
All
right
and
just
a
reminder
here.
B
So
next
next
meeting
with
marco
you're
on
top
for
that
right.
B
I'm
not
hearing
you,
I
think
you
unmuted,
but
I
can't
hear
you
but
yeah.
So
that's
on
the
on
the
26th
again,
then
it's
be
three
hours
earlier
than
normal
and
I'll
be
sure
to
you
know
heading
if
we
got
any
more
questions
we'll
reach
out
to
you.
You
know,
and
you
can
ignore
us
if
yeah
you're,
busy
or
whatnot
but
but
yeah
thanks
so
much
for
presenting
and
if
nobody
else
has
anything
else.
Then
we'll
see
you
in
two
weeks.