Artoo: Ruby on Robots | Hacker News Reader

Artoo: Ruby on Robots

artoo.io

194 pointsadamnemecek56 comments

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.

> But it also feels increasingly unlikely that it will escape the Rails ecosystem to any significant extent.

It already did, with Puppet, Chef and Vagrant.

Also, mruby is gaining adoption and Rubymotion seems to be in an interesting niche.

There's a lot of new projects currently (like Lotus), so I wouldn't as negative as this.

Also, don't ignore the foothold that Ruby has in the asian markets.

Puppet is only "escaping" in that it's implemented in Ruby. It's not people outside the Rails world picking up Ruby.

Chef, in my experience, is favored almost exclusively by people who are already Rubyists. The concept of applying The Power Of Ruby (TM) to system configuration is not attractive to non-Rubyists.

I don't see Vagrant much these days. I suspect Docker is displacing it.

The fact that Ruby is the language chosen to implement these tools is the proof it's not just for Rails.

Also, Docker may become more popular but I doubt it is going to replace Vagrant. There are just too many times where you need a full VM instead of a container process. Not every problem can be solved with containers.

Also where do you test your docker containers in?

Also, SketchUp. (http://www.sketchup.com/intl/en/developer/)

> And for larger codebases I think opt-in typing a-la Typescript is a huge win.

You can have static typing with InfraRuby (at http://infraruby.com/live), and it's opt-in in the sense that InfraRuby code runs on Ruby interpreters without modification, but (un)fortunately InfraRuby doesn't support reflection so it doesn't run Rails.

Ruby devs could look at Dylan and Lisp for inspiration how to improve the language performance, but I doubt it will ever happen.

Me personally, I tinkered with Ruby when Rails initially came out and it was about it, as it didn't brought anything new to my toolset.

I found Rails to be a massive productivity boost from the Java frameworks that I was using at the time (Tapestry, Struts, etc). And I still think it's the most productive framework for the typical web CRUD app. But the typical web CRUD app is a dying breed these days and the poor performance and maintainability of Ruby/Rails for building fast, concurrent APIs puts it at a disadvantage.

I wonder how much of Ruby's adoption was driven by Rails, and how much of Rails' adoption was driven by developers who previously only had experience with languages like Java or PHP.

I say this because as nice as Ruby is (at least in some ways), someone already familiar with Lisp or Smalltalk will learn nothing new from it, and yet there are no shortage of blog posts by Rubyists touting its borrowed features as if they didn't exist before Ruby, suggesting, perhaps, ignorance on the part of its more vocal advocates and of those persuaded by them

I actually got into Ruby before Rails hit and was immediately taken by it because it brought some of the best features of Lisp and Smalltalk and Icon into a language with a very practical, unix-friendly implementation. So I could drop in Ruby where I previously might have used Python or Perl. This was much harder to do with Lisp or Smalltalk, for example.

But I didn't have a good excuse to really use it at work until Rails came along and completely blew the existing Java frameworks out of the water for productivity.

I've used 20+ languages over the years, and Ruby is by far my favourite not because it has "new" features, but because of it does it's best to ensure syntax gets out of the way.

And that is incidentally why I have no interest in Lisp or Smalltalk. I have a very visual interpretation of code. I can remember the visual layout of programs I worked on 20 years ago. Those visuals matters greatly to me to be productive with code, and means I am extremely picky about formatting that works for me, and I have nothing but hate for the layout of Lisp and Smalltalk code.

I'm greatful for all the great stuff to have come out of Lisp and Smalltalk. I just pefer to use those features in the nice embrace of Ruby syntax.

Ruby doesn't not fit in my toolset because the available implementations neither deliver the performance our customers care about, nor suits itself for the types of applications we usually are asked to deliver.

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...

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.

Alongside Julia, most likely.

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.

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.

Part of the problem is that one of Ruby's good sides is that most of the time, it does what you want without requiring most developers to delve into the darker corners of the language. Or indeed care much about performance.

While there are lots of productive, opinionated Ruby developers, the vast majority of us don't know much about the internals of the language.

Heck, for my part I'm working on a Ruby compiler (and have been writing about it for 7 years now... Unfortunately I have far too little time to devote to it), and part of the challenge is that there's no proper language spec and even most people working on MRI does not know the full semantics of the language.

My favourite example of this, is that for a long time during the 1.8.x, the inheritance of one of the core classes was different than what was documented - I wrote an article about the Ruby object model and was "corrected"; except my diagram had been created based on instrumenting the interpreter to verify what actually happened. It was like that for years without anyone noticing (and to be fair, it was a dark corner of the language - very little code depends on the specifics of the inheritance of the eigenclasses of the core classes).

Of those of us who love Ruby and are interested in compiler technology and have the motivation to slog it out to try to get working compilers - whether JIT or AOT - there are extremely few.

And most of that effort is going into JRuby, which is definitively seeing some impressive improvements (e.g. with Truffle) but which a lot of us avoid because of the JVM.

Ruby will get faster. And will get better implementations, but it may still take some time to have much impact.

MRI is using RubySpec (RSpec is something different).

http://rubyci.org/

The issue is more complex than Brian puts it.

https://lobste.rs/s/oozjtg/matz_s_ruby_developers_don_t_use_...

Also, MRI makes great improvements every version _while keeping breaking changes rather low_. Changing a running system is hard.

If jitting is what you want, JRuby is a very good option.

At the time of terminating RubySpec not a single MRI contributor had committed any code back to the main RubySpec repository for over a year. Sure, they might use it in terms of "run the specs" but they never contributed anything back. Besides their fork was highly outdated compared to the original repository.

Besides that I don't really get the fuzz about the particular tweet mentioned. This was in regard to various small changes being made that while nice were not very significant in the grand scheme of things.

That's because they decided to drop their efforts in 2013, because RubySpec broke their build.

Sure, it's a political debate, but just saying they don't run it also isn't honest.

I'm optimistic about the future of Ruby speed. We've seen a lot of improvement in the 2.x series of releases, to the point where we're as-fast-or-faster than Python in most cases.

I'm also very optimistic on the future of JRuby, as with the new 9000 release it has the potential to bring Ruby speed in line with base Java. It's got decent corporate backing now as well with Red Hat and Oracle funding people to work on it.

Are you sure?

From https://github.com/rubygsoc/rubygsoc/wiki/Ideas-List#mri-mat...

"List of ideas for improving Ruby during Google Summer of Code 2015", little summary:

- Fine-grained locking (a.k.a. removing the MRI global lock)

- JIT Compiler

- Type System

- New C Extension API

- Cross-thread Fiber support

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.

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 [2] http://youtube.com/watch?v=Va-NE55AqBs

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.

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 [2]: http://www.raspberrypi.org

Just because it doesn't run on the basic Arduino boards doesn't mean it can't run on other chipsets. It runs just fine on Beaglebone, Raspberry Pi, newer Arduinos, and Intels.

Essentially, don't confuse the general robot with the highly specialized Arduino.

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

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.

It is, which is why the same people also do:

http://gobot.io/

I agree, I don't know if Ruby is the greatest choice for a language so close to low-level. But, I am glad it (artoo) exists

"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.

"True parallelism" is EXACTLY not having a GIL.

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.

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.

If ROS is anything like player-stage, it is probably a great deal more involved for quick hacks than something like Artoo. P/S was a good research platform, but not good for hacking on stuff (not the year I spent with it, anyways).

I've been working with ROS for almost five years and maintain a number of sensor drivers and other packages. It's certainly a large and complicated system, but the onboarding story gets better all the time. If you're starting from an Ubuntu desktop, you can install 1500+ packages from debs, including pre-built Gazebo simulators for dozens of robots.

There are already a ruby client for ROS: 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.

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...

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.

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.

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

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

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.

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.

Lucasfilm is Disney now, right?

I don't think Disney would know a "playful homage" if they read it in a book of traditional fairy tales.

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...

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.

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?

Artoo is part of a family of libraries, all of which are similar. For Node.js robots, check out Cylon.js by the same group.

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

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/

Any plans to support Romo? http://www.romotive.com/

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.

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

Reply on news.ycombinator.com