So back when I was working as a Scenic Carpenter I built a lot of stuff from expanded polystyrene foam (which we, like most of the US and Canada, would refer to inaccurately as "styrofoam.") You could usually find pretty big chunks of it, although for larger projects you'd glue several together with wood glue, a caulk gun, or Great Stuff (spray foam insulation in a can).
I'm building up the body of one of the two robots out of foam. But the expanded stuff just doesn't seem to be around, at least not in other than the odd scraps left over from shipping boxes. Instead the local art and hardware stores carry extruded polystyrene, or as I've been calling it of late, "crunchy foam."
It is really horrible stuff. I searched for foam until I found something that looked like it would work, and I committed to this stuff -- thirty bucks of it so far, plus of course sculpting time. I wish I had kept searching. A few days later, I discovered you can get pink insulation foam from Home Depot. I might not have gone that way even then, since I have a rather small space to be handling a full sheet of material in! It wasn't until I had actually worked with it that I realized how horrible it was.
Anyhow. The craft foam crunches. It is way too easy to break, or to dent. It is very bad about glue; most of the glues I tried never seemed to dry and didn't hold well when they dried, either. The cells are large and open; gesso goes right into it. The only thing that seems to be filling the pores is spackle, and I'm using a ton of it. Which is kinda hurting the whole intent of using styrofoam (aka, the light weight).
The body of the first robot is currently a rather sorry looking mass of styrofoam and foamcore board, patched up with spackle and apoxie sculpt (for the larger holes). It looks like it is going to take several coats and a lot of sanding before I get that smooth glossy plastic look I want.
At this point I would lose no more than four hours if I were to throw out the existing robot, buy some pink foam, and start carving a new one from scratch. But it would cost more money, and money and time are both short on this.
The most frustrating part is that everything takes forever to dry. Again the hazards of not having a big shop to work in. In a proper shop, I could be laying out the other parts of the project. But this takes up so much of my available space, and makes so much of a mess, I am loathe to try to do anything else until I can get the body of the first robot completed. And I'm still looking at probably another two days of sanding, spackling, gesso'ing, and waiting for stuff to dry.
And what else is there to do? I might not bother putting servos or other electronics in the first robot. The controller that came with it is a two-channel job and I'd have to create not just a second radio link, but some way for the operator to run both at the same time. If nothing else, that means another battery or a bunch more connections to deal with. And this has to be set up, batteries charged, systems checked every performance for five weeks.
(Of course, I found some LED-equipped iPod speakers that would look just so cute as "eyes" -- but I'd need to take them apart and hack them to work, and they are a little small anyhow, and it might be simpler to make something from scratch...)
I am also not sure I like the look of the Ethafoam bumper I planned to add. It needs the bumper for what little protection it gives, though.
Robot #1 is using a $30 toy car for a chassis (as they say in the business, if it says "remote control" on the box it is a toy. If it says "radio control" is it a hobby class.) It has medium-hard knobby "outdoors" tires, a plastic chassis, a very light and springy suspension, and the controller is non-proportional; you get three choices -- fast, off, and reverse.
Fortunately, one of the discoveries made while investigating-by-building is that when weighted down with my new body, it settles down and seems to be decently controllable. I haven't quite put it to the test by trying to hit the marks at the theater, though...
Robot #2 is planned around a "radio control" chassis. A Tamiya Frog, in fact -- 1980's tech, but it has nice suspension and shocks, the typical Tamiya 540 motor. Unfortunately it is a bit of a stripped chassis. So I have ESC (electronic speed control) on order, I need to put one of my servos in for the steering, and of course I'm still hoping I can get the combination of Vex radio and Arduino to work.
I have no servo saver, and no idea yet what I'm doing about the battery pack. Nor have I tried yet to fit the frame of a new body around it. Robot #1, at least, the body appears to sit nicely enough on top that it will not have to be fastened down (meaning it is easy to pull it off to work on.) But Robot #2 looks like it will be more interesting.
Especially since -- after all, I've got that six-channel Vex to play with! -- it is intended to have the fully pan-and-tilt camera head.
My biggest problem, however, is paying rent while I'm working on this. I told them I was volunteering the labor. I also haven't brought the project to the point where I can get reimbursed for parts and supplies -- if worst comes to worst, and I don't have a working robot they want to use for the show, I might end up eating much of the cost. And that might be all I eat for the month of July!
Wednesday, June 20, 2012
Thursday, June 14, 2012
Sleazy Easy
I put an Instructable up for my Wireless Easy Button:
Actually, doing it with the boost converter seems needlessly complex, and also appears to result in a shortened battery life. Just wire the XBee direct to the battery pack. It works fine that way.
Actually, doing it with the boost converter seems needlessly complex, and also appears to result in a shortened battery life. Just wire the XBee direct to the battery pack. It works fine that way.
Monday, June 11, 2012
Robot
I'm trying to build a cam-bot, on a budget, in the next three weeks.
Anyone who plans or documents a construction project learns very quickly that time and money graph against each other. If you want it faster, it will cost more money. If you want it cheaper, it will take longer. And the edges of the graph are increasingly non-linear; shaving the last few days or the last few dollars becomes astronomically costly in money or time.
Add quality and you have three items that can not all be high at the same time. If you make it as quickly AND as cheaply as you can, it is not going to good-looking or reliable.
I'm making an effect for the stage. For a musical. The robot has to come out under remote control and get to a certain spot on stage within the context and choreography of a scene. And not stall, or go out of control and roll into the orchestra pit. And it has to do this every single night. And it has to survive being backstage before its guest appearance, meaning surviving people moving around it and sometimes accidentally hitting it or stepping on it or dropping things on it. And it has to do this for five weeks plus technical rehearsals.
In any realistic world, you'd say "Let's take the time to build this right" or "Let's spend money on good parts so it will hold up to the stresses of performance." But we are trying to achieve this without spending either.
See, the difference here is between what is possible and what is practical. I could get hold of some gear motors, or even surplus electric motors and a pile of gears from Grainger. Or find a couple of cordless drills at flea markets and hack the internals out and use them to drive wheels, and work out some interface electronics. Of course I could, and people can. But it takes time. The first couple arrangements won't work. The hardware you find at the surplus store won't quite fit without a lot of Dremel work and epoxy and other hacking. And the first trial runs the robot will be jerky and uncontrollable (or too slow to be able to perform the necessary choreography within the time the music allots to it).
And by the time you go back multiple times to various flea markets and yard sales and surplus stores, and wait for mail deliveries from Hong Kong or Kowloon, and get through re-building multiple times...well, you will have probably spent significant money and even more importantly, significant time.
Three weeks sound like a lot of time, but not when you have other jobs to do, and you don't have a well-equipped shop to work in, and it is your first foray into robotics. The point being; there is just way too much chance that after all the time you spend hacking something together on salvaged and home-grown parts, you will find yourself at deadline without a working robot.
The smart solution from the deadline standpoint is to purchase an existing robot or the essential parts (in this case, mostly the part called the Rolling Chassis; the basic set of wheels, axles, transmission, and steering gear). But here is where money and quality plot inversely. The R/C cars you find at the toy store are often under thirty bucks, but they also usually have a wheelbase of under 12", plastic wheels, and can barely manage their own weight -- much less the mock camera and other dressing we want on them.
When you go looking for rubber tires, gas shocks, differentials, and all the other goodies of a road-worthy R/C car, you jump up into the $400 range real quick. As a basic rule, an R/C car that is big enough not to vanish on stage (the stage is sixty feet across and will have upwards of thirty actors on it) is going to be right at the fringe where they turn from toy store racers to serious gasoline powered grown-up-kid hobbies -- with price tags to scale with other adult hobbies.
I think this is probably the smartest route, however. Going through eBay one can find a used chassis of the non-toy type for under $200. It is probably solid and reliable enough to perform the necessary movements on stage without breaking down, and they are standardized enough so working out the electronics end may be as simple as buying a used Futaba transmitter and receiver and maybe an extra servo or two.
But I think our director has not done this research and believes that either toy store cars ARE big enough and reliable enough to do the job, or that there must be one in a garage sale somewhere and all one needs to do is spend a few weekends driving around to every garage sale in the county.
And I simply don't believe that this is a good gamble. People win the Lotto, too. Even if there IS a car in fully functional shape at a really great price right up the street this Sunday, planning the entire project on that happening is not the smart way to proceed. The odds are much higher you'll find something that is underpowered, missing parts, gearbox filled with cat hair, and priced only ten bucks cheaper than what you'd spend at the toy store. That's the problem with eBay and the internet in general; price reference is too easy these days. People are going to price based on a much better understanding of the price other people are getting away with. So add to your long odds, the chance of finding the person who bought the thing recently but has no idea how much it is worth.
I did take a long look at a robotics chassis -- as sold at such places as RobotoShop. They have some decent prices, and they are designed to carry significant loads (which means the dressing and camera is no issue). They are also designed to be easy to integrate the electronics on -- RobotShop has a chassis which is not only an Arduino compatible with FTDI chip for easy programming, motor drivers already integrated and PWM software already loaded, but it even has XBee headers to make a wireless control option simplicity itself.
The downside, however, is speed. Whereas I suspect many of the R/C toy cars are going to be so fast there is a good chance it will smash into an actor or fly off the stage entirely, the robotics chassis are spec'd in terms like tens of centimeters per second. A quick calculation shows me that many of these robots would take up to a minute to get from their entrance to their spike marks for the scene. And in an American musical, a minute is a VERY long time.
So I did build a camera. A mock-up of a 1970's broadcast television camera (but much smaller). Turret lens, boxy body. Tilt and pan mechanism for the camera, another servo for the turret lens, and a bright multi-color LED. It is a bit wonky, because I built it really fast while tired and between rehearsals, and I didn't have the time or energy to re-arrange my room so I could get out the drill press and other more accurate tools (I did briefly use the bench grinder with it balanced on top of a kitchen wastebasket, however!)
The camera looks decent even without the paint job and final detailing, and all the servos work. But I think I'm going to build a new one. I think it needs to be even smaller, and even lighter, in order to work with the R/C cars we can afford.
And here's the thing again. I built my own pan-tilt servo bracket out of white pine, aluminium bar stock, nylon bushings and machine screws. It took three hours and probably cost ten bucks or more of materials. I can get a servo bracket from RobotShop or SparkFun for fifteen bucks. And it will have a greater range of motion and have the elements in the right order (my camera tilts then pans, which means the plane of the pan changes -- which makes it impossible to keep the image level).
So I just won a cheaper R/C chassis on eBay. I'll grab one of the toy store R/C's while I am waiting on delivery and hack into it and see just how bad it is, too. I need two robots, anyhow. And I'll design and build a new camera around a proper Dagu pan-tilt bracket. The one thing my existing camera did -- besides being a learning experience and looking kinda cool -- is to confirm from the Director that I am on the right track. But I have yet to get explicit permission to spend money, and I can't afford to go into what is going to be a good $200 in parts entirely out of pocket.
I haven't gotten far enough to think about the actual controller. Too much depends on the chassis (several chassis options come with radio already). I recognize the utility of the standard controller form-factors to allow a human to control the robot in real time. But on the other hand, some of the actions -- operating the LED that shines through the "lens," rotating the turret to the next lens -- require a layer of intelligence. So for those, at least, it makes sense to go through a single serial link (via XBee) and simply communicate from controller to an on-board micro which will then execute the proper commands. This is possibly fast enough to do the steering and motor control in real time as well, but it still leaves me trying to put knobs and pots on a box solid enough so an actor can learn how to run the bot.
In the end, having anything more than a fixed (and lightweight!) styrofoam camera may be a stretch goal. But if I can get a pair of R/C cars dressed, then I'll have an acceptable fall-back position.
Anyone who plans or documents a construction project learns very quickly that time and money graph against each other. If you want it faster, it will cost more money. If you want it cheaper, it will take longer. And the edges of the graph are increasingly non-linear; shaving the last few days or the last few dollars becomes astronomically costly in money or time.
Add quality and you have three items that can not all be high at the same time. If you make it as quickly AND as cheaply as you can, it is not going to good-looking or reliable.
I'm making an effect for the stage. For a musical. The robot has to come out under remote control and get to a certain spot on stage within the context and choreography of a scene. And not stall, or go out of control and roll into the orchestra pit. And it has to do this every single night. And it has to survive being backstage before its guest appearance, meaning surviving people moving around it and sometimes accidentally hitting it or stepping on it or dropping things on it. And it has to do this for five weeks plus technical rehearsals.
In any realistic world, you'd say "Let's take the time to build this right" or "Let's spend money on good parts so it will hold up to the stresses of performance." But we are trying to achieve this without spending either.
See, the difference here is between what is possible and what is practical. I could get hold of some gear motors, or even surplus electric motors and a pile of gears from Grainger. Or find a couple of cordless drills at flea markets and hack the internals out and use them to drive wheels, and work out some interface electronics. Of course I could, and people can. But it takes time. The first couple arrangements won't work. The hardware you find at the surplus store won't quite fit without a lot of Dremel work and epoxy and other hacking. And the first trial runs the robot will be jerky and uncontrollable (or too slow to be able to perform the necessary choreography within the time the music allots to it).
And by the time you go back multiple times to various flea markets and yard sales and surplus stores, and wait for mail deliveries from Hong Kong or Kowloon, and get through re-building multiple times...well, you will have probably spent significant money and even more importantly, significant time.
Three weeks sound like a lot of time, but not when you have other jobs to do, and you don't have a well-equipped shop to work in, and it is your first foray into robotics. The point being; there is just way too much chance that after all the time you spend hacking something together on salvaged and home-grown parts, you will find yourself at deadline without a working robot.
The smart solution from the deadline standpoint is to purchase an existing robot or the essential parts (in this case, mostly the part called the Rolling Chassis; the basic set of wheels, axles, transmission, and steering gear). But here is where money and quality plot inversely. The R/C cars you find at the toy store are often under thirty bucks, but they also usually have a wheelbase of under 12", plastic wheels, and can barely manage their own weight -- much less the mock camera and other dressing we want on them.
When you go looking for rubber tires, gas shocks, differentials, and all the other goodies of a road-worthy R/C car, you jump up into the $400 range real quick. As a basic rule, an R/C car that is big enough not to vanish on stage (the stage is sixty feet across and will have upwards of thirty actors on it) is going to be right at the fringe where they turn from toy store racers to serious gasoline powered grown-up-kid hobbies -- with price tags to scale with other adult hobbies.
I think this is probably the smartest route, however. Going through eBay one can find a used chassis of the non-toy type for under $200. It is probably solid and reliable enough to perform the necessary movements on stage without breaking down, and they are standardized enough so working out the electronics end may be as simple as buying a used Futaba transmitter and receiver and maybe an extra servo or two.
But I think our director has not done this research and believes that either toy store cars ARE big enough and reliable enough to do the job, or that there must be one in a garage sale somewhere and all one needs to do is spend a few weekends driving around to every garage sale in the county.
And I simply don't believe that this is a good gamble. People win the Lotto, too. Even if there IS a car in fully functional shape at a really great price right up the street this Sunday, planning the entire project on that happening is not the smart way to proceed. The odds are much higher you'll find something that is underpowered, missing parts, gearbox filled with cat hair, and priced only ten bucks cheaper than what you'd spend at the toy store. That's the problem with eBay and the internet in general; price reference is too easy these days. People are going to price based on a much better understanding of the price other people are getting away with. So add to your long odds, the chance of finding the person who bought the thing recently but has no idea how much it is worth.
I did take a long look at a robotics chassis -- as sold at such places as RobotoShop. They have some decent prices, and they are designed to carry significant loads (which means the dressing and camera is no issue). They are also designed to be easy to integrate the electronics on -- RobotShop has a chassis which is not only an Arduino compatible with FTDI chip for easy programming, motor drivers already integrated and PWM software already loaded, but it even has XBee headers to make a wireless control option simplicity itself.
The downside, however, is speed. Whereas I suspect many of the R/C toy cars are going to be so fast there is a good chance it will smash into an actor or fly off the stage entirely, the robotics chassis are spec'd in terms like tens of centimeters per second. A quick calculation shows me that many of these robots would take up to a minute to get from their entrance to their spike marks for the scene. And in an American musical, a minute is a VERY long time.
So I did build a camera. A mock-up of a 1970's broadcast television camera (but much smaller). Turret lens, boxy body. Tilt and pan mechanism for the camera, another servo for the turret lens, and a bright multi-color LED. It is a bit wonky, because I built it really fast while tired and between rehearsals, and I didn't have the time or energy to re-arrange my room so I could get out the drill press and other more accurate tools (I did briefly use the bench grinder with it balanced on top of a kitchen wastebasket, however!)
The camera looks decent even without the paint job and final detailing, and all the servos work. But I think I'm going to build a new one. I think it needs to be even smaller, and even lighter, in order to work with the R/C cars we can afford.
And here's the thing again. I built my own pan-tilt servo bracket out of white pine, aluminium bar stock, nylon bushings and machine screws. It took three hours and probably cost ten bucks or more of materials. I can get a servo bracket from RobotShop or SparkFun for fifteen bucks. And it will have a greater range of motion and have the elements in the right order (my camera tilts then pans, which means the plane of the pan changes -- which makes it impossible to keep the image level).
So I just won a cheaper R/C chassis on eBay. I'll grab one of the toy store R/C's while I am waiting on delivery and hack into it and see just how bad it is, too. I need two robots, anyhow. And I'll design and build a new camera around a proper Dagu pan-tilt bracket. The one thing my existing camera did -- besides being a learning experience and looking kinda cool -- is to confirm from the Director that I am on the right track. But I have yet to get explicit permission to spend money, and I can't afford to go into what is going to be a good $200 in parts entirely out of pocket.
I haven't gotten far enough to think about the actual controller. Too much depends on the chassis (several chassis options come with radio already). I recognize the utility of the standard controller form-factors to allow a human to control the robot in real time. But on the other hand, some of the actions -- operating the LED that shines through the "lens," rotating the turret to the next lens -- require a layer of intelligence. So for those, at least, it makes sense to go through a single serial link (via XBee) and simply communicate from controller to an on-board micro which will then execute the proper commands. This is possibly fast enough to do the steering and motor control in real time as well, but it still leaves me trying to put knobs and pots on a box solid enough so an actor can learn how to run the bot.
In the end, having anything more than a fixed (and lightweight!) styrofoam camera may be a stretch goal. But if I can get a pair of R/C cars dressed, then I'll have an acceptable fall-back position.
Saturday, May 26, 2012
Blink..and you miss it
I thought about titling this "Don't blink" in honor of the great Doctor Who episode, but that would sound like I was recommending against the ThingM products.
And that isn't true. I think the BlinkM is, unfortunately, underpowered for theatrical use. I took my breadboard out to the theater and viewed it from stage distance against a variety of subdued lighting looks and the best that can be said is that it will light up a diffuser globe real well with color. Casting light you can see on an actor, though...not so much.
So it is time to play Tool-Tim Tim, but there are a bewildering variety of options for "More Power!" I spent a while trying to spreadsheet them (and downloading lots and lots of datasheets from different manufacturers). And, well...for a smaller and simpler battery-powered device the BlinkM MaxM is actually quite competitive. So my work in hacking up alternate software wasn't a complete waste (although I really need to rewrite the core function as an interrupt-driven loop -- and there are some cute PWM tricks you can do to speed things up even more).
At the lowest price end of the options, the ATtiny chips can sink 40 ma from each of the I/O pins. Each channel in an RGB "Piranha" LED is about 20 ma. So technically one CPU chip could drive as many as three Pirahna, making it 3x the power output. Which of course will not appear 3x as bright in most situations! There are other 20 ma LEDs around, but most of the super-bright and ultra-bright (which inevitably give misleading specs in millicandella) are narrow-angle. And that just isn't appropriate for most of the lighting applications I have in mind. One exception is the "flat-top" LED sold by some Hong Kong suppliers, which offers 25 ma and a half angle of 120 degrees.
For making a pure candle (or perhaps some RGB thing that is around the same effective output) it is hard to beat the price point of buying ATtiny's and Piranha LEDs in bulk. Wire them up with no driver, no power regulator...nothing but ballast resistors. You can make them on a perf or in "dead bug" style for a nice small form factor. Actually, you can make them brighter and more efficient by sacrificing the RGB and using amber, yellow, or "warm white" LEDs instead. The main advantage to using multiple LEDs in a candle is that you can move the point source around a little and produce a nice flicker in angle as well as in intensity.
For practically anything else I can think of in theater -- and that includes a railway lantern or any period portable light sources other than candles -- we need more power. Which introduces drivers to the equation. The simplest driver circuit is a Darlington. The handy ULN2803 can sink 8 channels worth at 500 ma each from a basic 20-pin DIP package. The venerable TIP120 power Darlington can swing as much as 5 WATTS.
Wiring up multiple LEDs yourself can be time consuming. SparkFun carries the "Satellite" from the same people who built the ShiftBright; it is a grid of 13 single-color Piranha meaning it puts out about 300 ma per color channel. Which makes it about 15 x the lumens of the BlinkM. Adding the driver and CPU and some discretes, however, brings you close to the $24 of the MaxM -- which is already assembled, and uses just three high-power RGBs to put out the same juice in a more compact package.
So to make it worthwhile you need to jump up to the Luxeons and similar LEDs pulling from half an amp to a whopping 10 amps each. SparkFun does have breakouts, but they are pricey; it brings the surface-mount Luxeon Rebel up to about $7 a channel -- not including controller -- and $18 for an RGB array. Plus you might just want to add diffusing lens, additional heat sink, even a constant-current source.
At which point you step back and say, "I'm not trying to do UL-listed architectural lighting here; I just want an effect for stage use." And this makes some of the Hong Kong suppliers hanging out on eBay very attractive; as some of them offer 1-3 watt (300 to 750 ma) single-color surface-mount LEDs with rudimentary breakout boards/heatsinks for as low as a buck each. Throw in some TIP120's to switch them, hack out some primitive PWM code on an ATtiny, and if you are lucky it won't burn out (or worse, burn up) before the show closes.
Which, if someone comes up to me today and says, "We want Willy Wonka's cane to light up when he taps it on the floor," is what I will do.
And I'm still going to stick my modified BlinkM in one of those cheap plastic candlesticks to show it off.
And that isn't true. I think the BlinkM is, unfortunately, underpowered for theatrical use. I took my breadboard out to the theater and viewed it from stage distance against a variety of subdued lighting looks and the best that can be said is that it will light up a diffuser globe real well with color. Casting light you can see on an actor, though...not so much.
So it is time to play Tool-Tim Tim, but there are a bewildering variety of options for "More Power!" I spent a while trying to spreadsheet them (and downloading lots and lots of datasheets from different manufacturers). And, well...for a smaller and simpler battery-powered device the BlinkM MaxM is actually quite competitive. So my work in hacking up alternate software wasn't a complete waste (although I really need to rewrite the core function as an interrupt-driven loop -- and there are some cute PWM tricks you can do to speed things up even more).
At the lowest price end of the options, the ATtiny chips can sink 40 ma from each of the I/O pins. Each channel in an RGB "Piranha" LED is about 20 ma. So technically one CPU chip could drive as many as three Pirahna, making it 3x the power output. Which of course will not appear 3x as bright in most situations! There are other 20 ma LEDs around, but most of the super-bright and ultra-bright (which inevitably give misleading specs in millicandella) are narrow-angle. And that just isn't appropriate for most of the lighting applications I have in mind. One exception is the "flat-top" LED sold by some Hong Kong suppliers, which offers 25 ma and a half angle of 120 degrees.
For making a pure candle (or perhaps some RGB thing that is around the same effective output) it is hard to beat the price point of buying ATtiny's and Piranha LEDs in bulk. Wire them up with no driver, no power regulator...nothing but ballast resistors. You can make them on a perf or in "dead bug" style for a nice small form factor. Actually, you can make them brighter and more efficient by sacrificing the RGB and using amber, yellow, or "warm white" LEDs instead. The main advantage to using multiple LEDs in a candle is that you can move the point source around a little and produce a nice flicker in angle as well as in intensity.
For practically anything else I can think of in theater -- and that includes a railway lantern or any period portable light sources other than candles -- we need more power. Which introduces drivers to the equation. The simplest driver circuit is a Darlington. The handy ULN2803 can sink 8 channels worth at 500 ma each from a basic 20-pin DIP package. The venerable TIP120 power Darlington can swing as much as 5 WATTS.
Wiring up multiple LEDs yourself can be time consuming. SparkFun carries the "Satellite" from the same people who built the ShiftBright; it is a grid of 13 single-color Piranha meaning it puts out about 300 ma per color channel. Which makes it about 15 x the lumens of the BlinkM. Adding the driver and CPU and some discretes, however, brings you close to the $24 of the MaxM -- which is already assembled, and uses just three high-power RGBs to put out the same juice in a more compact package.
So to make it worthwhile you need to jump up to the Luxeons and similar LEDs pulling from half an amp to a whopping 10 amps each. SparkFun does have breakouts, but they are pricey; it brings the surface-mount Luxeon Rebel up to about $7 a channel -- not including controller -- and $18 for an RGB array. Plus you might just want to add diffusing lens, additional heat sink, even a constant-current source.
At which point you step back and say, "I'm not trying to do UL-listed architectural lighting here; I just want an effect for stage use." And this makes some of the Hong Kong suppliers hanging out on eBay very attractive; as some of them offer 1-3 watt (300 to 750 ma) single-color surface-mount LEDs with rudimentary breakout boards/heatsinks for as low as a buck each. Throw in some TIP120's to switch them, hack out some primitive PWM code on an ATtiny, and if you are lucky it won't burn out (or worse, burn up) before the show closes.
Which, if someone comes up to me today and says, "We want Willy Wonka's cane to light up when he taps it on the floor," is what I will do.
And I'm still going to stick my modified BlinkM in one of those cheap plastic candlesticks to show it off.
Wednesday, May 23, 2012
Blink Blink
My code is kudzu, but have the basics for the new BlinkM running. One thing I didn't think about was that mixing to amber isn't wonderful on an RGB LED. It makes an "okay" candle but it isn't a lovely color. Might be better to build one from scratch around a 1 watt amber LED instead!
Except -- one thing I was thinking as I remembered how real candles and lanterns look, is that they don't just dim up and down. The location of the light SHIFTS over time, which can lead to very visible flickering shadows. So a cluster of amber LEDs, each fading independently, is a better model and a better effect.
So maybe I should just design my own board from scratch. Sigh.
In other electronics news, one of the three shows in the pipeline might have an R/C robot in it. I think the director's idea was that we would find a cool toy robot and use it, but just maybe we'll make up our own stage-sized, 1970's looking, camera-toting robot.
A fresh look around and we could put together a tracked chassis and controller for a bit over a hundred bucks. How long it would take to program to respond to the controller is unknown -- it might be a simple plug-and-play, or it might be a hassle.
Well, back to trimming the kudzu. I'm using a hand-drawn look-up table to smooth the fade curve (128 possible programmed levels feeds into 255 pulse width positions). I'm still using delay(microseconds) instead of delving into an interrupt timer, because I'm pretty sure the built-in Arduino functions are all pointing at the wrong register locations for an ATtiny45. Actually, I'm rather surprised at how much of the Arduino code compiles without issue on the ATtiny. If I really cared about performance I'd re-do the code in straight C.
I've tried three different methods of plugging in target values; the random(min, max) function, a toggle or switch/case for simple binary looks (like a power button pulse), and an array for multi-step programs.
I haven't added the next layer of the code, which is smooth cross fading from one running program to another. I'm not sure it is actually needed. What I DO have to try out soon is the button method. At Makers Faire, ThingM was showing off a couple of MaxM demonstrations with program functions through that analog input port. So it obviously can be done. Unfortunately that same pin is part of the ISP header, so programming and testing this is likely to be fun.
As I suspected, it was fun -- the exposed analog I/O pin is shared with Sck -- the clock pin necessary for programming. So spent a delightful hour pulling out and putting back that pin so I could try out different software interpretations of the analog input.
The concept proofs. Using a 500K linear slide pot, I am able to solidly dial in at least 10 selections. Once I get it off breadboard and soldered up properly with power supply smoothing and so forth it should be just fine.
But writing various "looks" so I could see what it was like to switch between them really impressed on me that I need to finish the "program step" code that will allow me to simply write a short array of numbers and let the software take care of the rest of it.
It never is quite so simple, is it? I wrote a somewhat cool set of functions that read off target values from an array. This meant I could write new looks just by writing columns of four numbers (R, G, B intensity and Fade Rate.) In addition, a set of "999" codes told the software whether to loop back or hold at the end of the array values.
Except. Because of my shaky breadboard and random old potentiometers -- plus the hassle of pulling the Scl Pin out of the programmer and putting it back over and over -- I didn't realize the jitter I was seeing was actually in the code.
Apparently arrays are a bit funky on the ATtiny. Or they are funky when combined with things like AnalogRead. Because even when I gave up on getting stable behavior with the analog pin, I still couldn't switch looks with a digital input without all sorts of funny behavior.
So I tossed that whole section of code. As it turned out anyhow, most of the looks I wanted to write were randomized functions (candle light, color swirls) and those were already rather shoe-horned into the array value code. But I did have to give up being able to change looks any arbitrary point in a fade cycle; all those button calls were making the fades jittery.
The new version works. It was solid enough going from look to look via potentiometer, which means that a selected resistor soldered to a switch will work just fine. And since I'd already gone too late to start on other tasks, I checked out the XBee connection as well. Since the XBee node I was using was configured to reset the pin values after 650 ms, I had to do a bit of a hack to be able to switch looks. In the proper version, the XBee will maintain a particular pin state and thus the BlinkM will always be able to detect it the next time it hits the end of a fade loop.
But I'd say the concept is now well and truly proofed.
The question is, is it worth it? For what I want to do with theatrical candles or lanterns, it might be smarter to purchase amber LEDs and create a custom circuit. Even using a through-hole ATtiny, in the 8-pin DIP configuration the electronics package is still going to be smaller than the battery. And for other applications, like the Witch's Crystal Ball for "Wizard of Oz," I think I need more output than the BlinkM can give me.
And here we have a few choices, all of them poor. The MaxM, which can take the same programming but is about twice the cost of the BlinkM. SparkFun has a fairly cheap breakout and driver board for the Luxeon LEDs but it is badly designed and using it just offends the engineer in me. The ATtiny chip by itself tops out at the 30 mW or so of the Piranha LEDs (and buying ATtinys and Piranhas in bulk is a lot cheaper than buying BlinkMs) but that is not any brighter. There are some driver chips that will handle an intermediate value...but at some point you need to admit what you need for some effects is close to the output of a theatrical instrument. So we're talking 5 watt LEDs here and a lot of work with drivers and power supplies and heat sinks.
Well. The concept is proofed, but it is hard to show off a breadboard with ISP and battery pack stuck to it with double-stick. I might, might just find a cheap candlestick -- even better, one that already has a fake candle flame at one end -- and hack it to the full glory of a remote-controlled candle.
November 9, 2012 --
Made two more discoveries. First is that the current show is using a dozen or so of those LED tea candles, and they are quite bright enough for what they are doing. So the BlinkM, modified or not, may not be capable of doing all of the effects I wanted from it, but it can make a realistic candle.
(I also brought my current circuit to a dinner party and left it running on a coffee table -- and the host asked "is that candle over there safe or should we put it out before it catches something on fire?")
The other was discovery of an article on the internal coding of the Arduino "digitalWrite" function. It had not occurred to me that the function could be THAT inefficient. 56 program cycles? This explains why my math was off by what appeared to be (without benefit of an oscilloscope) about two magnitudes.
So writing a new version that uses direct pin manipulation instead of the Arduino macro would run a good 50 times faster. And that would mean smoother fading.
Except -- one thing I was thinking as I remembered how real candles and lanterns look, is that they don't just dim up and down. The location of the light SHIFTS over time, which can lead to very visible flickering shadows. So a cluster of amber LEDs, each fading independently, is a better model and a better effect.
So maybe I should just design my own board from scratch. Sigh.
In other electronics news, one of the three shows in the pipeline might have an R/C robot in it. I think the director's idea was that we would find a cool toy robot and use it, but just maybe we'll make up our own stage-sized, 1970's looking, camera-toting robot.
A fresh look around and we could put together a tracked chassis and controller for a bit over a hundred bucks. How long it would take to program to respond to the controller is unknown -- it might be a simple plug-and-play, or it might be a hassle.
Well, back to trimming the kudzu. I'm using a hand-drawn look-up table to smooth the fade curve (128 possible programmed levels feeds into 255 pulse width positions). I'm still using delay(microseconds) instead of delving into an interrupt timer, because I'm pretty sure the built-in Arduino functions are all pointing at the wrong register locations for an ATtiny45. Actually, I'm rather surprised at how much of the Arduino code compiles without issue on the ATtiny. If I really cared about performance I'd re-do the code in straight C.
I've tried three different methods of plugging in target values; the random(min, max) function, a toggle or switch/case for simple binary looks (like a power button pulse), and an array for multi-step programs.
I haven't added the next layer of the code, which is smooth cross fading from one running program to another. I'm not sure it is actually needed. What I DO have to try out soon is the button method. At Makers Faire, ThingM was showing off a couple of MaxM demonstrations with program functions through that analog input port. So it obviously can be done. Unfortunately that same pin is part of the ISP header, so programming and testing this is likely to be fun.
As I suspected, it was fun -- the exposed analog I/O pin is shared with Sck -- the clock pin necessary for programming. So spent a delightful hour pulling out and putting back that pin so I could try out different software interpretations of the analog input.
The concept proofs. Using a 500K linear slide pot, I am able to solidly dial in at least 10 selections. Once I get it off breadboard and soldered up properly with power supply smoothing and so forth it should be just fine.
But writing various "looks" so I could see what it was like to switch between them really impressed on me that I need to finish the "program step" code that will allow me to simply write a short array of numbers and let the software take care of the rest of it.
It never is quite so simple, is it? I wrote a somewhat cool set of functions that read off target values from an array. This meant I could write new looks just by writing columns of four numbers (R, G, B intensity and Fade Rate.) In addition, a set of "999" codes told the software whether to loop back or hold at the end of the array values.
Except. Because of my shaky breadboard and random old potentiometers -- plus the hassle of pulling the Scl Pin out of the programmer and putting it back over and over -- I didn't realize the jitter I was seeing was actually in the code.
Apparently arrays are a bit funky on the ATtiny. Or they are funky when combined with things like AnalogRead. Because even when I gave up on getting stable behavior with the analog pin, I still couldn't switch looks with a digital input without all sorts of funny behavior.
So I tossed that whole section of code. As it turned out anyhow, most of the looks I wanted to write were randomized functions (candle light, color swirls) and those were already rather shoe-horned into the array value code. But I did have to give up being able to change looks any arbitrary point in a fade cycle; all those button calls were making the fades jittery.
The new version works. It was solid enough going from look to look via potentiometer, which means that a selected resistor soldered to a switch will work just fine. And since I'd already gone too late to start on other tasks, I checked out the XBee connection as well. Since the XBee node I was using was configured to reset the pin values after 650 ms, I had to do a bit of a hack to be able to switch looks. In the proper version, the XBee will maintain a particular pin state and thus the BlinkM will always be able to detect it the next time it hits the end of a fade loop.
But I'd say the concept is now well and truly proofed.
The question is, is it worth it? For what I want to do with theatrical candles or lanterns, it might be smarter to purchase amber LEDs and create a custom circuit. Even using a through-hole ATtiny, in the 8-pin DIP configuration the electronics package is still going to be smaller than the battery. And for other applications, like the Witch's Crystal Ball for "Wizard of Oz," I think I need more output than the BlinkM can give me.
And here we have a few choices, all of them poor. The MaxM, which can take the same programming but is about twice the cost of the BlinkM. SparkFun has a fairly cheap breakout and driver board for the Luxeon LEDs but it is badly designed and using it just offends the engineer in me. The ATtiny chip by itself tops out at the 30 mW or so of the Piranha LEDs (and buying ATtinys and Piranhas in bulk is a lot cheaper than buying BlinkMs) but that is not any brighter. There are some driver chips that will handle an intermediate value...but at some point you need to admit what you need for some effects is close to the output of a theatrical instrument. So we're talking 5 watt LEDs here and a lot of work with drivers and power supplies and heat sinks.
Well. The concept is proofed, but it is hard to show off a breadboard with ISP and battery pack stuck to it with double-stick. I might, might just find a cheap candlestick -- even better, one that already has a fake candle flame at one end -- and hack it to the full glory of a remote-controlled candle.
November 9, 2012 --
Made two more discoveries. First is that the current show is using a dozen or so of those LED tea candles, and they are quite bright enough for what they are doing. So the BlinkM, modified or not, may not be capable of doing all of the effects I wanted from it, but it can make a realistic candle.
(I also brought my current circuit to a dinner party and left it running on a coffee table -- and the host asked "is that candle over there safe or should we put it out before it catches something on fire?")
The other was discovery of an article on the internal coding of the Arduino "digitalWrite" function. It had not occurred to me that the function could be THAT inefficient. 56 program cycles? This explains why my math was off by what appeared to be (without benefit of an oscilloscope) about two magnitudes.
So writing a new version that uses direct pin manipulation instead of the Arduino macro would run a good 50 times faster. And that would mean smoother fading.
Sunday, May 20, 2012
Quick Hack
Makers Faire was this weekend and for once I didn't have to work a show. I went, I wandered, I bought a couple parts, but mostly I listened to music, pedaled a generator at the pedal-powered stage, and drank the only beer they sold (although I was dying for some decent German beer).
Was house tech over the weekend for a show that brings their own sound and light operators. Except for one early-morning showcase performance. When they handed me a CD and told me they had a couple of simple lighting cues. Problem; the sound board is still at FOH position (actually, rear of the house, but the important part is, it is NOT near the light board).
So pulled some toys out of the bag to be able to run the light board remotely. There's one MacGuyver episode where he has to build a telescope from random lenses and he has maybe five minutes to do what took Galileo years. But as Mac puts it -- he already knew it could be done. Same with the lighting console -- I'd SEEN another group use one of the MIDI functions to control the ETC "Expression" board. I just hadn't done it myself.
Opened the manual. The Expression speaks MSC (MIDI Show Control) and will take a "Go" in that format. Ran a MIDI connection through the audio snake that was already there via my hand-made pair of MIDI-to-XLR adapter cables. I remembered QLab had some kind of drop-down menu of MIDI control sequences already written for you -- I opened up my fully-registered copy of QLab 1.0 and looked around.
The board didn't seem to be seeing the commands, but then after I'd tapped at the button a few times (trying different options) I noticed the lights had changed. Turns out you had to deliberately press and hold the "send a message now" button within the QLab interface before it would spit out the full-length MSC.
Now, since it was already in my bag, I pulled out my Arduino-based MIDI message generator and the XBee-modified Staple's Easy Button. And now I could trigger the "Go" button for the next lighting cue from basically anywhere in the theater.
It's a hack, and a bit of a chain; the inside of the Easy Button currently holds not just the XBee node but is wasting a perfectly good USB Explorer as a break-out board. I haven't gotten around to putting in a new breakout board (and boost converter) as replacements. When the Easy Button is pressed, the XBee node sends a radio message with the changed status of pin D0. The receiving node toggles the output level of its pin D0 in response, and the Arduino it is connected to detects this as a switch closed (aka +v is present on a pin that is otherwise pulled to ground. Or is it the other way around?) The Arduino, which at least is in a nice box, debounces the "switch/sensor" input, creates a NoteOn event, and sends it out the serial port at 31250 BAUD. A standard MIDI connector picks this up, creates a newly formatted message via USB, and this triggers a cue within QLab. The QLab cue creates a new MIDI event -- an MSC "Go" command -- and shoots that OUT the same USB MIDI adapter. That runs through two adapter cables and sixty feet of audio snake to reach the back of the lighting console.
But, the point of the demonstration is, this worked. And more importantly than that, it worked off-the-shelf. I had the components already, and I didn't even have to go inside via the USB connection and write new code to one or more of the components to do this particular task (which, if I had, could have removed the laptop and its MIDI adapter from the chain of connections).
And this is what I've been striving at with all of my theatrical gadgets; to have things that I can pull out of the gig bag and hook up in a few minutes to solve a problem. Or to so something new that hasn't been done before, thus enhancing the fun and the creative options of a show.
And today I needed to do a touch-up focus on stage and I had no assistant to run the board. At least this theater has an RFU (Remote Focus Unit), but it was still faster to write a couple of cues, each containing just the system I needed to touch up, then hook up my Wireless Easy Button again. And then I could move from light to light without having to run back to the board each time.
Was house tech over the weekend for a show that brings their own sound and light operators. Except for one early-morning showcase performance. When they handed me a CD and told me they had a couple of simple lighting cues. Problem; the sound board is still at FOH position (actually, rear of the house, but the important part is, it is NOT near the light board).
So pulled some toys out of the bag to be able to run the light board remotely. There's one MacGuyver episode where he has to build a telescope from random lenses and he has maybe five minutes to do what took Galileo years. But as Mac puts it -- he already knew it could be done. Same with the lighting console -- I'd SEEN another group use one of the MIDI functions to control the ETC "Expression" board. I just hadn't done it myself.
Opened the manual. The Expression speaks MSC (MIDI Show Control) and will take a "Go" in that format. Ran a MIDI connection through the audio snake that was already there via my hand-made pair of MIDI-to-XLR adapter cables. I remembered QLab had some kind of drop-down menu of MIDI control sequences already written for you -- I opened up my fully-registered copy of QLab 1.0 and looked around.
The board didn't seem to be seeing the commands, but then after I'd tapped at the button a few times (trying different options) I noticed the lights had changed. Turns out you had to deliberately press and hold the "send a message now" button within the QLab interface before it would spit out the full-length MSC.
Now, since it was already in my bag, I pulled out my Arduino-based MIDI message generator and the XBee-modified Staple's Easy Button. And now I could trigger the "Go" button for the next lighting cue from basically anywhere in the theater.
It's a hack, and a bit of a chain; the inside of the Easy Button currently holds not just the XBee node but is wasting a perfectly good USB Explorer as a break-out board. I haven't gotten around to putting in a new breakout board (and boost converter) as replacements. When the Easy Button is pressed, the XBee node sends a radio message with the changed status of pin D0. The receiving node toggles the output level of its pin D0 in response, and the Arduino it is connected to detects this as a switch closed (aka +v is present on a pin that is otherwise pulled to ground. Or is it the other way around?) The Arduino, which at least is in a nice box, debounces the "switch/sensor" input, creates a NoteOn event, and sends it out the serial port at 31250 BAUD. A standard MIDI connector picks this up, creates a newly formatted message via USB, and this triggers a cue within QLab. The QLab cue creates a new MIDI event -- an MSC "Go" command -- and shoots that OUT the same USB MIDI adapter. That runs through two adapter cables and sixty feet of audio snake to reach the back of the lighting console.
But, the point of the demonstration is, this worked. And more importantly than that, it worked off-the-shelf. I had the components already, and I didn't even have to go inside via the USB connection and write new code to one or more of the components to do this particular task (which, if I had, could have removed the laptop and its MIDI adapter from the chain of connections).
And this is what I've been striving at with all of my theatrical gadgets; to have things that I can pull out of the gig bag and hook up in a few minutes to solve a problem. Or to so something new that hasn't been done before, thus enhancing the fun and the creative options of a show.
And today I needed to do a touch-up focus on stage and I had no assistant to run the board. At least this theater has an RFU (Remote Focus Unit), but it was still faster to write a couple of cues, each containing just the system I needed to touch up, then hook up my Wireless Easy Button again. And then I could move from light to light without having to run back to the board each time.
Thursday, May 10, 2012
Feeping Creaturitis
Physiologists are continuing to refine just how they feel about stretching. I know that back when I was doing some serious cross-country running, I did not believe in stretching while my muscles were cold. Instead I would warm up by jogging in place, shallow bends, and so forth. And I'd stretch out following a run, because it seemed to me I cramped up less if I eased my muscles down to rest again. Except even when I converted to treadmill running, I found a better cool-down was using the Treadwall my gym had for far too short a time.
Anyhow...stretching may or may not damage your body, but stretch goals can damsure hurt a project.
One of the basic -- and hardest -- elements of good engineering is parameterization. You have to identify the problem at a larger level than "how do I best make a machine do this" or, worse, "how can I make this machine I happen to have do this?" Good enough parameterization can ofter parameterize the engineering itself right out of the game; "Oh, I guess there IS a commercial machine that already does it well enough," or "Well, it doesn't look like anyone would even use this application."
Which is all a round-about way of getting to my current work with the BlinkM. This started with bottom-up practice; there is a device which puts on one very small footprint PCB a bright RGB LED and an AVR. And it is configured out of the box to upload and run both commands and programs via an I2C serial port. So I started with a solution in search of an application; could this product be of any use in addressing the various kinds of controllable lights I've identified a need for in live theater?
I wasted a fair amount of time in trying to implement a minimum-component serial-over-wireless link for these devices before I finally got around to doing the higher-level parameterization. And one thing leapt out at me; there was no identified theatrical application for which full serial communication was necessary.
Of course the basic problem in this kind of geekery for theater is that you are not just replacing existing solutions with more elegant ones. You are trying to identify solutions for what no-one has identified as a problem before. Few people have come up and said "In our production of 'Gypsy,' it would be very useful if Electra's boob lights would light every time she bumped." Fewer still have come up and said "In our production of 'Godot,' it would be great if the spectral plot of the wind sound altered in response to how close Estragon gets to the bush, tree, shrub...whatever the heck that thing is."
In the first example, someone might have imagined the effect, but assumed it was technically unfeasible and thus never brought it up in production or design meetings. In the latter example, no-one had even envisioned the potential of dynamic alteration of the soundscape of the play via sensor networks and DSP.
Actually, honestly, by the time the resident geek is even consulted even easily solvable problems have already been "solved" either by changing the blocking, or altering the set, or using one of the venerable theater tools like fishline.
(Although sometimes there is the flip side -- a company like Berkeley Rep, that might ask for "blood to come pouring out of the giant translucent eye"; a problem that required electro-pneumatics and some kitchen chemistry to solve.)
The point being, the set of known applications is much, much smaller than the total set of solutions for what had never previously been identified as potentially soluable problems!
Anyhow. The one BlinkM-derivative application I am absolutely sure of is the candle or lantern. Because I've done so many of them in the past.
My best lantern solution was a half-dozen grain-of-wheat bulbs or amber LEDs, wrapped with diffusion from the lighting supply closet, and a 9V battery pack stuck in the original fuel reservoir. The most elegant switch I made was wired to the wick adjustment wheel. The most intriguing one I saw, however, was at Berkeley Rep, which used an R/C model car servo to turn a potentiometer, when thus allowed the lamp to be turned off remotely and on cue.
Which allows this application to be readily parameterized; "A battery-powered, fully portable simulated lantern light that will fit into a prop lantern, that is bright enough to be visible under stage lights, and that can be turned on and off remotely -- preferably from within lighting cues (aka it becomes a wireless DMX device)."
The first round of stretch goals would be to allow a range of stable intensities (not just fade up, fade out), and to flicker.
The next round of stretch goals says, since this is a potential "drop in any light" solution -- aka candles, small torches, even a wall sconce on a portable set piece -- we should add control of the color, and control of the range of the flicker effect.
I can't actually imagine any other application so specific and well-described. I can think of, say, a crystal ball (such as is used by the Witch in "Wizard of Oz." Or a Vial of Mysterious Liquid that glows from within (it might even be Atomic!)
But it seems plausible that whatever the application, the very process of being small, battery powered, not that bright, and installed in a prop, seems to imply that the wanted behavior for each application can be worked out easily before installation. Which is to say -- it doesn't have to be re-programmed over the air.
And in many, many applications, it makes more sense to have a button in the hands of the actor than it does a wireless connection to the lighting console.
So throw out the attempts to create a serial link. Instead, as the BlinkM board makes available one analog input of the AVR, simply set it to be controlled via a resistor ladder. As many different pre-programmed behaviors as the resolution of the analog in port allows can be called up with nothing more complicated than a button.
For the lantern, the most sensible is two commands; fade to lantern-on flicker loop, and fade to all LEDs off.
And if you do desire wireless control? Why, then, you can use the pin-passing mode of a pair of XBee nodes to pass an analog value. Assuming you can work out the balance between the 4.5V nominal of the BlinkM and the 3.3V supply desired for the XBee, you should be able to press a button (or run a line of code on a host AVR) and have the XBee network pass that button value wirelessly to the lantern.
So here I am coding. I am still using microseconds() to keep the size of the PWM loop consistent, but even though it is a lot more work I may want to switch to an interrupt routine based on one of the ATtiny45's two hardware timers. The basic idea is straight-forward; for each loop through the PWM loop, the LEDs are all switched off, then at set values from the first step to the last step of the loop they are switched on, thus creating a duty cycle varying from (basically) 0% to 100%.
An added wrinkle is that human perception is roughly log, not linear, thus it makes sense to either include a gamma correction calculation or look-up table prior to determining the duty cycle. This has the advantage of meaning you need less resolution (fewer steps) in the loop in order to maintain resolution (visible changes in brightness) at the lowest end of the scale.
The simplest possible shell code to this just feeds three numbers into the PWM loop; one each for R, G, and B.
The next iteration is a fade-to. For this, we have the known RGB state, and a target RGB state, and a rate (the number of program steps between one and the other). At this point the central statement looks more like float current_value = (old_value - new_value/rate); if (timer > gamma_table[int (float current_value)) { LED = high; }
Which is to say; we need to use a floating-point variable in order to correctly track fractions of increase, convert it to Int to find the next whole-number step, and feed that into the look-up table in order to find the moment the LED needs to switch on.
But what of, say, a pulse like the sleep light on a computer? This alternates between two steps; fadeTo on, and fadeTo out. Or, rather, fade to, in alternating order, two defined RGB values. So the program flags when all fade steps are completed, and then grabs the new target value and re-commenses.
Except. It is easy to imagine a program in which more than two states follow. A traffic-light pattern, say. So rather than make an arbitrary list, instead we will establish an array of RGB values, and test on the completion of each fade loop if there is an array element in the ++ location. And, of course, since not all steps would necessarily be the same length, the fourth element in the array is unique fade rates for each target.
And now the goals are getting reeeeaaallly stretchy. Because it is easy enough to imagine having to fade from one multi-element loop to another. In the simplest case, imagine a flickering candle slowly fading. You don't want to freeze the flicker and fade from whatever the current color is. Instead, you want to continue running the flicker program whilst changing ALL of the values in an incremental way according to the external fade loop.
And since you are being silly already, why not ask how you would go from a steady pulsing white light to a steady pulsing RED light -- without a stutter? Well, by putting in the command that says "fade to new pulse" a flag that requires the new loop to synchronize with the old loop.
And at some point you realize the iterations become endless -- that there is always some scenario you can imagine by which a multi-stage program could be cross-faded with another multi-stage program.
And that's the point at which stretching really starts to hurt. Better to get back to the known basics -- things like a flickering candle that can be dimmed -- and actually finish the code for that before adding on more and more bells and whistles.
Anyhow...stretching may or may not damage your body, but stretch goals can damsure hurt a project.
One of the basic -- and hardest -- elements of good engineering is parameterization. You have to identify the problem at a larger level than "how do I best make a machine do this" or, worse, "how can I make this machine I happen to have do this?" Good enough parameterization can ofter parameterize the engineering itself right out of the game; "Oh, I guess there IS a commercial machine that already does it well enough," or "Well, it doesn't look like anyone would even use this application."
Which is all a round-about way of getting to my current work with the BlinkM. This started with bottom-up practice; there is a device which puts on one very small footprint PCB a bright RGB LED and an AVR. And it is configured out of the box to upload and run both commands and programs via an I2C serial port. So I started with a solution in search of an application; could this product be of any use in addressing the various kinds of controllable lights I've identified a need for in live theater?
I wasted a fair amount of time in trying to implement a minimum-component serial-over-wireless link for these devices before I finally got around to doing the higher-level parameterization. And one thing leapt out at me; there was no identified theatrical application for which full serial communication was necessary.
Of course the basic problem in this kind of geekery for theater is that you are not just replacing existing solutions with more elegant ones. You are trying to identify solutions for what no-one has identified as a problem before. Few people have come up and said "In our production of 'Gypsy,' it would be very useful if Electra's boob lights would light every time she bumped." Fewer still have come up and said "In our production of 'Godot,' it would be great if the spectral plot of the wind sound altered in response to how close Estragon gets to the bush, tree, shrub...whatever the heck that thing is."
In the first example, someone might have imagined the effect, but assumed it was technically unfeasible and thus never brought it up in production or design meetings. In the latter example, no-one had even envisioned the potential of dynamic alteration of the soundscape of the play via sensor networks and DSP.
Actually, honestly, by the time the resident geek is even consulted even easily solvable problems have already been "solved" either by changing the blocking, or altering the set, or using one of the venerable theater tools like fishline.
(Although sometimes there is the flip side -- a company like Berkeley Rep, that might ask for "blood to come pouring out of the giant translucent eye"; a problem that required electro-pneumatics and some kitchen chemistry to solve.)
The point being, the set of known applications is much, much smaller than the total set of solutions for what had never previously been identified as potentially soluable problems!
Anyhow. The one BlinkM-derivative application I am absolutely sure of is the candle or lantern. Because I've done so many of them in the past.
My best lantern solution was a half-dozen grain-of-wheat bulbs or amber LEDs, wrapped with diffusion from the lighting supply closet, and a 9V battery pack stuck in the original fuel reservoir. The most elegant switch I made was wired to the wick adjustment wheel. The most intriguing one I saw, however, was at Berkeley Rep, which used an R/C model car servo to turn a potentiometer, when thus allowed the lamp to be turned off remotely and on cue.
Which allows this application to be readily parameterized; "A battery-powered, fully portable simulated lantern light that will fit into a prop lantern, that is bright enough to be visible under stage lights, and that can be turned on and off remotely -- preferably from within lighting cues (aka it becomes a wireless DMX device)."
The first round of stretch goals would be to allow a range of stable intensities (not just fade up, fade out), and to flicker.
The next round of stretch goals says, since this is a potential "drop in any light" solution -- aka candles, small torches, even a wall sconce on a portable set piece -- we should add control of the color, and control of the range of the flicker effect.
I can't actually imagine any other application so specific and well-described. I can think of, say, a crystal ball (such as is used by the Witch in "Wizard of Oz." Or a Vial of Mysterious Liquid that glows from within (it might even be Atomic!)
But it seems plausible that whatever the application, the very process of being small, battery powered, not that bright, and installed in a prop, seems to imply that the wanted behavior for each application can be worked out easily before installation. Which is to say -- it doesn't have to be re-programmed over the air.
And in many, many applications, it makes more sense to have a button in the hands of the actor than it does a wireless connection to the lighting console.
So throw out the attempts to create a serial link. Instead, as the BlinkM board makes available one analog input of the AVR, simply set it to be controlled via a resistor ladder. As many different pre-programmed behaviors as the resolution of the analog in port allows can be called up with nothing more complicated than a button.
For the lantern, the most sensible is two commands; fade to lantern-on flicker loop, and fade to all LEDs off.
And if you do desire wireless control? Why, then, you can use the pin-passing mode of a pair of XBee nodes to pass an analog value. Assuming you can work out the balance between the 4.5V nominal of the BlinkM and the 3.3V supply desired for the XBee, you should be able to press a button (or run a line of code on a host AVR) and have the XBee network pass that button value wirelessly to the lantern.
So here I am coding. I am still using microseconds() to keep the size of the PWM loop consistent, but even though it is a lot more work I may want to switch to an interrupt routine based on one of the ATtiny45's two hardware timers. The basic idea is straight-forward; for each loop through the PWM loop, the LEDs are all switched off, then at set values from the first step to the last step of the loop they are switched on, thus creating a duty cycle varying from (basically) 0% to 100%.
An added wrinkle is that human perception is roughly log, not linear, thus it makes sense to either include a gamma correction calculation or look-up table prior to determining the duty cycle. This has the advantage of meaning you need less resolution (fewer steps) in the loop in order to maintain resolution (visible changes in brightness) at the lowest end of the scale.
The simplest possible shell code to this just feeds three numbers into the PWM loop; one each for R, G, and B.
The next iteration is a fade-to. For this, we have the known RGB state, and a target RGB state, and a rate (the number of program steps between one and the other). At this point the central statement looks more like float current_value = (old_value - new_value/rate); if (timer > gamma_table[int (float current_value)) { LED = high; }
Which is to say; we need to use a floating-point variable in order to correctly track fractions of increase, convert it to Int to find the next whole-number step, and feed that into the look-up table in order to find the moment the LED needs to switch on.
But what of, say, a pulse like the sleep light on a computer? This alternates between two steps; fadeTo on, and fadeTo out. Or, rather, fade to, in alternating order, two defined RGB values. So the program flags when all fade steps are completed, and then grabs the new target value and re-commenses.
Except. It is easy to imagine a program in which more than two states follow. A traffic-light pattern, say. So rather than make an arbitrary list, instead we will establish an array of RGB values, and test on the completion of each fade loop if there is an array element in the ++ location. And, of course, since not all steps would necessarily be the same length, the fourth element in the array is unique fade rates for each target.
And now the goals are getting reeeeaaallly stretchy. Because it is easy enough to imagine having to fade from one multi-element loop to another. In the simplest case, imagine a flickering candle slowly fading. You don't want to freeze the flicker and fade from whatever the current color is. Instead, you want to continue running the flicker program whilst changing ALL of the values in an incremental way according to the external fade loop.
And since you are being silly already, why not ask how you would go from a steady pulsing white light to a steady pulsing RED light -- without a stutter? Well, by putting in the command that says "fade to new pulse" a flag that requires the new loop to synchronize with the old loop.
And at some point you realize the iterations become endless -- that there is always some scenario you can imagine by which a multi-stage program could be cross-faded with another multi-stage program.
And that's the point at which stretching really starts to hurt. Better to get back to the known basics -- things like a flickering candle that can be dimmed -- and actually finish the code for that before adding on more and more bells and whistles.
Subscribe to:
Comments (Atom)