Finally!!! One of my bigger project write ups has been completed. It took a while to go back and figure out what I did and how I did it. But it’s done. This project never got the front page attention I feel it deserves, so I have posted this announcement (because it is a new post) along with the actual back dated post so it falls in line with when the build actually happened, not when I wrote it ( which was now). Click through to read all about it.
So… this is one of those posts I have been needing to do for a long time, but when I looked at the project I kept asking where the heck does one even start? The majority of this was built around May of 2015 and I will be back dating this post to reflect that. The wording is written as if I wrote it back then to keep the tenses at least a little bit proper, but as usual, grammar police be warned… Dangerous reading ahead. Also, this was a project that had many areas being developed at the same time, so while I will try to write things as linear as possible, it will not be, it can’t be, and it wasn’t. Now on with the show…
A couple of years ago I built a camera slider for my brother based on a design by J.G. Pastorjak. While I was doing the research about how to build it, I decided to build one for myself as well. This was a simple slider which worked very well, provided some wonderfully smooth video, and I have used it a lot. The time-lapse community have made several advances using sliders. Shots in which the camera is actually moving in during the time-lapsed event. It’s very complex and beautiful movement. While I suppose this could be done without computer / machine control, someone is going to have a really bad day trying to do it. I have also been following the work of some of the higher end commercial slider systems which not only moved the camera within the time-lapse, but it also included automated pan and tilt. These were the sorts of goals I wanted design and work for. While I suppose I could have saved some money and time and just bought the dern’d thing, that’s not how I tick. More, I didn’t want to be limited by the features that someone else dictated to me based upon some sort of pricing structure. I want to understand it, explore it, and most importantly make it my own. I did a ton of researching and reading trying to find answers and solutions. While I found a few people who have ventured down this alleyway, I couldn’t find anything like what I was personally imagining, or wanting.
A few items which I wanted (the basics)…
- Pan, tilt, and slider (duh)
- Must be self contained.
- Must be able to be used for both video and stills (time-lapse).
- Should be easily convertible for new features.
- Should be smallish in size.
- In stills mode, the controller will also trigger the camera shutter.
- I wanted to reuse as much as I could of the slider I had originally built.
Then there were the constant burning questions which gummed up the process…
- What type of motors should I use? Stepper motors, standard motors with some sort of encoders, servos?
- Does the slider engage with a ball screw, rack & pinion gears, or belt feed?
- What materials would I use for the slider, the deck, the moving bits?
- How would the pan and tilt actually work? Belt, worm gear, direct drive?
- If it was self contained, how would I control it (without needing a laptop)?
- How would I power it?
- How would I connect it to my camera (shutter release interface)?
I usually have 4 – 5 projects brewing at any given time. Probably more than that if I am being honest. Most of the time I will hit some cliff of impossibility or creative wall and stop that project for a while. I will then work on another while I mull over the issue. I am not an engineer by trade, but my engineer friends tell me I am one, just minus the degree. It’s just how my mind works. These problems are like brain puzzles. There has to be a solution, so sometimes I will plow into a project without fully knowing if it will pan out (pun not intended). This project was no different. There were some pretty hard issues to resolve here. It covered so many areas of discipline… Mechanical, structural, electronics, programing, and general artistic aesthetic.
My thinking was that I needed to work on the slider trolly portion (called the ‘slider’ from here on) first because if there’s no slider, there’s nowhere to place the motors, or camera. Pretty straight forward, right? I am sure that this is going to start sounding very circular, but stick with me. One issue I had with the original slider is that it could get a little wobbly if I got some weight on it. So I decided to re-deck the slider for extra rigidity. I started to think about what size the deck would be and realized that the deck would be based upon the distance between the rails + the width of the wheels + a little extra for fine tuning. It then occurred to me that if I am cutting the deck out, I also need to think through where the pan and tilt would live on that deck. If the pan and tilt are on the slider, then the motors will also be on the slider. If the motors are on there, how do I get wires to it. Wait… if it has wires and it is spinning, how do I keep them from getting caught up on itself. In the end, I realized that I was going to be designing the whole pan, tilt, deck, and slider assembly at the same time.
While the Shapeoko II is an amazing machine and is completely capable of making beautiful things, it’s not a exactly speed burner. When cutting aluminum, parts could take up to 4 hours to cut out. With that time commitment, I didn’t want to remake parts if I could help it. With this in mind, there was a lot of benefit of thinking through the whole mechanism. I was using Draftsight for the design. Sometimes the hardest part is starting. Where do you start? Eventually I just started placing design ideas with rough spacing. Once I started seeing something I liked, I then started taking measurements and dialing it in. This of course meant that lots of things needed to shift, but the idea was there.
I started work on the base of the slider system. This means the end caps which would support the rails on which the slider would slide… upon. My previous slider rails were 1 inch square aluminum tubes held together with 2 – 6 inch pieces of “all thread”. This put a 3 inch space between the rails. While this worked, as I mentioned earlier, it had the tendency to be a bit wobbly once you got a camera and head on it. To make things worse, the original rails were the stuff you find at Home Depot which had very thin walls and HD don’t tell you what grade of aluminum it is (several threads on the internetwebz says box stores are selling generic low grade 5052). I called and talked to a woman who said she would find out and get back to me (I am still waiting). I bought a new set of rails from Metal Supermarkets which are quite thick, and if the web is correct, a superior grade of aluminum (6061). I bought the new rails for less than the cost of the thin stuff from the HD (makes one think).
While it is not a huge increase, I spread the gap between the rails from 3 inches to 4 inches, hoping that the strength and extra width would make things more rigid. The rails are held together with custom aluminum brackets or end caps (no, I haven’t come up with an official name for them). These brackets were milled out of 6061 aluminum. Actually I’ll just place it here… everything on this project was 6061. It’s super strong, light weight, and can be machined well. The caps are a half inch thick which is probably a little bit overkill, but I don’t have to worry about them bending anytime soon.
The caps have threaded holes in the leg sections in which leveling screws could be placed to allow the slider to be stabilized on just about any surface. They also have a set of holes for M5 screws to tighten down on to the rails, locking them in place. This is important so I can break the system down quickly and easily. There’s a notch cut out dead center to receive various types of mounts which can be screwed into (motor, pulley, etc.). I didn’t build any of these additions to be permanent (although they could be) as I wanted a test bed for further ideas after the slider system was complete. The pulley end plates have a recessed cut pocket for a bearing and a small hole in the center for a M5 screw to pass, through a geared pulley in between, through a second bearing, through the top plate which is then secured with a washer and locknut. There are 3 holes around the outside for m5 screws and a bushing. Once the bushings are in place the whole thing sandwiches together and locks tight. The other end cap holds a fixture which holds the slider stepper motor. Again, this is attached via 2 – M5 screws.
I am not going to go much into the angst and back and forth I went through trying to make some of my final decisions on various various parts unless it is absolutely necessary. Otherwise this will become a silly long blog post (which is already a bit too long), and you dear reader would probably need some serious therapy as a result. I settled on using stepper motors. Steppers offered me the assurance of repeatability and strength. For some effects work I am imagining, I will need to repeat the exact same move, over and over, many times. I need the camera to match up both in time and spatially, so exact repeatability is critical. The steppers I am using are Nema 17 Bipolar 64oz./in. and provide 200 steps per revolution. This accuracy can be expanded by microstepping which splits each main step into smaller sub steps. The number of microsteps really comes down to the driver one chooses to use. Initially, getting up and running, I am using some of the super cheap knock off A4988 type drivers (There’s a lot of money falling into this project, so inexpensive while prototyping, yeah?). These are suppose to provide up to 16X or 3200 microsteps per revolution. The only problem with using microstepping is that I loose some holding torque when using higher levels of microstepping. This is not a problem if the slider is on a level surface, but it could potentially slip if I am trying to have the camera climb. So… build it, see what it can do, and update it as necessary.
At this point it was time to get at least a basic amount of the automation work started with the current slider and the new rails. Clearly this would be a microcontroller driven thing. My go to microcontroller is of course the Arduino. I knew it would be more than capable of the movement as that’s what’s driving my Shapeoko, and if you think about it, this is really just a CNC machine with a camera attached. Getting the stepper going was not too hard, while getting it moving smoothly, was. Let me rephrase, the linear movement was perfectly smooth. It was just getting an object to ramp into up into motion without a heavy jerk was somewhat problematic. Software can be fixed. Mechanical issues, would have needed to be tweaked and rebuilt. Being that this was a software thing, I moved on. Eventually I found an Arduino library that let me set a specific distance and it would ease in and out of the movement. The video below shows that progress. I am sorry for the crap quality, but at that moment, it was very exciting and I wanted to capture it’s first real steps. The belt was attached by being sandwiched between a couple washers and screwed tight. A more permanent solution was designed for the new deck, but hadn’t been cut out yet.
Below is a video of the first bits I shot with a camera, the new end caps, new rails, pulley and motor mount, but with previous slider. I was grilling out on back porch, so I figured I would take out slider and give it a try in between burger flips. While it’s not an Oscar winner (nor all that entertaining), you can see that it is very smooth. Speed was not the goal here. I was curious (concerned) to that I would see stutter(ish) motion artifacts at really slow speeds caused by the stepper’s movement which by it’s nature is based upon pulses. Would this translate into the video? I was really happy to find that it was buttery smooth. I will point out that at about 13 seconds into the video, you can see the image shake. This is a result of the sudden jerk into motion when the slider started to move. This was before putting on the new deck, so effectively the camera was suspended over the center of the slider (only connected from one of the sides). I had to detach the deck from the other wheel fixture due to the wider width of the gap between the rails. The new deck helps this a lot, but again, this is why I need to get some easing worked into the motion portion of the programming. Smooth movement from a stop, up to speed, then smooth slow down, and stop.
The motors somehow need to connect to the slider if things are going to move, right? I decided that it would be belted gears. The idea being that I could tension the gears and motors after building everything. I can also re-gear things if the movement is too fast or slow. While I am all for building my own things, there are some items in which I felt there was no need to reinvent the wheel. Gears, pulleys, and belts need to be exact for things to run smoothly. Most of these types of items I purchased from Servo City as they have some really beautiful stuff. Everything else was built from scratch.
The center point which ties everything together, is the deck. The deck was designed with attach points all around it in the form of tapped holes, so that there would be gobs of options. While I am not sure if this was a good idea or not yet (only time will tell), but I made all the hole spacing on one deck axis in inches, and millimeters in the other. My thinking is that perhaps someone would produce something I might want to attach, so why not try to make it somewhat universal. I have been trying to keep everything I build as metric, just because it’s wonderful to work with, but made an exception here. The deck also has attachment points for the wheel rigs. There are points for the belt connection plates and a finger hole for tensioning them. The belt connection plates are what physically attach the slider to the stepper. The belt is easily fed through these slots in the plate, but once the belt is tensioned, there’s no worry of it slipping back out. These are held in place with M3 screws.
I am currently shooting with the Canon 5D mkIII and Panasonic GH4, so I have built the slider around the 5D as it was the bigger of the two. This thing is going to be carrying a lot of wiring which has to reach from the outside the slider all the way up through the pan and tilt arms and up to the camera. I concocted a number of ways to do this, but they were all limited in some way.
Then I had an ‘aha’ moment. Adafruit announced a slipring wiring harness. While this product didn’t make it very far in my design, it was the idea of the wires being integrated into rotational axis that got me. The reason being is that I could do a couple of rotations without causing harm. I started digging into the ServoCity site and on paper put together a stack of items which would provide this cored rotation.
The item the brought it all together was a set of crazy thin bearings with a huge center bore. These were used on both the pan and the tilt axis. The tubes were flanged on one end which provided a base to which everything could stack and lock to. I will try to explain the stack, but it’s a little convoluted in text. For the rotational base, the tube was fed through a hub which would lock onto the tube. The tube is passed through a large pulley and the hub is screwed to that. The tube is then passed through a very thin plastic washer, and then one of the ultra thin bearings. There are 2 milled plates which sit on top and underneath the slider deck. These plates have pockets cut to exactly fit these bearings. These plates are bolted to the deck to provide a secure rotational center. The tube coming out the other side of the slider deck and bearing plate is then passed through the second bearing, through a plastic washer, then the bottom hub lock. The only difference with the tilt axis is that the tube passes through another inside riser piece which ultimately connects to the camera plate. I am sure that this was a bit hard to follow, so hopefully the photos spell it out a bit more clearly.
I wanted the pan to around the nodal center of the lens. If the lens sits too far forward, a pan can feel more like a swing. Being that different lenses would have different points, I have built in a a slot to allow for forward, and backward movement. I also built in the ability to put the camera plate at several height levels so I can change how the camera tumbles, or allow space for an extended battery pack. Basically I built in a ton of options I which I might or might not need, but wanted the option. I also added many spots for other things to be attached, and wires to be strapped to. Zip ties will keep things wired flat to the plates and I have cut slots which the wires can cut back and forth to stay out of the way of the rotating arms. I am making this sound somewhat easy, and it wasn’t. There were several attempts on a couple of these parts which ended in sadness due to unforeseen spacing issues, bearing pocket being on the wrong side of the piece (I was trying to do some 2 sided milling which is quite difficult to do and keep things perfectly aligned).
Meanwhile… Back at the batcave… The previous video was being controlled from my laptop. I needed a way to control this thing remotely. I wanted both immediate physical control (joystick) and programmable control for repeat performance. I needed something which could provide visual feedback as well as let me know the status of the system. I decided to use a 4D Systems touch screen instead of a bunch of dedicated physical buttons and switches. Sure… why not throw in a whole throng of unnecessary hardship in my path when I could have just made life far easier with physical real world things… but no, I had to go way too far off the deep end and go all touch screen.
Well here’s the thing… I had purchased this one of their displays about a year ago and never used it for the project I intended it for. I needed to use it because it was stupidly expensive and I didn’t want it going to waste and it seemed to be the type of project which lent itself to perfectly. I used a plastic project box to contain it all. I designed the interface in Draftsight, and let the Shapeoko have at it. I used blue painters tape to help prevent rip-outs and to keep the surface clean. I then used some of my 80’s Tetris skillz to get all the shapes to fit into the box as tightly as possible as there was not very much room. There are a couple of switches. One is for the basic Arduino power and screen, then the second is for the higher voltage for the motors which would be supplied from the LiPo batteries used for RC aircraft. The second switch would also act as an emergency stop in case I needed it. It is an automated device, and I didn’t want to let a robot run without a way of stopping it dead in it’s tracks. Eventually I got it all packaged in the box. The problem I encountered was that updating the code now also required taking part of the box apart. While this doesn’t seem like a big deal, I am really scared that the universe will discover that I had too much mater in one location and result in an explosion of some sort. Taking the box apart just exposes a lot of fragile things to danger, and I once you have come this far, having an accident could result in a lot of time / money trying to fix what usually comes down to a moment of stupidity (I live in a house with a giant golden retriever which has a tail with a striking force of several thousand pounds, capable of destroying most things in it’s path, let alone also the potential spilling drinks and or other liquids one wouldn’t want on their electronics).
One of the hardest parts of all of this was the programming. I am not a programmer, but I do what I need to do, and learn what I need to learn to make things work. Most of the time, and especially in times like this, I was way out of my comfort zone. There were two sides to the programming. One is the Arduino code itself which is hard enough, but then there’s the LCD code. There’s also the design of the LCD. The LCD is touched which in return sends commands serially to the Arduino. The Arduino then goes to town on whatever I told it to do and sends feedback back to the LCD. The LCD then interprets what was sent, and displays this on the screen. This back and forth pattern must be thought through and as I found out the hard way, you really need to have all your wants and desires planned out. For some reason everything is numbered on the display and if you delete something, or add something above an item which was already there, you can not renumber the items, it just becomes the next in line. This becomes very confusing when you are trying to program some very odd stuff to start with. Many times, you are unsure if it is a coding mistake, or a numbering mistake (which yes, is coding, but not the structural stuff). Everything for the display is loaded onto a microSD card which is inserted into the display. If you are developing for it and trying to get code working, you render the code and graphics onto the card, eject the card from the computer, insert it onto the display, connect it to the Arduino, turn on the Arduino, test and realize that things are not how you envisioned them to be, shut everything down, disconnect the monitor, eject the card, put it back in the computer, choose the windows side of the Mac, go back into the 4D software, tweak, and repeat. But the up side, is that you have a touch screen interface in a fairly short amount of time. Once the touch system and Arduino was sorted out, it was time to get the cameras working with the controller.
Having worked on my Blackbox Camera Controller (yes yes yes… blogpost forthcoming) several years ago, I was somewhat familiar with how to trigger a camera. Well… I was familiar with how to trigger a Cannon, but not so much with Panasonic cameras. Cannons use a 5 pin cable which works by closing a circuit to trigger the focus, and closing another circuit to trigger the shutter. The I found that the GH4 was not at all the same. It uses different ranges of resistance, or better said, different ranges of voltage to trigger various functions. The resistance was the part I needed to sort out. While I found a couple articles on line, it was a little interesting getting it to work.
So where does all of this lead us? It leads us to machines taking over the world. Bow to your new masters. When you start to see a project like this come together… there are just no words. You turn the thing on, put in the settings telling it how you want it to behave, and then you press go. After that, it’s just doing what it was told. For the timelapse, I usually have it move, then settle for a second or so (we want a nice sharp image). Then it triggers the camera to shoot an image. Currently it is all set in camera, but changing the length of the exposure would not be difficult, it’s just setting a longer delay between the pin high and pin low. At this point, I could just put the camera into a bulb mode and let the Arduino drive the length. This will be great for things like sunrises where the light levels will change quite a lot. Back to the sequence… Once the camera has fired, it starts the cycle over again. It can be set up for how much distance it moves between images as well. Currently I have the slider working and the pan and tilt are on hold. I built a center disk specifically to take a camera head. I needed to get this up and running for a project we were working on at work. So, I made a major push to get all of this done in my evenings after work. Most of this came together within about a month and I was working on the programming up until about 15 minutes before the first shoot we needed this for. It was a really tight finish. But the video turned out beautiful and our people loved it. After our convention, I was ready for some down time, so what does a technonerd do? Yeah, takes all his camera stuff and heads out on vacation. Here’s a short video I shot from the back porch, again while I was grilling (seeing a trend here?).
The next thing on my list was getting some air moving over the shield. While I understand that they will run hot and have become okay with the idea (sort of), I still want to take care of it. So I set off to cage the Arduino and shield and make a pseudo cooling stack sort of thing. I had some acrylic left over from another project years ago. While not a crazy hard project, this is my first venture into making something where all the parts really needed to line up. I designed this in a couple of hours in Draftsight. It probably would have gone faster if Game of Thrones was not on. I went through a time where I was buying all sorts of things from garage sales so my son and I could take them apart and grab the goodies inside. I am not sure what it came out of, but I had a 24V fan which I wired into the V-In on the shield. It moves a heck of a lot of air.
I cut’er out and put it all together. I was really pleased how close everything came out. Projects prior to the Shapeoko always ran the great possibility that come assembly time it may, or may not come together all together well. This was precise.
This year, I took the year off of building a car (not by choice). Instead, I took the helm of the whole Pinewood derby. It may surprise you, but the pinewood team (our pack’s leadership) actually spent a considerable amount of time discussing how we could make the whole PWD a smoother experience. This includes everything from the (pre) registration, to the weigh in, to the event it self. When my son was in his first year of Cub Scouts, we just showed up under the delusion that these things just somehow happen. It was really amazing how much time we all spent working on all the little details. We wanted it to be the most massively fun experience possible for the kids. It was an extremely successful and positive night for all.
Being techie by nature and profession, I have been adding more and more technology each year. My focus has prior to this year has mainly been on the extra stuff. You know, all the techie stuff not related to the track. This year was really over the top. We were using 3 projectors sporting racing software, custom ‘Christmas tree’ racing software, and Pinewood TV. We used a full on sound system with speakers all over the place to envelop the spectators and bring them deeper into the event. It was probably overkill, but so worth it.
Last year (2011) we had a fairly serious glitch. The racing software would not communicate with the track and the track stopped… em… tracking. It was an all out frantic search for paper and pencils and trying to decide how to run the race off of paper. In reviewing the issues, this came from an incomplete understanding of how the system worked, and the ins and outs of the race software. Being that I was responsible for the running of this thing, I was going to understand it. Ultimately I found that it all came to a dead halt because of 1 silly little teeny tiny switch. When I meter’d it all out, the switch would not ‘close’. In English, it would not reset the track. If the track is not reset, it (the track brain) stops sending information to the computer. The switch was totally FUBAR. It looked fine. It clicked fine. But when I metered it, there was NO internal connectivity either in the open or closed set of leads. Not sure what happened, but it was done. To compound this when I looked at how it was attached to the track, it was loose (floppy loose), and poorly placed. I decided to re think how it was built. I replaced the switch with a new one, and moved where it was located. I made sure that this was a really solid placement. More, there was a lot of mechanical movement in the area where the switch lives. A lever holds the starting pins in place (The starting pins hold the cars in place at the top of the track). When this is released, several fairly heavy springs on the back pull the starting pins causing them to slam down and under the track thus releasing the cars. There was really no need for so much travel, nor that much umph ( from the springs) to get it there. This was solved with a strip of squishy foam cut down to fit in the little void behind the starting pin block. This reduced the jarring ‘clack’ down to a gentle ‘doof’ as well as reduced the vibration and stresses placed directly on the switch.
I was feeling some pressure to make sure this thing rocked, so I took some time to learn the racing software inside and out. As with most cottage businesses, the pinewood software started because a den dad had a need and a skill set to match. He started writing the software and it has been growing ever since. While looking through it, I found that it was actually very well written with lots of great features. More, I found out that we could have actually used it during last year’s emergency using a points system mode vs. the time based races which we were using. But one can’t change the past. Oh well. Trying to be prepared in case the worst happened again (which I was nervously confident that it would not), in addition to the software, we were armed with mass preprinted spreadsheets and pencils.
Another upgrade I built last year was the ‘ready’ system to help simple communication between the cogs of the race. When it is loud (crowds of kids and mass excitement), it is hard for the emcee to know if the cars are ready on the track, or if the computer people are ready for the next group to run. So I addressed this by building a ‘ready’ system which would seem natural, but served a very important function. I started by writing a couple of programs in Processing and the Arduino that would simulate a “Christmas Tree”. Instead of cars crossing a line (telling the computer when it could start) in a real world drag race, I made a button box which sat at the computer position and one start of the track (for the car set up guy). When the computer (pencil and paper) was ready, they would hit their ready button. The same went for the car set up folks. When and only when both groups were set up could the race begin. This was all interfaced through an Arduino into Processing. The races were started by the car set up person. The lights would run the way a real Christmas Tree would run, and when the green lights hit, they would release the cars. This was all accompanied by a ferocious set of sound effects to match. So when they would hit their ready buttons, engine sounds would rev (it was loud and deep enough you could feel it in your chest). The race would start with the Christmas tree lights on the screens blinking down, accompanied by beeps (remember the sounds from the start of the video game Pole Position (if you are old enough to remember) Boop boop Boeeeeeeep!). At the green lights, the sound was of screeching tires and wild engine sounds . When I did the sound design for the audio side of things, I panned the car racing sounds so the sound actually attempted to follow the cars on the track. A PWD race is really only a couple of seconds long, so I faded the race off into the distance. Lastly, there was an emergency stop button on both button sets. This was for moments where some unforeseen ‘thing’ might pop up. Either party could press stop and it would kill the sound and reset the display. If the emergency stop was pressed, I used this cheesy VW Bug ‘meep beep’ noise. In contrast to all this crazy high powered stuff, this rather anemic sounding car horn added a touch of humor. It all worked out very well. The whole thing was put together in a couple of days. It was butt ugly, but it worked wonderfully.
This year I improved on the system quite a lot. I did three things. I built the system to be more rugged, added lighting effects, and added automated starting of the races so it completely sync’d with the sound. I gutted the cardboard boxes used last year and bought some electrical wall boxes. These were spray painted black (because black looks cooler than blue). Instead of using a standard wall plate for the buttons, I made clear plexiglass covers. I have been talking to the boys about how electronics live all around us and I wanted the kids to be able to look inside the box to see what was making this thing tick. I also reduced the project to a breadboard so they could see how robust a prototype could be (it doesn’t always have to be perfectly printed circuit boards all the time). I found some wonderful reflective yellow and black warning tape at Harbor Freight. This was placed on the boxes which did a killer job of making them look rather menacing. I also added a clear red start button and inserted a wicked bright led so that when the race was set up and ready, it would blink bright red for all to see. The 2 button boxes were connected to the main box via Cat 5, so set up and tear down was super easy.
For the automated starting of the races, I bought a solenoid from Sparkfun and built a little mosfet circuit to run it (also housed in the main circuit box). I used one the ears off of a set of server rack rails to mount the solenoid to. Without mutilating the track (which was out of the question) there was no way for the actual solenoid plunger to reach the release lever (which drops the pegs which hold the cars in place). I made a little whachamacallit to attach to the plunger so it could reach up and wrap around the lever. This was cut out of an old metal computer case (my go to material for all my little metal whachamacallits). I did not want to manage multiple voltages (a 12v system system for lights, and a 24v system for the solenoid). I found that I could under powered the solenoid with 12v. With 12v it had just about enough push that it came pretty close to releasing the start lever as is, but it was not quite enough on it’s own. The solution came through many of the methods used to get PWD cars to run faster. The movement needed to be slicker and smoother. I used a heck of a lot of graphite on all connective surfaces, and minimized any points of friction by sanding a filing my plunger widget completely smooth. These modifications were very effective and the release was flawless. During the PW derby itself the mechanism only failed 3 times during the 100+ races, and 2 of those were due to user set up mistakes. Sorry for the braggin’ moment there, but rarely do projects work that smoothly. I had to take the moment when I could.
For the lighting, I added a 5 meter strip of RGB LEDs. This was controlled by the same Arduino (actually BoaArduino this year) as the button system. I had to move a couple of pins around from last year as I needed the PWM pins for the LEDs. The track is made out of aluminum which takes light very well. I suspended the strip about a foot above the track. When the ready buttons were pressed, the lights would rev up to match. When the race would start and the lights would blink in synch with the sound which would be in synch with the screen. When the lights went green on the screen, the track would go ape dooky with a strobe of green and bright white. Then when the racing was finished, the lights faded down to red, then down to dim red. If an emergency stop was called, the lights would sit and blink red on and off for about 4 seconds like hazard lights.
Mentioned above, we also had TV. I brought in a small video switcher (straight cuts only, nothing fancy). I made a 5 minute looped graphic video of racing flames, checkered flags, and a logo. This would play on the screen in between races. There were 2 track cameras. One pointed up at the starting line. This was suspended right over the track on a sort of wood bridge that I made. This was a great shot. You could see the race start and then the cars would fly right at, then under the camera. the camera lens was sitting just 2 inches above the maximum height allowed for cars. (The 2 extra inches was so that I would not get yelled at by some parent who thought that I had somehow had lost their kid the race. While the PWD brings out some of the best qualities in a kid, it brings out some of the worst in some parents (Just sayin’). The second camera was placed at the end of the track to catch the cars as they went through the finish line. My son actually did the video switching for the night and I must say, he did a great job.
You can not pull off something like this without a great team, and man, all of our Pack 553 leaders stepped up and helped out wherever needed. We started the load in and set up at 10am (the morning of the event), and finished about 5 minutes before it started. While everyone was working hard, no one was rushed. We just did everything we could while we could. After the PWD, it came time to tear down and pack up the car. I will tell you that everything in that room (aside from the track) fit in my Prius. Granted, it probably would have popped if I poked it, but it handled the load.
I have been a fan of weather and storm watching since I was a little kid. It really all started one night when I was in bed in the midst of a wild thunderstorm. I was awake and frightened and thought everyone else was asleep. I heard a noise, and as kids do when they can’t sleep, I went in search of what I was hearing. It was my grandmother. She was standing by the sliding glass window watching out across the lake. I went and stood next to her. I told her that the storm was scaring me. I asked if it was scaring her. She said no. She explained how she loved to watch the storms. We sat there together not really saying a whole lot, just watching the storm. Occasionally we would comment about the lightning or thunder hits. I forgot to be scared. It turned out that I wasn’t. I was amazed.
I have been in many storms since. I have been closer to tornadoes that I would have liked. But all in all, I am still fascinated by the storms. Since I started learning about the mircocontrollers, one of the earliest ideas I had was that I could somehow use one to measure the weather. Early on I did not know how to go about it. But as I have been exploring new areas of technology, as well as learning to build, building, and crafting new things I am starting to understand more and more what can go together. It is somewhat freeing actually.
So, weather. Where to begin. Starting with my most basic needs, I need to know how fast the wind is going and from what direction. I decided that I wanted to build an anemometer. There are several folks on the web who have built them, but true to form, I did not see one that sort of suited me. (What can I say, I like making my own stuff). So, I started to play with different ideas. I still had several skateboard wheel bearings from the windmill, but I have found that those will rust when exposed directly to the elements. I could use them, but they would need to be shielded. I wanted to integrate electronics so I could measure the speed. I wanted it to be cheap. I wanted it to be repeatable in case I wanted to do it again.
PVC is a great, low cost, experimental building material. It can be cut, shaped, sanded, and painted and put together in countless ways. It’s like Legos for Adults. The way I decided to approach it was to have a cap suspended on top of a smaller cap. The outer cap would need to freely rotate, yet stay connected to the inner cap. An issue I ran into was how to drill a hole in the exact middle of the pvc cap. I have no good scientific answer. I used a ruler and marked lines across the dome. I kept doing this from many angles till one spot showed it’s self as the center. I used a 1/4 2 inch brass bolt. I used brass as this is what they use in toilets and figured it would be outside.
The bolt was put through the end of the cap and nut tightened in place. Before I get too much farther, I should mention that I fit everything together to make sure it all worked then went back and epoxied all the non moving bits. I drilled a hole in the middle of the smaller cap and widened the hole until the ball bearings fit snugly inside. I put the outer cap over the inner cap and added another nut to the inside of the smaller cap to hold the two caps together. The 2 nuts sit directly on the inner rim and not the sleeve of the bearing. Being that the outer rim is firmly attached to the smaller cap, the inner rim spins freely. BTW, something that I did not take into consideration was how to hold the nut as I was tightening it. There is no room for fingers in that small of a space. Needle nose pliers helped out here, but it still was not easy. If you are asking why, remember that the tighter that the nut gets, the further down the large cap gets, which means you have nothing to grip onto after a while because the outer rim spins.
The next issue I needed to figure out was the scoops. I have seen all sorts of ideas ranging from as simple as easter egg cups to folks who have custom machined their own. I wanted something bigger than easter egg shells and far less complex than machining. I could use a makerbot and make whatever shape I wanted, if I had one (Man oh man, I want a makerbot). One day when trolling the dollar store (a good source for budget makers) I saw a huge display of big plastic spoons. After being an ass and asking how much they cost, I bought 4 of em’. I bought 3 for the build and one to goof up. Not long later, I had the handles removed and ready to attach.
I used super glue at first, but it really did not work well. Epoxy eventually was the right solution. But how does one hold a salad spoon to a round spinable object until it hardens in place? You get comfortable because you are not going any place for a while. With all the goofy angles, there was not a good way to clamp it. Fortunately is was 5 min. epoxy.
For the electrical part of this, I took apart a relay I had in my kit o goodies. If you gently pull on one of the ends of this variety, the glass reeded vial will come out fairly easily. I soldered wires to the leads and covered them in heat shrink to keep the water out. I epoxied the reed to a groove I made on the outside of the inside cap. (clear as mud?) I drilled a hole in the side of the bigger cap just big enough to push a little magnet into. The magnet trips the reed which gives you your pulse for your uC (microcontroller).
The wind vane was dome somewhat similar. But, to make the assembly a little easier (which occurred to me after putting together the anemometer, I bolted in reverse this time. I had the bolt come out of the top of the big cap. Something I did not realize when I started on the arrowish part of the vane was that the 2 sides had to be of equal weight. Who knew. I cut it all out and epoxied it to the cap. It was locked in and when I went to test it, it sort of lazily flopped around, but did not really head into the wind as I had expected. I am writing this some time afterwards and seriously have no idea how I solved this one, but I found that balance was the key. I some metal bits, but it was not enough. I started looking for small, really heavy stuff so I could balance the thing. I remembered the fishing weights we had used for the pinewood derby cars. I cut a slit down the middle of a large weight and epoxied it in place. The vane came to live. While it is ugly as hell, it effortlessly moves about when even the slightest wind is present.
So, it was pinewood derby time for the Cub Scouts again. My son’s pack has a race for the adult kids too. I had been plotting my car since last years races. I wanted to really light the thing up. Last year I had working head and tail lights, but this time I wanted bigger and better. I was just not sure what form it would take. I had considered many options. The most predominant idea was using an accelerometer to change the light settings based on force. The problem was that I wanted the lighting to stay very minimal until race time so that the surprise factor would be maximized. I was leaning heavily towards the Arduino Pro 3v due to it’s nice and tidy size. After more thought I started heading away from the accelerometer and started thinking about using an XBee to control the Arduino remotely. Then while shopping at Sparkfun one day, I stumbled upon the Funnle IO board and that locked the plan together.
Funnel is an Arduino based board, with the added benefit of having an on board Xbee socket. Plus it is tiny, has a 3.2v line in (for LiPo), and a LiPo charger onboard too.
I ordered the stuff from Sparkfun and started designing the circuits. The mental picture was to make 2 stripes that ran down the sides of the car. These would be able to blink, pulse, fade, and ripple. Then on the 4 corners I wanted to have a very bright strobe light effect that would strobe at about 1 pulse per second. The idea was something like a jet preparing to take off and the taxiing lights. I put together a breadboard mockup. I decided to use the 6 PWM outputs for the stripes. This way I could make them flow however I wanted. I worked on many different ideas for making a slow PWM roll. I finally found that to make the lights really roll along, I needed to have more than one set as the rolling motion is much more pronounced when repeated in a longer strip. The thing started to take form.
I decided to use 3 sets of 6 LEDs on each side, but instead of running down the sides, they would actually sit on top of the car like some evil menacing engine. I did not want big bumpy 5mm LEDs all over it (which actually might just be cool), so I went with surface mount. All the LEDs and resistors are 1206. 36 LEDs at 20ma each would easily exceed the max draw for the Funnel, so I built a driver board to take the load off of the FIO. The driver board was nothing fancy, just a few small 2222 transistors (sot-23).
One thing I had a great amount of fun with was designing empty spaces on the board. Once the board was designed, it was quickly clear that though functional, it was hardly cool looking. There was a still ton of blank space, so I decided to decorate the PCB. It was arts n crafts time with Eagle Cad. So, I spent a couple of hours just playing with shapes. By about noon the next day, I had the board etched, and all soldered up, and was ready to start testing. I uploaded the code to the funnel and started to play. I had some problems with one the channels of strip lights. It turned out to be a transistor that was not completely seated on the board. It looked soldered, but when I heated it up and pushed down on it, it just sank. It was a quick fix and it worked great from there on out. I made sure that the xBee was working, but mainly stayed on the ftdi cable during the remainder of programming and testing.
After designing the car, I needed to route out the innards where everything would fit. This was a little easier on paper than it was in wood. Eventually, it started to come together. Making a long story short, I got everything together and it worked great. This was my first real Xbee project. I really liked that I got feedback from the car which was sitting like 60 feet from me. Of course I had to program the Arduino to do so. All I needed to do to trigger an effect was just type a letter into the serial command box in the Arduino IDE. I had about 14 different things I could have it do.
Edit: (News) – My car is on Sparkfun’s Front Page!!! Call it my Andy Warhol 15 seconds. :0)
Edit: (Clarification) – No, I am not employing a “joule thief” circuit in the car. We get to name the cars, and I felt that the name fit. Some folks have asked if this is an “official scout issued” PWD kit. Yes it is, but I used 2 kits. The finished car is legal weight, but just scraping by. The wood weighs almost nothing as it is more or less, a shell. When I weighed it after finally getting all together, it was over by quite a bit. I had to hollow out just about every place that was thick enough to be drilled. I avoided the spaces right around the wheel grooves as I did not want it to bust through during the race. If you look at the front picture on the video, in the reflection in the glass you can see where I had hollowed out the sides. Drilling a car that was already completed was a pucker factor of about 12. I really thought I was going to blow out one of the sides. But even that was not enough, when it raced, it did not have the left screw in place as it pushed the car over the legal weight of 5 oz..