►
From YouTube: ROS WebTools Working Group (2021-07-15)
Description
Third meeting of the working group.
Very sorry! I forgot to start recording until 20 mins in.
Topics of discussion:
* Rover Robotics discussion on new Rover Mini product
* Foxglove browser-build release announcement
* ROS simulator options - off-topic but interesting
* ROS2 web bridge nodejs builds
* Message Definitions "on-the-wire"
* Dheera showed us his tools ROSboard (browser visualizer) and ROSshow (terminal visualizer)
A
C
And
yeah
well
that
well
that's
going
if
anyone
else
has
any
questions
about
the
specs
of
the
robot
or
about
how
it
works.
It'll
it'll,
be
to
add
your
own
computer,
you
just
plug
in
an
ethernet
cable
and
then
the
robot
will
provide
power,
we're
trying
to
get
it
so
that
it
provides
either
battery
power,
12,
volts
or
5
volt.
So
you
can
power
most
computers.
B
The
latest
and
greatest
in
open
source,
robotics
hardware,
so
yeah
coming
up.
We
will
have
a
launch
page
on
our
website,
rover
robotics.com
within
the
next
week
or
two,
and
we
have
a
kickstarter
going
live
on
september
1st.
So
please
check
it
out
if
you
get
a
chance
and
thank
you
for
letting
me
do
that
again.
Yeah.
A
Thanks
for
the
recap,
davis,
I've
now
added
to
the
the
meeting
agenda
start
the
meeting
recordings.
The
first
items
process
fix
brain
okay.
So
where
were
we
before
that
interruption?
I
think
we
were
talking
about
message
definitions.
Do
we
want
to
jump
back
into
that?
Or
did
we
want
to
talk
briefly
about
the
web
deployment
for
foxglove?
First.
D
Oh
yeah,
we
can
mention
that
that's
just
more
of
an
fyi
sorry
about
the
background
noise.
Here
we
foxglove
studio
has
always
supported
a
web
build,
but
we
only
just
recently
actually
deployed
that.
So
we
are
still
sort
of
mostly
encouraging
folks
to
download
the
actual
desktop
electron
app
because
it
has
a
few
more
features
like
connecting
to
live
roswan
systems
over
tcp,
which
is
something
we
can't
do
from
the
browser,
but
we're
gonna
start
sort
of
making
the
web
build
a
bit
more
available
and
a
bit
more
supported.
D
C
D
Yeah
yeah
I'd
be
asking
yeah.
I
think
this
came
out
last
week
too.
So
the
main
thing
so
fox
club
studio
will
always
as
it
is
today,
will
always
be
a
free,
open
source
product
and,
and-
and
you
know
what
we
have
published
today
will
always
be
free.
Where
were
you
planning
to
charge
us
around
team
features
so
logging
into
a
team
having
layouts
that
are
shared
among
team
members
being
able
to
share
views
among
team
members,
possibly
getting
into
things
like
being
able
to
add
comments
and
metadata
and
stuff
around?
D
You
know
data
that
you've
recorded,
so
those
are
things
that
sort
of
become
really
interesting.
Once
you
have,
you
know
companies
and
like
10,
plus
people
working
on
the
same
project,
but
you
know
for
people
that
want
to
use
or
or
download
or
run
studio,
it's
that
that
part
will
always
be
free
and-
and
you
know,
obviously,
it's
open
source
people
are
welcome
to
it
and
do
whatever
they
like
with
it
as
well.
D
On
the
kind
of
app
store
thing,
we
are
building
an
extension
kind
of
registry.
We
haven't
really
put
any
thoughts
into.
You
know
whether
people
might
want
to
like
make
commercial
extensions
or
anything
like
that.
It's
certainly
plausible,
but
for
now
the
extension
registry
will
look
a
bit
more
like
what
you
get
from
visual
studio
code,
where
it's
just
you
know,
you
go
to
the
sidebar
and
store
whatever
extensions
you
want,
and
in
the
early
days
all
of
the
extensions
will
just
be
sort
of
like
you
know,
free
on
github.
D
If
people
have
published
them,
yeah
couldn't
rule
out
that
they
could
be
sort
of
like
an
app
store
model,
but
I
would
have
to
like
see
if
people
actually
were
interested
in
charging
for
extensions,
but
yeah.
We
do
care
a
lot
about
the
extension
support
because
I
think,
like
you
know
not
under
any
delusion,
that
the
fox
love
the
core
product
will
be
able
to
solve
100
of
everyone's
needs.
A
So
you're
talking
about
maybe
using
fox
glove
or
some
other
solution
for
a
rover,
robotics
front
end
for
the
robots,
I'm
wondering
if
you
have
an
open
software
stack
and
potentially
a
gazebo
model
for
the
robot
such
that
members
of
the
community.
Here
could
possibly
help
out
with
that
effort
before
the
release
it.
Actually,
you
know
before
someone
can
actually
have
a
physical
robot
in
hand.
C
A
Gotcha,
because
I
think
you
could
definitely
have
a
pretty
solid
workflow
between
a
gazebo
simulated,
you
know
rubber,
mini
and
hooking
that
up
to
a
web
interface.
In
order
to
get
you
a
lot
of
the
way
there
before
you
can
have
a
robot
in
hand,
yeah
that
actually
may
be
a
nicer
development
workflow
in
terms
of
iteration,
without
deploying
to
a
bot.
D
A
D
A
A
So
it's
still,
it's
kind
of
in
line
with
no
it'll
go
on
a
little
bit
beyond
foxy
yeah,
unfortunately,
that
ross
and
his
evo
releases
don't
line
up
in
any
meaningful
way,
but
yeah
gazebo
11
will
last
past
the
end
of
life
for
foxy.
So
it's
still
relevant,
but
I
think
the
majority
of
new
feature
development
is
going
into
ignition
gazebo
and
it
looks
like
that's
a
complete
rewrite
in
the
same
way
that
rust2
is-
and
I
think
it's
I
haven't
used
it
much
myself.
A
Some
reports
have
heard
is
that
it
still
feels
like
an
early
product.
It
needs
some
polish
and
bug
fixing
and
stability
work,
but
potentially
based
on
the
new.
You
know,
re-architecture.
It
has
a
lot
of
promise.
That's
that's
what
I
can
say
my
understanding
of
the
situation.
I
don't
know
if
anyone
else
on
the
call
has
a
different
perspective.
E
E
A
Yeah,
so
the
way
I
understand
it
is
that
the
ignition
suite
of
libraries
acts
as
a
set
of
apis,
so
you've
got
the
ignition
rendering
api
and
you
can
plug
in
various
rendering
engines
under
that,
rather
than
having
something
like,
for
example,
ogre
in
the
original
gazebo
be
tightly
tied
into
the
core
code.
So
if
you
wanted
just
to
write
another
renderer
plug-in
you
could
you
could
have
a
different
graphics
engine
than
the
one
that
ships
by
default
same
with
physics
yeah.
So
so
that's
that's
my
understanding.
E
Does
anybody
know
it
are
they
then
trying
to
include
the
new
open,
open,
3d
render
that
was
just
announced
like
last
week
or
whatever?
Is
that
I
don't
know,
because
I
know
I
noticed
open
robotics.
At
least
the
twitter
account
keeps
talking
about
the
open
3d,
this
new
renderer
released
by
amazon.
It's
it's
a
whole
coalition,
a
bunch
of
people
but
that'd
be
interesting.
I
didn't
know
that
it
was
a
plug
and
play
type
thing
with
the
render.
A
E
A
A
A
Funny
yeah,
I
I
definitely
know
a
lot
of
projects
use
unity
and
some
people
try
to
do
integrations
with
unreal.
I've
seen
ross
unreal
bridges,
ross,
unity,
bridges,
none
of
them
are
as
as
mature
as
the
like
ross
gazebo
bridge,
but
that
makes
sense,
given
that
you
know,
even
though
they're
completely
separated
teams
and
projects
at
least
they're
coming
from
the
same
organization.
E
A
Yeah,
it's
a
distributed
pub
sub
system
also,
I
mean
same
with
gazebo
to
an
extent
like
it's
also.
You
know
pub
sub
system
just
different
type
of
transport
yeah,
so
I
guess
yeah,
the
the
the
original
start
of
that
conversation.
There
was
nick
davis
once
you
have
some
gazebo
resources
for
the
rover.
Many
will
all
be
at
least
I'll
personally
be
happy
to
see
it.
So
whenever
you
got
that
put
some
links
and.
A
That
something
that
would
be
a
possibly
interesting
conversation
for
this
group
would
be
browser-based
front
ends
for
these
simulators.
You
know
you
could
run
the
simulator
natively
somewhere
and
have
a
front
end
just
like
we're
doing
with
I
mean
I,
I
assume
adrian,
that
you've
thought
about
this
with
foxglove
of
hooking
it
up
to
the
simulation,
not
just
the
live,
robot.
A
Okay,
but
even
though
this
isn't
a
simulation
working
group
will
probably
pull
us
back
to
the
message.
Definition
topic
that
we
started
to
talk
about.
It
sounds
like
it's
pretty
important
for
you
know
not
having
to.
If
you
want
to
have
especially
this,
no
install
a
browser-based
or
electron-based,
which.
A
But
maybe
you
don't
need
to
have
ros
installed
being
able
to
get
access
to
your
data
in
a
meaningful
way
there
without
having
to
build
it
all
in
ahead
of
time
needs
to
have
this
message.
Definition
thing.
I
think
that
would
be
really
useful
for
us
to
have
a
conversation
with
the
middleware
working
group,
which
is
largely
core
open,
robotics
team,
william
woodall
runs
it
and
my
understanding
is
they
generally.
A
A
A
Are
definitely
issue
trackers,
there's
if
you
go
to
github.com,
that's
sort
of
the
top
level
issue
tracker
for
the
project
that
tracks
you
know
ross2
spanning
features
which
this
might
be,
then
you
know
you've
also
got
individual
issue
trackers
on
on
every
single
one
of
the
micro
repros.
That
makes
up
the
whole
project.
D
A
H
D
We
can,
we
can
do
a
write-up,
you
know,
google
doc
or
something
just
just
kind
of
explaining
the
how
we
see
the
issue
as
a
regression
from
ross
one,
and
you
know
some
potential
solutions,
the
other
so
yeah.
So
one
of
the
issues
this
thing
around
being
able
to
like
dynamically
request
message:
definitions
from
a
running
node
so
that
we
don't
need
them
in
advance.
The
other
thing
that
might
be
more
worth
discussing
with
this
group
is
the
ross.
D
Actually
you
guys
looked
into
this
more
than
I
have,
but
the
ros
ii
web
bridge
a
websocket
server
as
written
in
node.js.
It
sounds
like
it's
not
a
great
kind
of
user
experience
for
someone
setting
that
up
like
the
ros
one
web
bridge,
you
just
install
the
node
and
run
the
node,
and
now
you
have
a
websocket
server
running,
but
the
ros2
one
sounds
like
you
know
you
sort
of
have
to
have
this
node.js
dependency,
and
then
you
have
to
build
it.
D
You
have
to
run
npm
install
and
a
bunch
of
things,
so
we
were
sort
of
looking
around
it.
I
don't
know
who
wrote
that
and
how
much
effort
there
is
behind
it,
but
and
why.
Whether
there's
kind
of
context
on
like
why
the
decision
was
made
to
move
away
from
that
being
in
python
and
just
being
sort
of
like
easier
to
install
for
typical
ros
folks.
A
Yeah,
we
don't
have
g
on
the
call
who
has
a
lot
of
context
about
the
existing
tools.
Is
anybody
here
familiar
with
the
roster
web
bridge
sounds
like
not
theoretically,
there's
not
like
a
fundamental
problem
with
there
being
a
node.js
package,
although
I
don't
know
that
right
now,
like
today,
colcon
knows
how
to
build
a
node.js
package,
but
in
theory
it
should
be
able
to
it's
meant
to
just
be
a
build
manager.
A
That
calls
builds
for
various
types
of
projects
someone's
been
working
on
a
cargo
build
for
rust
and
right
now
out
of
the
box.
It
does
cmake
and
python
setup
tools
based
packages.
So
why
not
a
nodejs
node-based
package,
you
just
have
to
add
a
package.xml
file,
but
then
beyond
that
you
shouldn't
have
to
make
it
into
a
cma
project
or
anything.
I.
I
Actually
think
it
would
be
good
if
there
was
like
a
good
documentation.
Example,
I'm
not
a
super
experienced
node.js
developer.
I've
touched
on
it
but
like
it
would
be
nice
if
there
was
like
an
example
of
how
to
build
a
ros
package
in
node.js
that
sort
of
just
works.
If
you
drop
it
into
colcon,
and
it
should
automatically
do
all
the
npm
install
and
everything.
A
D
It's
also
like
you
know,
is
it
possible
versus
it
easy
for
people
like
you
know
if
the
majority
of
ross
developers
have
never
seen
a
node,
that's
outside
of
c
bus,
processor
python,
we're
just
adding
you
know
a
whole
stack
of
extra
app
dependencies
that
they
need
to
install
and
a
whole
lot
of
stuff.
That
seems
like
it.
Just
could
be
simpler
if
it
was
just
you.
A
H
A
A
H
A
G
A
H
F
G
Yeah
connecting
it
back
to
the
earlier
topic
about
introspection
of
a
live
system.
That
is
how
fox
club
studio
works
with
roswen.
Today
it
connects
it
discovers
all
the
topics.
It
downloads,
the
message,
definitions
as
it
connects
to
topics,
and
it
can
parse
everything
on
the
fly.
We'd
love
to
get
to
feature
parody
with
ross2
to
say:
ross2
works
just
as
well
as
ross
one.
G
I
think
they're
up
earlier,
for
our
you
mean
like
the
ross
one.
We
don't
have
the
the
ross
one
library
published
outside
of
our
monorepo,
yet
we
plan
to
move
it
as
an
independent
package.
That's
the
last
one,
but
it's
an
all
independent
implementation.
We've
we
used
roslib
in
with
the
websocket
bridge
currently
because
we
haven't
made
kind
of
our
own
typescript
version
of
that.
But
for
all
other
things
and
even
the
message
parsing
whatnot,
we
have
our
own
separate,
smaller
modules
and
implementations
of
that.
So
roslift
doesn't
have
tcp.
G
F
F
H
H
G
With
that
approach
in
the
past,
it's
what
allowed
us
to
also
experiment
with
different
tools
and
make
our
own,
and
so
we
hope
that
the
same
can
apply
for
others.
They
can
just
take
these
individual
pieces
if
they
want
to
make
their
own.
You
know,
bag,
parsing
tools
or
live
connection
tools,
or
something
that
you
know
go.
C
G
D
C
Could
could
one
solution
be
just
increase
the
number
of
messages
that
ship
with
ross
like,
if,
like
we,
have
our
own
custom
messages,
so
that
would
be
a
problem
for
us,
but
if
we
had
some
way
of
of
shipping
our
custom
messages
with
ross,
then
then
it
might
leave
it
might
get
rid
of
that
problem.
Do
you
know
how
that
work
process?
Does
anyone
know
how
that
process
works
right
now,.
G
G
A
Suite
that's
what
gets
built
in
yeah.
That's
what
we
yeah!
That's
it,
and
that's
I
mean
that
in
terms
of
talking
about
process,
that's
they
call
those
variants
and
it's
just
a
meta
package.
So
if
you
go
to
the
roster
variants,
repo,
which
I'm
linking
right
now,
you'll
see
that
there's
a
package
there
called
desktop
and
it's
xml
defines
what
gets
pulled
in.
H
It
also
was,
there
was
a
little
bit
of
discussion
of.
Can
we
just
expand
the
common
message?
Types
and
people
will
be
good
to
use
those.
I
think
definitely,
the
more
that
there
are.
The
more
people
can
just
do
out
of
the
box.
That's
great,
but
I
think
there
will
always
be
especially
for
larger
projects
and
companies.
There
will
always
be
a
need
for
custom
types
that
represent
more
closely.
H
You
know
what
they're
actually
doing
if
it's
a
in
a
perception
system
like
a
tracked
object
or
something
like
that,
that
has
custom
metadata
fields,
whatever
sort
of
custom
thing
will
they'll
need
to
type
for
it,
and
it
would
be
great
if
they
any
of
the
web
tools.
They
can
just
sort
of
start
using
them
without
a
bunch
of
additional
setup.
A
Yeah
so
yeah
I
mean,
I
think
we
all
agree
and
I'm
double
motivated,
because
I
want
message:
definitions
for
ross
bag
as
well,
because
I'm
I'm
working
on
on
that
project,
and
so
I've
added
it
as
an
action
item
here
to
attend
the
middleware
working
group,
which
is
in
two
week
it'll
be
the
day
before
our
next
meeting.
So
maybe
we'll
have
an
interesting
conversation
that
we
can
recap.
D
A
A
A
A
H
A
A
A
A
A
I
Be
enough
and
I'm
happy
to
go
into
more
detail
because
I
have
some
more
things
planned
out.
That'll
probably
be
done
by
next
time,
so
you
know
like
I
think
you
know
I
guess
in
terms
of
jumping
on
the
bandwagon
for
like
web.
This,
like
web
visualization
tools
here,
like
that's,
always
been
sort
of
a
pain
point
of
mine.
So
you
know
without
really
I
don't
wanna,
since
we
only
have
five
minutes.
I
I'm
not
gonna
tell
you
all
the
backstory
behind
this,
but
this
is
like
basically
been
a
long-standing
project
of
mine
that
I
just
recently
revived.
It
is
also,
I
guess,
a
web
visualization
tool
for
ross
topics.
It's
right
here
at
my
name,
slash
rossboard
on
github,
so
off
the
bat
it
supports,
ross2
and
ros3,
I'm
sorry
ross1
and
ross2.
At
the
same
time,
the
whole
idea
here
is:
you
should
be
able
to
just
literally
just
click
on
some
topics
and
get
some
visualizations.
I
So
that's
what
this
is
all
about.
One
of
the
things
that
I
have
been
generally
trying
to
do
is
try
to
make
this
like
really
mobile,
capable.
So
you
know,
if
you
see
on,
I
think
my
screen
is
blurring
here,
which
I
can
disable
yeah
so
like.
Basically,
this
this
should
be
able
to.
You
know
my
phone
got
off
the
wi-fi
here,
but.
I
We
go
so
there
it
is
in
the
phone
and
and
there
we
go.
You
know
three
cameras
streaming
on
on
a
phone
web
ui
right
there.
So
you
know
one
of
the
things
I
really
like
to
do
is
to
be
able
to
walk
around
with
a
robot
and
look
at
the
occupancy
grid.
Look
at
the
map!
So
that's
what
this
is
about.
Ross
board
is
a
ross
node.
So
you
just
put
it
in
your
you.
I
Can
you
can
run
it
directly
if
you
want
right
off
the
repo
or
you
can
install
it
to
your
robot,
either
in
roswan
or
ras2
and
it'll
just
be
a
web
server
on
your
robot.
You
just
pick
up
your
phone,
go
to
your
robot's
ip
call
in
port
8888
and
you
can
just
click
on
ross
topics.
So
I
also
do
want
to
add
you
know,
publisher,
you
know,
for
you
know,
being
able
to
actually
joystick
the
robot
right
off
the
phone
and
a
few
other
tools
like
that.
I
Oh
by
the
way,
this
is
also
something
I've
always
wanted
is
d
message,
because
sometimes
you
know
you
know,
like
here's,
a
random
usb
device,
I'm
gonna
plug
it
in
and
you'll
see
that
show
up
right
there.
So
I
I
know
we
had
issues
with
like
realsense
usb
cables
and
things
so
I
wanna
see
you
know
what
else
we
might
want
to
add
to
this.
One
of
the
cool
things
is
like
this
is
mostly
it's
vanilla,
js
plus
some
jquery.
I
It's
all
bsd
license
so
yeah,
I'm
hoping
to
package
this
up,
but
it
also
in
the
build
farm,
because
it
is
a
ross,
node
and
yeah.
There's
only
thing
is:
there's
one
configure
script
to
either
ross
one
or
roster
it'll
turn
this
into
the
ross
package.
But
if
you
don't
want
to
use
this
package,
you
can
just
use
the
run
script
it'll
just
work.
I
This
makes
use
of
ross
pi
2,
which
is
another
library
I
wrote,
which
basically
allows
you
to
say:
import,
rospi
2
as
rospi,
and
then
use
the
ros1
api
to
talk
to
ros2.
It's
just
like
basically
a
polyfill
for
roster
that
does
the
ros1
type
api,
so
that
allowed
me
to
actually
make
this
ros1
roster
compatible
in
literally
five
minutes
and
just
another
plug
for
another
tool.
I
wrote,
which
is
not
a
web
tool,
but
this
in
the
spirit
of
remote
debugging.
I
Yeah,
oh
yeah
yeah,
so
like
basically
I
mean
it's
it.
It
even
allows
you
to
fall
back,
so
this
is
actually
using
unicode
braille
dots
to
do
the
to
do
the
lighter
points
and
you
know
sometimes
you're
on
a
really
old
terminal
that
doesn't
support
unicode
and
it
actually
does
have
a
strict
ascii
fallback.
So
yeah,
it's
like.
Basically,
I
I
just
want
to
make
it
like
that
easy
for
people
to
visualize
stuff,
so
yeah,
that's
that's!
My
plug
ross
board
does
support
lidar
scans.
I
I
That
the
so
ross
show
right
now,
I'm
in
the
process
of
porting
it
to
ross2.
You
also,
you
already
see
some
evidence
of
that
in
the
repo,
but
there's
currently
already
preliminary
support
for
roster,
but
I'm
still
working
on
implementing
the
verb
command
so
that
you
can
actually
do
ros2
show
some
topic
and
it
should
actually
just
show
it
because
that's
possible
in
rotsu.
That's
not
fully
implemented
yet,
but
also
also
probably
should
be
done
within
the
next
next
next
few
weeks,.
I
Yeah,
so
I
I
I
like,
that's
definitely
an
issue,
so
what
I,
what
I
do
with
ross
board
right
is
because
it's
actually
running
as
a
ross
node.
It
expects
you
to
have
sourced
all
your
message,
files
that
you
plan
to
be
using
and
as
long
as
you
do
that
you
can
just
desterilize
them
because
it
it
actually
just
uses
a
proper
raw
subscriber.
It
doesn't
intersect.
I
I
No,
it's
just
doing
a
ros
topic
list
of
its
own.
It's
just
it's
just
doing
the
get,
get
messages
and
message
types
whatever,
and
it's
because
like
as
long
as
long
as
you
do,
you
know,
source
your
devel
setup
that
bash
and
run
raspboard
as
part
of
your
dev
environment
or
your
robot
environment.
Then
you
should
have
all
your
message
files
in
it.
I
guess
yes,
if
you're
going
to
view
a
ros
bag
offline
on
some
other
machine
that
doesn't
have
the
message
files
yeah.
I
I
guess
that
could
be
a
little
bit
of
an
issue.
I
was
thinking
of
potentially
having
ross
board,
scrape
all
of
opt
ross
and
look
for
message
files
and
then
import
them,
like
basically
dynamically
add
them
to
the
python
path
that
might
be
something
to
implement
for
later.
But
since
my
my
my
like
personally,
my
intent,
initial
use
for
this
was
less
about
rosbach's
and
more
about
being
able
to
view
robot
data
live.
D
A
A
It
and
we've
also
got
the
rostu
tsc
meeting
today,
so
I
will
be
reporting
on
the
the
this
working
group
there,
so
they
they're
aware
of
us
and
we're
actually
going
through
a
little
conversation
as
to
whether
to
make
this
a
a
tsc
official
working.
I
think
we
just
need
to
take
a
quick
vote.
I
don't
think
anyone's
opposed
so
probably
will
be.