I got the prototype DuckNode working in time for the meeting. Attached accelerometer (and an LED for the RSSI pin) to an XBee, and stuck those on top of a AAA battery holder. Using Rob Faludi's XBee API library for Processing, was able to throw together a sketch that read off the transmitted values and triggered a MIDI note event when the right motion was detected.
Stitched up a simple wrist strap, and I was able to fling my hand out and trigger a sound effect that way.
But. Well, first off, at this point it doesn't really do anything a sharp-eyed Stage Manager and a button can't do. Second, it is a bit too much of a lump with battery pack and all. Might be acceptable with a LiPo, and might work better with the parts re-arranged a little, but basically is more than you want on your wrist if you can help it.
The concept of the DuckNode is that it is complete; no messing around running wires under a costume, just strap on the sensor pack and do the scene. Or stick it on the set as a remote sensor, or even stick it up (or put it inside a prop) as a remote button.
The idea being a general-purpose package, trading the ease of just pulling a standard part out of the kit, for the gains from optimizing for a specific need.
But it is in present form a little too large to be comfortable worn on the forearm, and a little too streamlined to be of use in other applications. So I will probably have to make the pack a little larger, add more buttons and batteries, but run a wire for a remote sensor..even a wire down to a wrist band (or, for that matter, wires to glove contacts or a flexi-strip trigger finger sensor.)
I'm also putting my POV wand on back-burner. When I get more time I'm going to dress up more-or-less the current one with double the LEDs, brass tubing, and some extra display modes. But I don't think it will be in this show.
What will be in the show is the voice-controlled LED controller. It is PWM, although you can hardly tell (I might need to massage the code some more with a lookup table).
AFTER mucking about with all that extra circuitry, THEN realizing I couldn't just port Arduino software into the chips I had on hand, I went back to the manual and finally got a grasp for how you handle the ADC (analog read) on the metal.
And. Working within the Arduino abstraction makes for fast coding, but it is amazing what is being hidden from you sometimes. In the AVR series -- even in the ATtinys -- the ADC already has multi-sample, adjustable gain, and the ability to operate as a comparator (aka you could feed it a balanced audio signal.)
Plus I realized a while back the AVR has port protection diodes and resistor built in. So, the only parts you really need are a couple of passives to build a basic low-pass filter (the ADC can run into aliasing problems on high-frequency inputs).
So I am very tempted to code up a better version of the circuit on the ATtiny85's that just arrived today.
Except what also came in the mail are my MAX485's for building a DMX512 receiver. For which there is an Arduino library. So perhaps I should toss the box, and put together an Arduino shield instead (containing DMX512 port, the heat-sinked TIP120, analog trim pots that allow real-time adjust of internal setpoints, and a proper kill switch.
Well, I do have to test the DMX circuit. And see if I've got Arduino-Tiny working for ATtiny85's (with care I won't brick these, too!) I'm not sure I'll need a voice-controlled 60v PWM in the near future, so it probably makes the most sense to finish up what I've got and put it aside.
Friday, June 28, 2013
Thursday, June 27, 2013
Sometimes Hacking IS Better
Embarrassing.
It took all of ten minutes to run a wire from my computer's headphone jack to an Arduino, hook up the strand of LEDs I have wrapped around the monitor (via a TIP120), and throw a bit of software together to blink the one in reaction to the other.
But I wanted something neater. I wanted it bulletproof. At the moment, I've managed to make something full of holes. Instead of being bombproof, it looks like a bomb. From a cheap movie.
A day or two to get it all working on breadboard; LM368 amplifier, LM741 balanced input stage, two trim pots for gain and DC offset, and another of those ubiquitous 7805 voltage regulators.
Of course when time came to put it in a box I tried to be fancy. And thus blew a full day on just that. Adafruit Altoids-sized perma-proto board. Not quite enough room for jacks so I stuck Euro-strips on the outside of the mint tin.
First problem; the TO-220 style heat sink was too big to close the lid on. I may hit five amps on this (I suspect it will be more like two amps in practice but I'm trying to play safe, right?) So the box is without a lid. And the components got even more cramped.
Second problem; I bricked both my ATtiny45's, and there isn't a simple way to port Arduino code (or use the Arduino IDE) on my one remaining AVR; a venerable ATtiny13.
I have some ATtiny85's on order (more 8 pin dips that will run at 8 MHz on internal oscillator). In the meantime I had to get the rest of the circuit running, so I strung wires to an Arduino that very much doesn't fit in the box.
(This may still be a problem; the code will need adapting for even the ATtiny85's. I might need to program in C anyhow. But I lost my old AVR toolkit in a computer crash, and the new one seems to make it much more roundabout -- in the interest of "better and more efficient," of course! -- to access the registers. Plus, I never did figure out how to work the ADC, which turns out to be rather more complex than doing PWM and other timer interrupts.)
Oh, and although it worked fine on the breadboard, the balanced input stage refused to work in the box. And I rebuilt a duplicate on the breadboard and patched it in and it still doesn't work. So I gave up and jumpered over it.
Which means at this stage, I could have just popped a shield on an Arduino and been done. Not like I'm really going to need this specific circuit again, right?
It also struck me, as I was setting trim pots and juggling op-amps, that I could have just done the whole thing analog at this point. I did it in digital because that gave me the ability to do signal processing in code; control the dwell time and so forth. Except I'm learning that the audio signal varies so widely, software adjustment isn't sufficient. I needed to have analog real-time adjustments (aka trim pots -- even if one of them is fed into an ADC port in order to set an offset number).
So no pictures for this entry. I'm too embarrassed by the thing. Pics after I've patched it up into something nicer.
So my other show-off project before tomorrow's meeting is to fake up the first DuckNode. One problem; the only analog accelerometer I have is on my POV stick, and I don't want to take that apart just yet. So I may have to wire up the I2C accelerometer, adapt the code to a friendly I2C library...and THEN wire the analog one on to an XBee.
The big question is whether I can remember what I'm doing fast enough to adapt my work-in-progress Processing framework to detect the remote accelerometer. I could use another weekend to work on this!
It took all of ten minutes to run a wire from my computer's headphone jack to an Arduino, hook up the strand of LEDs I have wrapped around the monitor (via a TIP120), and throw a bit of software together to blink the one in reaction to the other.
But I wanted something neater. I wanted it bulletproof. At the moment, I've managed to make something full of holes. Instead of being bombproof, it looks like a bomb. From a cheap movie.
A day or two to get it all working on breadboard; LM368 amplifier, LM741 balanced input stage, two trim pots for gain and DC offset, and another of those ubiquitous 7805 voltage regulators.
Of course when time came to put it in a box I tried to be fancy. And thus blew a full day on just that. Adafruit Altoids-sized perma-proto board. Not quite enough room for jacks so I stuck Euro-strips on the outside of the mint tin.
First problem; the TO-220 style heat sink was too big to close the lid on. I may hit five amps on this (I suspect it will be more like two amps in practice but I'm trying to play safe, right?) So the box is without a lid. And the components got even more cramped.
Second problem; I bricked both my ATtiny45's, and there isn't a simple way to port Arduino code (or use the Arduino IDE) on my one remaining AVR; a venerable ATtiny13.
I have some ATtiny85's on order (more 8 pin dips that will run at 8 MHz on internal oscillator). In the meantime I had to get the rest of the circuit running, so I strung wires to an Arduino that very much doesn't fit in the box.
(This may still be a problem; the code will need adapting for even the ATtiny85's. I might need to program in C anyhow. But I lost my old AVR toolkit in a computer crash, and the new one seems to make it much more roundabout -- in the interest of "better and more efficient," of course! -- to access the registers. Plus, I never did figure out how to work the ADC, which turns out to be rather more complex than doing PWM and other timer interrupts.)
Oh, and although it worked fine on the breadboard, the balanced input stage refused to work in the box. And I rebuilt a duplicate on the breadboard and patched it in and it still doesn't work. So I gave up and jumpered over it.
Which means at this stage, I could have just popped a shield on an Arduino and been done. Not like I'm really going to need this specific circuit again, right?
It also struck me, as I was setting trim pots and juggling op-amps, that I could have just done the whole thing analog at this point. I did it in digital because that gave me the ability to do signal processing in code; control the dwell time and so forth. Except I'm learning that the audio signal varies so widely, software adjustment isn't sufficient. I needed to have analog real-time adjustments (aka trim pots -- even if one of them is fed into an ADC port in order to set an offset number).
So no pictures for this entry. I'm too embarrassed by the thing. Pics after I've patched it up into something nicer.
So my other show-off project before tomorrow's meeting is to fake up the first DuckNode. One problem; the only analog accelerometer I have is on my POV stick, and I don't want to take that apart just yet. So I may have to wire up the I2C accelerometer, adapt the code to a friendly I2C library...and THEN wire the analog one on to an XBee.
The big question is whether I can remember what I'm doing fast enough to adapt my work-in-progress Processing framework to detect the remote accelerometer. I could use another weekend to work on this!
Sunday, June 23, 2013
How Not to Use a Breadboard
1/8" audio jack from my computer, plugged directly into Arduino analog input. A simple program averaging samples over a short stretch of time and setting a PWM value. PWM output driving a TIP120 Power Darlington, which is switching a 12v power supply into a string of red LEDs.
On the output end, this will do. I could put an opto-isolator in, or something else to protect the micro from accidents. There is no back EMF from LEDs (unlike switching a relay or similar), and a single TIP120 will handle five amps -- plenty to deal with the strips I mean to use. About the only major change to make for the final circuit is it would be good to bolt a heat sink on. With 2 feet of LED strip, it didn't even get warm to the touch.
On the input end, though; audio is AC, so I'm exposing the input to negative voltage swings. And I have practically no isolation, especially to keep hum from coming back into the rest of the audio system. And I'm using a headphone output for the proof-of-concept, whereas the final version has to be driven off line level.
So I need to create a circuit that will at the very least buffer the input. Better yet, isolate it, amplify it, and allow me to use a balanced signal line. Op-amp should be perfect for the task.
But I wasn't really needing to get into audio electronics as well as everything else I have to solve to get this show up (including working out how to speak DMX512).
Oh. The current form of the effects box is it takes audio output from the sound board (meaning I can use the sound board to compress/expand, set noise threshold, etc), and turns it into PWM for about 8 meters of LED strip that will be attached to the set.
But it would be useful if we could also turn on the lights from the light board.
The simplest solution would be to stick an opto-isolator on an existing dimmer. But that ties up a dimmer, and those are always in short supply.
Also fairly simple is to use the MIDI functions of the ETC "Express" series consoles. Except. It turns out they don't generate MIDI from channel. Only from cues and from the bump buttons on the submasters. Not quite as useful. Worse, experience at various theaters is that ETC boards tend to bork when you ask them to send MIDI. Receiving MIDI, they can deal with. Sending it, though....bad.
From a systems perspective or operator's perspective, the simplest thing is to add the box to the DMX universe, with a unique starting ID. Then it just gets controlled like any other light. (You could even drive it like a smart fixture, with one or more DMX channels setting behaviors for the circuit).
But DMX is non-trivial on the Arduino (unlike MIDI). It is extremely timing-sensitive, and most DMX libraries involve assembler or hacking the IDE or similar ugly stuff. Plus the interrupt-driven nature of the critical timing means a lot of the expected Arduino functionality (delay loops, for instance -- although those are works of the Devil anyhow) go away.
It can be and has been done. Even DMX reception and PWM output to lights. It just is more involved than I would like it to be.
Oh. And really requires an interface chip. I'll order a few now, but I'm not expecting this is going to happen today.
I may or may not include MIDI functionality. Once again, I had an existing MIDI circuit, but I'd done less good of a job of hanging on to the source code. But once again, I eventually found the back-up. It isn't the greatest MIDI read framework ever, but it is clean enough to use again.
Thursday, June 20, 2013
Wizardry
So now it is official.
I have several projects I've promised to work on, with a deadline already looming.
1. Put LEDs on a hat.
2. Put a strip light on voice control.
3. Create a gestural interface.
4. Keep working on my POV wand if I get time.
The first is a no-brainer. My "Cree" 3W RGB's arrived in the mail, as did several meters of 6mm light pipe. I can do this with some 1 watt resistors (I've learned THAT lesson!) but I'm holding out for the constant-current drivers I also put on mail order. I don't have any strips or really many discrete LEDs, though. I was pricing some nice 50ma greens in Pirahna style cases at Digikey, though. But I think there's enough time to wait and see what the hat looks like before I have to make another shopping trip.
This might just be hard-wired. The most complicated part of it might just be the power button. But...I am fully prepared to go RGB with it, and do some chases or something.
At the moment I am lacking most of the "DuckNode" system I've been trying to design over the past few years. Which is to say; I don't currently have a plug-and-play solution to send wireless control out to the stage and into a costume for an effect like this.
(The local Orchard Supply Hardware just got some vintage style oil lamps in stock. I'm pretty strongly tempted to stick a Cree, an ATtiny implementation of my custom "blink" code, and an XBee for hand-rolled remote control into one of them. Except the oil tank is small enough I'd probably want to use a LiPo for power, with a USB jack and a charging circuit. And that makes this an $80 lamp....)
2. I picked up an 8-channel EQ display chip, which should do just fine for a voice control. Except it spits out analog data serially, which means you pretty much want a micro to control it, and I'm starting to run out of free AVRs (Arduino or not). I may just have to solder up another protoboard with an ATtiny on it, and do more pretend-it-is-an-Arduino clone because I just don't have time to think my way through straight C and the AVR toolchain.
The tough part is controlling anything more than a strip of LEDs. I've been reading up on triac dimming, and I'm really not wanting to do hasty work around raw AC. So the best options at this point for controlling lights at line voltage are;
a. Power Tail. This is a plug-and-play relay box for 15 amps. At 10ms cycle time it isn't going to do PWM, but I'm willing to bet that timing a pure off and on is going to be close enough for a Dalek Eyestalk effect.
b. Cheap Dimmers. American DJ type baby dimmer packs are as cheap as ninety bucks on Amazon. Only four channels at a whopping 5 amps each, but it is a solid metal case and more-or-less UL listed. Also the one I'm looking at will take a 0-10 analog control signal, which is easy enough to fake up with an external power supply and some TIP120's.
c. Learn to talk DMX. It has been done on the Arduino, and there are even libraries. It isn't trivial -- in several ways it is more messy than MIDI. Of course, some packs you can talk to with MIDI as well but spitting a LOT of MSC (MIDI Show Control) at an ETC light board is a good way to crash the board and stop the show. So, yeah...I'll pass on the odd MSC for a single effect, but trying to do a PWM-type effect that way would be even more stupid than wiring up my own TRIAC-based danger shield.
3. And this one gets interesting.
I've already shown I can detect a punching motion (which is a possible "Tim the Enchanter" magic gesture.) Not sure exactly how best to detect a snap of the fingers, if that's how the actor wants to go.
Hold on.
Ouch ouch ouch.
Yes...I can detect the jarring motion of a snap of the fingers with an accelerometer mounted in a wrist band. Or attached to a wrist with masking tape. Ouch ouch ouch.
The tougher part would be discriminating -- better, specifying -- which of several DIFFERENT effects is to be triggered via pointing at them whilst gesturing.
The simplest solution is a compass. Or, rather, a tilt-compensated triple-axis magnetometer. Which aren't that expensive, but only talk I2C. Which means I can't talk to those naked, either. I'd need an AVR to read off the magnetometer chip, and then tell the XBee to transmit the signal to the interpreter.
Which in any case brings me squarely back to the DuckNode, and the Processing host software I have only begun to write. (Current status? I can select available ports on the fly, and recognize individual pin status).
Fortunately, #3 is completely stretch goal. First I need to get that voice-activated light working on the breadboard. Maybe I'll even dare some 120v relays -- just for a proof of concept, mind you.
Oh, and I realized something about the POV circuit. The persistence of vision effect only takes place over 250 milliseconds. But if a lighting effect is much brighter than the ambient light, you will also get afterimage. Which can linger quite a bit longer.
In daylight, my POV circuit isn't particularly good. In a darkened room, I "see" clearly a swath that crosses most of my body.
So it is still plausible. The next iteration I'm moving the LEDs closer together, find some way to diffuse them a little (they are a little too much brighter on-axis now), and increase their number. I'm also finding that arbitrary patterns read better than words. But at some point I really need to write a Processing routine that will turn a bitmapped image into a binary string, because I'm getting pretty tired of counting rows by hand as I manually type in 1's and 0's.
I have several projects I've promised to work on, with a deadline already looming.
1. Put LEDs on a hat.
2. Put a strip light on voice control.
3. Create a gestural interface.
4. Keep working on my POV wand if I get time.
The first is a no-brainer. My "Cree" 3W RGB's arrived in the mail, as did several meters of 6mm light pipe. I can do this with some 1 watt resistors (I've learned THAT lesson!) but I'm holding out for the constant-current drivers I also put on mail order. I don't have any strips or really many discrete LEDs, though. I was pricing some nice 50ma greens in Pirahna style cases at Digikey, though. But I think there's enough time to wait and see what the hat looks like before I have to make another shopping trip.
This might just be hard-wired. The most complicated part of it might just be the power button. But...I am fully prepared to go RGB with it, and do some chases or something.
At the moment I am lacking most of the "DuckNode" system I've been trying to design over the past few years. Which is to say; I don't currently have a plug-and-play solution to send wireless control out to the stage and into a costume for an effect like this.
(The local Orchard Supply Hardware just got some vintage style oil lamps in stock. I'm pretty strongly tempted to stick a Cree, an ATtiny implementation of my custom "blink" code, and an XBee for hand-rolled remote control into one of them. Except the oil tank is small enough I'd probably want to use a LiPo for power, with a USB jack and a charging circuit. And that makes this an $80 lamp....)
2. I picked up an 8-channel EQ display chip, which should do just fine for a voice control. Except it spits out analog data serially, which means you pretty much want a micro to control it, and I'm starting to run out of free AVRs (Arduino or not). I may just have to solder up another protoboard with an ATtiny on it, and do more pretend-it-is-an-Arduino clone because I just don't have time to think my way through straight C and the AVR toolchain.
The tough part is controlling anything more than a strip of LEDs. I've been reading up on triac dimming, and I'm really not wanting to do hasty work around raw AC. So the best options at this point for controlling lights at line voltage are;
a. Power Tail. This is a plug-and-play relay box for 15 amps. At 10ms cycle time it isn't going to do PWM, but I'm willing to bet that timing a pure off and on is going to be close enough for a Dalek Eyestalk effect.
b. Cheap Dimmers. American DJ type baby dimmer packs are as cheap as ninety bucks on Amazon. Only four channels at a whopping 5 amps each, but it is a solid metal case and more-or-less UL listed. Also the one I'm looking at will take a 0-10 analog control signal, which is easy enough to fake up with an external power supply and some TIP120's.
c. Learn to talk DMX. It has been done on the Arduino, and there are even libraries. It isn't trivial -- in several ways it is more messy than MIDI. Of course, some packs you can talk to with MIDI as well but spitting a LOT of MSC (MIDI Show Control) at an ETC light board is a good way to crash the board and stop the show. So, yeah...I'll pass on the odd MSC for a single effect, but trying to do a PWM-type effect that way would be even more stupid than wiring up my own TRIAC-based danger shield.
3. And this one gets interesting.
I've already shown I can detect a punching motion (which is a possible "Tim the Enchanter" magic gesture.) Not sure exactly how best to detect a snap of the fingers, if that's how the actor wants to go.
Hold on.
Ouch ouch ouch.
Yes...I can detect the jarring motion of a snap of the fingers with an accelerometer mounted in a wrist band. Or attached to a wrist with masking tape. Ouch ouch ouch.
The tougher part would be discriminating -- better, specifying -- which of several DIFFERENT effects is to be triggered via pointing at them whilst gesturing.
The simplest solution is a compass. Or, rather, a tilt-compensated triple-axis magnetometer. Which aren't that expensive, but only talk I2C. Which means I can't talk to those naked, either. I'd need an AVR to read off the magnetometer chip, and then tell the XBee to transmit the signal to the interpreter.
Which in any case brings me squarely back to the DuckNode, and the Processing host software I have only begun to write. (Current status? I can select available ports on the fly, and recognize individual pin status).
Fortunately, #3 is completely stretch goal. First I need to get that voice-activated light working on the breadboard. Maybe I'll even dare some 120v relays -- just for a proof of concept, mind you.
Oh, and I realized something about the POV circuit. The persistence of vision effect only takes place over 250 milliseconds. But if a lighting effect is much brighter than the ambient light, you will also get afterimage. Which can linger quite a bit longer.
In daylight, my POV circuit isn't particularly good. In a darkened room, I "see" clearly a swath that crosses most of my body.
So it is still plausible. The next iteration I'm moving the LEDs closer together, find some way to diffuse them a little (they are a little too much brighter on-axis now), and increase their number. I'm also finding that arbitrary patterns read better than words. But at some point I really need to write a Processing routine that will turn a bitmapped image into a binary string, because I'm getting pretty tired of counting rows by hand as I manually type in 1's and 0's.
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.
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.
Sunday, June 16, 2013
Equivocation
There's science, and there's engineering. My latest project has been illuminating as to the difference.
I've been trying to make a POV device. Specifically, the idea was a wand or staff that would be used in some capacity in our next production, "The Wiz." What I chose to display would depend on the quality and detail of the display. The first step was to see if it would actually work.
My latest setback is running foul of the Weak Equivalence Principle. But this is, oddly, the first problem I've had with the science of the thing. Everything up to this point has been, well, errors in execution.
Here's the current test platform:
I've been trying to make a POV device. Specifically, the idea was a wand or staff that would be used in some capacity in our next production, "The Wiz." What I chose to display would depend on the quality and detail of the display. The first step was to see if it would actually work.
My latest setback is running foul of the Weak Equivalence Principle. But this is, oddly, the first problem I've had with the science of the thing. Everything up to this point has been, well, errors in execution.
Here's the current test platform:
Friday, June 7, 2013
...and fricken lasers!
I keep hoping to get started on that machine gun. Or, for that matter, the drum magazines. But the hot projects on the table now are lighting effects for the next production. So my work table is covered in light pipe, LED's, Arduino clones, and laser diodes.
Like these:
Like these:
Subscribe to:
Comments (Atom)