►
From YouTube: ROS WebTools Working Group (2021-07-02)
Description
Second meeting! Still discussing high level goals. Visited by Foxglove.dev team, who showed us the visualizer. Got sidetracked on rosbag discussions :)
A
B
A
A
A
C
A
Of
of
reaching
out
to
foxglove
and
I'll
join
the
slack
in
terms
of
call
for
interest
for
presenters,
I
think
we'll
do
that
for
next
time.
This
time,
I
think
we'll
probably
pay
attention
to
the
action
items
we
have
going
on
yeah,
so
no
presentation
today
so
yeah.
Unless
adrian
you
had
any
sort
of
off
the
cuff
a
bit
of
fox
glove,
you
could
show
don't
wanna
put
you
on
the
spot,
though,
if
you're
not
ready
for
that
yeah.
B
Something
else
that
might
be
nice
to
throw
on
the
agenda.
I
think
you
talked
a
bit
about
it
at
the
last
one,
but
just
sort
of
understanding
like
what
is
the
charter
for
this
group
and
like
what
the
other
folks
want
to
get
out
of
it.
You
know,
is
it?
Is
it
just
about
kind
of
maintaining
the
stuff
under
the
rust
web
tools?
Org
or
is
it
you
know
other
things?
B
A
A
C
A
So
I
haven't
gotten
a
chance
to
look
at
that,
but
we
have
some
ideas
about
solidifying
the
list,
at
least
of
things
that
go
in
here
and
if
we
want
to
refine
the
language
in
there,
this
is
really
just
a
first
draft.
It's
not
set
in
stone
and
we
can
keep
writing
it
as
we
go.
So
this,
I
think,
is
a
good
place
to
to
try
and
define
what
we
want
this
working
group
to
be
about
and
that
that
could
be
a
sort
of
collective
understanding
that
that
we
gain
over
time
but
yeah.
A
You
know
we
say
web
tools,
I'm
including
the
node.js
client,
largely
because
I
think
it
is
a
critical
portion
of
the
bridge
to
a
browser,
because
I'm
not
saying
browser
tools
right
and
in
order
to
do
say
the
rost2
rosbridge
protocol
you're
using
the
node.js
client
in
order
to
connect
into
the
ros
system.
So
I
consider
that
part
of
the
ecosystem.
A
But
that
basically
gets
us
through
like
having
these
agendas
just
because
it
gives
you
a
checklist
of
things
to
go
through,
but
that
is
the
only
community
pr
to
look
at
right
now
and
we
already
took
a
look
at
that
last
time.
So
what
I'd
like
to
do
shortly
after
this
meeting
is
address
that
any
comments
we
have
on
there
and
then
just
merge
it
aft
after
we've,
maybe
taken
care
of
I'm
actually
inclined
someone.
B
Matter
either
way,
do
you
yeah,
I
mean
it's
it's
possible
to
edit
it
after
it's
almost
easier
to
iterate
on
it
after
it's
merged,
because
then
you
can
just
make
prs
and
discuss
individual
things.
Absolutely.
Is
there
a
point
in
listing
all
of
the
repos
I
mean,
would
it
be
easier
to
just
link
to
github
that
list
might
change
over
time.
A
May
or
may
not
get,
you
know,
gain
and
lose
repositories,
but
you
want
to
have
some
sort
of
place
where
you
discussed
whether
you
actually
want
to
take
that
on
as
this
this
entity
that
we're
trying
to
create,
I
don't
know
how
much
value
that
adds,
but
at
the
very
least
it
sort
of
says
we
discussed
this,
we
decided
we
were
going
to
maintain
it
rather
than
you
know,
someone
created
a
repository
and
now
it
exists.
There
was
the
idea.
A
I
think
that
that
is
yeah.
Probably
that
would
make
sense
so
so
actually
yeah.
Maybe
we
want
to
talk
about
maintainers
first
and
then
well,
I'd
like
to
get
that
just
first
or
after
the
charter
in
it
can
list
everything.
That's
in
there
right
now
and
we
could
remove
things
that
we
decide.
Don't
have
a
maintainer,
so
I
don't
know
if
anyone
wants
to
toss
an
approval
on
this.
A
C
A
C
C
A
B
B
So
weber's
is
an
awesome
project.
You
know,
I
love
it.
About
half
of
the
weber's
code
is
open
source
and
the
other
half
is
closed
source
and
the
two
are
very
tightly
intertwined.
So
it's
quite
difficult
to
sort
of
contribute
to
weapons,
and
it's
quite
difficult
to
extend-
and
I'm
not
saying
this
in
a
bad
way.
B
B
A
lot
of
folks
from
the
from
the
weapons
team,
plus
a
few
other
folks
from
cruz
and
other
companies
yeah,
I
think,
there's
probably
four
people
on
the
call
today,
roman
john
esther
and
myself
so
yeah
I'll,
give
a
quick
demo.
You
know
we've
we
forked
from
weber's
in
back
in
sort
of
early
february.
So
the
last
you
know
four
or
five
months.
We've
done
quite
a
bit
of
changes,
we've
added
new
panels.
B
And
we'll
probably
get
around
to
publishing
that
at
some
point,
but
you
know
electron
gives
us
a
few
advantages.
One
is
that
we
can
do
some.
We
can
have
access
to
native
apis,
so
we
can
do
things
like
we
support
native
ross.
One
connections
now,
which
is
a
you
know,
talks
directly
to
the
ros
master
over
tcp,
which
you
can't
do
from
a
browser
and
other
you
know
just
things
like
that
that
we
have
access
to.
B
A
B
There's
browser
compatibility,
so
there's
a
web
build
in
our
repo,
oh
that's
where
it
runs
through
ci
and
everything
just
we
haven't
like
published
that
on
the
internet,
but
you
can
check
out
the
repo
and
build
the
web
version
of
it
and
our
ci
does
that.
So
it's
you
know
it's
there.
It's
just
not
something
that
we're
pushing
right
now,
but
I'm
kind
of
curious
to
hear
from
people
like
you
know.
Some
people
show
up
and
they
have
you
know
they
want
a
browser
version
for
one
reason
or
another.
B
Something
people
have
specifically
asked
for
is
a
browse
submission
so
that
they
can
access
it
on
an
ipad,
but
that's
more
than
just
publishing
a
browser
version
that
would
actually
require
us
to
add
webkit
or
safari
support
so
yeah
anyway.
Just
some
things
like
that,
it
does,
you
know,
supports
live
connections
and
website
connections.
Like
I
said
we
can
do
rosbridge
connections,
we
can
do
ros1
native
connections.
Rust2
is
kind
of
in
progress
at
the
moment
john's
working
on
that
we
have
a
bunch
of
sort
of
work.
B
That's
come
out
of
that
some
feedback
that
we
might
try
and
feed
into
the
ross
bag
project
and
some
things
like
that
when
you
load-
I
guess
you
know
some
of
the
changes.
I
don't
know
how
familiar
people
are
with
weapons,
but
we've
added
a
bunch
of
new
panels.
We
have
layout
management
now,
so
you
can,
you
can,
you
know,
create
layouts,
you
can
create
a
new
layout,
that's
empty,
and
then
you
can
add
panels.
B
So
the
3d
panel
is
sort
of
the
thing
that
people
will
be
most
familiar
with
as
as
being
kind
of
similar
to
others,
and
let's
see
so
I'll,
just
stop
that
playing.
You
can
turn
on
enough
different
topics.
Something
else
we
added
was
support
for
just
decoding
this,
so
this
bag
file
actually
is
out
of
the
udacity
data
set.
So
that's
just
like
an
open
source
data
set
that's
available
online.
B
Let's
see
yeah,
we
added
support
for
just
decoding,
like
validation
scan,
for
example,
like
we
also
support
point
cloud
2,
but
we
added
support
for
just
decoding
follower
and
scan
directly
as
well.
In
case
people
find
that
helpful.
This
you
know
there's
different.
You
can
have
different
transforms
of
that
the
specs
relatively
simple,
so
there's
not
a
ton
in
there.
You
have,
you
know
like
images
you
can
put
on
and
off
like
different
images.
You
can
split
panels,
you
can,
you
know,
set
up
like
like
camera
right
camera.
B
We
support
like
3d,
markers
and
and
image
markers
as
well.
What
else
plots
topic
graph
is
interesting,
although
it
doesn't
work
with
a
back
file,
but
I
think
I
heard
you
guys
talking
about
topograph
sort
of
like
rqt
graph
yeah
a
little
bit
and
then
yeah.
Let's
see
you
can
like
plot
arbitrary
data.
Raw
messages
is
quite
interesting.
You
can
just
like
get.
You
know
any
sort
of
any
data
out
of
it,
so
this
is
all
built
with
the
web
stack.
B
We,
I
guess
also
as
part
of
that
have
written.
Quite
I
mean
it's
all
open
source,
the
we've
written.
Quite
a
few
libraries,
too,
is
kind
of
part
of
this
work,
so
all
of
that's
kind
of
public
on
our
github
as
well,
this
stuff
for
interacting
with
ros
messages
and
ros
bags
and
there's
a
ros
one
kind
of
implementation,
which
sort
of
overlaps
conceptually
a
bit
with,
and
I
always
mix
up
like
ross,
node.js
and
rco
node.js
and
there's
a
third
one
too.
B
But
but
we
have
our
own
one,
which
we
needed
to
make
it
work
with
electron,
because
we
needed
to
have
like
pluggable
transport
layers
so
that
we
can
do
some
clever
stuff
to
feed
the
the
data
through
electrons
like
various
layers
of
security
yeah.
The
other
thing
that's
sort
of
interesting-
I
probably
I
won't
this
like
takes
quite
a
while
to
explore,
but
so
there's
a
there's,
a
thing
called
node
node
playground,
which
this
concept
needs
a
bit
of
iteration.
B
B
Yeah,
you
can
sort
of
like
actually
write
inline
here,
something
that
would
run-
and
you
know,
take-
have
a
look
at
some
incoming
ros
messages
and,
for
example,
like
publish
markers
or
something
like
that.
So
it's
sort
of
like
a
way
that
you
can
write
like
live,
transforms
yeah,
that's
kind
of
interesting.
What
else
we
added
support
for
uids,
yeah,
there's
a
bunch
of
stuff
on
our
roadmap
but
happy
to
answer
any
questions.
That's
probably
like
the
main
overview.
B
B
To
extending
it
is
basically
like
you,
take
the
code
base
and
fork
it,
and
then
you
know
hopefully
you're
able
to
like
rebase
your
changes
over
time,
which
is
pretty
annoying.
We
believe
in
making
this
like
very
extensible,
and
so
we've
just
actually
launched
like
an
extension
api,
where
you
can,
you
can
create
panels
and
publish
them,
and
we
have
you
know
kind
of
a
sort
of
like
an
extension
store
kind
of
thing.
B
This
is
like
the
first
version
of
it
here
so
kind
of
taking
some
ideas
from
vs
code.
I
guess
where
you
can,
you
know
you
can
sort
of
have
the
base
editor,
and
this
is
going
to
give
you
a
basic
set
of
panels
and
all
the
layout
management
and
the
data
management
connections
and
things
like
that
and
then
you
know,
but
you
can
very
easily
kind
of
take
it,
make
it
your
own,
build
your
own
extensions
and
either
publish
them
or
keep
them
private.
A
B
A
B
So
that's
an
interesting
question
with
ross1
and
with
ross
rosbag
one.
We
have
access
to
the
message,
definitions
so
and
and
rosberg
one.
The
message
definitions
are
in
the
bag
file,
so
that
makes
it
nice
and
easy
to
read
and
with
with
rosbridge,
I
think
maybe
john
roman
can
speak
more
confidently
to
this,
but
I
think
the
same
answer.
The
same
thing
was
true
of
ross
bridge
and
the
same
thing
was
true
with
the
ross
one
native
connection.
However,
that
is
kind
of
one
of
our
sticking
points
with
ross
too.
B
D
Can't
talk,
oh,
I
was
just
going
to
say:
yes,
that's
that's
what
I've
been
seeing.
We
lost
all
of
the
introspection
and
also
all
the
check
summing
as
well.
So,
even
if
you
have
a
message
definition,
you
don't
know
if
a
value
had
changed
between
an
n32
and
a
float32,
it's
going
to
silently
decode
the
same.
You
know
if,
if
that
bag
format
had
changed
before
or
after
you
published
it.
A
Yeah,
so
that
that's
interesting
and
I
think
that
that's
something
we're
hearing,
so
I'm
one
of
the
primary
maintainers
of
rosberg
2
right
now,
so
this
good
place
to
start
this
conversation,
I've
got
another
working
group
that
is
on
the
fridays.
It's
tomorrow,
the
ross,
tooling
working
group
where
we
mostly
discuss
ross
bag.
A
So
if
you
want
to
join
us
there
and
talk
about
any
of
these
features,
I
there's
there's
absolutely
no
disagreement
that
we
need
these
sorts
of
introspection
capabilities,
but
we
just
haven't
had
the
development
resources
to
design
it
out
properly
yet
and
build
it.
So
that's
one
of
the
things
that
we
want
to
build
in
for
for
h,
humble
which
is
coming
out
next.
May
I'm
personally
thinking
about
humble
hawksbill
as
ros2
1.0.
I
think
everything
up
to
this
has
been
like
a
real,
solid,
beta
and
so
like
collecting.
D
A
C
A
D
Totally
the
other
set
of
challenges
for
I'm
running
into
myself
is
around
the
use
of
sqlite
versus
a
more
like
flat,
binary
file,
so
in
webviz
and
now
in
fox
glove.
One
of
the
nice
features
that
was
developed
early
on
is
the
ability
to
drag
and
drop
a
bag
file
into
a
web
browser,
and
you
can
start
playing
back
and
seeing
it
supporting
that
is
challenging
in
rossbag
2
using
sql.
I
I
don't
know.
A
So
I
I
have
a
lot
of
thoughts
about
this.
I
don't
want
to
like
derail
the
entire
meeting
onto
talking
about
rosberg
in
the
web
tools,
but
I
would
maybe
we
need
to
have
like
a
little
breakout
meeting
to
because
there's
no
hard
requirement
on
it.
Being
sqlite
3
based
like
the
storage
implementation,
is
a
plug-in
in
rospec2
and
we're
even
working
on
a
way
to
easily
convert
between.
You
know
different
storage
back-ends.
A
There
aren't
a
lot
of
other
ones
out
there
yet,
but
there
could
be
and
we
could
potentially
add
a
conversion
tool
that
would
easily
make
it
you
know
into
a
much
more
web
consumable
version.
So
I'd
like
to
have
that
conversation,
I
think
there's
a
few
different
ways.
We
can
tackle
this
problem
and
it's
good
to
see
those
real
use.
Cases
coming
into
play.
B
A
A
You
know
a
developer
workstation
that
had
the
rost2
code
and
an
installation
of
ross,
and
you
know
on
ross1
it
had
to
be
ubuntu
instead
of
their.
You
know
whatever
windows
or
their
chromebook
or
whatever
and
having
a
purely
web-based
interface
is
a
great
way
to
build
an
operational
or
testing
workflow
around
a
robot
when
you're
talking
about
the
like
non-developer
persona
within
the
company
yeah.
C
Yeah,
I
want
to
second
that
I
I
have
been
asking
adrian
about
exactly
what
that
same
motivation
at
several
yoga.
I
was
the
vp
of
software
at
studio
and
our
biggest
concern.
There
was
operational
efficiency,
and
so
my
team
was
like
60
percent
of
our
time
was
spent
on
building
tools
for
our
ops
folks,
just
just
the
persona
that
you
just
described,
amazon,
so
yeah
anything
that
you
can
give
them.
So
I
was
actually
going
to
ask
you.
C
C
B
Asked
for
that,
it's
it's
probably
some!
It's
probably
something
that
we
want
to
support
long
term.
I
guess,
like
the
things
that
we
need
to
take
into
account
are
there's
a
lot
of
code
in
the
boxed
off
code
base.
You
know
there's
several
years
of
development,
of
like
a
full
team
of
people
that
have
gone
into
it
and
we
don't
want
to
make
all
of
that
sort
of
like
a
stable
api.
B
B
It
could
be
possible
that
there's
some
way
to
sort
of
instantiate
a
version
of
fox
glove
where
you
can
just
sort
of
it's
kind
of
like
you
know,
an
embedded
google
maps
panel
or
something
right
where
you
just
like
have
a
you
know,
a
one-liner
that
boots
it
up
with
a
fixed
layout
with
one
panel
open
and
a
specific
data
source
connection,
or
something
like
that
totally
could
be
possible.
It's
it's.
You
know
it's
work.
B
That
would
need
to
happen
just
to
figure
out
like
what
that
api
is
and
then
because
we're
sort
of
like
committing
to
maintaining
that
over
time,
but
yeah
it's
it's.
It's
definitely
a
use
case
that
I
can
see
value
in
and
that's
you
know
a
lot
of
the
point
of
it
being
open.
Source
too,
is
that
people
can
kind
of
like
just
remix
it
and
use
for
various
things
like
this.
B
B
Everything
right
now
is
open
source,
so,
where
we
intend
to
add
paid
features
is
around
anything
that
that
talks
to
a
backend
so
we're
doing
a
bunch
of
planning
now
around
kind
of
the
ability
to
log
into
a
team
and
have
like
shared
layouts
and
shared
views,
and
things
like
that.
So
again,
that's
something
that
was
really
useful
and
powerful
at
cruise
and
we
and
crews
never
open
sourced
that
part,
because
the
whole
back
end
is
you
know,
I
mean
that's
tied
into
a
bunch
of
other
cruise
things.
B
It
wouldn't
be
possible
to
open
source,
but,
but
you
know,
there's
the
ability
to
kind
of
log
in
and
like
collaborate
more
with
a
team
and-
and
you
know
anything,
that's
kind
of
talking
to
that
back
end
would
probably
be
part
of
a
pay
plan.
The
tool
itself
and
anything
that
you
can
kind
of
do
individually
on
your
computer
would
be
it's
always
going
to
remain
open
source.
A
D
A
B
Yeah
that
worked
well
yeah,
we're
we'd
love
to
collaborate
too.
If
anyone
you
know,
wants
to
check
it
out
or
make
pr's,
and
also
as
as
we
kind
of
get
into
talking
about
the
robot
wave
tools,
libraries,
you
know
it
could
be
interesting
to
talk
about
whether
there's
overlaps
or
gaps
or
certainly,
I'm.
I
already
trip
over
myself
keeping
track
of
the
various
like
ross,
javascript
implementations.
So.
A
Yeah
yeah,
I
mean,
I
think,
there's
definitely
a
possibility
for
taking
some
of
the
common.
You
know
non-uh,
I
don't
want
to
say
non-interesting,
but
sort
of
non-business,
critical
portions
and
turning
them
into
generic
components.
Seeing
where
that
goes,
yeah
anyways
possibility
for
collaboration
definitely.
B
A
Cool
getting
people
back
together.
Let's,
let's
talk
about
the
road
map
and
I
think,
high
level.
The
question
is:
what
road
maps
do
we
want
to
put
together
for
this
working
group?
I
think
we
have
a
general
idea
of
of
the
set
of
libraries.
We
want
to
be
working
on
at
least
to
start
out
with
set
of
projects.
You
know
which
is
basically
javascript,
clients
and
rosbench
protocol
and
maybe
a
couple
of
of
individual
components,
but
it's
mostly
this
infrastructural
stuff
right
like
clients
and
protocol
for
communication.
A
It
seems
to
me
to
be
the
core
of
the
charter
here
and
do
we
want
to
put
together
a
high
level
road
map
for
ross1,
or
are
we
putting
that
into
maintenance
mode?
Given
that
noetic
is
out
and
there's
not
going
to
be
another
rosslyn
distro?
I
guess
that's
a
first
question
personally.
I've
focused
entirely
on
ross2,
but
I
I
want
to
make
sure
that
I'm
being
inclusive
of
everyone's
needs
and
not
just
putting
my
priorities
onto
this.
A
A
E
I
think
hi
this
is
roman,
another
fox
love
person.
I
think
that
finding
a
path
for
ross,
what
we
call
the
ross
message,
ross
message,
serialization
and
ross
bag
libraries
for
ross-
one
to
you
know,
gain
more
prominence,
whether
under
robot
web
tools
or
somehow
would
be
useful.
Some
of
the
genesis
for
kind
of
why
rosbach
js
even
exists.
I
was
first
author
of
it
back
in
cruz
and
we
didn't
find
amongst
the
existing
js
tooling
at
the
time
ways
to
work
with
quote
bag
files
and
just
messages
themselves.
E
C
A
E
Yeah
so
to
some
backstory
ross,
bat.
So
the
first
things
that
when
we
started
to
foray
into
web
tools
into
browser-based
and
javascript-based
tooling,
at
cruz,
both
node.js
and
client,
you
know
side
one
of
the
first
projects
that
we're
involved
in
was
you
know
what
could
we
do
with
bag
files
and
so
a
lot
of
our
thinking
evolved
from
the
rosbag.js
package.
E
But
what
went
into
making
that
package
that
we
didn't
really
find
at
the
time
were
pure
kind
of
idiomatic
javascript
ecosystem
libraries,
for
you
know
doing
the
ros
message.
Parsing
of
the
definitions,
then
serializing
desterilizing
off
of
those
definitions,
so
those
were
like
the
first
building
blocks
we
actually
put
together,
and
I
know
that
there
is
in
gen
message.
There
are
some
javascript
message
generators,
but
they
were
not
consumable
and
certainly
at
the
time
as
like,
published
npm
modules
or
even
as
javascript,
I
think
those
might
have
been
actually
written
in
python.
E
It's
been
a
while,
since
I've
looked,
and
so
that
was
like
a
kind
of
hurdle
and
that's
why
the
native
js,
parsing
and
serialization
deserialization
was
written
kind
of
into
rosbach.js,
so
the
lineage
has
to
trace
to
rosbach.js
kind
of
how
we
got
there.
We've
been
working
on
separating
out
because
we
believe
those
pieces
are
independently
reusable,
but
that's
kind
of
some
of
the
back
story
around
that
and
why
kind
of
even
rosbag.js
exists
with
those
pieces.
If
you
look
at
cruz's
version,
you'll
see
more
history
there.
A
B
See
yeah
yeah,
it's
worth
pointing
out.
I
just
put
a
link
in
the
chat,
but
we
have
a
bunch
of
sort
of
incubation
packages
in
our
fox
love,
studio,
repo
and
we're
in
the
process
of
like
extracting
those
into
separate
repos
and
separate
npm
modules.
So
that's
why
that's
why
the
ros
message
serialization
one
that
you
found
on
github,
has
a
commit
from
two
days
ago,
but
the
actual
code
is
in
the
studio
repo.
I.
A
C
B
A
C
Sorry,
ginger
jack.
The
person
we're
missing
here
today
is
chris
forget
his
last
name
right
now,
chris
smith,
from
formerly
rethink
robotics,
he's
now
at
ready,
robotics
he's
the
main
author
of
rosnel
js,
there's
two
two
serialization
deserialization
methods
there
one
actually
was
originally
written
by
brandon
alexander
who's
at
iron
ox
now,
and
I
took
that
over
and
merged
it
into
ross
node.js.
But
I
think
roman.
I
think
you
and
chris.
C
I
should
connect
the
two
of
you
if
you
haven't
spoken
yet,
because
I
think
it
would
be
really
good
to
sort
of
get
your
heads
together
and
think
about.
Perhaps
the
four
of
us
with
adrian
also
to
think
about
how
to
how
to
maintain
that
going
forward.
I
think
that
the
community
would
really
benefit
from
us
merging
efforts
there,
because
I
I've
taken
a
look
at
what
you've
done
and
john
was
also
kind
enough
to
elaborate
a
little
bit
on
the
differences
on
on
roster's
course.
I
think
that
would
be
a
real.
A
C
They're
currently
separate-
and
I
haven't
talked
to
chris
about
his
interest
in
putting
it
under
the
purview
of
of
this
repo
to
me,
it's
all
semantics
like
it
doesn't.
It
doesn't
really
matter
which
which
repo
it
is
under,
but
I
do
think
one
way
or
another
chris
belongs
into
this
working
group
and
talk
where
we
maintain
it
as
sort
of
yeah,
probably
around
them.
Yeah.
A
We're
using
the
robot
web
tools
organization,
there's
no
strong
requirement
for
things
to
be
mapped
one
to
one
at
the
end
of
the
day,
it
kind
of
comes
down
to
whoever
shows
up
here
and
wants
to
work
on
stuff
wherever
that
stuff
they
want
to
work
on
is
because
you
know
we're
not
we're
not
anyone's
boss,
we're
just
bringing
people
together
who
are
working
on
a
common
set
of
things.
Yeah,
and
I
guess
more
than.
A
I
think
that
the
road
map
is
interesting
from
the
perspective
of
communicating
to
the
community
what
the
priorities
are,
are
and
and
trying
to
bring
people
together
to
collaborate
on
some
of
these
efforts.
So
if
we
say
you
know
we
as
a
working
group
and
there's
you
know
over
a
dozen
people
here
say
these
are
the
most
important
things
it's
possible.
We
can
bring
in
other
other
efforts
as
well.
A
You
know
anyone
who's
looking
for
some
way
to
contribute
or
yeah,
but
like
I
think
that
the
value
we
can
provide
is
yes
getting
getting
people
in
the
same
room
which
already
we've
had
a
few.
I
think
serendipitous
conversations
that
will
unblock
future
development
and
and
then
trying
to
to
an
extent
steer
some
of
these
projects
or
at
least
communicate
their
importance.
A
So
what
I
want
to
do
also
is
is,
I
would
like
to
try
and
have
a
road
map
for
ross
to
humble,
and
that
way
we
can
try
to
decide
as
a
group.
What
we
think
are
the
blockers
for
usability
for
us
to
right
now.
That's
the
way
I'm
trying
to
think
about
it
is
like
what
is
the
gap?
What
is
the
experience
we
have
in
ross,
one
that
that
we're
still
missing
in
ros2
and
or
what
are
we
missing
in
both
of
them?
B
B
So
I
would
assume
so
that's
like
statement.
One
feel
free
to
push
back
on
it.
So
if
you,
if
that
is
true,
then
most
of
our
concerns
that
relate
to
like
the
timing
of
ross
releases
are
probably
going
to
be
things
more
about,
like
you
know,
like
john's
point
like,
can
we
get
some
work
into
ross2,
h
or
whatever
it
is
to?
You
know,
allow
ross
to
give
us
some
way
to
receive
the
message.
Definitions
or
stuff
like
that,
like
is.
A
So
I
think
that
there
there
is
a
boundary
there
where,
where
the
sync
stops
to
make
sense,
so
I
think
that
rcl
node.js
or
the
roster
client
library
that
runs
on
the
native
side.
I
think
that
that
you'll
want
to
pair
with
the
distro,
because
it
matches
up
with
the
native
apis,
but
then
you've
got
the
other
side
of
it,
the
javascript
or
sorry,
the
browser
javascript
side,
client.
A
So
I
think
it
makes
sense
for
the
you
know
the
node.js
client
to
to
have
have
a
roadmap
map
times
the
distro,
and
I
think
it
makes
sense
for
us
to
think
about
what
core
tooling.
We
need
on
the
native
side
to
help
us
build
the
more
generic
and
cross-distro
capable
functionality.
We
need,
because,
right
now,
I
think
that
doing
things
across
you
know
across
distros
is
difficult,
and
some
of
that
just
has
to
do
with
the
maturity
and
stability
of
rost2s
project.
A
A
B
A
B
E
E
A
Yeah
to
jump
back
like
the
the
rust
bag
use
case
is
different,
like
I
was
thinking
about
the
the
native
transport
use
case
and
in
rosberg
2
we
try
to
make
a
distinction
between
the
the
bag,
functionality
and
the
transport
layer
that
actually
talks
to
rust,
too
and
has
communications
there.
One
of
the
interesting
things
is
is
given
that
the
the
the
middleware
implementation
is
is
a
generic
api
and
can
be
it's
under
the
hood.
You
know
you've
got
dds
by
default,
but
there
are
other
options.
A
That's
why
it's
nice
to
have
the
you
know
rcl
as
a
a
common
common
core
to
that,
because
you
know
we
it's
going
to
be
hard
for
us
to
well.
We
can't
necessarily
expect
that
a
raw
system
is
running
dds
and
then
you
know
grab
the
that
particular
serialization
format
and
communication
protocol
in
the
browser,
but
in
terms
of
the
ros
bag
itself,
we
try
to
keep
that
separated
and
it
might
make
sense
to
have
parsing
libraries.
A
A
I
mean
sony
built
a
level
db,
implementation
of
the
storage
backend
and
since
plugin
based
that's
easy
to
do.
You
can
just
ignore
the
sql
implementation,
but
we
could
have
other
formats,
and
so
that's
why
the
the
plug-in
based
nature
of
these
tools
makes
these
conversations
a
little
bit
more
complicated.
A
Which
is
why
I
like
trying
to
get
all
more
of
these
working
groups
going.
It
just
helps
with
cross-pollination
of
ideas.
I
mean
we've
got
a
few
out
there
that
are
a
little
bit
less
application
focused,
but
are
super
useful
too,
like
you
know,
you've
got
the
navigation
group.
The
the
control
working
group
are
two
that
are
actually
actively
building
products.
There
are
a
few
others
that
are
more
just
discussion,
forums
that
I
haven't
seen
as
much
output
from,
but.
B
Yeah
something
that
is
probably
worth
noting
on
on
the
thought
about
you
know
how
roster
is
a
lot
more
pluggable
and
modular
actually
presents
more
of
a
challenge.
I
think
for
us
working
in
the
web
tools
than
anything,
because
you
know
like
we're
in
ross
one.
It
was
usually
just
you
know,
implementing
one
we're
not
building
a
robot
right,
and
so
it's
not
we
don't
everyone.
Building
a
robot
can
just
like
pick
an
implementation
and
move
on
with
their
life
for
us
building
tools
that
interact
with
that.
B
Now
we
have
to
like
deal
with
the
kind
of
product
of
every
possible
combination
of
these
various
plugins
that
people
are
using
so
yeah.
I
don't
know
what
the
solution
is
there,
but
it's
just
something
to
note
and
something
that
we've
kind
of
noticed,
as
we
try
to
add
ross
to
support.
Is
that
even
you
know
even
we're
thinking
about
rosbag.
B
I
don't
know
if
other
people
building
web
stuff
have
noticed
that
it's
probably
less
of
an
issue
if
you're
building
like
tools
internally
for
a
company
because
you're
still
only
dealing
with
like
you
know,
one
set
of
choices,
but
if
you're
trying
to
build
generic
tools
for
the
ross
ecosystem,
it's
yeah.
It
makes
life
rather
difficult.
D
A
D
A
I
feel
like
we
still
have
a
ton
to
talk
about,
but
we're
reaching
the
end
of
our
hour.
How
does
everyone
feel
about
this
day
and
time
I'd
like
to
get
a
recurring
meeting
on
the
calendar
rather
than
having
to
do
a
doodle
for
each
one
yeah
anyway?
Anyone
think
this
time
was
not
very
good.
The
last
one
we
didn't
like
this
one.
I
like
better,
okay,.
C
A
Yeah
I'll
schedule
another
one,
two
two
weeks
from
now
same
time
same
day,
and
if
we,
if
we
like
the
two
week
cadence
then
we'll
stay
with
that.
If
we
decide
to
go
to
once
a
month
at
some
point,
we'll
see
about
that
at
the
moment,
we're
still
early.
In
the
conversation
I
have
time
to
talk
about,
so
I
think
two
weeks
is
good.
A
So
I
will
say
yes,
two
weeks:
okay,
I'm
not
sharing
my
screen
anymore,
but
I'm
just
writing
notes.
If
anyone
has
any
any
notes
from
the
meeting,
please
feel
free
to
dump
them
in
here.
I
basically
just
hit
okay
on
on
edits,
so
feel
free
to
take
notes
during
the
meeting
or
afterwards-
and
I
will
put
the
next
meetings
block
there.
B
Something
that
something
that
might
be
interesting
for
folks
to
bring
to
the
next
meeting
is
like.
Are
there
requests
or
specific
pain
points?
People
are
having,
because
I
feel,
like
we've
talked
a
lot
from
I'm
sorry.
If
I've
like
hijacked
the
meeting
too
much
but
like
we've
talked
a
lot
from
the
implementation
perspective,
but
if
folks
are
kind
of
struggling
with
something
or
they
wish,
the
library
did
x
or
yeah
it'd
be
great
to
hear
from
people
who
are
like.
B
A
I
think
that's
a
good
perspective
to
come
at
it
from
so
I
have
this
drive
folder
that
I
have
that
the
meeting
notes
live
in
and
I've
created
another
dock
there
just
called
road
maps
which
doesn't
have
any
contents
in
it
right
now,
but
if
you
want
to,
if
anyone
wants
to
just
toss
like
yeah,
I
think
I
think
use
cases.
It's
a
really
good
way
to
approach
it
actually
like.
A
If
there
are
things
that
you
want
to
have
supported
that
are
not
supported
right
now,
that's
a
great
way
to
inform
a
roadmap
rather
than
talking
about
sort
of
features
from
an
implementation
perspective.
I
think
it's
way
more
useful
to
think
like
what
do
we
want
it
to
do,
and
then
we
can
figure
out
what
features
are
needed
to
support
that
and
that
can
yeah
inform
future
conversations
like.
B
A
Yeah,
I
mean,
I
think,
if
we
just
get
everyone
to
throw
in
their
important
things
here,
maybe
we
can
then
get.
You
know,
gather
thumbs
up
on
them
and
figure
out
what's
most
important
based
on
that.
Well,
I
got
problems
yeah.
We
all
got
problems:
okay,
yeah
thanks.
Everyone
really
good
meeting
great
conversation,
and
I
will
see
you
all
again
in
two
weeks.