
Artoo: Ruby on Robots - adamnemecek
http://artoo.io/
======
cageface
Ruby has put food on my table for the better part of the last fifteen years
and there's a lot I love about the language. But it also feels increasingly
unlikely that it will escape the Rails ecosystem to any significant extent. In
the dynamic language space Javascript seems unstoppable and with the ES6 and
ES7 features and vastly better performance I don't see much advantage in
sticking with Ruby in the long run other than the excellent Gem ecosystem. And
for larger codebases I think opt-in typing a-la Typescript is a huge win.

I'll always applaud creative projects like this but I'm not optimistic about
the longer term health of Ruby at this point.

~~~
gentoopenguin
What I can't understand is why Ruby's standard implementation still has such
terrible performance after all these years. Yes, the language is quite
complicated, at least syntactically, but semantically it's similar enough to
Smalltalk, and most Smalltalks have fast jitting VMs, including Squeak and
Pharo (CogVM). The Ruby community is enormous by comparison and full of
productive, opinionated developers who write tons of code, books, and blog
posts, and yet the standard implementation (MRI) remains abysmal (sorry).

It's really unfortunate that the MRI devs won't support Rubinius or event
adopt RSpec to ensure interoperability with it:

[http://rubini.us/2014/12/31/matz-s-ruby-developers-don-t-
use...](http://rubini.us/2014/12/31/matz-s-ruby-developers-don-t-use-
rubyspec/)

~~~
cageface
I've wondered about this too and my best guess it that writing a good
optimizing compiler for a dynamic language like Ruby or Javascript is quite
difficult and beyond the abilities of most developers. The JS engines in the
major browsers are only fast because tremendous resources have been devoted to
making them fast. I don't think PyPy or Rubinius have had anything close to
the same level of investment. This is why I think JS is pretty much guaranteed
to "win" the dynamic language race in the long run.

~~~
MrBra
You're reasoning is taking a bit too much for granted that the best engineered
solutions will be the ones coming off big corporations investments but in this
field this has been proven wrong many times... that's not always the one and
only win factor.. fortunately.

~~~
cageface
It's true that LuaJit is mostly the work of one person, as far as I
understand. Maybe talent _does_ take precedence in most cases. But the
incentive for browser developers to improve and optimize JS is just vastly
stronger, despite its flaws, for practical reasons. The impact of the work is
just orders of magnitude larger.

------
schappim
A word of warning for those wanting to use this on Raspberry Pi.

Firstly I love what the folks are doing with 'thehypridgroup'are doing with
Artoo however:

I teach Raspberry Pi Workshops in Australia
(raspberry.piaustralia.com.au/workshop). I initially used to teach the
workshops using Artoo, however I found it buggy.

I've since migrated the workshop to Python. I'd prefer to do the workshops in
Ruby, but the gems have not kept up to date with the new hardware.

I also don't believe this will work with the Raspberry Pi 2 Model B (the
current generation Raspberry Pi).

I haven't tried on other platforms recently.

~~~
wtf_is_up
Not sure how you feel about Go, but thehybridgroup also have a Go port [1] of
this lib (and a node.js one, I believe).

They gave a pretty cool demo @ last year's GopherCon [2]

[1] [http://gobot.io](http://gobot.io) [2] [http://youtube.com/watch?v=Va-
NE55AqBs](http://youtube.com/watch?v=Va-NE55AqBs)

------
trishume
This is cool, but "on Robots" is a bit dishonest. Really it can only control
robots, the "robot" has to have some exposed interface for a computer to
control it, like the Firmata firmware for Arduino.

I forgive them though because they probably just call it "Ruby on Robots" for
the parallel pun to "Ruby on Rails" rather than to make people think it
actually runs on the robots.

~~~
andrewstewart
Artoo actually can directly run on single-board Linux computers, such as the
Beaglebone Black[1] or Raspberry Pi[2].

Running on such a device, it can in fact control other supported platforms
connected to it, such as the Leap Motion or Sphero (with addon hardware as
applicable).

For simpler stuff like the Arduino (or other micro-controllers), however,
Artoo needs to run on a beefier host platform and connect to the device
remotely.

[1]: [http://beagleboard.org/black](http://beagleboard.org/black) [2]:
[http://www.raspberrypi.org](http://www.raspberrypi.org)

------
buf
I think this is excellent for application developers looking to quickly make a
proof of concept with hardware. Well done.

------
TylerE
Seems like Go would be a good fit here - true parallelism would have to handy
since I'd imagine you'd often want to have several control routines running at
once.

~~~
vidarh
"True parallelism" is not a problem in Ruby at all.

If you stick to threads, then there is the global interpreter lock, yes, but
that has much less impact than people tend to think unless you depend on lots
of poorly written C extensions. Especially on small systems without lots of
cores.

And you don't need to stick to threads.

~~~
TylerE
"True parallelism" is EXACTLY _not_ having a GIL.

~~~
vidarh
It appears you missed the last line of my comment:

And you don't need to stick to threads.

Anyway, the GIL makes _no_ difference to the level of parallelism of most Ruby
apps unless you're on a server with lots of cores, so all you're really saying
is that "true parallelism" is irrelevant for most use cases.

On a server with lots of cores, it can start becoming a constraint if you
can't use multiple processes for some reason, but if you become constrained
with it on the type of small systems this is intended for you're doing
something _very_ wrong.

------
deeviant
What would be the advantage of Artoo vs something like ROS?

ROS has some pretty significant infrastructure laid down, and has bindings for
C and python. It probably wouldn't even be too hard to create a Ruby binding
if Ruby is your thing.

~~~
mikepurvis
There are already a ruby client for ROS:
[http://wiki.ros.org/rosruby](http://wiki.ros.org/rosruby)

However, I'm not aware of any significant ecosystem software written in it, so
it's definitely of the experimental flavour.

That said, the ROS 2.0 plan is to build generic header interface to the
standard client library so that the language support is a matter of generating
bindings rather than reimplementing serialization code and so-on.

~~~
ticking
The current serialisation code needs to die, and be replaced with something
usable and already existing, e.g. zeromq + msgpack.

There are currently horrible bugs in the very foundation of ROS, the spec of
the serialisation format and its hashing, that are in `wontfix` status because
the maintainers are idiots _.

_ The arity of a field (value, array [and its arity], list) is not part of the
hash of a message definition. Thus it is possible to change a message
definition breaking existing protocols without the clients noticing. This is a
hard to detect bug, that I've seen several times in the wild. But it won't be
fixed because it would break old precompiled packages (yes one would have to
recompile things _gasp_ ). So instead everything is left broken.

But hey I heard they want to change the messaging protocol to CORBA for 2.0,
what could go wrong with that...

~~~
deeviant
Well, my company uses ROS for two different robotic systems currently in
production.

We use ros serialization quite intensively and I would have to say it "works
fine". I previously came from a more enterprise-centered environment working
with a rabitMQ/Protobuff&Json stack, so I probably wouldn't have created ROS
serialization the way the maintainers did, but it hasn't gotten in our way at
all.

I don't think it's that great of an idea to place too much validation in a
serialization framework, as your are just asking for rigidity, which is why
Json went the way they did and is much better for it.

~~~
ticking
I agree 100% with you. Rigidity is something you don't want, but this is
something entirely different.

ROS serialisation format is basically a C++ struct that gets send over the
wire. You specify your .msg definition, tell the (horrible) build system that
you want to use it, and the build system will compile it to deserialisation
code in your language. During deserialisation of C/C++ this code will just try
to recast the message from a void* buffer to a valid .msg struct.

So O(1) message parsing, nice in theory, but also what causes the rigidity
that makes it harder for dynamic languages that would easily be capable to
deal with a self-encoding message format.

But because you end up with this unsafe recasting "parser", you _really_ want
to feed it what it expects, and this is why during tcpros handshake between
two clients they will exchange hashes of the msg format that they speak.

Note that this is fundamentally different from JSON where you are adding
fields. JSON _will still work_, as long as the new message is a superset of
the old one.

But with ros msgs a command might end up putting your nice robotic arm into
the table/human because you changed the LED from a green one to a
multicoloured that has a field `color[3]` instead of `color`. The field will
use up more space, and the field that came after it, say `arm-height`, will
now have the color value in it.

But we got the hash of messages to protect us from this right?

NO! Because the build system does a half assed normalisation step on each .msg
format in which it removes comments, reformats and reorders fields and tries
to find the canonical _textual_ representation of messages. Sadly somebody
forgot to keep the arity (variable/tuple/list) in there. So it gets thrown out
and is not part of the hash.

Source: I build a ros-msg deserializer from scratch for clojure that can
import message definitions at runtime, compiling them into ad-hock
deserialisers.

------
cwyers
If Lucasfilm sued Verizon over a word so innocuous as "Droid," I expect this
to get slapped with a trademark suit at some point.

~~~
JamesSwift
The idealist in me would like to think that this industry would allow a
playful homage.

~~~
cbd1984
The problem is, it isn't easy to distinguish between "playful homage" and
someone cynically trading on your goodwill with products designed to trick
customers.

Especially if you have to convince a court to stop _that_ company from doing
something which seems identical to what you've already allowed three other
companies to do.

These things are always so easy to see, so _obvious_ , when you're one person;
the moment you have to convince others, things so obvious as to not require
elaboration become serious points of contention.

~~~
riffraff
well but there is a difference between a free project run by unknown people
and a for-pay product run by a huge multinational product. E.g. there has been
a C3PO project in java for more than a decade.

------
pramalin
I have started and coached a new FIRST Robotics Competition team last year for
2014-2015 season and wanted to use Java. Initially I thought the programming
would be very complicated for the high school students, many of whom didn't
have any prior programming experience.

How can you control the speed of the robot proportional to the pressure
applied on the joystick for example?. However, I was very pleased with the
WPILib framework that comes with the kit. This can be accomplished by
essentially a single line like (ignoring the variable initialization),

    
    
        myRobot.arcade(stick);
    

[http://wpilib.screenstepslive.com/s/4485/m/13809/l/145307-cr...](http://wpilib.screenstepslive.com/s/4485/m/13809/l/145307-creating-
your-benchtop-test-program)

------
dorkrawk
How actively is this being maintained? I noticed that the last commits were a
few months ago. Maybe it's in a pretty stable place and doesn't need much work
these days, but I like seeing Ruby used for more than just Rails so I'd love
to see this stick around.

------
woah
I'm familiar with Tessel, which is something similar, but with their own
hardware and node.js. One of the implicit selling points is that Node is
uniquely suited for soft realtime stuff because of its completely nonblocking
nature. Is most Artoo code blocking?

~~~
angersock
If you're really about soft-realtime stuff, look into Erlang/Elixir by way of
the Nerves project:

[http://nerves-project.org/](http://nerves-project.org/)

The hot code-loading is really impressive; I've seen quadcopters update motor
controllers in-flight to fix bugs. I think that that's probably the future.
The non-blocking stuff in Node is more a function of the library style than
the language itself (though the closures make life easier). I don't think
there's any reason why the Ruby stuff _necessarily_ has to be slower and
blocky.

Artoo has some nifty stuff in the vein of testing:

[http://artoo.io/documentation/guides/test-driven-
robotics/](http://artoo.io/documentation/guides/test-driven-robotics/)

------
m4tthumphrey
Any plans to support Romo?
[http://www.romotive.com/](http://www.romotive.com/)

------
gr8b8m8-88
This is awesome! I myself am a former mechanical engineer who now does Ruby
(and JS), and now that Ruby is finally on other embedded machines, I can
finally start building some gay robots.

~~~
angersock
I too believe that robots running Ruby would be quite happy!

