Arduino: it’s not just for academics and hobbyists anymore!

I was first introduced to the Arduino in 2007 while at ITP.  At the time, I thought it was about the coolest thing I had ever seen.


 I also thought it had absolutely no use in industry applications.  As much as I loved the little gizmo, I dismissed it as a tool for academic and hobby uses while more serious hardware such as PLCs (programmable logic controllers) or specialized animation controllers were the only options suitable for professional applications.  And so, after my semester of using the Arduinos, I dismissed them as toys, albeit amazingly, unbelievably cool toys.  I put them in a drawer and forgot about them.

Seven years later, not only has the Arduino evolved a lot, but so has its uses, and it has lot more acceptance in industry.  I know it seems counter-intuitive to build a mockup for a high-budget project with a gizmo you bought from Radio Shack, sitting there next to the cell phone batteries and RC helicopters, but you really can.  Not only that, but it may well be the best way to do it.  Through its various versions, programming environment, libraries, and add-on hardware, it is possible to create nearly anything that involves sensing, control, and media.  And it’s still cheap, much cheaper than its more industrial counterparts while offering much more flexibility.  Sure, you will not be controlling, say,  a half-million dollar ride vehicle with one, but short of that, and especially for prototyping, mockup, and proof-of-concept purposes, it is possibly the fastest, most flexible, and least expensive way to build things.  It is, after all, a way to accomplish that task you may know as “Show Control” or “Automation.”  It’s just cheaper and more flexible.  Easier?  At times.  At other times maybe not.

What is it?  

The Arduino is an open source microcontroller.  In simple terms, it’s a little board-based device that has a bunch of inputs and a bunch of outputs.  You tell it what to do with the outputs based on the logic, which you write with code.   What kind of inputs?  These could be manual controls such as simple pushbuttons, knobs with potentiometers attached, or sliders.  It could also be sensors such as proximity sensors, light sensors, limit switches, optical sensors, color sensors… or about a million other things.  You can also use methods and protocols such as infrared, ethernet, RF (radio frequency,) and serial communication.  What can you control?  Once again, pretty much anything, ranging from simple blinking LEDs to servo and stepper motors, relays, larger full-color LED displays,  theatrical lighting, and… a million other things. Through the use of relays, you could control pneumatic circuits for animatronic figures or show action equipment.  So, for example, you could say “when someone pushes this button, play this sound and this video, and light up this display, but not until they’ve hit this other button first, which makes this air cylinder animate this prop.”  


How Do I Program It?

Well, that’s just it, you DO have to program it.  There is no fancy timeline-based interface like there is on animation controllers, and there is no ladder logic like there is on PLCs.  You have to write that code yourself.  Yes, I know.  Scary!  

"I don’t have a Computer Science degree!"  "I’m an Art Director!"  " I’m a Project Coordinator!" " Functions and variables and loops, oh my!"  " I can’t possibly learn to write code!"  "It’s too hard!"

It really isn’t.  Writing code, particularly for the Arduino is, well, very, very logical.   Of course, there are also thousands of example on which to base your code, but you will have to get comfortable writing IF statements, working with variables, working with loops and functions, etc.  The Arduino programming language is based on C and is accessed through its IDE (Integrated Development Environment,) that interface you use to type your code in and then upload to your board using a USB cable.  


And so, while this isn’t quite as easy as plopping down logic on a timeline on an animation controller, it does allow for much, much, much more flexibility.  You will stop saying “I wish this thing could do X,” and instead start saying, “how do I get this thing to do X?”  If you eventually outgrow the default IDE, you can try out an alternative such as Maria Mole, or you can just write up your code in any old text editor, then copy-paste it into the Arduino IDE so that you can upload it to your board.  If this all sounds terribly confusing, it really won’t be once you start doing it yourself.  So if you’re an Art Director, Prop Builder, Storyboard Artist, or Lighting Designer who has never written a single line of code in your life, but would like to stop calling for help every time you need to build a mockup or a prototype, just get over your fear, and sit down and try it.  It is easier than you think.  If you are a Show Control professional, it will be a piece of cake.   

What are my options?

Okay, so we can go over the currently available crop of Arduinos.  The most common variety is the Uno.  It is so common that you can find it in Radio Shack.


As the most common version of the Arduino, the Uno is a great place to start, because it has the highest level of compatibility with shields (more on this later,) and libraries (more on this later too.)  Most likely, you’ll end up using the Uno as your general purpose go-to tool, just like your Leatherman multi tool. On Amazon, an Uno costs a whopping $25.  If you’re really cheap, you can take your chances with a generic copy.  Some of them work great.  Others don’t work at all, so if you decide to save $10 on a generic clone, understand the risks.

If you need more inputs and outputs and more memory (you’d be surprised at how quickly memory fills up on these tiny boards,) you can move up to the Arduino Mega.  Let’s say your project, perhaps it’s a kiosk or something, involves 20 push buttons, 5 proximity sensors, some infrared, and a bunch of servo motors, and the Uno just isn’t big enough.  This is my personal favorite, because it’s pretty hard to run out of inputs and outputs and memory. Besides, I just like to say “mega.”  It costs a bit more than the Uno, but still, if you compare it to industrial PLCs and animation controllers, it’s downright cheap.  It does have, however, less compatibility with shields and libraries, since it isn’t used nearly as often.



If you want to build something smaller, say a prototype for a toy, you might look into something like a Pro Mini.  It doesn’t have a nice set of headers pre-installed.  This means that in order to prototype, you’ll have to stick it into a prototyping breadboard, and that eventually, you’ll probably have to have a custom board made for it.  

 If you specifically need sensors to control a computer with keyboard input, let’s say in a kiosk, you might use the Leonardo.  So suppose you, or someone else, makes a whiz-bang application that needs a computer to run on and operates on keyboard inputs.  The problem is, you don’t want people to be pushing keys on a boring old keyboard.  You want them to be pushing nice, big themed buttons, or waving their arms, or yelling or singing or something like that.  You can use the Leonardo to emulate those keyboard presses.


Another really cool device is the Arduino Ethernet.  With this device, you can talk to your Arduino through a web browser, have it talk to other devices over ethernet, etc.  You can also do this with a shield, though, which might cause you to ask…

What are shields?

Shields are add-on boards that you plug into the Arduino for added/specific functionality.  For example, you can make your Arduino play back sound with this shield and this one.  You can record your data to a memory card with this one.  Theater people: you can control DMX with this shield, though be aware that it has some limitations.  If you really get into coding for DMX, I recommend something like this instead.


What are libraries?

Well, the long-winded answer is here.  In more simple terms, it’s code that someone else has written so that you don’t have to.  Using libraries makes programming for specific functions (let’s say, playing sound or controlling servo motors) much, much easier.


How can I get started?

Obviously, you need to buy an Arduino, but beyond that, I recommend this excellent book.  On top of that, Arduino development has a huge internet presence, and you can find out just about anything with a web search.


Are there other similar gizmos?

Yes, there are.  Intel has introduced its version, called the Galileo.  In addition, there is the Teensy.  The Teensy does not yet come with a nice board package like the Arduino, but you can buy/build them yourself.  

So there ya go.  This stuff is Show Control and Automation on the cheap, only you can do so much more with it.    

A brief rundown of data flow programming packages

I have been teaching myself yet another piece of data flow programming-media wrangling-presentation type software this week, and it has occurred to me just how many of these things there are now, and how completely baffling and overwhelming all these different packages might be.  Trying to figure out what does what and when to which one is pretty confusing, to say the least.  So, in an effort to summarize some of the packages available, I decided to do a blog post on the subject.

Derivative TouchDesigner is one I just started learning this week.  I am just barely getting my feet wet with it, but it’s quite amazing and intuitive.  From the TouchDesigner wiki:  

TouchDesigner is a software product from Derivative (Toronto and Los Angeles) which is used to build interactive 3D and 2D applications. It is “procedural”, “node-based”, real-time and is considered a visual programming language. It is designed to give its users enormous flexibility in building applications without needing to program in a conventional way.

When I first started watching the instructional videos on TouchDesigner, I thought the terms “CHOps” and “TOps” sounded awfully familiar, so it wasn’t much of a surprise to find out that its roots are in Prisms/Houdini.  

Here you can see a screenshot of the example project, and as you can see, it is definitely a “data flow” node-based approach to programming.  Scripting capability is available via Python (not sure where yet, but it’s there somewhere,) and you can access the 3D functions of your GPU, use OSC (Open Sound Control,) etc.  As TouchDesigner has its roots in graphics, both 3D and 2D, it makes sense that most content created with it is graphics-oriented.  I will make more entries about TouchDesigner as I learn it, because, as I mentioned, I just started with it.  But it seems like an enormously flexible tool.

Now onto our old standby, Max MSP.  I am much, much more familiar with Max, and while I most certainly can’t claim to be an expert in it, I have been using it since 2008 or so.  From wikipedia:

Max is a visual programming language for music and multimedia developed and maintained by San Francisco-based software company Cycling ‘74. During its 20-year history, it has been used by composers, performers, software designers, researchers, and artists for creating recordings, performances, and installations.

As you can see, Max also has a very data flow, drag-and-drop interface.  Scripting is available via javascript (which I have not used personally,) and you can get just about everything into and out of Max—OSC, Kinect, DMX, etc.  Max’s wonderful video extension, for both live video and manipulation of pre-rendered video, is called Jitter.  Max’s real strength is its documentation and its huge user base.  If you don’t know how to do it in Max, you can usually find out without too much trouble.  Max’s weakness, IMO, is when you try to go into 3D space.  My one experience with attempting to access openGL in Max consisted of printing out hundreds of pages of baffling instructions and tutorials, giving up, and then just coding everything in Processing instead.  Since TouchDesigner has its roots in 3D graphics, I have to wonder if it might be the ideal tool for that sort of work instead.

Alright, now onto the ones that I have absolutely no experience with, but they’re worth a mention.

VVVV is “a hybrid graphical/textual programming environment for easy prototyping and development. It is designed to facilitate the handling of large media environments with physical interfaces, real-time motion graphics, audio and video that can interact with many users simultaneously.”  As you can see, we have yet another very Max-like interface.

This is vvvv’s wikipedia entry.  

Pure Data is “enables musicians, visual artists, performers, researchers, and developers to create software graphically, without writing lines of code. Pd is used to process and generate sound, video, 2D/3D graphics, and interface sensors, input devices, and MIDI. “

As you can see, we once again have a very Max-like interface.  

Isadora is a package that’s enormously popular in theater and live performance.

"The award-winning, real-time media manipulation software to create stunningly interactive visuals, sounds, and environments."

And then there are more specialized entries such as Watchout and MadMapper for more timeline-based work and projection mapping specifically.  

There are also many, many others (like those specializing in VJ applications) that I haven’t mentioned, and then I suppose that one could argue that there is also some crossover with 3D content creation tools like Unity.

To complicate matters, there’s a lot of crossover among the tools.  While most people consider MadMapper to be a projection mapping tool, for instance, you can also do similar things with Max, TouchDesigner, or Isadora.  Right now I’m just going to focus on learning TouchDesigner and will blog about my progress here. 

Really awesome metal 3D printing via robotic arm

The MX3D-Metal is the latest project from Joris Laarman Lab.

Getting GIS data files into your 3D applications

It seems that GIS (Graphic Information Systems) are playing an increasingly important role in, well… everything these days.  At some point, you might need to import GIS data into your 3D application.  Let’s say you’re doing an architectural rendering, or a sight line study, or something, and you need to see how the terrain affects your site.  So, the typical method of doing this is to ask your GIS person for a 3D model of the terrain, and then bring that into your 3D application, merge your models… and then deal with a bajillion polygons eating up all of your RAM, crashing your computer, and taking up many hours of rendering time.

Guess what?  There’s an easier way.  Almost any 3D application these days (Maya, Cinema 4D, 3DS Max, etc.) will support Displacement Maps.  First of all, if you have GIS shape files (*.shx) you can view them in ArcGIS Explorer, which is a free download.  This should give you some idea of what your terrain is supposed to look like.


 At this point, most people ask their friendly GIS expert to export the terrain as some kind of 3D file, dxf, or possibly VRML, or fbx, resulting in a massively huge, lockup-inducing mesh of zillions of triangles and much frustration.  There’s another way!

Instead, ask your friendly GIS expert to export a DEM file.  What’s a DEM file?  It’s simply a grayscale raster image that represents the terrain instead.  And what are those useful for?  That’s right, displacement maps!  See, this is what our DEM file looks like:


Black represents the lowest points in the map.  White represents the highest points.  Now it’s a simple matter of placing one flat plane (it can be one polygon,) applying the dem file as a displacement map, setting your tiling and scale correctly, and you’ve replaced many, many triangles with one simple plane and a texture map.  This image took a scant few seconds to render in Cinema 4D:


You can then ask your friendly GIS person what elevations are the lowest and highest in the map, set your displacement map accordingly, and *poof* everything is to scale.  Remember that the GIS elevation is in feet above sea level!  This is why you have to ask for relative heights instead of absolute.


In this case, I have asked for a few reference points from the GIS data.  I have then eyeballed the locations on my ground plane in the XZ plane, then placed a cube and scooted it back and forth in the Y axis until it was sitting at the same height as the displaced terrain.  Then I took a note of the Y position in feet.

It turns out it is not too far off.  Of course, it’s not exact, and I did have to keep doing test renders over and over again to see where the placeholder cubes were, but it’s pretty close.  And again, using this method, the test renders are lightning fast.

There are limitations with this, however.  The displacement map typically won’t render in your working viewport, so you won’t get to see it until you render your project out.


So if your project requires very close work with the terrain (for example, showing a house sitting on a mountainside,) you’ll have to do things the old way, by importing 3D data directly.  An alternate solution is to “bake” your displacement map into your geometry if your 3D package allows you to do so.