Run, Robot

Consider this post a re-visit of my "Theater Should not be a Hackerspace" rant.

I'm in the middle of the run of a very complicated show that was thrown together too fast on too small a budget, by a company that has fallen in to a pattern of doing that.  The props and effects, some of the costumes and set dressing, and other basic technical elements are held together with gaff tape and hot glue.

My robot is one of these elements.  Although I spent the money and did the research for a robust chassis and control linkage, what we had time for is a $40 R/C car chassis carrying the lightest extruded-foam body I could build on top of it.  Even a fiberglas shell would be too heavy for the undersized motor -- and at that, I had to tighten the suspension with a few strategically-placed zip ties.

It has managed to survive running into scenery a few times and being kicked by actors more than once.  It only failed to make an entrance once in the run -- due to the antenna on the transmitter being snapped off thus limiting control range to about two feet.  That required a last-minute frantic repair with brass tube, epoxy, and a quickly-soldered wire to bridge the gap.

The lights also failed once -- in the same performance the projector douser failed -- and this is exemplar of what I was talking about.  There is a real difference between a "hacked" solution that will last for a quick shoot or the first day of a convention, and an engineered solution that will work reliably through a five-week run.

The best thing I can say about the douser is that it was already built.  I had to rip off the flag and epoxy up a new one to fit the particular projector, and I had to modify the software to use an external switch instead of an external button, but that took under an hour.  The rest of the servo housing and power supply and software and so forth was already built.

If nothing else, this proofed the concept of having ready-to-go solutions.  My Duck Remote is the same; the XBee solution was already built and programmed and all it took to get to technical rehearsal was cramming the electronics into a different housing.  (On the other hand, I did spend several days making a different software solution so as to simplify the hardware end -- and that only partially worked).  But as robust as my devices are, they still fall short of the reliability I desire.




I don't at this point know if the douser fouled, overheated, or if the servo needs to be lubricated, but it failed once and the servo is visibly and audibly sticking at one point in its travel.   Probably, if I simply swap out the servo for a new one it will make it to the end of the run without further failures, but that underlines the point.  I simply can not trust it to keep working for an indeterminate amount of time.  And I lack knowledge on how it failed, thus I can neither change it so it doesn't fail, or even predict mean time till the next failure.

In the case of the robot, I do not know why the lights failed.  In establishing communication with the onboard Arduino to interrogate it over serial monitor I reloaded the software.  And it started working again and hasn't failed since.  So I don't know what happened.  The only suspicion is that somehow the software got corrupted.  But it is also possible that it doesn't always boot up correctly, or that there is a loose connection that fixed itself while I was jiggling the unit to get access to the USB port.

Again, I don't know, so I don't have any way of either fixing it or predicting when it will break again.



On the gripping hand, of course, commercial devices fail all the time.  We have a gobo rotator in the show which has failed in most performances.  One of the bubble machines already quit.  So for all the jerry-rig aspect of my robot, it has shown to be doing a more complex job in a more reliable way.

And of course all these devices are leveraging existing commercial modules.  XBee modules and the Zigbee protocol and the underlying 802.15.4 standard.  Servo motors, with gear trains and position sensors already integrated.  Arduino, of course; that artist-friendly open-hardware, free software embedded computing solution.  And even the lowly chain-store R/C car, building on decades of experience building playable remote-control toys.

As I implied earlier, the costumes are coming apart, set decorations are peeling off, props are breaking...my electronics are nowhere near the least reliable elements in the production.  But in a larger perspective, all of these are also hacks.  Making costume pieces with unusual and often untried materials, making props with re-purposed materials, and so forth.  Theater is always about making things work outside of their usual context, and replacing what can't be afforded (or carried, or whatever) with something else. 

Every kingly palace with marble floors and gilded throne is of course cunningly painted plywood.  The jewels are resin-cast, the swords pot-metal, the armor is vacuuform plastic reinforced with medical cast material (aka celastic).  The rocks are made of expanded polystyrene foam.

What the key lesson is, is that it isn't about the technology; it is about the process.  Too much in a production like the one I'm currently mixing depends on guesswork about poorly-understood materials and processes, and risk-taking that these elements will function from night to night. 



Theater does not need fewer hackers.  What it needs is more engineers.

(It also needs to schedule the time to apply an engineering process.  As an area set designer once put it, if whatever improvisation you've done makes it through dress rehearsal, the show will close with it.  There is never time or energy or money to come back to something that works -- even if poorly -- and rebuild it.  But engineering a solution requires a cycle of development and testing.  The only way this really happens in theater is over the length of a season, or a career; what worked once, is refined and improved for the next show down the road.  What is lacking, though, is still the analytical approach to finding out the parameters of why it worked when it did and describing the envelop of where it won't work.  To do that you need more than simple empiricism.)