Tuesday, June 18, 2013

De-Bouncing

So you have this effect.

In a recent effects meeting, we were talking about a lighting effect attached to a costume.  If, we said, you put electrical contacts in the costume gloves, you could light the light by holding your fingers together.

That's clever.  It works well enough.  But make it two lights, and it starts to get complicated.  That's two gloves, two sets of contacts, and if the actor forgets themselves and presses their fingertips together...you've cross-circuited.  Which may be the all-purpose problem solver on Star Trek The Next Generation, but works out badly in the real world.

This is yes another case of being unable to uncouple in your mind the physical trigger (call it a button, or call it a sensor),  and the resulting effect.  If all you are using is basic circuits -- battery, light, switch -- then this is indeed how it works.  But...an awful lot of theatrical effects -- including lighting effects built into costumes -- are already complex effects.

Which is to say; they already include intelligence.  And if your costume or prop already has an embedded micro-processor chasing a string of LEDs or counting down on a 7-segment display, it is just plain silly not to break out another pin for control input.

And, actually, circuits are cheap. A switch needs to be mounted to something solid, and needs to be soldered in.  Solder in a stand-alone capacitance sensor breakout board, and you have a latching circuit for your light.  The same number of wires to solder, it is no more expensive than a good switch, AND it doesn't need a good surface to be mounted on.  And it has no moving parts to break or snag.

More discussion, and more rant, below the fold.  No circuit diagrams this time around, though.





De-bouncing is one of the term we use.  "Latching" or "toggling" is another.  A nice technical term is "hysteresis." Moving further from simplicity, feedback loops, Kalman Filters, fly-by-wire.

But what they all describe, in simple terms, is the de-coupling of sensor input from circuit action.

In my car, I have a spare Arduino attached to a cheap eBay radio receiver.  When it gets the signal from the keyfob transmitter, it holds down a relay for one second than releases it.  So it doesn't matter if the RF signal is patchy, going in and out.  The relay holds closed long enough for the door locks to completely cycle.

Basically, this is a rather wasteful bit of switch de-bouncing.





But let's get back to those gloves. 

First off, changing the function of the switch (the contacts in the gloves) from power to data means you are no longer putting significant current through the gloves.  Your wires are lighter, the gloves are safer.  And it becomes impossible to damage anything no matter which fingers you touch.

More subtly, when you are in the data realm, the amount of time the effect stays on is no longer constrained to the time the fingers are in position.  Maybe you want the effect to last only as long as the fingers are in contact.  Or maybe you want the effect to complete each time the actor snaps their fingers.  With intelligence in the loop, both options are possible.

Slightly subtler still, the effect is also buffered in time (or can be).  You can still constrain the effect to run for exactly the time the fingers are in contact.  Or you can take any detectable transient and use that as a trigger for an effect of pre-set duration.

And the next iteration.  Since a button is data, it no longer is a single button.  Two buttons queried for off or on status only returns four states.  (00, 01, 10, 11).  Add time and you can also differentiate between a quick stab, holding the button in, or double-clicking.  Add program steps, and any of these signals can advance you through options.  (For instance; one button, a light tap advances the preset, holding the button in executes the preset.  You now have as many different "lights" under control as is appropriate to present to the user as a serial chain of options.)

If the original effect was one light, then maybe a batter-light-switch paradigm is the best-fit engineering.  But if there are three lights...at this point, you should probably be bringing all your wiring down to a central battery pack for ease of maintenance, and it is roughly equal effort to either solve the control with physical switches, or with electronic switches.



And once you open your possibilities to electronic switching, it all becomes data.  This is the ultimate de-coupling.

Instead of having that original glove contact event mapped exactly to the effect, it becomes just another data point.  What the effect wants for a trigger might be as simple as whether the contacts closed for long enough, or as complex as whether the contact occurred in the right context of other sensor information.

Perhaps the light pulses in time with the music, and the glove contacts are used as a Tap Tempo entry; they don't directly control the light, but instead set the frequency of the oscillator.

Or perhaps the glove contacts are a safety switch; one tap arms the circuit, which will then flash the lights when a photocell elsewhere detects a flash of light from outside the costume.  Another tap puts the effect back on safe.

Or, of course, the contacts can be removed.  Because we don't have to use gloves any more.  With capacitance sensing, we don't need to bring two wires together; a single contact patch is sufficient.  Or the effect might be better served with a button, or with a piezo contact (I saw a fun act a while back that used drum triggers attached to a costume to play a synthesizer hambone style).  Or it might not be the responsibility of the actor at all; you might be using radio to drive the effect from the light board or from a button at the console.




And let's get practical here.

The option is not as user-friendly as it could be, not yet.  There are stand-alone RF sets (twenty bucks will buy you a keyfob transmitter and a circuit board receiver that will switch enough amps for a costume or prop), and there are cap sense boards and even de-bounced micro-switches (Adafruit just got a nice one in stock). 

But to get total control over how long the transient has to be to reach trigger threshold, how long to hold the effect for, and to step through different options on command requires programming a chip.  The ATtiny chips are under a buck each and run stand-alone -- they will run on nothing but a battery (using their somewhat inaccurate internal clock).  And, yes, they make them in through-hole, which means those of us with full-sized fingers can solder them.

Programming, alas, requires a little more.  You need something to get from computer to chip; development board, (or you can work in-circuit) and USB interface or cable.   The Arduino platform brings all three elements together in an extremely convenient package, but you are paying a few more bucks for that convenience.  Fortunately, there are options that straddle this; a Boarduino or BareBonesBoard strips off the USB interface and is about half the price.

This is the kit I've been using of late;


 ATtiny development board, hand-made on vero.  All it is, is a socket, a Power On LED, and a 6-pin programming header.
 Arduino clone on Adafruit strip board.  Second chip is a Darlington Array for switching bigger loads than the ATMega can handle.  This one includes a 7805-based 5V regulator.  And unlike the ATtiny, is using an external resonator instead of the internal oscillator.

Arduino cobbled up on a breadboard.  This one is in the middle of a capacitance sensor test (using two of the Arduino's own pins and the Cap Sense library.  In this case there was no development board; the circuit moved from breadboard trials to soldered-up final board, using the ability to do in-system programming to bring the software up to the hardware.




I can't find the picture of my USB tinyISP that I use for an interface.  You can use an Arduino as an interface, or an FTDI cable...there are several cheap options.  I just happen to like the one I have.

One shameful admission, though.  Although I have the toolchain and have written C native and loaded it into an AVR via command-line interfaces (aka compiling with avr-gcc and using avrdude as uploader), I tend to just write Arduino clones now.  Since the IDE is very easy to use (even if not all the functions are efficient for all purposes), uploading is a snap, and the core code runs on pretty much everything from the ATmegas down to 8-pin ATtinys like the ATtiny85.


No comments:

Post a Comment