RON EVANS: Good afternoon everybody.
AUDIENCE: Good afternoon!
R.E.: This is RubyConf 2013!
AUDIENCE: Whoo!
R.E.: Yeah! So before we get started, we just
want to say a very special thank you to
the organizers of Ruby Central and to all
the
conference staff, the sponsors, and to all
of you
for being here. Thank you so very much, let's
give a big round of applause for everybody.
So I am @deadprogram, aka Ron Evans in the
real world. I'm the ringleader of the @hybrid_group.
This
other guy over here is @adzankich, aka, Adrian
Zankich.
He is the serious programming guy at the @hybrid_group.
So he does all the work and I take
all the credit. Yeah.
I love how that gets applause.
So we're with the HubridGroup. We are a software
development consultancy based in sunny Los
Angelos, California. And
among other things, we are the creators of
KidsRuby.
How did you guys like my new boss this
morning? She's awesome, right. The funny part
if you're
kid- you think I'm kidding. Yeah. So, but
here
today we are here to talk to you on
Ruby on robots. Zzzz-zzzz.
This robot is not with us today.
So let me ask you, is innovation dead?
AUDIENCE: No! Yes!
R.E.: I mean, William Gibson said the future
is
already here, it's just not very evenly distributed.
Isn't
that really true? I mean, many of us have
been doing web development for years, and
yet we've
been seeing a very interesting thing happening
as we've
been creating all these different technologies.
We've discovered that innovating is really
hard. I mean,
doing something genuinely different. And,
in fact, it's especially
hard when you're dealing with hardware. So
about six
years ago, my younger brother Damien and I
started
building unmanned aerial vehicles using Ruby.
A number of
people remember that. And we had to source
parts
from literally all over the globe, AKA China.
And
they would ship us these really amazing microcontrollers
and
we would put them in blimps and they would
burn up and we would order more.
Nowadays though you can go to the Apple store
and buy several different kinds of robots.
I mean,
the robot revolution is already here. So we're
here
to introduce to you Artoo, which is Ruby on
robots. It is a Ruby framework for robotics
and
physical computing. It supports multiple hardware
devices, different hardware
devices, and multiple hardware devices at
the same time.
In Ruby?
I mean, are we serious?
Yes! We are extremely serious, and the reason
for
that is a remarkable piece of technology called
Celluloid.
Tony, are you here, by any chance? You bailed
on my talk? What's up with that?
So anyway, a bunch of the committers from
Celluloid
are here, and actually this is probably the,
one
of the most important technologies to occur
in the
entire Ruby community in years, and if you're
not
paying attention to this, you need to be.
In fact, you're probably using it right now,
if
you use SideKiq, which is another great project.
So
it runs on the MRI Ruby, of course. It
runs far better, however, on JRuby, thanks
to the
concurrency of the JVM - excellent piece of
software.
You probably saw Charles and Tom's talk earlier.
Great
work.
But, we're gonna be showing most of our demos
today on Rubinius. The Ruby of the future.
If
you love any of these projects, please go
help
them. Bryan Sharrai is here. Bryan, are you,
are
you here? Oh, he's probably with his daughter.
Where are all my friends? Anyway, these -
AUDIENCE: I'll be your friend!
R.E.: Aww! Giant hugs!
Channeling my inner tenderlove.
So, anyway, this is an amazing project. It
just
reached the 2 point 0 release, and Rubinius
X
has been announced. There's really exciting
things happening to
it, and it's an important part of, really
a
pillar of the future of Ruby.
Anyway, back to Artoo. So Artoo is to robotics
like Rails is to web development. I'm gonna
say
that again cause it's really, really important.
Artoo is
to robotics like Rails is to web development.
Actually,
it might be a little bit more like Sinatra,
as you can tell from this code example.
So you see, first of all, we require Artoo.
Then we're going to declare a connection to
an
:arduino that's going to use an adapter called
:firmata,
which is a serial protocol that you can use
to communicate with various arduinos and arduino-compatible
microcontrollers. Then
we're gonna connect on a particular port.
Then we're
gonna declare a device.
This device is an LED. It's gonna use the
LED drive and be connected to pin thirteen.
Then the work that we're going to do is
every one second, we're going to led dot toggle,
which is going to turn the LED either on
or off. So this is kind of the canonical,
make an LED blink. So we'll show you that
in a minute.
So, Artoo's architecture. We have a couple
of very
important design patterns that we're utilizing
within Artoo. Here's
a little bit of a outline. So the main
entity in Artoo is, of course, the robot.
And we have two things underneath that. We
have
the connections, as you saw before, and we
have
devices. Now, we are using the adapter pattern
in
both of these cases. So connections use an
adapter,
we can use, similar to the way ActiveRecord
or
other ORMs work, we can actually use this
adap-
these different adapters to talk to different
kinds of
hardware.
So where connections control how we actually
communicate, whatever
protocols with the device, then the devices
control behaviors.
LEDs know how to blink, drones know how to
fly, et cetera.
And then we are also using the polish and
subscribe pattern via events. Devices, by
their drivers, can
detect events and then tell the robot about
them.
So it also has an API in Artoo. I
mean, what good is a robot unless you can
control it via an API across the intertubes,
right?
So here's a, an example of both a restful
API and a web sockets API that could be
used by two different applications to talk
to the
MCP or the master control program, which will
then
control all of the different robots. And there
you
have it.
Of course, test-driven robotics is very, very
important. I
mean, we are Rubyists and we test first, right.
Well, traditionally in robotics, the way you
do testing
is you would turn on the robot and jump
back really fast.
I have scars.
However, this is Ruby, and we can do a
little better. Here's an example of TDR, or
test-driven
robotics, as we call it. In this case, we're
actually using mini-spec, we're using mocha
and we are
using timecop. So let's take a quick look.
First, we're gonna declare :start right now.
The robot
is going to be the main robot, which is,
as you'll remember, very similar to the Sinatra
syntax,
and then before this test, we're going to
Timecop.travel
to the start. Then we start our robot's work.
It must roll every three seconds. So we travel
to three seconds after the start. We're going
to
expect a roll command, and then we process
messages
to give Celluloid's mailboxes a chance to
catch up
with its actors.
So this way we do not have to wait,
just a little over three seconds to test something
that takes three seconds. Because otherwise
if we wanted
to test something like turn the sprinklers
on once
a week, we would have to wait a week.
And that's not good. You think your CI is
bad, try it with robots.
So, of course, Artoo also has a command line
interface, because, two, well one of the important
patterns
that we've discovered, as we call it RobotOps,
is
that you definitely want to use commands to
connect
to all the devices. You do not want to
do these sort of things manually.
Anyway, though, I've done enough talking.
How about a
demo? You guy's want to see a demo?
All right.
So, the - oh, first thing I'm gonna take
a look at is the Digispark microcontroller.
So the
Digispark is what we might call the minimum
via
microcontroller. Oh yeah, please. It's very
small. We have
to get it very close. Oh. It would help
if you had the camera. All right.
So this is it. It's extremely small. Oh, can't
see it. I can see it.
Hey. There it is.
So this is it. It's a, it's a rather
small device, as you can tell. It actually,
let's
take the shielf off. This is the Digispark
itself.
It's a very small, well, thank you, it is
very small, itty-tiny powered microcontroller
that actually uses another
protocol called littlewire, similar to fermanta
but it runs
on even smaller microcontrollers.
We're good? All right, we're in focus. And
we're
going to use this LED shield that plugs into
it, it. It's better when it's over here. All
right, so the program that we're gonna run
-
well, that's not it. That's definitely not
it.
OK, so the program we're gonna run here is,
the first thing we're gonna do is we're gonna
connect to the Digispark using the little
wire adaptor
with the vendor in ID since it's a USB
device. We're gonna connect to the boad to
retrieve
it's device info, which we're gonna display
on this
screen that you won't be able to see. Then
the LED device, we're going to, again, toggle
it
every second.
So you see it's exactly the same code as
we were using with the arduino. See a pattern
forming? All right. Let's run this.
Oh, right. The video.
Executing code. So it should start to flash.
A
three thousand dollar lamp!
All right. And, and you're applauding. Ha
ha ha
ha! I should be Apple. All right.
So moving on. So what do you do with
a flashing LED? Well, we are software developers,
and
of course what we do is we check our
Travis build status notifications. Yes, the,
the build notifier
is to physical computing like the blog engine
was
to website development. That's the thing you
do. All
right.
So let's take a look at some code, real
fast.
All right. So in this case, we're gonna require
Artoo, we're gonna require Travis. We're gonna
connect to
the Digispark and its different LEDs. Then
we're gonna
connect to a broken repo that we've called
broken
arrow, in the tradition of flying things that
don't
necessarily work. We're gonna connect to the
Travis repo,
then every ten seconds we're gonna check the
repo.
If the repo is green, we're gonna turn on
the green LED. When we're tasking it, it's
going
to turn blue, when we're check either the
build
is running or we're checking the Travis status.
And
then if the build fails we're gonna turn red.
And then last we have a couple of functions.
One turns on one particular LED and the other
turns them all off. All right.
So if this actually works, across the internet,
it
will turn blue that we're checking the Travis
build
status, and it will turn red since broken
arrow
is a broken build. Working. Working. Working.
Fail.
Now, we could go in and fix the build
but in the interest of time let's just move
on to the next thing. All right, so what
is the next thing?
Oh yes. So one of the greatest things on
the internet are cats. And the only thing
better
than cats are internet enabled cats. For example,
internet
enabled cat toys. So in this case, we have
a cool little device that we've made, kind
of
homebrew, but we like it. It's got two servos
and it plugs into the Digispark, and then
is
connected to this fun little toy. Whoops,
get the
right angle.
Can you guys see this OK?
We don't have a cat. They wouldn't let us
bring one in. We have a robot cat but
it's not the same.
All right, so let's take a look at the
code. Wait, that's something else. Where is
the code?
I forgot to load it. All right. Well, in
any case, we're using this leap motion. Yes.
This
leap motion is going to allow us to, with
nothing more than his hand waves, control
these servos,
moving this cat toy to the invisible internet
cat
on the other side.
Oh, wait.
K, let's see the toy.
O.V.: What it's this. There it goes.
R.E.: All right.
AUDIENCE: Oh! Whoa!
R.E.: Ah, we broke it.
I don't know how long this would last with
a real cat, but it's still cool.
Look ma! Just hands!
Thank you.
OK. So, so now let's switch to something else.
The Beaglebone Black. So one of the important
robot
ops patterns that we want to share with you
is, you do not want to think you are
going to develop robotics on your notebook
computer unless
you plan on duct taping it to a drone,
which you might try. It might work. For you.
On the other hand, there are amazing single
board
system on chip, or SOC Linux computers that
are
very, very inexpensive. The Raspberry Pi is
one. Another
one, though, that is a little bit more powerful
but is also opensource hardware, is the Beaglebone
Black.
Where is my video? There we go. So the
Beaglebone Black is a very, very cool, also
arm
coretex powered single board computer. It
has a one
gigahertz processor and 512 megabytes of RAM.
In this
particular case, we are running an Arch Linux
distro
that we have built that is also available
on
the Artoo, a link from the Artoo dot IO
website where it includes everything you're
going to need,
software wise, to turn this into a complete,
full
physical computing and robotics platform.
Can you see this OK? There, we need it
on the other side.
OK. So let's take a, a closer look.
It's, it's naked. We have cases, but.
So, you see that it has a lot of
different pins that you can plug into for
digital
IO, for analog IO, for pulse with modulation
and
for I2C. Now, I might mention, you saw before
that we had difference between drivers, and
connections. Well,
we have generic drivers for general purpose
IO and
for I2C devices. So you can actually use these
same drivers on arduino, on a Raspberry Pi,
on
the Beaglebone Black, on the Digispark, or
on any
other platform that supports Linux GPIO.
Think about that. Kind of fun.
So what we're gonna do here is we're going
to show our - there we go. The blink
program that we showed before with a slightly
different
syntax, but same idea. Except in this case,
we're
gonna use the connection to the Beaglebone
using the
Beaglebone's adaptor. And we have a slightly
different pin
numbering scheme, because the Beaglebone Black's
pins are different
in a similar fashion that Raspberry Pi pins.
This is actually what the pin is labeled on
the device. That way you're not trying to,
go
to a lookup table. Man, there's software for
that.
It's called Artoo.
All right. Back to the camera. So and now
we're going to - he's actually SSH pin to
this Unix computer and is going to make our
gigantic LED start flashing.
If all goes well.
Blink on the Beaglebone. Yes. It's real.
All right. So that was cool, but can we
get a little more exciting? Like, yes. So
let's
bring in another toy. Another robotic device.
The Sphero.
So the, the Sphero is from Orotix. Oh, yeah.
The camera. Oh, camera.
So the Sphero is a small robotic sphere from
Orbotics based out of Boulder, Colarado. Fantastically
interesting toy.
It might be the minimum viable robot, because
it
actually possesses input. It has accelerometers
that can detect
collisions. It has output. It can change its
color.
And it can move around on its own volition.
It is a bluetooth device. So we're gonna connect
up to it using another Artoo program.
Which, let me show you the code for that.
All right. So in this case, we're gonna require
Artoo. We're gonna make a connection to the
Sphero
using the Sphero adaptor on a particular IP
address.
Another one of the lessons from the robot
ops
toolbook is you definitely want to use serial
to
socket connections. You don't want to try
to connect
directly to the serial ports. You know, well,
that
way we can use nice TCP and UGP style
software development.
In this case, the work that we're gonna do
is every one second, we're going to display
a
little message, and then we're gonna set the
Sphero's
color to a random color - RGB color -
and then we're going to roll at the speed
of 90 in a random direction. Crazy Sphero.
So let's go and see what happens.
So blue means we are connected to the bluetooth
device. Oh, by the way, we are running this
off of the Beaglebone Black as well. Go, go,
Sphero!
It is alive.
So one thing we did want to mention before
we go any further is, choose your own hardware
adventure! What good is this stuff if you
don't
have some hardware? Well, luckily we have
a lot
of wonderful friends, and these friends said
please give
away hardware to the awesome Ruby community.
So you
get to choose your own hardware adventure!
Now, not everyone is gonna get hardware today.
Only
those who go to the Twitterverse and appeal
to
the magnificent of the robotic overlords,
and say please
give me a microcontroller. So, if you Tweet
@digistump
and @artooio you can win one of our Artoo
Digispark starter kits that comes with the
microcontroller, it
comes with an RGB LED shield. It comes with
all the little connectors that you will need
to
connect it to motors or servos or other things.
So @digistump and @artooio to win the Digispark.
If you want to win a Beaglebone Black starter
kit that includes a Beaglebone Black, SD card,
jumpers,
preg board - everything you need to build
your
own robot - Tweet @beagleboardorg - kind of
long,
sorry - and @artooio to win that.
And if you want to win a Sphero 2
point 0, the hot new item, then you Tweet
@gosphero and @artooio. All right, so to run
through
that again.
@digistump and @artooio to win that. @beagleboardorg
and @artooio
if you go in that direction. And if you
go north, you get to try to win a
@gosphero and @artooio.
So again our criteria is whichever Tweet we
like
most, so, beg. It's OK.
All right. Onto the demo!
So Conway's Game of Life. Who knows about
Conway's
Game of Life? A decent percentage. But let's
just
to a quick mathemagical review. So John Conway
was
a mathemagician who invented something that
we call cellular
automata. It basically says by using very,
very simple
algorithm we can get interest emerging behaviors.
It's absolutely
kind of like a swam of robots.
And we thought, let's just do the, do the
rules here real fast. So it's usually played
on
graph paper using a paper and pencil. By the
way, I highly recommend graph paper for doing
creative
work. It's fantastic.
All right. So with graph paper, you would
draw
some cells, which are the dots, and then the
rules are, if a cell has less than two
neighbors, it dies on the next turn. If a
cell has exactly two neighbors, an empty space,
a
new cell is born into it. And if where
a cell is there are more than three neighbors,
it dies from over population. So that would
be
the second move. So first move. Second move,
and
so on.
Well, we thought it would be really cool to
do Conway's Game of Life with robots. But
we
realized we'd have to do things a little tiny
bit differently.
One of the differences is that the Sphero
does
not possess the ability - you might want to
start connecting - the Sphero does not possess
the
ability to see other Spheros. However, it
does an
accelerometer to detect collisions. So by
doing a little
bit of an inverse fourier transform, we can
basically
turn the collisions into an estimation of
proximity within
a slice of time. And thereby we can make
a decision about whether or not this is actually
collided and whether it should live or die.
So let's watch artificial life with Artoo
and Sphero.
And it begins.
They have become alive. Now they're wandering
around looking
for love in all the wrong places. They need
just a little contact. Not human. Sphero.
Actually human contact would probably work,
but. Oh. Two
died.
I feel traumatized even when artificial life
loses it.
They can come back to life. We call that
zombie mode.
Well, so, and eventually they might all die,
or
it might just go on for long periods of
time. It's very hard for me to kill off
any life form, artificial or natural. So let's
give
it a brief moment. Oh. It's so lonely. The
last, the last Sphero.
There's something kind of epic. Maybe someone
will compose
a ballad. Ooh!
Anyway, I think you guys kind of get the
idea. Let's take a quick look at some code.
So in this case, we're actually using Artoo's
modular
mode, where we're declaring a class, which
is the
Conway Sphero robot, so the connecting to
a Sphero,
the device is a Sphero. The work it's gonna
do is first it's born, then on the Sphero's
collision - and here we see an example of
Artoo's event syntax - every, on a collision
we're
gonna call the contact method.
Every three seconds we're gonna make a move,
and
if we're alive, and every ten seconds a birth
day if we're still alive. Life is short, hard,
and colorful in Sphero land.
So then you see some of our helpers, check
if we're alive, rebirth. If we actually follow
the
rules we can be born, life, and death. So
you kind of get the idea.
Oh, wait, there's one last thing that's kind
of
important here. So then we declare a hash
with
all of our different IP addresses and the
names
of Spheros, and then each Sphero we create
a
new one and then tell all of them to
go to work at the same time. A swarm
of Spheros.
All right.
So now let's do something completely different.
This is the time to put on your protective
gear if you have some.
So we're gonna demo the ARDrone and we're
moving
over there so we have some space. Oh, yeah,
we forgot to set this up before. Whoops! Oh,
the Sphero.
I mean, sorry, the ARDrone, yeah. That thing.
AUDIENCE: Sphero is funnier.
R.E.: Many people got to see Jim Weirichs
Argis
gem. We're actually using the Argus gem wrapped
up
inside of the Artoo ARDrone adapter and we've
done
a few contributions to it ourselves. It's
very, very
cool. Thank you Jim. We really appreciate
it.
Standing on the shoulders of giants is awesome.
All right, so what we're gonna do here is
take a quick look at some, some code. All
right. So in this case, we're gonna make require
Artoo, we're gonna make a connection to the
ARDrone
via its adapter. The device is gonna be the
drone - you seeing a pattern forming?
So the work we're gonna do is first we're
gonna start the drone. Then the drone's gonna
take
off. After fifteen seconds, it's going to
hover and
land, and then after twenty seconds stop.
So a
little bit of automated drone flight.
So this is the drone.
Hello.
ARDrone in Artoo!
So now, for this next demonstration we're
going to
need a courageous volunteer from our studio
audience. I
mean courageous, like this is kind of dangerous.
And
you have to be tall.
Oh, yeah, let's just use of the Hybrid group
members cause I believe we are insured for
them.
And if not I can just drive them home.
Daniel Fisher, HybridGroup strongman!
All right.
DANIEL FISHER: (indecipherable - 00:26:47)
R.E.: Oh, OK. Yes, thank you. All right. So
what we're going to do - recently, we added,
there we go. Recently we added openCV support
to
Artoo. If you're not familiar with it, openCV
is
probably the most important computer vision
library. It's open
source. It has, it's, it's a very deep and
rich platform, and so what we're gonna do
here
is we're gonna make a connection to the capture
device, then we're gonna make a connection
to the
video device, and we're gonna make a connection
to
the ARDrone.
We're gonna use a facial recognition set of
data
and then the work that we're gonna do is
we're going to capture each frame and display
it
on a window, which we'll see in a moment.
We're gonna start the drone and take off.
After
eight seconds it's gonna boost up to about
face
hugger level. After ten seconds it will hover
again
and then at the mysterious thirteen second
mark it
will begin its facial recognition mission.
It should detect Daniel's face and then, as
he
tries to evade it, it should follow him.
I think you see now why we chose our
own volunteer.
All right. So without further risk to us,
cause
it's gonna be over there - get behind me
man. All right.
This is how you know it's real.
We swear.
All right.
Wanna enlarge the window please?
V.O.: Why would do this?
R.E.: Well, when we say customer service drone,
we
mean customer service drone. Evasive.
We put in code to stop it before it
got too dangerous.
So thank you Daniel. I owe you a drink,
man.
All right. So we promise new hardware every
time
we do a show and basically we cannot disappoint.
So why is it getting dark?
AUDIENCE: (indecipherable - 00:29:30)
R.E.: Oh. That explains it. I'm like, it's
all
getting dark in here. Around the edges especially.
So we have a, some really awesome new hardware
- where is it? It's really small, so it's
hard to find.
AUDIENCE: Are we gonna do the- (indecipherable
- 00:29:47)
R.E.: Oh, OK, yeah let's do that first. All
right. Actually we do have two kinds of new
hardware today. So the first thing is, many
of
you might have seen us fly the ARDrone around
with a Wii classic controller using an arduino.
But
even Nintendo has stopped dealing with Wii.
So we thought, hey, it's time to get in
the modern generation. So we now support the
PS3
controller and the xBox 60, xBox 360 controller.
So
Adriane, who is serious programming guy and
test pilot,
is going to use this generic GameStop PS3
style
controller to fly this ARDrone around. Let's
see if
- take a look at the code here.
No, I went the wrong way. There we go.
So we can see that we're gonna declare connection
to the ARDrone. We're gonna declare the device
of
the drone, a connection to the joystick, and
then
we see that we're gonna - whoops.
We're gonna handle a bunch of these controller
events
- for example, when he hits the square button
it will take off, the triangle button, it
will
hover. The x button it will land - et
cetera.
And so now if all goes as expected -
oh yes, reset the drone.
If it comes really close to you, please duck.
This is human-powered flight, so blame him.
ADRIENNE: I just work for this guy.
R.E.: No, it all comes here. Blame me. I
have band aids. I think.
Standing by.
This is Tower. How you doing control?
ADRIENN: (indecipherable - 00:31:45)
R.E.: Still trying to connect to the wifi
on
the drone. We're, we're standing by ground
control. There's
a certain cadence to this.
ADRIENN: There we go.
R.E.: If you don't do it right, it literally
won't take off. I mean if you don't say
it right. If there's anybody from Rocket City
here,
please correct my English. American.
ADRIENN: All right, ready?
R.E.: Standing by.
Yeah, get some altitude. Get some altitude!
ARDrone, PS3 controller!
Ah, you're not gonna buzz the back row? No,
don't do it. Don't do it. If I want
you to.
It's tempting, but no. Not today.
OK. So now the grand finale. What you've all
been waiting for.
The Crazyflie, ARDrone, and PS/3 Controller.
So, what is
the Crazyflie? Are we crazy? We are. Extremely.
If
you hadn't noticed that. It's probably the
minimum viable
quad copter. This is the Crazyflie from BitCrazy
out
of Sweden. It's a, it - it's gonna hurt,
yeah. It's really small - how bad can it
hurt?
So this is actually a very, very impressive
piece
of technology. It also has an armcore tox
processor
running a realtime operating system. It's
got a accelerometer
- three axis accelerometer. It's got a magnitometer,
a
to a compass, and it also has a barometer
for altitude detection. It's actually quite
an acrobatic drone.
It's very, very hard to control.
Luckily it's very small. Also luckily it only
has
about a seven minute life span on that battery.
So there's that. If you can get away from
seve- six and a half minutes, you're fine.
Actually,
in about five minutes, the sensors start going
off.
So if you throw some, like, tin foil and
run that way.
All right. So what we're going to do, the
first time ever anywhere seen, is we're actually
gonna
control both of these drones with the same
code.
Which, let's take a look at it.
All right, so first we're going to require
Artoo.
Then we're gonna make a connection to the
Crazyflie
using its adapter, and we're going to then
connect
to the joystick. Then we're gonna connect
to the
ARDrone.
So the work that we're gonna actually do here
is we're gonna use the controller to control
the
Crazyflie, and then we're gonna use the ARDrone
to
do automated take-off. And if this all goes
as
expected, the ARDrone should take off and
hover, and
then Adrienne should be able to kind of fly
around it manually using the Crazyflie.
Should be interesting.
Let's do it. Standing by. Multidrone. Two
drones, one
code.
V.O.: Watch out!
R.E.: They live!
We so crazy.
Adrienne, our test pilot!
So was that fun? I love this stuff.
AUDIENCE: ( indecipherable - 00:35:58)
R.E.: Yeah. Let's, the question was, is it
possible
to control them both with one controller?
The answer
is yes, however, because there's a significantly
different vector
of thrust in the Crazyflie versus the ARDrone,
we
didn't really have time to get that perfected
with
the amount of space we had in the hotel
room here. And we kind of didn't want to
spoil all the surprise, cause as soon as you
start flying something around, people start
coming in and
swarming on it.
So, we'll get to that. Come and see us
at Robots Conf in December, here back in Florida.
But wait, there's more!
There's always more. We, we heard that, you
know,
some people really, really like JavaScript
these days, and
so we thought, we'd like to put some robots
on JavaScript. So Cylon dot JS is a project
we just announced last month. And it lets
you
use CoffeeScript or JavaScript with node.js
to do basically
the same exact thing that you just saw, except
in those languages.
And so it's actually available now. It doesn't
have
all twelve platforms supported. The Artoo
does, but it's,
but we're getting there. And then, today we
announce
GoBot!
Because we heard that the Go programming language
was
something you guys were kind of interested
in, too,
and we sort of liked it ourselves. And we
thought, Go, Go Robot! so, actually GoBot
is this
month's project announcement. It's literally
very, very hot and
fresh. In other words, it barely works, but
it
kind of does.
And I-
ADRIENNE: It runs Conway's Game of Life.
R.E.: Exactly. We have artificial life with
GoBot already.
So, so check it out. Join the Robot Evolution!
Because we need all of you to help us
build this future. So artoo dot io, or follow
us @artooio on Twitter. cylonjs dot com or
follow
us @cylonjs on Twitter. Or gobot dot io and
follow us @gobotio on Twitter. So once again
-
those numbers again.
Artoo dot io, cylonjs, and gobotio.
All right. So I, for one, say welcome to
the machines. But there are a few questions
that
we have. One of them, perhaps, has to do
with robot economics. So when machines are
doing the
jobs that humans do now, what will we do?
Kurt Vonnegut in Player Piano kind of posited
a
future where the satisfaction that we have
would be
greatly lacking because of a meaning and purpose
that
we needed in our lives. And what about the
pay that people need for jobs?
Well, and what about robot ethics? Do robots
actually
have ethics, or do they only have the ethics
that we give to them? So what is going
to happen? The answer is - I don't know.
However, I know some actual professional futurists,
and Daniel
Rasmus is a very dear friend of mine. He
wrote a book called Listening to the Future
where
he talks about something called scenario analysis.
So we're gonna do a little scenario analysis
of
what we think's gonna happen, and we're gonna
use
two axis. The first one is robot sentience
-
will it become intelligent or not? And the
other
one is robot friendliness - will they be friendly
or hostile?
And because we are a Los Angelos based company
at HybridGroup, we look at everything in terms
of
Hollywood movies. So a, if the robots become
non-intelligent
and they're not friendly, we get the movie
Brazil.
In other words, life today.
Now, if the robots become intelligent but
they're not
friendly, we get Terminator. Enough said.
Now, if the robots are not sentient but friendly,
we get Power Rangers. And then if the robots
are both sentient and friendly, we get singularity.
So this guy spent a lot of time thinking
about what was gonna happen in the future.
I,
I hope every one knows that this is Isaac
Asimov.
AUDIENCE: Oh yeah.
R.E.: You didn't know Conway's Game of Life,
but
thank you know Asimov.
So he wrote the three laws of robotics, and
I'm gonna read them to you now. Number one:
a robot may not injure a human being or,
through inaction, allow a human being to come
to
harm.
Number two: a robot must obey the orders given
to it by human beings, except where such orders
would conflict with the first law.
And then number three: a robot must protect
its
own existence, as long as such protection
does not
conflict with the first or second laws.
So, how's that been working out for us guys?
But I don't think it's fair to blame the
robots, because this in fact is not a robot,
it is a drone, and it is being controlled
by a person in a hidden bunker, where they
are far, far away from the battlefield where
these
weapons are actually being utilized against
real humans.
So we propose a small change - just a
little patch revision to Asimov's first law.
Version one
point one. A human may not injure a human
being or, through inaction, allow a human
being to
come to harm.
Imagine that future. Let's make that future.
Thank you.