►
From YouTube: ROS WebTools Working Group (2021-06-11) - First Meeting
Description
The very first meeting of the ROS WebTools working group.
We went through introductions of most folks on the call (which unfortunately was not recorded), then jumped into discussing what we would like out of the working group, what the major areas of focus are, and how we should approach making it useful going forward.
A
Okay,
I
think
there
we
go.
I
think
that's
working
now
we
didn't
catch
any
of
the
introductions
on
the
recording,
but
I'll
just
put
the
little
vertical
marker
here.
This
is
the
first
meeting
of
the
ross
web
tools
working
group-
and
here
we
are
so
I'll-
just
share
this
screen
here
to
bring
up
the
document.
Anyone
who
doesn't
have
this
notes
link
it
was
in
the
invite,
but
I'll
also
paste
it
in
the
chat
here.
A
I've
been
using
a
document
just
like
this
for
the
the
tooling
working
group,
it's
pretty
simple,
like
some
important
links
up
top
a
template
for
the
meetings,
a
list
of
like
to
do's
that
haven't
been
done
yet
and
then
just
one
by
one.
The
meeting
notes
I've
found
it
fairly
effective
at
capturing
things
without
having
a
lot
of
friction.
A
B
A
Does
well
yeah
if
anyone
knows
how
to
configure
google
meets
to
just
automatically
let
people
in,
let
me
know
otherwise
I'll
figure
it
out
offline
before
the
next
meeting
and
then
the
first
thing
that
I
had
up
to
talk
about
was
I
made
a
proposal
for
a
charter
for
the
working
group.
This
is
kind
of
part
of
the
template
that
open
robotics
has
set
up
for
how
working
groups
work.
It's
nice
to
have
a
governance
model
here.
A
I
had
initially
copied
over
the
just
forked
the
the
template
repository,
which
gives
us
an
open
template
that
doesn't
have
any
details
filled
in,
and
so
I
added
a
thing
to
fill
in
the
details
and
I
would
love
some
feedback
on
it.
We
don't
necessarily
have
to
merge
it
live.
I
made
a
couple
of
comments
like
the
main
purpose
for
me
was
getting
familiar
with
everything.
A
That's
in
the
organization
on
github
and
taking
a
look
at
you
know
what
all
the
repositories
are,
whether
we
want
to
commit
to
maintaining
everything
and
having
just
an
explicit
accounting
of
everything.
That's
in
there.
So
just
wanted
to
call
attention
to
that
is,
is
all,
and
if
anyone
has
any
thoughts,
let
me
know
otherwise
we
can
move
on
and
potentially
just
review
this
asynchronously
thanks
jihoon
for
for
giving
feedback
on
that.
A
Already
so
the
next
thing
is,
I
appreciate
that
you
gave
me
the
access
to
to
fork
that
repository
into
into
the
organization.
I
know
I'm
not
like
a
long
time
contributor,
so
that
was
you
didn't
have
to,
but
it
was
helpful
and
I
think
something
we
will
want
to
think
about
is
who
who
are
the
owner
set
of
the
the
assets
associated
with
the
working
group
and
right
now,
like
anybody
who
thinks
they
should
be
an
owner.
A
I
also
think
you
should
be
an
owner
and
we
can
make
potentially
like
reviewer
teams
on
the
organization
and
add
the
auto,
auto
sign
rotation
for
for
contributions,
which
I
have
found
pretty
useful,
I'm
not
sure
if
that's
already
configured
anywhere,
if
it
isn't,
we
can
get
it
set
up
if
anyone's
interested
in
that
I've
found
that
an
auto
assign
rotation
at
the
very
least
puts
a
little
bit
of
pressure
on
a
on
a
maintainer
to
to
look
at
it.
Otherwise
you
get
a
lot
of
notifications
on
github.
A
Yeah,
and
so
most
of
the
discussions
I've
put
here,
are
fairly
like
bookkeeping
once
we've
got
through
them.
I
would
just
want
to
open
up
the
floor
to
like
what
everyone
wants
to
talk
about
and
where
we
think
this
should
go.
So
my
question
is
like:
do
we
want
to
have
some
sort
of
project
management
tool
that
aggregates
the
backlogs
from
the
different
things?
I,
for
example,
have
used
zenhub
a
little
bit,
but
that's
only
if
that
provides
value,
just
want
to
throw
it
out
there.
A
I
was
thinking
about
like
a
centralized
way
to
view
issues
across
the
various
repositories,
because,
right
now,
if
you
look
at
a
single
repo,
you
can
see
the
issues
there
and
that
may
be
good
enough
for
for
what
we
need
to
do,
in
which
case
we
don't
need
to
think
any
further.
I
just
wanted
to
bring
it
up.
A
I've
used
zen
hub,
which
allows
you
to
look
at
the
combined
backlogs
across
multiple
repositories,
which
maybe
helps
you
think
about
prioritizing
things
on
a
a
higher
level,
and
then
you
can,
maybe
I
don't
know,
put
a
prioritized
list
of
of
the
roadmap
for
what
what
should
be
built
next
and
and
send
that
to
the
prayer
of
the
community
to
communicate
the
priority
of
tasks.
According
to
this
body
of
people
who
cares
about
where
things
go
see
yeah,
it
may
be
extra
work,
it
may
be
not
worth
it.
A
I
just
wanted
to
throw
it
out
there
so
that
we're
thinking
about
that
sort
of
thing.
I
also
wanted
to
ask
if
anybody
else
is
interested
in
sharing
the
the
load
of
running
these
meetings.
I
definitely
just
wanted
to
get
everyone
in
the
room,
the
first
time
I'll
keep
coming,
but
I
also
wanted
to
see
if
we
wanted
to
pass
around
the
talking
stick.
A
A
C
E
D
A
A
Okay
and
then
something
else
I
wanted
to
bring
up-
and
maybe
we
can
talk
about
this
at
the
end,
actually
is
whether
we
want
to
you
know
what
schedule
we
want
to
have
these
meetings
on,
but
maybe
we
should
open
up
the
floor
for
any
other
discussions.
We'd
like
to
talk
about
here
like
where
do
you
want
to
take
the
road
map?
What
needs
love?
What
needs
maintainers
yeah
so.
C
Yeah,
probably
it's
good
me
starting
the
describe
what
I,
what
the
robot
web
tools
needs
at
the
moment.
So
so
far
for
the
recent
years,
like
the
all,
the
maintenance
were
on
and
off
all
the
time,
and
so
it
was
so.
I
tried
so
how
I
so
okay.
So
how
probably
it's
good,
starting,
how
I
described
how
I
have
been
maintaining
the
robotic
tool
so
far,
and
probably
from
that
perspective
you
can
think
of
how
we
can
manage
our
wt
in
the
longer
period.
C
So
how
I
did
was
actually
like
there
were
a
lot
of
depending
pull
requests
and
issues
as
you
saw,
and
it's
been
stacking
over
years
and
I've
been
singing
honestly
speaking.
I've
been
ignoring
like
questions
and
issue
ratings
on
about
the
library,
but
I
only
cared
about
somebody
actually
fixing
something
or
adding
up
features
and
if
I
see
the
familiar
github
id
a
couple
of
more
times
or
so
actually,
mingang
and
wayne
said
and
sent
me
an
actual
email
to
discuss
about
creating
a
new
features.
C
And
if
and
it's
been
rotating
a
whole
time
and
like
thanks
to
mingang.
Actually
he
he
is
the
founder
of
the
rcl
node
and
he's
been
maintaining
by
himself.
So
I'm
very
thanks
to
him
as
well
as
wayne.
Actually
he
started
to
contribute
last
year
right
and
so
that's
how
I'm
maintaining
and
one
the
philosophy
I
was
believing
was
wherever
it
goes,
it's
better
and
it's
better
than
doing
nothing.
So
I
just
try
to
trust
all
the
contributors
or
requesters
and
just
like
accepting
everything.
C
F
Start
yeah,
I
think
the
the
best
way
to
go
or
actually
back
then
when
we
were
a
bit
more
active
than
we
are
now,
was
that
someone
would
be
able
to
assign
let's
say,
pull
requests
to
to
other
people
who
are
maintainers
right.
So
right
now
we
can,
or
we
already
know
more
or
less,
who
is
willing
to
be
more
active
right
and
maybe
someone
would
be
able
to
assign
these
pull
requests
or
these
issues
to
people
from
within
the
working
group.
A
A
And
like
every
every
working
group
that
I've
seen,
does
things
a
little
differently.
I
know
in
navigation
they're
frequently
looking
at
issues
and
pull
requests
is
a
major
focus
of
the
working
group.
That
could
be
what
we
want
to
do
here.
I'd
love
to
hear
more
opinions
on
on
what
we
want
to
get
out
of
out
of
this
group
like
we're
here,
we
showed
up
we're
interested
in
this
project.
A
D
Yes,
for
me,
it's
like
all
about
trying
to
bridge
all
all
sort
of
modern
developments
in
the
javascript
environment,
so,
for
example,
with
deep
learning
and
computer
vision.
All
of
these
things
can
be
capable
down
in
the
browser
and,
secondly,
a
lot
of
things
which
are
happening.
One
specific
framework
I
can
think
of
as
web
gpu,
so
you
have
opencl
compute,
which
could
be
done
on
the
browser
and
webgl
as
well.
D
A
A
It
is
valuable
to
come
in
and
talk
about
the
thing
we're
interested
in
and
maybe
that's
the
only
value
we
need
out
of
it,
but
I
think
that
maybe
the
more
value
that
can
be
gotten
out
of
it
is
how
do
we
structure
structure
this
commonplace
around
getting
work
done
and
organizing
that
work
is
is
maybe
where
it
could
provide
more
value
like.
I
think
we
can
talk
about
the
things
that
we're
interested
in
on
on
discourse,
but
this
is
also
a
good
place
for
it.
A
G
To
me,
it
seems,
like
those
are
two
different
kinds
of
meetings
possible.
One
is
that,
let's
figure
out
the
direction
that
you
want
to
take
this
this
set
of
tools
and
build
the
roadmap
kind
of
exploratory,
let's
set
a
goal
out
there,
and
so
we
can
trace
towards
it
and
a
different
type
of
meetings,
maybe
on
different
basis.
G
G
A
I
think
that
makes
sense,
especially
if
we're
thinking
about
a
quarterly
or
even
a
ross,
distro
level
roadmap.
You
have
those
meetings
once
every
so
often
and
in
between
it's
it's
trying
to
break
it
down
and
track
progress
towards
the
goal
and
adapt
to
the
roadmap
that
we
inevitably
don't
hit
everything
in
and
seeing
what's
the
top
priorities
from
what
we
can
still
do,
it
might
be
interesting
too.
A
I
know
that
you
know,
especially
it's
farther
out
in
the
ecosystem
out
of
the
core,
we're
not
as
tied
to
the
exact
release
dates
of
the
distros,
but
it's
still
probably
interesting
to
think
about.
You
know:
what's
the
what's
the
road
map
for
ross
to
humble
hawksbill,
because
I
think
that
one's
gonna
be
a
really
really
big
deal
for
ross
too.
I
would
consider
it
probably
the
1.0
point,
because
you
know
first
five-year
support
release.
A
I
think
there's
been
a
lot
of
really
good
development
going
on
since
foxy
after
the
foxy
release
that
maybe
makes
ross2
actually
usable
for
a
lot
of
folks
that
it
wasn't
before
so
I'd
be
really
interested
in
trying
to
figure
out
what
are
the
most
important
things
that
we
could
get
done
that
are
missing
for
ross
too.
I
don't
want
to
forget
about
the
ross
one
folks,
of
course,
now
that
noetic
is
out,
it
kind
of
seems
like
we're,
maybe
not
at
a
feature
freeze,
but
you
don't
want
to
break
any
existing
apis.
A
You
don't
have
much
of
an
opportunity
to
do
that
anymore
for
for
us
one,
so
we
could
have
a
dedicated
meeting
for
setting
up
a
age
turtle
and
roswell
end-of-life
road
map
just
to
try
and
set
top
priorities.
I
don't
know
if
we
want
to
get
into
that
today.
I
think
this
is
more
brainstorming
where
we
want
to
go,
and
then
we
can
execute
on
that
in
the
following
ones,
but
I
like
that
idea.
G
A
That
I
personally
have
been
thinking
about.
I
feel-
and
this
may
be
a
controversial
opinion.
I
feel
like
the
the
the
visualization
tools
for
ross
and
ross
too.
Our
cute
and
rviz
are
a
little
outdated
and
hard
to
extend
and
I've
been
wishing
that
we
could
somehow
throw
the
all
of
the
progress.
That's
gone
on
in
web
gui
technology
to
these
problems
and
something
that
I
thought
might
make
a
lot
of
sense
would
be
a
native
app
using
web
guise.
A
So
I
was
interested
in
figuring
out
how
to
get
rcl
node.js
to
run
in
an
electron
application
so
that
you
could
package
and
distribute
a
native
app
but
still
use
these
these
technologies.
So
that's
a
pet
interest
of
mine.
I
don't
know
if
it's
acute
or
high
priority,
but
it's
definitely
something
I'm
trying
to
think
about
is
how
do
we,
you
know
maybe
like
get
a
full-featured
arviz
or
our
cute
or
combination
of
the
both,
and
you
just
get
better
gooey
tools.
D
Remember
for
a
very
similar
project,
in
fact,
they've
used
another
open
source
that
visualized.
I
think
it's
about
this
for
autonomous
cars
and
I
think
they're
using
electron
to
build
desktop
native
solutions.
So
I
think
this
is
the
link,
but
this
is
really
tied
to
webviz
autonomous
vehicle
vertical.
So
I
think,
there's
like
definitely
a
sport
there.
If
we
can
streamline
or
even
customize
widgets
based
on.
H
H
We've
been
working
mostly
in
the
node
back
inside
of
it
for
a
couple
years,
so
definitely
any
contributions
to
the
project
there.
It
may
not
even
be
part
of
something
that
we
do
directly
on
the
rtl
node.js,
but
just
some
other.
You
know
repo
that
some
other
some
other
guys
that
are
more
familiar
with
some
of
the
front
end
technology
could
contribute
to
be
awesome,
but
that
does
bring
up.
The
question,
in
my
mind,
is
in
terms
of
the
split
between
back
end
front
end.
H
You
know,
because
I've
just
been
working
on
the
back
inside
of
things,
and
so
I
think,
maybe
a
discussion.
We
could
kind
of
start
to
bring
all
our
interest
again.
I
know
this
we
want
to
work
towards.
I
guess
some
kind
of
big
vision
that
we
could
all
kind
of
see
how
we
fit
in
and
how
we
can
contribute
to
that
vision
is
something
that
I'm
looking
for
again
the
front-end
side
of
things.
There's
a
it's
just
continually,
opening
up
more
and
more.
H
The
discussion
about
like
web
was
it
gpu
and
just
more
and
more
technology
using
webassembly
and
all
whether
it's
on
the
back
in
the
front
end
continues
to
mature
and
I'd
love
to
see
us
have
a
continuous
discussion,
and
I
think
if
we
start
to
embrace
more
of
these
cooler,
newer
technologies,
we'll
it'll
it'll
be
more
attractive
to
lots
of
people
coming
in.
They
have
maybe
a
kind
of
a
distance
interest
in
robotics,
but
they
bring
some
really
interesting
skills
in.
H
If
you
can
kind
of
connect
them,
I
think
we
could
kind
of
multiply
or
scale
up
our
just
the
contributions
and
the
visibility
again.
Be
anything
you
do.
This
visible
people
are
going
to
pull
in
on
that
versus
talking
back
in
you
know,
technology,
that's
a
smaller
group,
so
I'd
love
to
see
us
start
to
talk
in
that
direction
and
again
ming.
He
has
he's.
You
know
he's
been
with
us
for
a
long
time
and
he
has
some
some
thoughts
too.
Hopefully
he
could
get
connected
here
and
share
some
of
his
thoughts.
A
Yeah,
I
agree
with
that
completely.
I
feel
like
there's
a
wide
developer
world
who
might
be
interested
in
building
applications
around
robotics.
You
know
if
you
provide
a
useful
interface.
That
is,
is
easy
to
call,
then
all
of
a
sudden
they
can
start
building
front
ends
for
people
to
just
more
easily
use
their
robots.
Some
thing
that
I've
had
as
a
pain
point
on
past
robotics
projects.
I've
worked
on
is
that
you
have
all
the
developers
who
are
intimately
familiar
with
the
robot
code
base
ssh
into
the
robot.
A
Do
their
like
ross
topic
lists,
maybe
bring
up
an
rvs
window
because
they
have
ross
in
the
development
environment
installed
on
their
computer,
and
then
you
try
to
hand
it
over
to
the
the
qa
testers
or
the
robot
operator,
who
needs
to
take
it
out
in
the
field
and
all
of
a
sudden.
They
need
a
developer
machine.
For
that
like
they
should
be
able
to
pull
this
up
on
an
ipad
or
something
yeah.
Yeah.
G
A
A
G
C
D
A
A
I
think
what
it
comes
down
to
is
whether
we
have
developers
and
maintainers
who
are
willing
to
spend
time
on
that
there's
a
little
bit
of
a
consideration
of
like
it's
nice
to
have
a
focused
charter
and
make
sure
that
the
projects
we
put
in
here
fit
within
that.
But
but
beyond
that,
and
I
don't
want
to
make
the
charter
too
narrow.
It's
mostly
like
just
meant
to
be
a
guiding
guiding
light
for
like
what
should
we
be
thinking
about
yeah
beyond
that,
it's
like
who
wants
to
maintain
it.
E
D
E
E
Branch
of
our
charter,
perhaps,
is
not
only
providing
tools
for
web
developers
to
interact
with
robot
systems,
but
also
providing
tools
for
robot
developers
who
are
not
necessarily
web
developers.
I
stumbled
through
a
lot
of
javascript
and
css
stuff.
Very
painfully
so
you
know
my
pain
point
is
developing
or
making
it
easier
to
develop
web
tools
as
a
robotics
person.
A
A
It
was
just
a
you
know,
first
draft,
at
what
I
thought
a
charter
should
sound
like,
so
I
definitely
want
to
capture
like
we
want
to
make
it
easier
for
ross
developers
to
provide
interfaces
for
folks
who
are
not
ross
developers
to
use
their
robots
and
if
there's
a
prefab
set
of
components
that
people
can
plug
in
and
a
template
project
to
get
started.
All
of
a
sudden.
That
starts
to
make
it
a
lot
easier
if
you're
not
familiar
with
starting
up
a
web-based
project.
A
Yeah,
I
mean
that's,
I
think
the
nice
thing
about
the
rosbridge
protocol
is
you've
got
a
way
to
that's
the
nice
thing
about
anonymous
pub
sub
distributed
systems.
Is
you
can
have
specialists
on
either
end
building
their
portion
of
it
and
you've
got
this
common
interface
and
so
with
something
like
rosbridge.
If
we
provide
common
web
components,
you
can
plug
in
the
basic
stuff
and
get
it
done
out
of
the
box.
Ideally
otherwise,
you've
got
all
the
messages
you
need
and
someone
with
more
advanced
skills
in
that
area
can
keep
running
with
it.
A
A
C
I
got
actually
got
in
question
regarding
that:
the
the
working
at
the
people's
in
the
working
group,
what
what
are,
what
are
the
repos
you
guys
are
actually
looking
into.
I
got
interested
in
because
when
I
saw
the
the
the
contributions
there
are
four
different
groups,
one
is
who
is
contributing
only
ross
bridge
and
the
other
one
is
only
contributing
raw
sleep,
js
and
or
roth
3djs,
and
on
another
one
is
r.
C
A
A
I
think
they're
both
promising
and
have
their
own
unique
use
cases
so
both
yeah-
I
haven't
gotten
too
deep
into
it.
Yet
I
only
have
played
on
around
a
little
bit
with
trying
to
get
rcl
node.js
running
in
an
electric
in
an
electron
app
and
my
the
demo
that
I
wanted
to
build
wayne.
You
brought
up
building
a
demo
and
I'd
love
to
try
and
get
involved
in
that
is.
A
I
wanted
our
cute
graph,
a
visualization
of
the
ros
graph
in
a
browser
tool
using
some
of
these
interactive
graph
libraries,
because
I'm
often
looking
at
all
these
nodes
and
topics
and
thinking
man,
I'd
really
like
to
figure
out
the
name
spaces
a
little
better.
So
this
graph
is
easier
to
understand
and
if
you
can
highlight
and
drag
things
around
in
your
graph,
that
makes
it
a
little
bit
easier
to
think
about
it.
So
that's
the
tool
that
I'm
I'd
like
to
exist.
F
Yeah
for
me,
I
guess
most
of
my
contributions.
If
not
all
of
them
were
in
the
rosbridge,
basically
rosbridge
server,
and
I
only
use
the
rosslip
js
as
a
yeah
as
a
web
developer.
You
know
so
sort
of
an
end
user
and
yeah.
I
would
be
glad
to
either
continue
yeah,
basically
in
the
same
directions
or
maybe
get
more
involved
in
the
roslib
js
right
but
yeah.
I
I
had
to
diverge
a
little
from
ross
at
some
point
and
now
I'm
coming
back
so
hopefully
it's
better.
B
If
I'm
exposing
exposing
all
the
topics
to
the
user,
let's
say
a
browser,
it
can
basically
see
any
topic
and
publish
to
any
topic,
and
that
could
be
concerning
if
some
some
of
your
actions
or
services
should
not
be
exposed
to
to
every
user
in
in
that
network
or
or
even
on
the
web.
Your
client
could
be
like
in
our
country
or
whatever,
and
maybe
you
have
any
ideas
or
experience,
working
with
authentication
authorization
and
bridging
the
bad
gap
between
ross
and
like
authenticated
clients
in
and
any
thoughts
would
be
appreciated.
C
A
A
I
guess
you
would
need
to
do
that
on
the
server
side
of
the
ros
bridge,
something
that
I
also
thought
of
if
you're,
if
you're
looking
at
ross2
at
all,
is
there's
the
sros
project,
which
is
trying
to
use
dds
security
features
to
secure
raw
systems
strongly.
I'm
not
super
familiar
with
how
it
works,
but
there
is
a
security
working
group.
A
Yeah,
but
that's
also
an
interesting
thing
to
take
a
look
at
is:
is
this
is
sort
of
the
dds
level
security?
So
you
could
limit
the
abilities
of
of
the
server
node
itself,
so
it's
not
even
like
in
the
bridge
to
the
web.
It's
that
that
node
doesn't
even
have
access
to
more
than
the
topics
you
allow
it
to.
B
C
C
C
E
A
So
they're
both
owned
by
or
they're,
both
run
by
open,
robotics,
the
the
organization
which
I
don't
believe
we
have
anyone
from
open
robotics
on
the
call.
Otherwise
I
would
let
them
talk
about
it,
but
they
are
run
as
two
completely
separate
projects
and
that,
from
my
understanding
is,
is
historical.
A
You
know
you've
got
the
gazebo
ross
packages
which
provide
your
bridge
between
and
now
there's
the
ignition
ross
bridge,
which
is
slightly
different
than
the
way
the
gazebo
ross
bridge
worked
but
yeah
they
their
road
maps,
are
separate.
Their
release
schedules
are
separate,
they're
communicating
their
pub
sub
frameworks
are
separate,
so
there's
not
a
lot
of
overlap
there.
A
I
had
a
discussion
at
one
point
with
some
of
the
the
ross
and
gazebo
maintainers
about
you
know.
Potentially,
would
we
want
to
use
ignition
rendering
for
arviz
instead
of
having
arviz
have
a
custom,
rendering
code
and
they
were
very
open
to
that
idea?
I
think
they
like
the
way
they've
put
together
the
new
ignition
tools
project.
D
I
think,
personally,
I
feel
one
limitation
with
always
is
it's
purely
a
visual
library
and
with
gazebo
you
have
physics
and
a
lot
of
robotics
project,
it's
all
towards
rl
and
simulations
and
so
on.
So
I
think
physics
is
something
which
is
missing
in
plus
web
tools,
even
though
we
have
javascript
is
perfectly
capable
of
doing
physics.
A
Yeah,
I
think
that's
an
interesting
point.
I
mean
I
do
get
the
arguments
that
are
put
forward
for
why
arvis
and
gazebo
are
separate
things
you
know.
Arviz
is
the
robot's
understanding
of
the
world
like
the
arviz?
Is
the
the
robot's
eye
view
of
what's
going
on,
whereas
gazebo
is
the
the
world
eye
view
of
what's
going
on?
So
that's
you
know
ground
truth,
that's
reality,
whereas
the
robot
may
not
understand
reality
perfectly
and
that's
that's
meant
to
be
represented
in
our
viz.
A
I
think,
as
you
start
to
get
more
to
more
advanced
use
cases,
you
want
your
robot
to
have
some.
You
know,
maybe,
if
you're
working
on
something
like
manipulation
gripping,
you
do
want
to
have
a
physics
understanding
in
your
robot,
but
I
still
don't
know
if
it's
arviz,
that
does
that
you
might
have
you
know,
sort
of
a
mini
simulator
within
your
manipulation
code.
That
has
a
basic
physics
understanding
to
to
to
plan
things
out,
but
my
counterpoint
is
that
maybe
maybe
our
viz
is
meant
to
just
be
a
visualizer.
A
A
C
C
Let's
say
like
band
say
you
you
wanted
to
have
like
a
wvs,
which
was
actually
I
tried
to
implement
the
web
version
of
the
arvis
like
10
years
ago,
and
it's
and
due
to
the
two
gen
and
two
general
application
was
wasn't
necessary
to
use
it
for,
as
for
that
moment,
and
so
we
tried
and
four
robot
web
tools.
Actually
we
tried
to
keep
it
as
a
library
and
application
that
can
implement
the
uplink
and
the
company
can
implement
the
application
level
so
yeah,
that's
why
they
we
tried
to.
C
C
That
was
a
start
of
a
start
of
the
the
robot
web
interaction
projects
and
after
that,
2013
we'll
look
at
their
velo
gear
as
bosch,
and
we
look
areas
and
join
the
team
and
try
to
make
it
as
actually
actual
library
called
robot
web
tools
and
yeah.
That's
how
the
raspberries
protocol
has
implemented
and
based
on
that,
we
implemented
the
raw
slip
js
as
well
as
raw3djs.
A
Great
okay,
I
think
we're
we're
at
about
the
hour
here,
and
so
I
want
to
make
sure
we
get
to
this
before
we
run
over.
I
don't
want
to
mess
with
anyone's
schedule.
How
often
do
we
want
to
run
these
meetings?
I
think
that
we've
had
a
really
good
conversation
here.
I
think
we
might
need
to
just
kind
of
work
continue
working
through
it
a
little
bit,
but
I
think
what
we
probably
want
to
do
is
just
schedule
another
general
meeting
as
the
next
one
before
we
do
anything
really
specific.
A
A
Okay,
pretty
standard
yeah,
so
I
will
schedule
the
follow-up.
The
next
meeting
for
two
weeks
from
now
at
this
same
time,
does
that
work.
I
think
this
was.
I
picked
this
one
to
fit
with
the
most
of
the
doodle
responders,
as
I
could.
While
I
was
prioritizing
jihoon
picking
one
of
the
times
that
you
you
chose,
because
I
wanted
to
make
sure
that
you
could
make
it.
C
A
A
If
anyone
has
any
suggestions
up
front,
let
me
know
otherwise
I'll
just
open
up
the
same,
the
same
thing
again
and
we
can
go
from
there
and
then
I'll
try
to
schedule
it
for
two
weeks
from
now.
So
I'll
put
that
up
right
away
that
way,
people
have
time
to
respond
and
get
it
scheduled.
For,
let's
see
what
would
that
be
june
25th,
I
think.
A
Maybe
trying
to
think
of
a
high-level
roadmap
would
be
a
good
exercise
there.
So
for
me,
I'm
thinking
about
the
ross2h
roadmap
there's
also
ros1
considerations,
so
someone
who's
more
focused
on
that
will
need
to
drive
that
discussion.
I
think,
and
what
timelines
we
want
to
think
about
there.
I,
I
guess
there
are
still
noetic
patch
releases
and
melodic
is
still
live.
A
Genetic
just
went
so
melodic
is
maybe
next
year
or
something
like
that.
Yeah
yeah,
so
I
mean
that's
still,
consideration
is,
is
in
there
I
mean
anything
for
melodic.
I
think
it's
just
stabilization
bug
fixes.
There's
no
new
development,
that's
going
to
happen,
but
I
imagine
you
still
have
some
room
for
a
new
development
for
no
addict
because
that's
going
to
be
live
for
another
five
years
or
four
years.
At
this
point,
I
guess
four
and
a
half.
A
I
don't
remember
so
yes,
anyway,
so
I
think
that
yeah
high
level
roadmap
is
a
good
agenda.
Lead
for
for
next
meeting
focus
high
level
road
map
and
we
can
go
from
there.
We'll
do
you
know
general
housekeeping
stuff,
high
level
road
map
think
about
where
we
want
to
store
that
information
if
we
want
to
have
a
backlog,
repository
or
use
the
community
repo
as
a
high-level
project
board.
Something
like
that.
A
A
C
I
actually
really
like
to
invite
mathias
who,
who
is
actually
making
helping
maintenance
of
broadsleep
js
as
well
as
ross3djs
and
actually
and
calling
for
help.
Everyone
is
welcome
to
add
a
comment
in
the
request,
or
just
help
to
come
and
manage
the
pull
request
and
opening
open
for
request
in
any
repos.
C
A
Okay,
yeah,
we
can
maybe
make
some.
It
seems
like
we've
identified
within
the
the
sorry
within
the
charter.
I
tried
to
identify
how
you
group,
together
those
repositories
a
little
bit
into
into
subprojects,
and
maybe
we
can
try
to
come
up
with
a
list
of
maintainers
for
those
high
level
groupings
and
that
way
you
can
assign
teams.
We
can
make
teams
in
the
organization
assign
those
users
to
then
get
auto
assigned
on
rotation
to
repos
within
that
sub-project.