so just your name and where you were
born and when
my name is brian gerke and i was born in
december 1976
in uh at the han air force base in west
germany
and where did you go to school there
stayed there for
well i stayed there for a couple of
years uh before moving on and my my dad
was in the air force so we moved around
a fair bit lived in north carolina
southern california
lived in madrid for a couple of years uh
ended up in the south
went to high school in rural georgia
how did you get interested in science
and engineering
i've always been been interested in
computers i knew
from pretty early on that i i wanted to
do something with computers when i was
in
third grade my dad brought home an apple
2gs i think it was it was the kind that
was
it didn't have a screen it would fit it
but it could just barely fit inside a
briefcase so he would carry it to and
from work and when he brought it home he
took it up to our tv
and then we you know we could play games
on it right programs and basic
um so when it came time to go to college
i
you know said i want to go into computer
engineering
i remember in college not not being able
to connect at all with people who
couldn't pick a major
when i applied i wrote i'm going to do
computer engineering and then four years
later graduated with a degree in
computer engineering the whole idea of
wandering around and
not knowing what you wanted to do was
totally foreign to me and so where did
you go to college
tulane tulane university in new orleans
i got my degree from a
department that no longer exists because
in the wake of hurricane katrina they
closed the school of engineering
and um did you go on to graduate school
after that
i did so i got i got interested in
robotics at tulane
um there was a young assistant professor
there named jim jennings who had just
come out of cornell
out of bruce donald's group so he
started a robotics lab at tulane
and some of my friends were helping out
in his lab
we were all undergrads he had a couple
of grad students as well and just so as
an undergrad
i started to sort of be on the the
fringes of the group that was
hacking on robots in his lab ended up
doing my senior
thesis under his supervision with robots
and when it came time to graduate i
um you know i looked at my options which
were to go get a real job or
stay in school and i'd i'd done real
jobs before so that and that didn't seem
like that much fun so
i applied to graduate school and ended
up at
in the interaction lab at usc down in
los angeles
and what were some of the projects that
you were doing in tulane with the group
it was mostly on multi-robot
coordination which turned out to be a
theme
of the work that i did in graduate
school so the particular
let's see my thesis was actually on
handing off tasks between robots
so the idea is that one robot was trying
to do something and these are pretty
simple mobile robots so the thing it was
trying to do was
like push a box across a room so it
would get the box pushed part way across
the room and then
be called off to do something else and
hand off that task to another robot
which would come and finish it and but
also
we we did a lot of work on the
middleware so
these robots came with not very good
software so we spent quite a lot of time
building up the software infrastructure
that allowed you to to program the
robots to do what you wanted them to do
what kind of robots were you working
with these were rwi
b14s they were trash can wrote
the trashcan robots they stood about
this tall this big around
and what year did you finish it tonight
98.
and um so uh what kind of robotics was
going on at usc when you got there
so when i got to usc uh i joined maya
matarix group there
she had recently moved there from from
brandeis and before that she was in rod
brooks group at mit
so she was really at the forefront of
behavior-based
robotics in particular with multi-robot
systems so her the focus of her lab was
how to program groups of robots to get
interesting behavior and that was very
much in line with the kinds of things
that
i had been doing and that i was
interested in so i
joined up there um at the time she had
about four of the these robots that were
called
r2s they were the followings they are
ones that she used in her thesis work
and those we were programming those to
do various things
but we were starting to get more
sophisticated robots
we got the pioneer ones and pioneer twos
from
active media and those became the sort
of workhorse mobile robots
in our lab were there specific
applications that you
were interested in well you know in
academia applications are often
secondary or
tertiary or non not in the picture so
it was for me i was more interested in
the um
in the science of organizing teams of
robots so
and that was something that i always
struggled with was what's a motivating
application
if i'm if i'm going to organize this
group of robots to do something what
should i have them do that
actually makes it worthwhile to organize
them
we tended to use placeholder tasks so if
the
you know if i imagine that these robots
might be useful in a warehouse well
i'll have them push a cardboard box
across a room and say that that was kind
of like material handling and
or if i imagine a security robot well
i'll have a robot that
patrols and goes to fix points around a
pen
and the idea is that you pick those
tasks and they have all the same
features as
that that task that you think is useful
in the future will one day have
and what were some of the technical and
scientific challenges that you were
working on in those tasks
uh you know it they they kind of fell
into two groups so
one on the one hand you had the the
scientific challenges so
if you're coordinating groups of robots
then the biggest issue is scalability
how do you how do you design a
decision-making process
that will get the behavior you want from
a potentially very large group of robots
uh in a reasonable amount of time
because you know from the start that it
doesn't make sense to take in
all say that let's say all the sensor
information from all the robots
and then centrally plan what all that
what they're all going to do and then
disseminate commands
for problems of computational
limitations and
communication limitations that you just
know that's not going to work so you
have to come up with
algorithms that make that decision
process efficient
so that that ten and that was the
scientific part of what i was doing i
borrowed a lot from operations research
and
using linear programming techniques sort
of things that have been around for half
a century in a different context
uh they turned out to be useful in these
multi-robot problems as well
but then there was a whole other set of
problems which was more on the
on the technical side which was
just keeping the robots working and
making them programmable
so the robots often arrived with
software that was subpar
and the hardware was flaky
and so a lot of the a lot of the issues
you dealt with were
just keeping the robots up and running
and providing a development environment
that would be that would allow you to be
productive
so uh what was your thesis work on what
was it called
my thesis was called uh on multi-robot
task allocation
i started with on you know felt kind of
old-timey
uh so the the it started out
as trying to build a system to do
task allocation for robots as a as a way
of getting them getting robust to
coordinate
so i have a bunch of things that i want
done
i have a bunch of robots who should do
what and how should that evolve over
time
i ended up building one or two such
systems
and then i had an epiphany one day when
i
i was i had just produced a video of my
robots
collaboratively pushing a box across the
room and it
there was this particular sequence where
i wanted to show fault tolerance so
the two robots were pushing this box and
i and i run into the video and i pick a
robot up and take it out
and then the other robot realizes that
and and automatically takes over so it
starts pushing the right side then the
left side it does it by itself and then
i can bring another robot and i can put
it back
and then they act as a team again i
thought that was really cool
this was in 2001 and then
not long after that i found a video from
lynn parker's thesis work with again
with rod brooks at mit
from 1994 in which her robots did
exactly the same thing
she had two robots pushing a box she
came in picked one up took it out
and then put it actually put a different
kind of robot back in
and i said well you know it's been seven
years what did we learn
and um that was disappointing for a
while
but then i had the idea to to try to
understand well what's really at the
core of
her approach versus my approach not the
details of the systems that we built
we could try to compare the code or the
robots but that's not really meaningful
what's really at the
at the core of the two approaches and
that's where the operations research
literature
turned out to be very helpful um and i
owe a lot to
mike wellman who's a professor at
university of michigan
who was on my thesis
proposal defense committee who who put
me on to the
fact that i was really what i was really
looking at was a well-studied problem
in the the or community and that there
were these well understood ways of
of looking at these problems and
characterizing solutions to them and
even
uh even bounding how good the solution
could be so then and then i could come
up with a framework where i said well it
turns out that my approach and lin's
approach were actually
equivalent in a certain way and and you
could say things about the performance
of them and so on so that
all together was the thesis and how did
you
get in touch with professor involvement
how did i get in touch with professor
wellman um i had been reading his papers
uh he's a computer scientist uh but and
verges into
into economics uh so i i just been
reading his papers and
when it came time to put together a
committee to
you know give me advice on the thesis
idea that i was proposing i got in touch
with him by email and he said yeah i'll
help out
your new house was on your committee on
my
proposal committee it was of course my
advisor maya
garofsa katmay also at usc
um deborah estrin from
who had just moved from usc to ucla she
does a lot of work in in networking and
embedded systems
and milan tombe who does multi-agent
systems work at usc and isi
so earlier you said you were eager to
get to stay in academia but um
how did you wind up working in a private
company
that's uh that's a good question uh so
i so from from grad school i went on to
do a postdoc because that's what you do
after grad school
um and i worked with sebastian throne at
stanford for a couple years
and then from there i went to sri which
is just around the corner from here
and did research there for about two and
a half years and
um and then near the end of that time
uh eric berger who's a student at uh
stanford at ken salisbury's group and
had been a co-designer on the pr1
um came by to chat one day when i was at
sri
he had he we had met
when he was a student at stanford and
was a postdoc there i think he might
have been an undergrad at the time
and he came by one day and said so we're
you know we're doing this new thing at
this new company and we're going to
build up all this open source
uh robot software infrastructure and
that's the thing that i have been doing
a lot of
completely independent of my thesis work
and he said you know do you want to come
help us do this and i said that sounds
pretty cool so i came over
and met steve and scott and the rest of
the team
that was here at the time um and then
came on board that was about three and a
half years ago
what kind of work were you doing at
stanford with sebastian's group
i uh in sebastian's group at stanford i
was
still doing multi-robot work so i was
sort of following on for my thesis work
you know trying to wrangle teams of
robots to do interesting things
spent a fair bit of time working on a
collaborative search problem where you
have a team of robots that you want to
have
run through a building and search it in
such a way that they find anybody who
might happen to be in the building
that turned out to verge a little bit
into computational geometry and
uh was a was a pretty interesting thing
to work on i was
i left right at the time that the
autonomous driving stuff
was coming up so i i didn't work on that
and you did similar work at sri
i did do similar work at sri that well
you know sri
um i did
some multi-robot work um and also some
some outdoor robot work we had an
interesting uh darpa project
that involved use where you had to have
a get a robot to
start from whatever location it happened
to be in
and get to some gps designated location
and along the way you had to use only
stereo vision to avoid all the obstacles
and get there
and that's where i first worked with
kirk conledge who
is actually here at willow now and we
worked together on that project he was
doing the stereo vision and visual
odometry part and i did the uh
the the controller part so how do you
actually uh
decide exactly where the robot is going
to go given the information you have
from the cameras
we talked about bowls over there and he
showed us the room full of all these
little robots and i guess they did
something
yeah oh yeah i know bob very well bob
was yeah bob was also on the logger
project
um so that that was the cinebots project
with all the little amigo bots
and that happened just before i got
there so i didn't
wasn't working on that i i that was part
of the sdr program
that darpa ran which i had a peripheral
role in when i was a usc
and how did you get involved with the
open source community
imagine you had done it before you came
here kind of on your own
yeah so when i mentioned the the the
pioneers the robots that we used when i
was in when i was in grad school
they came with some software
that was it was a particular
behavior-based
interface for programming robots and
it was it was fine it was a it was a
reasonable way to talk to the robot
but like any software it had bugs and it
had limitations
and unfortunately because it was a close
source piece of software
we couldn't do anything about it and it
was made all the
all the more uh frustrating because it
so happened that one of the
the author of that software was actually
a fellow grad student of mine in the lab
at ufc
he had done it under contract work for
the company um
and he's right across the room but i
can't you know i can't get access to the
code i can't
i can't fix bugs i can't make it do
something different um
so like any good computer scientist i
said well i can write my own
and not live with these limitations so
together with a
a visiting student named casper stoy
we um we wrote something that we ended
up calling player
which was a open source uh
middleware for robots it was a it's a
server that runs on the robot
it has incited all the pieces you need
to talk to all the devices the lasers
and cameras and the wheels and so on
it eventually came to contain algorithms
for doing things like localization and
mapping and planning and things like
that
and we released it open source we posted
it on sourceforge this was
2000 2001 and
ended up building a pretty substantial
community around that project
beyond the device server player came
stage
which is a 2d robot simulator and gazebo
which is a 3d robot simulator those all
were packaged together as part of the
what eventually we called the player
project
and still there are thriving communities
around all those pieces of software
what kind of uh people who constitute
that community
the player community is primarily uh
people doing
research and education player was really
designed for
robots like the pioneer it's a fairly
simple mobile base
and it tends to have a camera and maybe
a laser on it
a laser rangefinder and so a player is
well designed for running in that
environment so people that have a bunch
of those robots in their lab
we use it for to support their research
and people who have
a bunch of robots that they want to use
to teach robotics
uh we'll use it in classes that's the
that's the main use
a couple of companies picked it up and
shipped uh shipped robots
with player in it um but then they tend
to be shipping those robots to people
who are then using them for research or
education so it's only sort of one
degree removed
and do you find a lot of people writing
additional code that's
compatible and trying to build a larger
library around it
sure there were a lot of contributors to
to player
the the model that we had it was it was
very much following the linux model
where
the way we looked at it we had
essentially built a kernel there was a
there was the server that had all the
infrastructure in it for exchanging
messages and what and what provided new
functionality was
drivers so if if there was a new imu
came out or a new camera came out then
you could add support to that by writing
a driver that knows how to talk to that
piece of hardware
and um you know originally before
making a new release of player i used to
actually test it
so i would run it i you know i'd run it
on our pioneer and make sure everything
worked
but pretty quickly because of all the
drivers that got submitted from around
the world
it had code in it for hardware that i
had never seen and still have never seen
so i it got to a point where i am on my
own couldn't test it and had to rely on
the community
to to do quality control in more on more
of a continuous basis
and what did robot operating systems
look like prior to that
what else were people using at that time
prior to player
um they're i don't want to make any
broad claims
that that could be falsified but my
experience had been that they were they
tended to be
um libraries that you would link your
program against and
that they had embedded in them the
ability to talk to
certain devices and that that's
certainly the way that iu was that was
the software that we
originally used in the pioneer and so
the innovation
with player was that we made it work
across the network
so there was a server component on the
robot that could that would actually
talk to all the devices over serial
lines and usb lines and firewire and
whatever
but you wrote your control program the
thing that decided what the robot was
going to do
on the other side of a network
connection and that meant you could
write it in any language that you wanted
for example that was a big advantage so
you could there's still player
client libraries in c and c plus plus
and java and
lisp and ada and there was one in tickle
for a while so
there was it basically made the
development environment a lot more
flexible to have that network
abstraction
embedded into the into the middleware
and so um so i think that brings us
practically to
willow and you getting into willow and
the kinds of things you started
working on when you were here so could
you tell us a little bit about that
sure what was that like yeah so like i
said you know i
eric and i had interacted at stanford um
because he was he was actually using
player on a robot that he was building
there
so uh when when he and keenan were
moving over to willow
and they had the had the idea that we
should build uh you know a next
generation
robot software infrastructure he
came to me and said well you know if we
help us build this
and and that that's that's what became
uh ross was the was the thing we started
building um we were working closely with
morgan quigley
at stanford who had started have been
writing something he called switch yard
and that was the thing that he built to
use
to counter some of the limitations in
players so we took some ideas
in switch yard and morphed them and
iterated on them
you know there was about a year there
where if you had come to ross and tried
it then i'm
i apologize profusely because it was
terrible and it was
terrible in a different way every day uh
but eventually we settled on what we
still feel like is a pretty good design
for uh for a piece of robot middleware
what were the
problems you were running into in those
early days that made it be terrible in
different ways from day to day
well i think it's the problem that you
have on any new project there's such a
big space
of designs that that you might try
and especially when you're building
essentially a toolbox you don't know
exactly what it's going to be used for
so it's very hard to to make the
trade-offs
in a principled way because you don't
know exactly
who's going to use it for what so you're
trying to be general but you're also
trying to be
efficient and easy to use and all these
other things that tend to trade off
against generality
so what would happen is that we would go
down one path for a while and then
you know convince ourselves that that
was that was probably not a good way to
do it
and then throw it all away and then
write a new one and go down another path
for a while and then
throw that one away and i think but the
hope is that you get closer and closer
to
a good design as you go through that
process
and what were some of the concepts and
design elements of switch yarn that you
were able to
leverage well i'd say
the biggest thing that ross borrowed
from switchyard was a peer-to-peer
setup so player had been a client server
architecture which is
easier to write but and easier to use
but not as flexible as a distributed
peer-to-peer architecture
so that that was one piece that we
borrowed from switzerland
this idea that you're you're necessarily
setting up a distributed computing
system that is composed of many nodes
and that those nodes talk to each other
about
the connections between the nodes are
according to whatever information needs
to be shared between them
we also borrowed the idea an idea from
switcher which really came from unix
before it
which is that in building complex
systems a good way
to make progress is to build small tools
that
where each tool does something specific
and does it really well
and you design tools to be composed
together to give you the behavior you
want
so if you're familiar with unix there
it's full of command line tools that you
can string together in interesting ways
to do very powerful things
and that was the design philosophy
behind switchyard and also ross
we don't build a monolithic system that
does a particular thing we give you a
swiss army knife of all kinds of things
that can be
put together and in terms of
the fact that robots drive around and
can run into things and break things
what are some of the issues and concerns
about security and reliability in an
operating system for a robot well
the i'd say the biggest concern in terms
of reliability
is that at this stage in robotics
we're still working out the bugs even in
the even in the basic components
and so it's important to design the
system so that when one thing
fails it doesn't bring down the entire
robot
and that that sort of naturally follows
from the peer-to-peer setup if
if one one of node in my system crashes
there was just a bug in it i don't want
it to tear down the whole system i want
to have the ability to bring that piece
back up and have everything keep going
so certainly from a reliability point of
view just dealing with with buggy code
is really important um if you talk about
the fact that robots can run into things
that's not the that's not the sort of
thing you can protect against
at the low level right that's a that's
very much a high level
uh idea that that has to
it has to be in the that has to be
embedded into the decision making
process that that is at a at a different
point in the system
and also you know running into stuff
isn't necessarily bad
you know maybe maybe you meant to run
into something maybe you you need to run
into the door to close it
um you you know we have to have this
problem
with manipulation right we spend most of
the time controlling the robot arm
trying not to hit stuff we have a lot of
software that you know makes it so that
i can get my
hand from under the table to over the
table without hitting the table
but then if i want to pick something up
then i'm colliding with this pen to pick
it up
and so that's a purposeful collision you
know so it's it's not the case that
running into things is always a bad
thing it's very much context dependent
and so you mentioned when you were
developing player that you
envisioned being used with kind of small
simple robots
like some of the ones people were using
in education and research at the time
so when you were developing ross um did
you have any
considerations about particular types of
platforms or
no so when we were building ross
we were really we were designing it for
the pr2
um so the pr2 we we knew the basics
you know we looked at the pr1 and we
knew basically what the pr2 was going to
be like it was going to have
a lot of sensors it was going to have
arms it was going to have the sensors
were going to be
actuated the there was going to be a
laser that was going to be tilting there
were going to be cameras in the arms
that are moving with respect to the body
uh so we we took that into account when
making design decisions
about ross for example early on
we decided to put in an abstraction for
dealing with coordinate transforms
so this is a it's a really important
and totally tedious aspect of robotics
which is that if
if i want to incorporate say
two laser scans where one came from a
laser that is on the base of the robot
and one came from a laser that
is in the robot's hand for example then
i need to know where the base was
and where the hand was at a particular
point in time and then i need to pick
another frame in which i'm going to
incorporate them and then
do some math to transform the two and
that's the kind of thing that tends to
be done by hand
again and again and again in everybody's
program and it's the kind of thing that
everybody gets wrong
personally if i try to do that kind of
math by hand i take a random walk
through the space of
trig functions until i get it right so
early on we decided that's
that's crazy what we should do is have a
consistent way of dealing with
coordinate transforms and in fact every
piece of data
that is published should have a frame
attached to it we should say
this scan or this point cloud or this
image or whatever it is
was acquired at this time in this frame
and then there's a there's a library
that knows where
all the frames with respect to each
other over time and then can do things
for you automatically like take this
point cloud
that i took in the coordinate frame of
my hand and show me where it is in the
coordinate frame of my head
and obviously the pr2 is a much more
complex robot than the ones that you
were thinking of before so how did
some of that affect how you designed
ross or how you went
well the the complexity of pr2
it really came through in the design of
the software
in that we we knew that we wanted the
system to be flexible
we wanted to be able to to let the user
decide how to
um either exploit or hide the complexity
of the robot
and that that meant letting the user
decide
which parts would be up at any given
time which sensors are using which
actuators are you using
and also have full control over how the
how the robot was being commanded do you
want a high level interface
where you for example tell the hand
where to go
you say i want the hand to be here and
it computes inverse kinematics and
runs some fairly sophisticated
controllers and gets you there or
do you want to command the joints
individually and say apply a torque here
and then apply a torque there and then
apply a torque there
you can you can go in it at all levels
and can you tell us a little bit about
some of the initial
testing of the program and
anything interesting happened at those
points hardware or software
both uh well i'll tell you about
software because i'm
i i could i can't talk as much about
hardware
so i can tell you that in the in the
early days of ross development
we didn't do a lot of testing
we we started building up
pieces and started building up started
building up pieces very very quickly
in a short period of time we had a lot
of functionality we had the basics for
controlling the robot
we were starting to have it navigate we
were doing some control on the arm
perception pieces were coming together
and
we started to have trouble with
stability pretty quickly we had a big
code base
that on any given day may or may not
compile
and long story short we ended up coming
around to
very standard software engineering
techniques
where for example you write unit tests
and you write regression tests and you
have a continuous integration system
that
is watching the code that you're
checking in checking it out
compiling it running tests on it and
giving you some confidence that you
didn't break it with that change that
you just made it to in the morning
what turned out to be very important for
us was
whole system regression tests so we've
got this this very
complex hardware system and we've got
this pretty complex software system
as well it's very hard to test every
little piece of it
as much as we would like there's just
there's only so much time that you can
dedicate to testing you're never going
to get complete coverage
and even if you test every piece it's
then
if you really want to be complete you
need to test every interaction between
every piece and all the different ways
you might put them together and that's
pretty much impossible
so our proxy for doing that complete
coverage which we can't do
is to pick a few tasks that are
representative of what we want the robot
to do
make those tasks work in simulation and
then
have a regression test that runs inside
the simulator
so for example once we had the robot
opening doors
we made sure that it would open doors in
simulation in a 3d physics-based
you know pretty realistic simulation and
then that becomes a regression test
anytime somebody checks in code that
checks in a change to the code that is
involved in opening a door
somewhere on a server in a room in the
back there's a
simulation spins up with the road with a
pr2 on one side of a door and it's got
its arms tucked and it's
and it runs the whole door opening
sequence where it looks for the handle
and then reaches out an arm and opens
the door and pushes the door open and
then drives through
and we can make that into a test by
saying in
in within some period of time did the
robot end up on the other side of the
door
or not and it turns out those those kind
of trip wire tests you know did it
does it no longer get through the door
are really important
when the light turns red on that test
you know something went wrong you don't
know what
but you can look at the changes between
the last time it was you know between
when it was green and red and then
and then figure out what happened and do
you try to use that sign of
testing reliability for you know
community generated code
or integrating things that other members
of the open source community are
developing
so to to improve quality or or
support quality assurance in the
community we we do two things
one is um one is
technical in that we uh if people
release their code we have a release
system
so you can decide to release your code
to the world
then it runs on our automated
servers where it will run all the tests
that you defined
and give you reports did they pass did
they fail
of course that's not very helpful if you
didn't write any tests
um and we can't write the test for you
well we could but i don't think that's
the best use of our time so instead what
we do
is uh try to build a culture of testing
which is i think unusual in in the
in the research community to in my
experience there's not a not a big focus
on writing
tests so we're trying and
with some success to set an example for
what's expected
for good software in robotics even
coming out of a research lab
you know even it's it's so much better
to have basic tests that
show that it doesn't just break out of
the box than it is to have no test at
all
and and that's i think we're getting
some traction i mean even you know grad
students uh in university labs are
actually writing tests for their
software which is something i
never did as a grad student in
university lab and how are you raising
that kind of awareness with people
well it's um what we
i guess we're raising awareness about
testing mostly
by just by our just by our own example
if you go and look at code that we've
written
you'll find a good measure of testing in
there
um and we you know we let everybody know
that the the best way to protect
yourself against
changes in the system is to have tests
in your code so if you've
if you've written tests and you've
released your code
and somebody else makes a change that is
going to break your piece and you have a
test against it then
you know the light will turn red when
that other person made a change
and then you can you've got a chain of
uh
responsibility there and you can get
back to the person who made the change
if you didn't have a test
that that demonstrated that your thing
is no longer working
then we can't do anything about that
and have you have you found people uh
trying to port ross to other platforms
and pr2
oh yes ross so we designed ross for the
pr2
but um from the very beginning we wanted
it to
not only be for the pr2 we knew that the
pr2
was going to be a a really great robot
but it was not
going to be the only robot in the world
and
probably not even the only robot that we
build so we wanted to make sure that
it would run on other robots our mantra
early on was we wanted the string
pr2 to appear as little as often in the
code base
we would if something was pr2 specific
we'd say this is the
pr2 thing but we wanted to have as few
of those things as we could we wanted to
build general capabilities
so at this point it kind of depends on
how you count it but pr
ross runs on dozens of different robots
dozens of different kinds of robots that
are
made by robot manufacturers but also
just a
wide variety of one-off robots that
hobbyists and
educators and academics have what are
some of the crazier ones you've seen
well i mean in terms of unexpected ones
you know we there's the pr2
and then there are robots you could look
at robots that are kind of like the pr2
like we we
had some good experience collaborating
with folks in japan to get ross
the ross navigation system running on
the hrp
uh hrp four yeah
it was the one that was on wheels um
they had a version that was on wheels
but in any case it was
you know that robot it's kind of similar
to the pr2 um
there the carobot from fraunhofer in
germany is kind of like the pr2
and they've they've done a great job of
supporting ross on that platform
and then from there you can go to to
simpler robots like the pioneers
of the world but then there's some that
we just didn't think of at all like quad
rotors
people are running ross both on board
and off board uh
quad rotors running ross on on little
tiny embedded computers
there's uh there's a group a really
active group at eth in zurich that has
run ross on a
wide variety of things from these
crazy little two-wheeled robots that
have magnetic wheels
and are used to drive inside pipes to
inspect them
to uh vehicles that to boats that go on
the
surfaces of lakes there's a guy who
instrumented his surfboard to get
acceleration
information and used ross to acquire and
then plot that information so you could
see you know how
how he exactly what his board was doing
as he was coming down the wave
so certainly some areas that we didn't
we didn't plan for
and that's what's really exciting now i
mean early on we were really counting
users you know how many people are on
the mailing list how many repositories
are out there
how many packages have been written and
we still count that stuff because that's
interesting in terms of measuring impact
but now more than that we're really
looking for
different kinds of users different kinds
of people are
is it you know is are we now seeing ross
used on a completely different kind of
robot
are we seeing ross used in a in a
commercial context in
as opposed to an academic context
roughly how many users are you at that
counting users on an open source project
is hard because they don't have to tell
us that they're using it
um we so we we try to
have proxies for it our mailing our main
mailing list has
about a thousand users on it um so
it's at least that many but in my
experience most users won't join a
mailing list they'll
they just use the software and they come
in through other gateways to talk to
people at different forums and so on
one proxy that we use is how many unique
visitors hit the installation page
every month because we figure if they're
reading the installation instructions
some
some of them are going away and
installing it and that's about 10 000 a
month right now
so that's that's some indication of how
many users there are
we see peaks at certain times of the
year people are starting
they're using ross in classes and
universities so you see a peak of
installations around the
uh so you see a
you see a peak of installations around
the uh beginning of the academic year
for example
um it i would guess it's it's tens of
thousands
um maybe hundreds of thousands it's hard
to say
so what's the next evolution of ross and
the challenges you face
so um where sc ross going next
is getting ross on to more competing
platforms
so we started off really targeting linux
and that's still where we put most of
our effort
and um mac os 10
uh is also a good platform to support we
we're partially supported there right
now
but the real prize will be windows i
mean that if
so in in terms of getting a lot more
developers involved
having good windows support i think will
be important and that's something that
we're making
steps toward right now um and
once we have or or the reason that we
would do that is that
what i'd like to see happen is to get
people who are
who don't have robotics backgrounds
using ross
so right now um people who have robotics
backgrounds or are very interested in
robotics don't have any problem picking
up ross and it's it's great for them and
i think we're doing a good job
as a community of satisfying that need
but what will be really different is
when people who
have good software engineering skills
and have creative ideas for what you
might do with a robot
but don't have a robotics background can
come in and start using ross to start
prototyping their ideas for what
a robot might do and that's so there
there's some
work for us as a community to do to make
that to make ross
more accessible to people who are coming
in they they didn't go through grad
school and robotics program they're not
experts in computer vision
but we still want to what we want to do
is provide a toolbox that lets them put
the pieces together to
try out their crazy idea for what a
robot might be useful for
right and now we always wind up with
this question so for young people
interested in a career in robotics what
kind of advice do you have for them
for a young person who's interested in
robotics i'd say that
um first of all you're living in a lucky
time
uh you're lucky to live in this time i
should say i think things are really
taking off right now like
we've been hoping that they would for
quite a while
i would say get as much
computer science education as you can
get as much math education as you can
those are the those are the two pieces
on which
most of the work in robotics is is built
these days
but then i'm a computer scientist so i'm
gonna i'm not gonna tell you to go get
the mechanical engineering expertise
although that
would clearly be useful thank you great
thank you all right