Magical Motorized Stagelike Curtains of Awesomeness

This project is one that I've been building incrementally over the past 2 years.  In my apartment, I decided that I wanted my curtains to open like those you would see on a stage - where they pull up from the inner lower corners to the upper outer corners, bunching fabric as it goes, to end up with a nice framing of the window.

To do this, I started with plain, flat curtains on a standard static bar.  I sewed rings into the back of the curtain in line from the inner lower corners to outer upper corners, then ran a control line through them (dead-ending on the inner lower corners), through blocks on the curtain rod supports, then down the side.  To make it all controllable from one side, I have the right side running back across the top, then joining to the control line on the left side, resulting in a single point of control for both sides.  Since I'm using 2mm control lines, I needed pretty small blocks with tight clearances, so I ended up using ones from the Harken 16mm line - utter overkill, but they get the job done.  To make sure that the curtains closed tightly when closed (since there's not much overlap), I sewed magnets into both sides, so that they 'zipper' it shut when the curtains are down, and can easily pop apart when opened.


That's the state that the curtains have been in for about a year and a half.  My next step was to automate them, but I ran into a snag.  If you look back at the Card Swipe Unlocker project I did 7 years ago, I used a low-RPM, high-torque motor - that motor had been missing, blocking my next step.  I looked into other linear actuators and curtain automation systems, but none of them were suitable for my purpose.  When going through a random drawer a couple weeks ago, I happened to re-discover the missing motor - joy!  Once I had that element, I went about designing the circuit to control the raising and lowering (I also recycled the relays and plastic box from that project).  I wanted to use the same control system as my lights so that it could be automated using the same application (which includes scheduled events - ie open them in the morning), which meant that it needed to work via a DMX-controlled relay.  In addition, I decided that including a dedicated DMX control channel for direction (ie one channel for motor on/off, one for direction up/down) was excessive.  After much pondering, I came up with this circuit that does the job beautifully.

There are 2 switches that are triggered by knots in the control line - one indicating that the curtains are all the way open, and one that they are all the way closed.  The switches have to be placed facing in opposite directions in order to be triggered correctly by the line, and become circuit interruptions for the motor power when triggered (so normally forming a closed circuit when at rest).  To make the reed switches activate by the knots in the control line, I added a housing made from InstaMorph (mouldable plastic) around the switches, with a channel for the control line, and a 'hood' to ensure that the knot would hit the switch.

The power supply coming into the circuit is always active.  When the DMX-controlled relay is flipped, it triggers 2 DPDT relays.  One of the relays determines the polarity of the motor circuit's power supply (so changes the direction), and the other relay determines which of the switches affects if the motor circuit is open or closed (we want the 'passive' switch to be removed from the motor relay circuit when switching direction, otherwise the motor would never start, as it is activated when the change happens).  Ergo, when you change the state of the DMX controled relay, it activates the motor in the opposite direction, and changes the switch determining when the motor should cut off.  Add in a DMX-controlled relay (http://www.amazon.com/dp/B00CEOLYZ0), and you've got yourself a DMX-activated curtain control box.

One issue that I ran into with this is, when the curtains are approaching full closure, there's very little (or no) upward pressure on the control line.  Unfortunately, this means that the switch indicating that the curtains are fully closed is never triggered, and they start winding back open the other direction.  To get around that, I added another control line spanning from the junction point of the two primary lines on the left side across to the rod support on the right side.  I then added a small weight on an additional block to that 'tension' line with a small weight on it, and it worked perfectly - that tension line gives just enough pressure as the curtains are closing activate the switch, and pulls up and out of the way when the curtains are opened.  The length of the tension line is such that it is taught along the top when the curtains are fully opened, and drops down when they are closed (the image has it taught across the top when they are closed, which is not entirely accurate, but you get the picture).

And there you have it!  Curtains that open like those on a stage, and are automated using a single DMX channel and one power supply.  I plan to swap out for a stronger motor to make the opening process faster, but this fully proves out the automation process.

Balsa Bridge

The company I work for has periodical 'Tech Challenges'.  These are normally coding tasks - build an AI player for a board game, that sort of thing.  The latest incantation, however is a much more engineering-related challenge - build a balsa bridge (within very specific parameters - http://bridgecontest.phys.iit.edu/public/international/2014/international_rules) to support as much weight as possible.

Since I'm not a trained structural engineer, I thought it prudent to do some testing.  Based on various designs on a truss simulator (http://ivanmarkov.com/truss-simulator.html), I decided upon my overall design.

Since there's no kill like overkill, I also added in a bit of 'secret sauce' - Titebond-3 ultimate wood glue in a precision applicator bottle, hot glue on the bottom of the supports to provide friction, Pitsco Lumberjack cutter for precisely angled cuts, and the basic cardboard covered with parchment paper and straight pins to assist with the gluing process.

While the bridge only ended up holding about 30 pounds, it still put on a decent showing of ~600x it's own mass - and there were quite a few good explosions. For your viewing pleasure, the destruction reel.

Raspberry Pi Conference Room Schedule Display

The company I work for recently moved into a new office, and I've been wanting to make a digital display to put outside the conference room I'm near, so that I know if it's free for ad-hoc meetings, or if I need to find somewhere else to convene.  Since I recently worked on a project that involved querying Exchange WebServices (EWS) to retrieve information, and the room has a shared calendar with the schedule, it seemed like a pretty straightforward project.  It was.

Part 1 - The Hardware

Start with one Raspberry Pi (http://www.amazon.com/RASPBERRY-MODEL-756-8308-Raspberry-Pi/dp/B009SQQF9C), add a 2.8" TFT touchscreen that attaches on top (http://www.adafruit.com/product/1601), and a micro USB Wi-Fi receiver (http://www.amazon.com/gp/product/B003MTTJOY).  Cobble together the two boards into a case printed on a MakerBot (box from http://www.thingiverse.com/thing:233396), configure the operating system to connect to the office network and launch the browser to the schedule in fullscreen, and presto, you've got a dandy device that can display the schedule outside a conference room, with only a power cable going to it.

Part 2 - The Software

Using EWS, write an app to retrieve the events from a shared calendar (in this case, the calendar for the conference room in question).  Push that data into a database, and schedule the app to run every hour (Efficient?  No.  Effective and simple?  Sure is).  Then create a simple PHP web page to query the database for the data and format it into a website designed for the screen resolution of the TFT.  Bam, you just created a conference room schedule board that shows the meetings scheduled for each day.

End result:

Nerf Escalations

For a period of time, our office was in an all-out Nerf war.  Truly, there were battles to be remembered.  To gain true superiority, I decided it was necessary to, not only get a weapon superior to others, but modify it to gain yet more power.

It all started with a Nerf N-Strike Rayven.  For those not well versed in the world of foam darts, the N-Strike series is designed with battles in mind, utilizing aerodynamically streamlined darts.  The Rayven is one of the guns that uses spinning wheels powered by batteries rather than air to propel the darts.  The wheels counterrotate, the dart is pressed between them, and the wheels fling it forward.

The major advantage of the Rayven for my purposes was that, it was designed with a neat little trick of using glow-in-the-dark darts, with little lights in the magazine that charged them with light before they were fired.  Pretty cool trick, if you're into that sort of thing.  What made it even more appealing, was that the lights were powered by a separate bank of batteries.  

With a little ingenuity, screwdrivers, and hot glue, I re-worked the circuitry to be able to include the magazine's battery bank in with the primary bank that powers the motors.  This ran 10.5v through them, rather than the paltry 6v that comes stock (when I wanted the power, that is.  The switch on the trigger guard allowed the overclocking to be activated or disabled).  With the additional voltage running through the motors, I was able to improve the distance it threw darts by 50% - a nice little bump.  A quick-release, reversable connection between the magazine and the body ensured that reloading could be quick and polarity was never a concern.

They never saw it coming.

DMX Lighting Control Application - And Then Some!

There's been a bit of a dry spell around here, eh?  Shifting from the scholastic world to the professional world comes with it's share of changes, and some projects had to be put on hold for a bit.  Let's get back on that horse!

I've always had a love for stage technologies - pro sound, stage lighting, all that good stuff.  Once I got a real job, I was able to start getting some of my own equipment to use on the side - soundboards, speakers, and stage lights.  The next logical step (well, to me anyway) was to use those stage lights in my apartment instead of normal things like lamps.  They're all RGB LED fixtures (that is, each contains red, green, and blue LEDs in an array) positioned on the floor pointing up at the wall, so they give off a nice indirect, diffused glow.  The lights are all controlled via DMX (standard stage lighting control), so logically, I needed to make an application that would control them using a USB to DMX interface.

I started off with a very modular setup from the outset.  I set up a database that allowed for configured Light Types (each fixture has a specific way it needs to be controlled, as certain number of DMX channels it requires, etc), Lights (the actual devices, with their associated Type), Groups of lights, and Scenes (conglomerations of groups and their lighting state, like bright red).  I made a super-simple Windows Forms application to be able to configure all those settings in a tabular format.  Now that I had information about all the lights and their current state when various things happened, I was able to build a 'universe' of information about what value every DMX channel needed to be configured for in the current setup.  Using a USB > DMX interface with an API that plays nicely with C# (http://www.amazon.com/Velleman-VM116-Usb-Controlled-Interface/dp/B001IRMFUW, using K8062D.dll), I was able to commune with the lights to my heart's content.

Except the heart wanted more.  The nest step was to make the application web-accessable so that I could set the lights from my phone.  Obviously.  So, I updated the application to host a REST endpoint that allowed it to load requested scenes.  I then created a simple PHP web page that connected to the database, retrieved a list of all configured scenes, and then displayed them on the screen as big buttons that, when clicked, triggered a call to the application's service endpoint to enact the change.  Simple, and highly effective - my lights were now mobile-friendly!  And I saw that it was good.

And yet, there was something missing.  Sure, it was nice being able to take out my phone and set the lights, but shouldn't they be able to do that themselves?  I added a new tab to my rapidly growing application for Schedule items.  These had information about what Scene should be triggered, at what time, and on what days.  Once set up, my lights turned on a bright white in the morning when I was supposed to be awake (during the week, that is), green when I should start heading out, red when I really-no-kidding-for-realzies need to leave, then turn off when I sure as heck should be out of the house.  They then turn back on a nice bright white just before I get home in the evening, a soothing blue when I need to start heading to bed, and turn off when I should be falling asleep.  And thus, the lights gained a speck of artificial sentience, and my heart was happy for a time.

But alas, one cannot stem the torrent of need from the heart.  Yet another use case presented itself that seemed to be a wonderful fit for my little application.  One of my good friends was getting married, and he asked if I could provide sound and lights for the reception.  Never one to go into something halfway, I added to grant the application the ability to function as fully automated DJ.  I added a new tab to the interface for Songs.  Each song had an associated lead-in and end buffer (to trim out introductions and fade-outs to keep the party jammin'), as well as it's own scene (yep, I made a scene for each song).  These are mostly empty because I cleaned the lists out for everyday use.

Once started, the application cross-fades through each song in the list (using WMPLib.WindowsMediaPlayer objects), fades the lights from one scene to the next, and in general takes care of itself.  It also allowed for skipping and re-ordering songs (which, for those of you who have never played the role of music selection master, happens.  A.  Lot.)  There were a couple minor glitches like songs repeating, but in general, it worked out quite nicely, and allowed me to enjoy the reception as well.

What's next for Moody?  Who knows - the heart is a fickle organ; you can never quite tell what it's going to pine after next.

Grid Mark II

After completing the first version of the grid (see post a couple ago for complete details), I began pondering how awesome it would be to make a new version that had less spaghetti and fragility and was smaller with higher LED density, but had the same basic circuit design and components. The best way to do this was to make a printed circuit board. After doing some research on different options, I decided to try to make the PCB myself using the toner transfer method. The basic idea is to print the circuit on a laser printer onto glossy paper, then iron that onto a copper-covered substrate, then soak it in etchant to remove the copper not covered by the toner, then remove the toner and you have a PCB. Great and seemingly quite simple in theory. If you are looking into this method, I think it would work really well for small single sided boards. My board, however, is 5x8 inches (quite large) and double sided. If I ever did get one side correct, it would be ruined when I did the other side. Long story short, it was a failure. These are the best transfers that I ever got:

So, since DIYing it was out of the question, I looked into where I could get it made for less than a small fortune. Most places were well over $100 for a board of my size, but 4pcb.com has a deal for students where it is only ~$50 for a board including shipping. So, after re-doing my design in their application (wrangling all the wires to fit on 2 sides is not an easy task, and replicating it in a new application is no spring chicken) I ordered the board and crossed my fingers that I hadn't messed it up too badly, as this was my first foray into designing PCBs. A couple weeks later, and voila!

Gorgeous, yes? As an added benefit, ordering it meant that i didn't need to drill all 810 holes myself, and it was coated with a solder mask, which makes it more resilient to wear and tear. This board is actually 2 boards in one that needed to be split; the display is the square part that will hold all the LEDs, and the side board will stick off the back with a 90 degree connector to house the control chips. This means that it can theoretically be places side-by-side with more of it to make a larger overall screen. Future versions will likely contain this functionality. Nevertheless, after splitting the board (running a box cutter down the split 20 times per side or so and breaking it in half along the line), it was time to populate the board. It was at this point, however, that I discovered a mistake in my design that had been in it from the beginning. Without getting into too much specifics, I had switched 2 sets of 4 pins 3 times along the connection between the two boards. After having a minor freak-out, I managed to solve it by disconnecting 24 of the joints in the elbow connector and jumpering it together so the correct pins were connected. This is what the 3 juts of wire are off the side as you'll see. I also needed to re-write a bit of the multiplexing logic, but that only took a few minutes. After about 10 straight hours of soldering, I had myself a completed grid device. All told, there are 882 solder joints, 144 LEDs and 1 board of awesomeness.

Since I was making a new version of the board, I also decided to rewrite the controlling application to make it more user-friendly and include some more useful functionalities. This version adds the ability to dim lights, a large clock (the colon blinks on the second at 50% to 100% brightness) and the ability to display custom color images. To help make these (I had previously been doing it my manually creating a massive boolean array), I made an editor. There are still visualizations that cycle automatically and a marquise that can say whatever you'd like. Additionally, the app is backward-compatable with the old grid.

And now the money shots:

I would appreciate any comments or suggestions or ideas anyone has, new things are always good to add!

8-Switch Panel

This project was something simple that had been mulling around my mind for a while, and made my freshman year. I DJ'd in High School, and for controlling my lights, I purchased a power-strip type device that had 8 switches on the front, and 8 outlets on that back that were, you guessed it, controlled by the switches. This was nice, because it allowed me to turn each device on and off individually. My freshman year, I was inspired by the video of the house that had Christmas Lights that flashed to a Trans-Siberian Orchestra song. To create a similar setup without spending gobs of money, I found a solid-state relay that was activated by the voltage put out by the data pins on the parallel port, and could handle the wattage drawn by lights. Once I had the relays, it was very easy to simple solder a bridge that would duplicate the functionality of the switch through the relay if it were activated, and attach each of the eight relays to each of the eight data lines from the parallel port. One challenge I had was to identify what wires in the parallel cable were the data lines, and what order they were in, but an application that activated one at a time and a voltmeter make that relitively easy.

Once I had the hardware working, I needed to develop an application that would take advantage of the automation capabilities. I decided that the best way to give it similar functionality to the video would be to make the application take a text file of cues, then cycle through the cues on a button press so that the lights could be synced up to the music. Additionally, I had included an automation function in the application that attempted to calculate how quickly the button was pressed, then identify what the tempo was and continue cueing once the tempo was set. The cue file I made by having each line be a new cue, and the line consist of 0s and 1s to indicate that that channel was off or on. For example, 00010100 would use all 8 outlets, with all off except 4 and 6. The application converted that into an integer and transmitted it over the parallel port and, when that integer was converted by the parallel driver into electrical signals, it resulted in the required wires putting out a voltage. For one song, I made a cue file that was several hundred lines; the grew quite rapidly. It was somewhat of a challenge to get the song started and begin cueing right away, but when you got it synched up perfectly, it was really cool. As an added bennefit, the switches still function as originally, so no functionality was taken away.