Ruby Conf 2013 - Ruby On Robots Using Artoo by Ron Evans

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.