paint-brush
Create Lego Mindstorms Robots with Swift — Robotary Reviewby@attilavago
5,191 reads
5,191 reads

Create Lego Mindstorms Robots with Swift — Robotary Review

by Attila VágóDecember 29th, 2016
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

In an attempt to create something awesome and satisfy my own undying love and curiosity for robotics coupled with general tinkering and software development, two years ago I bit the bullet and got myself not one, but two (and a 3rd one this year) Lego Mindstorms sets. The <a href="https://shop.lego.com/en-IE/LEGO-MINDSTORMS-EV3-31313" target="_blank">retail edition</a> and the <a href="https://education.lego.com/en-us/products/lego-mindstorms-education-ev3-core-set-/5003400" target="_blank">education set</a>.

Companies Mentioned

Mention Thumbnail
Mention Thumbnail
featured image - Create Lego Mindstorms Robots with Swift — Robotary Review
Attila Vágó HackerNoon profile picture

A personal Lego Mindstorms project I’ve been sitting on for the last 2 years, in its infancy state …

In an attempt to create something awesome and satisfy my own undying love and curiosity for robotics coupled with general tinkering and software development, two years ago I bit the bullet and got myself not one, but two (and a 3rd one this year) Lego Mindstorms sets. The retail edition and the education set.

Before I go into the actual review, I am going to answer a few questions that many have asked me about these sets, so that I won’t have to ever answer them again:

Yes. They are expensive most of the time. The retail set however is often at up to 40% off on Amazon.

No. You do not need both sets to create robots and/or learn robotics, but the education set does come with a rechargeable battery pack, an extra ultrasonic and a gyro sensor. Buying just the sensors, the brick, the battery pack and the connector cables individually would cost you more than the set itself, so you could potentially say you’re getting all the Lego building parts for free. The education set tends to be better value for money if you ignore Amazon’s 30–40% off occasional offers. On that note, here’s a parts list comparison between the two sets. It’s a very exhaustive list of everything you need to know.

No. You do not need to buy any expansion packs. Any System and Technic Lego will do just fine, no matter how old or new. Lego Mindstorms EV3 is even compatible with its older sibling, the NXT should you have any of that in the attic. Expansion packs are expensive and frankly, not that useful (I own one of these expansions sets, so I talk from experience).

No prior programming experience is necessary, the software — which is visual and intuitive, be that the retail or education edition — will guide you through everything you need to know. That being said, there are a few extremely well-written and illustrated books out there that you might find useful, such as the EV3 Idea Book and The Art of EV3 Programming, which I both own and cherish.

On that note however, I have to say that one of the main reasons I have sat on this project of mine more or less idle for the last 2 years, was the software that Lego offers. IMHO this is in no way development environment. Just like I never saw Scratch anything else than a teaching tool, I don’t see Lego’s EV3 Programming IDE anything else than what it really is — another Scratch, a tool that allows kids and students to pick up programming concepts. So I needed something else.

There’s Lejos, but it’s Java (and I simply hate Java) and just looking at the site, gives me the creeps. What’s with hard-core developers and their inability to put up an inviting, well designed and well documented website? Then there’s RobotC which is another prime example of a terrible first impression and with a not so inviting pricing setup either. However, it employs a C-based language, which I like, so I was considering it. Finally, an option that almost convinced me, was ev3-npm. JavaScript I write on a daily basis, Node I can deal with, so all in all it almost looked like a winner. Until last night …

Looking for more info on ev3-npm, I actually ended up discovering another quite new and fairly ambitious project of bringing EV3 programming to developers and tinkerers, namely Robotary. Looking at the website, you can already see, you’re dealing with someone who actually put some effort into building a good-looking website. Sure, it’s not responsive, but it’s inviting, and to me that says a lot about the software you’re selling. It also costs less than RobotC’s any licence, and it’s a one-time fee of $14.99. Hard to beat, if you ask me. However, none of that makes Robotary special. What sets it apart from the crowd is that it uses Swift 3, Apple’s new programming language as the code for creating your EV3 apps.

And Swift, I like. Swift is a modern language, much like Python and Ruby. It’s also multi-purpose, running on anything from iOS, MacOS, or even a web server. It’s fresh, and it gives me a great excuse to leave the clunky, clicky, touchy, draggy Lego environment, so I bit the bullet and bought the app. No reviews on the Apple store, online, and have yet to find someone on the EV3 Facebook group who has had any solid experience with this, therefore I’m going to do my best and test a few things out.

Anything from here onwards in this article will be frequently updated as I test more and more things out.

My initial test involves fairly basic things, namely testing out the general usability and stability of the software, its features and basic code to run some of my motors and sensors. From a hardware perspective, this is what I am working with:

The test EV3 hardware

  • 1 EV3 Intelligent Brick
  • 4 large servo motors
  • 1 touch sensor
  • 1 ultrasonic sensor
  • 1 gyro sensor
  • 1 colour/light sensor
  • 1 IR sensor
  • 4 short connection leads

I am running the app on a mid-2012 Macbook Pro Retina, 15" top of the line (back then) hardware configuration, and MacOS Sierra.

Note: several reports from some EV3 Facebook Group members now show that on the latest Macbook Pro 2016 with touchbar, the app crashes quite often:

Michael B.A. It crashes quite often for me on 2016 MBP with touchbar. I hope they will fix it down the road so it is not a huge concern for me.

and

Jildert De W. […] Does crash quite a lot on the new mbp 2016 w/ touchbar, but Apple’s Xcode does that as well.

clearly have issues running it for longer periods of time. This however does not seem to be the case for those like myself with older editions, or the 2016 edition with no touchbar:

Frank L. It runs on Sierra […] No crashing detected i’m running on mpb 2016 (without touchbar)

So in terms of setup, nothing overly fancy. No Lego building bricks, it’s a purely test-run environment setup meant to test a little bit of everything, including Swift itself and the library Robotary provides. And on that note, here’s something I already absolutely love: the library’s documentation: it’s clean and to the point. Exactly the way us, developers like it! Oh, and it also features a Getting Started section. Very thoughtful.

You’ll notice that I jumped directly into the docs part, and have not mentioned anything on how you start Robotary or any intro to running this app. Well, that’s simply because it’s so dead-simple to use. It almost feels like it was developed by Apple itself. If you like X-Code you’ll like Robotary too. A very clean and intuitive IDE that looks like this:

Code on top, variables and dashboard on the left and console log on the right. Very neat.

The above code-sample you see is actually from a library of samples the app comes with, available for both EV3 and NXT! There are less samples for NXT but that’s understandable, given the system’s old age and decreasing popularity. That being said, the docs themselves are just as detailed and well-written as they are for EV3.

Connecting an intelligent brick is just as simple as plugging it in via USB and turning it on. Alternatively, you can choose to connect via Bluetooth, should you feel you prefer an untethered connection — which may often be the case. With the brick connected I can see a number of important features I can trigger via the Tools section, like the device information panel and the file browser.

A quick note about the Bluetooth connection, it connects as you would connect any other Bluetooth device via the appropriate settings in MacOS:

As you can see it shows up as not connected, but that is actually not the case. Robotary will see the brick being available and only when actual communication is taking place between it and the brick, will it show up as connected. At first I thought something went wrong in the connection or the pairing process, but don’t panic, it’s actually a welcome energy-saving feature.

There is no WiFi connection ability though, and that for some can be a deal-breaker, and it is after all, a fair point.

Frank L. It runs on Sierra, but lacks the Wifi connectivity only option is to connect via BT or USB. I would like to see WiFi Added.

That being said, one could argue that the brick itself does not have a WiFi feature — as that only works through a USB dongle even with Lego’s software, so it cannot necessarily be called a native requirement. Of course, that does not mean it’s not a feature all of us EV3 developers would like to see added as soon as possible. Hint, hint… ;)

So far things look surprisingly good for an app that came out of nowhere, done by - from what I can see - a single developer and his associate. 10/10 for good and clean UI, UX, and well-crafted documentation.

But there’s clearly more to a capable software than design and stability. So let’s get some of my motors running and my sensors… well… sensing. :)

What will follow is a series of tests, six, to be more accurate, and will go through testing the following in the below order:

  1. motor: time and speed measurement
  2. touch sensor: touch levels
  3. light sensor: light levels and colours
  4. IR sensor: distance measurement
  5. ultrasonic sensor: distance measurement
  6. gyroscope: getting tilt value

Without further ado, let’s dive into the code.

Note: most of the code will to some extent or another be modified versions of the “examples library code”. For the purposes of this review, I believe it’s enough. At a later date — as I develop my actual project — I shall post code samples of the project itself, as part of another article.

Testing the servo motors

I consider the above test to have been concluded successfully without any glitches. All four motors, both as a group and individually, run fine and console logs are printed out to the log area as expected. Both second and millisecond time units have been tested.

Note: I have also done a separate test of very sort running times: 10 and 20 milliseconds, both successfully, however, note that running a motor for 10ms only will not render anything visible, the only way you’ll know it worked, it listening to the motor and hearing the short click.

Testing the touch sensor

Working with the touch sensor is not included in the examples provided in the app’s code samples library, so I have cooked one up from scratch. This is also the first time I was completely reliant on the docs provided by Robotary. The test works and is successful, but it did bring to light three issues:

  • SourceKit crashing at some point so often, it rendered the app unusable — turns out that crashing is not a Macbook Pro 2016 issue only. Any code that doesn’t respect Swift syntax, crashes the app.
  • The documentation while nice, Apple-like and well organised, it’s going to be tough to digest for anyone who doesn’t have a couple of years of programming experience. Actual code examples would make this a whole lot better.
  • The code samples library does not contain any code to illustrate the use of the touch sensor. I find that at least odd, if not a shortcoming.

Testing the light/colour sensor

The above code is a verbatim copy of the original snippet from the examples library, and it does a good enough job for a test-case scenario. I managed to get ambient light intensity between 1% and 80% output onto the intelligent brick’s screen.

For the colour sensor test (which in EV3’s case is the same piece of hardware as the ambient light sensor), I’ve had to cook up again some original code, as none was available in the example library.

The code is similar to the touch sensor test, where I basically wait for the right event to trigger the console log. For testing purposes I’ve only used three colours.

As a side-note to the developer of the app, I find it a bit sloppy to include example code for ambient light and not for colour sensing. Half-done jobs never inspire too much confidence.

Testing the IR sensor

The above code sample is essentially the same as you’d find in the example library, except with just one motor on port A. The test ran as expected, without glitches, recognising the obstacle, stopping the motor and issuing the appropriate output to the screen and speaker.

Testing the ultrasonic sensor

This test again, uses essentially unedited library code, expect for the distance that I have set to 50cm (half a meter). This test being very similar to the IR sensor test, it’s no surprise that it ran as expected, without glitches, recognising the obstacle, stopping the motor and issuing the appropriate output to the screen and speaker.

Testing the gyroscope sensor

This final test is based on the colour sensor and touch sensor code, and was written from scratch, as there’s no gyro sensor example library code available in the app. That makes this a total of 3 sensors that have not been accounted for in the example library. The test itself ran fine, outputting “90” whenever the tilt position was less or equal to 90 degrees.

So, what does all the above say about Robotary? Truth be told, by now it’s a very mixed bag.

The good:

  • it’s very well designed, with excellent UI, while providing excellent UX (when it doesn’t crash)
  • it’s feature-packed, especially for a 1.1 release
  • the documentation is of familiar style— xCode like — and well organised
  • it’s very lightweight and uses the latest version of Swift (v.3)
  • it’s fairly inexpensive and it’s available on the app store
  • excellent error checking and code-completion

The bad:

  • the app expects 100% Swift syntax. Should you by any chance write even a single line of any other syntax, SourceKit crashes and so does Robotary. So stability is very flaky.
  • the documentation lacks examples, rendering the app unfriendly to Swift or programming juniors.
  • the sample code library lacks code for 3 important sensor types for EV3 and even more so for NXT. It’s incompleteness is a major let-down.
  • bluetooth connection is flaky and unstable. Often the only solution to make the app see the bluetooth connected intelligent brick, is by restarting it (the app).
  • programs created with Robotary, run in a sandbox on your machine rather than the brick itself, so a constant connection between Robotary and the brick is necessary to run your code.

The desirable:

  • WiFi support, while not crucial to most people, it’s definitely a required addition if it wants to stack up against the competition and Lego’s software.
  • Pixy Cam sensor support.
  • Running the app natively on the intelligent brick — custom firmware.

All in all, while it might seem like I am not ending this review on an overly positive note, Robotary is an excellent effort and holds a lot of potential, and I believe the developers together with Lego Mindstorms community feedback and support can turn what now is a beta product into a really exciting new and possibly the best app out there for EV3 and NXT developers, enthusiasts and tinkerers.

As an engineer and developer, I can, more or less, get things done, but as it stands now, this is not a production-ready application. But it’s close, so very close that it’s almost more disappointing than if it were a terrible application with no potential. If you’re an engineer or someone with experience in programming, it’s already worth spending the $15. To quote Michael B.A. from the Lego Mindstorms EV3 Facebook community:

Screw those 15$. I Think it is worth throwing money at the industry even if this specific product is no good.

But this one is good. Well, almost. It’s getting there… ;)