I'm using a mic for a hatstand. Sm58 in a straight round-base stand. Works pretty well. The PA just came back from a gig and there's no room in the closet to store all of it.
Doesn't help that the robot worktable is still set up and I have carving foam, paint, plastic bits, and of course electronics strewn around. I really need to move some projects from "in progress" to "done and can be put on a shelf out of the way."
Lacking the time and space for that, I'm putting more things in boxes today. So at least the half-done project has all the essential parts collected in one place. One such (large) box is filled with vacuumform Lewis Gun. Which spills over into another box, which also contains grenade spoons and other parts to build some prop smoke grenades.
On the table is the camera head we didn't use for the robot. I'm half-tempted to keep it. And instead of pulling out the mini servo, program an AVR to do random moves.
Actually, if I was doing random robotics that had any connection to the show I just opened, I'd be putting proximity/movement sensors in a basic servo to build a couple of what the BEAM community calls Head-type Squirmers. And then I'd put a big foam-core cube on the servo and paint it up like a candy. Which is to say; I'd be building some "Square candies that look 'round."
It is awfully tempting. I have all the hardware here. If I skipped active tracking and just had pre-programmed behavior linked to a simple IR proximity sensor.....
Argh! My goal for today was actually to log hours in element repair. I'm getting paid for that, at least. And I need some spares for the weekend. The other goal before the next weekend of the show begins is upgrades to the robot. And with my Vex apparently dead I was going to leverage the two new XBee nodes I just picked up.
The second test was going to be -- hopefully still will be -- trying out direct mode for control of a servo. I've seen it done as a demonstration at Makers Faire. Apparently the PCM output of the analog pins is close enough to drive an un-modified servo. And all you need for the transmitter side is a potentiometer. Of course, adding a couple trim resistors/pots would be smart.
I still prefer -- especially for something as fragile as my robot -- to set the servo limits in software. And this also means that if you are transmitting power on/power off signals to the lights and wireless camera (which draws power from the 7.2 nicads in the chassis), you can transmit a single "toggle" command instead of having to depend on continuous transmission of either the "on" command or a "kill" function. Plus, the eyes were wired with six high power LED's each in 3 colors, and with a micro somewhere in the signal chain you could command these to color mix or to chase.
All I really hope to get done by this weekend's shows is adding a camera and light kill switch, though. Which I can probably do with no more than my existing XBee nodes and the "Really" (aka "Relay") board I purchased from one of the Kowloon-based electronics suppliers via eBay.
The coolest way to do it is, of course, with full serial. Although I/O line passing on the XBee nodes is near-transparent and simple to set up, establishing a serial link gives a more robust link and a practically unlimited command set. Plus, of course, having client-side intelligence means you can program the thing to operate autonomously between commands. On the server side, set up an Arduino/AVR and wire that to buttons and switches. Or write an application in Processing and put in virtual buttons and switches/monitor keyboard and mouse.
This is more of the sort of thing I taught myself about "naked" AVRs for, so I didn't have to waste a whole $28 Arduino on an embedded application. But I'm not fluent and practiced enough with them so I can quickly write some serial data routines for the built-in UART and upload it to a 45-cent chip. It might only be basic C, but straight C is worlds away from Wiring (aka Processing/Arduino) wrapped inside that handy IDE. When you are programming for micros, you lose much of that layer of abstraction between you and the metal -- "Serial.print ("hello, world");" begins to look a lot more like "PORTB |= (0 << 2);"
Well. Maybe if I can get stuff boxed and the table cleared and XBees show they have the right firmware and the servo responds...I might hook up the IR proximity detector I have and see how fast I could make a "square candy that looks 'round."
Wednesday, July 18, 2012
Tuesday, July 17, 2012
Vexing
Ah, the joy of embedded computing -- when you are debugging you can never be sure if it is really a software error or if it is a hardware problem instead.
The two worlds blend into each other, too. Often the simplest "test circuit" is dashing off a quick program that will interrogate the inputs or run through a preset motion on a servo. So you find yourself working at both ends at once; with breadboard and alligator clips and double-stick tape on the desktop, and a couple feet away, similar commented-out and patched together boilerplate code running on a laptop.
I have three gadgets in performance right now. My XBee, in a new housing and with a new software interpreter, is in a children's show. Amusingly enough, the Easy Button it used to be in is in another show, sans electronics. My MIDI-controlled projector douser is in its first show, and is a visible lighting effect. The MIDI circuit is being bypassed, though, making it basically the world's most complicated solenoid. Good thing I included a quarter-inch jack for direct control (although I had to tweak the software to use it for this show). And the R/C robot with wireless camera is also in a show.
And it needs work. The transmitter is barely strong enough. The wheels and motors are so weak I'm scared it is going to stall out in the middle of a performance. And I could really use remote switches for the lights and camera. The latter, at least, I could hack up pretty fast with one of the new XBee nodes I just ordered. Pretty much a button and a Darlington transmitter and that old friendly pin echo mode would do it.
Which I may need to. I spent today trying to get the Vex transmitter I purchased to communicate with an Arduino. At this point about all I am sure of is that the receiver is getting power, and seems to put out at least one pulse distinct enough to trigger the Arduino's interrupt. Other than that, no joy.
For the first time in the two years since I got rid of it, I could use that old oscilloscope. I can't confirm that the receiver is actually working correctly, or seeing the transmitter.
The alternative (outside of ordering a second one and seeing if that one works better) is to delve a lot deeper into the Arduino PCM capabilities. Basically, write a series of sketches to confirm that the receiver is actually sending something like protocol. And then either go back through the code I've been trying to use, or write new code from scratch.
And I still don't know if the other end -- interfacing with the Futaba ESC and the steering servo, or even interfacing with the LED controller darlingtons -- will be as easy as hoped or will bring yet another software/hardware debug.
There isn't THAT much time this week. I have to re-do some sound cues and repair a whole bunch of microphone elements, plus I should really make some new mic belts. And I have a multi-track mixdown to do. And, after all that is done, it would be very, very nice to do some work I'll actually get PAID for!
Looks like it was a hardware error after all -- and not on my side. I hooked up a speaker and I don't seem to be getting regular tone bursts. I hooked it up to the Vex CPU and the Receiver Status light doesn't light. Still not as good as hooking up an oscilloscope, but I'm willing at this point to drop the $40 on a replacement receiver. Except that I am flat broke again (the current design is paying in installments) so I can't do that until the end of the month. By which point the show will be almost over.
The two worlds blend into each other, too. Often the simplest "test circuit" is dashing off a quick program that will interrogate the inputs or run through a preset motion on a servo. So you find yourself working at both ends at once; with breadboard and alligator clips and double-stick tape on the desktop, and a couple feet away, similar commented-out and patched together boilerplate code running on a laptop.
I have three gadgets in performance right now. My XBee, in a new housing and with a new software interpreter, is in a children's show. Amusingly enough, the Easy Button it used to be in is in another show, sans electronics. My MIDI-controlled projector douser is in its first show, and is a visible lighting effect. The MIDI circuit is being bypassed, though, making it basically the world's most complicated solenoid. Good thing I included a quarter-inch jack for direct control (although I had to tweak the software to use it for this show). And the R/C robot with wireless camera is also in a show.
And it needs work. The transmitter is barely strong enough. The wheels and motors are so weak I'm scared it is going to stall out in the middle of a performance. And I could really use remote switches for the lights and camera. The latter, at least, I could hack up pretty fast with one of the new XBee nodes I just ordered. Pretty much a button and a Darlington transmitter and that old friendly pin echo mode would do it.
Which I may need to. I spent today trying to get the Vex transmitter I purchased to communicate with an Arduino. At this point about all I am sure of is that the receiver is getting power, and seems to put out at least one pulse distinct enough to trigger the Arduino's interrupt. Other than that, no joy.
For the first time in the two years since I got rid of it, I could use that old oscilloscope. I can't confirm that the receiver is actually working correctly, or seeing the transmitter.
The alternative (outside of ordering a second one and seeing if that one works better) is to delve a lot deeper into the Arduino PCM capabilities. Basically, write a series of sketches to confirm that the receiver is actually sending something like protocol. And then either go back through the code I've been trying to use, or write new code from scratch.
And I still don't know if the other end -- interfacing with the Futaba ESC and the steering servo, or even interfacing with the LED controller darlingtons -- will be as easy as hoped or will bring yet another software/hardware debug.
There isn't THAT much time this week. I have to re-do some sound cues and repair a whole bunch of microphone elements, plus I should really make some new mic belts. And I have a multi-track mixdown to do. And, after all that is done, it would be very, very nice to do some work I'll actually get PAID for!
Looks like it was a hardware error after all -- and not on my side. I hooked up a speaker and I don't seem to be getting regular tone bursts. I hooked it up to the Vex CPU and the Receiver Status light doesn't light. Still not as good as hooking up an oscilloscope, but I'm willing at this point to drop the $40 on a replacement receiver. Except that I am flat broke again (the current design is paying in installments) so I can't do that until the end of the month. By which point the show will be almost over.
Sunday, July 15, 2012
Me, Robot
So the robot is built, and made it through opening night. Now if it can just make it through opening weekend I'll be able to take it home, reinforce and improve it.
Everyone loves the design, and it is very much design by circumstance.
Original concept was a camera bot. Given the wheelbase available in our price range, I was pretty much stuck with a robot not much more than a foot long, which meant it would have a small camera stuck on top of a long neck. I built a mock-up turret camera with a servo for the turret and a fairly poor pan-tilt mechanism with another pair of servos.
Then there was a request for a second robot, a "girl" robot, which would chase the camera bot on stage and flirt with it. Obviously someone had been watching "Wall-E" too much.
We were getting too close to tech for comfort and I wasn't getting assurances that the costs were going to be reimbursed. So I picked up a forty dollar remote control car from a mass retailer. And since it seemed a simpler proof-of-concept, I started building the "girl" robot on top of it -- mostly to see if a $40 set of plastic wheels would support the weight of a prop large enough to "read" on stage, or whether I had to gamble with a more expensive rolling chassis.
Framed out a dome-shaped body with foam-core and that ran. Began adding extruded polystyrene chunks and carved up a smooth dome from that. Still ran, although it was sagging a little on the wheels at this point. The foam was delicate enough I altered the design to include a bumper.
So I obviously needed the performance of the Tamiya rolling chassis I had my eyes on. Ordered that, and a Vex controller, and -- when I realized the chassis shipped without one -- a Futaba ESC, and a new medium servo, and a few more parts besides. The draft for the "guy" robot was now a boxy body (foam-core) with an industrial look, and the turret camera on a smaller version of those hydraulic pillars used on ENG vehicles. I bought some bumper material, sheet styrene, and a vent cover as part of the intended dressing.
The request came that one of the robots really needed a binocular head (more "Wall-E"). So that became folded into the girl robot; the guy would have the turret camera, the girl would have a smoother head that didn't look so camera like.
Made a progress report at a meeting and they cut the guy robot.
So now the girl was the primary camera carry, but the binocular head was half-built by this point. And we no longer needed to distinguish her so much so she lost the pink bow and eyelashes and stayed with the smooth "EVA" white paint job.
And the only thing that lingers from the expensive exploration is that her choreography keeps getting expanded. She has a long "flirt" scene with an actor, and her own bow at curtain call. And the cheap plastic wheels and remote control are barely making it. So over this next week I intend to upgrade to the Tamiya, and maybe stick some servos in her as well as radio control of her light-up eyes.
Made it to opening night with the sound effects as well. A lot of things are not right and some are still not ready, and I'm going to be doing some serious reflection about how I need to change my design process. This is not the first show in which sound has had to play pick-up, giving me too little time left to do the work.
My paradigm has been that sound fits into the existing environment. That as a mixer, and as an effects designer, I work with (or around) the blend of voices and band, and the timing and, well, mood of action, choreography, and set movement. If I have a cue about a drawbridge lowering, I will wait on the final version until we find out how long the on-set drawbridge takes. If I have a piece of underscore music, I wait until the actor has found the way he wishes to do that scene and has settled on his timing.
This means, unfortunately, that when choreography is late, when set is late, when cuts and changes are made late, I need to re-think the sounds. In some cases, when the show isn't blocked yet and the actors aren't even off book, I can't even start building certain cues.
James Horner talks about having a similar experience on scoring "Aliens." He arrived in England six weeks before opening expecting to find a locked picture. He had the shape, the ideas, motifs in his head, basic arrangements, etc. But he couldn't start composing the actual running score until he had an actual film to time it to. And he needed not just enough time for him to write, but for the copyists to do the breakouts and get the music on the stands, the LSO rehearse and be recorded, and of course the poor dubbing mixers (the editing team always suffers from this effect) to get it cut into the picture.
What I need, unfortunately, is a way to have cues that aren't right, but will do -- and have them built early on. I'm not sure what to do about new cues that get added at the last minute. The particular show I just opened, there were two DANCE pieces that I didn't hear about until we were two weeks out. I spent the bulk of my available build time doing this, as they prioritized WELL over phone rings and toilet flushes.
I think that part of the problem is better addressed by making sure the clients better understand how long these things take. That making two minutes of dance music is not something you toss off in a single evening. But because of these prioritized (and time-consuming) cues, and another show that ran over their allotment considerably, I had even less time than the two brief weeks I was given. And scenery changes and even basic scene blocking was still happening two days before opening -- when I had no more schedule-able time to build sound cues.
Another thing that will help is breaking out the effects design/reinforcement design again. To go back into partnership so someone else is worrying about effects at the time in which band monitors and wireless mics become the necessary priority.
But even this, even all this, doesn't fix the basic problem. And that is how to pre-load kinds of things that shouldn't be pre-loaded.
I have a lot more thinking to do about this show and what I can learn from it to do different, but one other thing stands out from the experience, and it is exactly the wrong lesson. And that is that the artistic shape -- the mood of the show, the pallet, the kinds of sounds, the very approach -- wasn't clear to me until a week out. If for some reason I had sat down with the script two months out and created all the cues then, they would have been wrong and I would have had to cut most of them.
The remaining question there is if this is still a net gain for the show. Having even one cue that is right is one less cue to be working on during the crunch. But that is based on an assumption of, basically, designing the entire show "on spec." And on-spec work is the last thing you want to do if you are actually hoping to make a living as a designer. Facing not just the chance but the probability that most of the hours you put in will be wasted is NOT a good way to have rent in hand at the end of the month!
Everyone loves the design, and it is very much design by circumstance.
Original concept was a camera bot. Given the wheelbase available in our price range, I was pretty much stuck with a robot not much more than a foot long, which meant it would have a small camera stuck on top of a long neck. I built a mock-up turret camera with a servo for the turret and a fairly poor pan-tilt mechanism with another pair of servos.
Then there was a request for a second robot, a "girl" robot, which would chase the camera bot on stage and flirt with it. Obviously someone had been watching "Wall-E" too much.
We were getting too close to tech for comfort and I wasn't getting assurances that the costs were going to be reimbursed. So I picked up a forty dollar remote control car from a mass retailer. And since it seemed a simpler proof-of-concept, I started building the "girl" robot on top of it -- mostly to see if a $40 set of plastic wheels would support the weight of a prop large enough to "read" on stage, or whether I had to gamble with a more expensive rolling chassis.
Framed out a dome-shaped body with foam-core and that ran. Began adding extruded polystyrene chunks and carved up a smooth dome from that. Still ran, although it was sagging a little on the wheels at this point. The foam was delicate enough I altered the design to include a bumper.
So I obviously needed the performance of the Tamiya rolling chassis I had my eyes on. Ordered that, and a Vex controller, and -- when I realized the chassis shipped without one -- a Futaba ESC, and a new medium servo, and a few more parts besides. The draft for the "guy" robot was now a boxy body (foam-core) with an industrial look, and the turret camera on a smaller version of those hydraulic pillars used on ENG vehicles. I bought some bumper material, sheet styrene, and a vent cover as part of the intended dressing.
The request came that one of the robots really needed a binocular head (more "Wall-E"). So that became folded into the girl robot; the guy would have the turret camera, the girl would have a smoother head that didn't look so camera like.
Made a progress report at a meeting and they cut the guy robot.
So now the girl was the primary camera carry, but the binocular head was half-built by this point. And we no longer needed to distinguish her so much so she lost the pink bow and eyelashes and stayed with the smooth "EVA" white paint job.
And the only thing that lingers from the expensive exploration is that her choreography keeps getting expanded. She has a long "flirt" scene with an actor, and her own bow at curtain call. And the cheap plastic wheels and remote control are barely making it. So over this next week I intend to upgrade to the Tamiya, and maybe stick some servos in her as well as radio control of her light-up eyes.
Made it to opening night with the sound effects as well. A lot of things are not right and some are still not ready, and I'm going to be doing some serious reflection about how I need to change my design process. This is not the first show in which sound has had to play pick-up, giving me too little time left to do the work.
My paradigm has been that sound fits into the existing environment. That as a mixer, and as an effects designer, I work with (or around) the blend of voices and band, and the timing and, well, mood of action, choreography, and set movement. If I have a cue about a drawbridge lowering, I will wait on the final version until we find out how long the on-set drawbridge takes. If I have a piece of underscore music, I wait until the actor has found the way he wishes to do that scene and has settled on his timing.
This means, unfortunately, that when choreography is late, when set is late, when cuts and changes are made late, I need to re-think the sounds. In some cases, when the show isn't blocked yet and the actors aren't even off book, I can't even start building certain cues.
James Horner talks about having a similar experience on scoring "Aliens." He arrived in England six weeks before opening expecting to find a locked picture. He had the shape, the ideas, motifs in his head, basic arrangements, etc. But he couldn't start composing the actual running score until he had an actual film to time it to. And he needed not just enough time for him to write, but for the copyists to do the breakouts and get the music on the stands, the LSO rehearse and be recorded, and of course the poor dubbing mixers (the editing team always suffers from this effect) to get it cut into the picture.
What I need, unfortunately, is a way to have cues that aren't right, but will do -- and have them built early on. I'm not sure what to do about new cues that get added at the last minute. The particular show I just opened, there were two DANCE pieces that I didn't hear about until we were two weeks out. I spent the bulk of my available build time doing this, as they prioritized WELL over phone rings and toilet flushes.
I think that part of the problem is better addressed by making sure the clients better understand how long these things take. That making two minutes of dance music is not something you toss off in a single evening. But because of these prioritized (and time-consuming) cues, and another show that ran over their allotment considerably, I had even less time than the two brief weeks I was given. And scenery changes and even basic scene blocking was still happening two days before opening -- when I had no more schedule-able time to build sound cues.
Another thing that will help is breaking out the effects design/reinforcement design again. To go back into partnership so someone else is worrying about effects at the time in which band monitors and wireless mics become the necessary priority.
But even this, even all this, doesn't fix the basic problem. And that is how to pre-load kinds of things that shouldn't be pre-loaded.
I have a lot more thinking to do about this show and what I can learn from it to do different, but one other thing stands out from the experience, and it is exactly the wrong lesson. And that is that the artistic shape -- the mood of the show, the pallet, the kinds of sounds, the very approach -- wasn't clear to me until a week out. If for some reason I had sat down with the script two months out and created all the cues then, they would have been wrong and I would have had to cut most of them.
The remaining question there is if this is still a net gain for the show. Having even one cue that is right is one less cue to be working on during the crunch. But that is based on an assumption of, basically, designing the entire show "on spec." And on-spec work is the last thing you want to do if you are actually hoping to make a living as a designer. Facing not just the chance but the probability that most of the hours you put in will be wasted is NOT a good way to have rent in hand at the end of the month!
Thursday, July 5, 2012
Duck!
My third "Duck" show in a row. So I brought in my Wireless Easy Button, and they wanted it in the show. It was fairly easy to cram the XBee into the prop remote (soldering to the board to pick up switch traces was less easy, and the 1-watt Luxeon I put in the front is not nearly as bright as a hoped -- that's the flaw in running it on barely more volts than the voltage drop!)
However. Instead of using one of my computers, they are using the Stage Manager's computer for sound cue playback. And that means they are using the free version of QLab -- without the money to pay for the MIDI license.
Fortunately, although the java classes for MIDI are basically screwed on Mac OS and will be for the foreseeable future (heck...it isn't as if java itself has a future on the Mac, with all the effort Apple has been making to have everyone dump cross-platform development platforms and write exclusively on Cocoa)...anyhow, although MIDI is a pain, basic sound file playback isn't bad. So over the Fourth of July, I sat home and wrote and compiled a stand-alone, double-clickable ap that looks for a serial-over-USB, and when it detects activity at the serial port it plays the sound sample out the default Core Audio device.
It took me a chunk of today to figure out the other trick; when transporting it to a different OS/platform, bring the entire sketchbook folder and open Processing and re-compile from inside that folder. Between Processing and the Mac OS, I was getting a lot of cryptic error messages instead of a simple "library not found" or "wrong library" and this solved the issue because saving out the entire project this way compiles a copy of ALL of the libraries in your #includes.
And here it is on my not-quite-as-ancient G5:
The rubber duck is providing a housing for a XBee Explorer USB, which links the receiving XBee node to the laptop's USB port. The app window is displaying the selected port and flashes green when the XBee receives a signal. The hacked remote is under the duck.
The app is total cludge code, of course. Among other things, I'm not even trying to parse the serial message from the XBee (my mistake on a previous implementation). Instead I'm simply detecting if ANY serial message is present, and then as soon as I've confirmed that, I wipe the serial buffer!
(Should have thought of that trick long ago.)
And that's all I have time for. I have some six minutes of music to compose before the weekend, and I need to learn how to run my new shareware software synthesizer to do it!
However. Instead of using one of my computers, they are using the Stage Manager's computer for sound cue playback. And that means they are using the free version of QLab -- without the money to pay for the MIDI license.
Fortunately, although the java classes for MIDI are basically screwed on Mac OS and will be for the foreseeable future (heck...it isn't as if java itself has a future on the Mac, with all the effort Apple has been making to have everyone dump cross-platform development platforms and write exclusively on Cocoa)...anyhow, although MIDI is a pain, basic sound file playback isn't bad. So over the Fourth of July, I sat home and wrote and compiled a stand-alone, double-clickable ap that looks for a serial-over-USB, and when it detects activity at the serial port it plays the sound sample out the default Core Audio device.
It took me a chunk of today to figure out the other trick; when transporting it to a different OS/platform, bring the entire sketchbook folder and open Processing and re-compile from inside that folder. Between Processing and the Mac OS, I was getting a lot of cryptic error messages instead of a simple "library not found" or "wrong library" and this solved the issue because saving out the entire project this way compiles a copy of ALL of the libraries in your #includes.
And here it is on my not-quite-as-ancient G5:
The app is total cludge code, of course. Among other things, I'm not even trying to parse the serial message from the XBee (my mistake on a previous implementation). Instead I'm simply detecting if ANY serial message is present, and then as soon as I've confirmed that, I wipe the serial buffer!
(Should have thought of that trick long ago.)
And that's all I have time for. I have some six minutes of music to compose before the weekend, and I need to learn how to run my new shareware software synthesizer to do it!
Wednesday, June 20, 2012
Bah on Craft Foam
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!
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!
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.
Subscribe to:
Posts (Atom)