As the W&B soda machine has been unplugged for the winter, I am putting the soda machine hack project on hold for a couple of months. In the meantime, I’m returning to some past projects, several of which I never wrote up in the blog. One such project is a system for handling and displaying an ultra-tiny bitmap font on a little graphic LCD, the sort that were on nearly every 90s cell phone and are currently popular with hobbyists.
After some modifications to the design and some tweaking to the print settings, pan/tilt rig version 2.0 is a success. At a marginally lower extrusion rate and temperature, the accuracy was greatly improved — this version was much less “lumpy.” This improvement turned out to be somewhat of a mixed blessing, however. The first draft ended up being slightly too small to fit the servos, so this version was scaled up by 10% prior to printing. Combined with the improved precision engendered by the print setting tweaks, the final result ended up being a bit too loose to grip the servos with friction alone. A small rubber band around each holder keeps the motor nicely in place, however.
(more…)
I made my first tentative steps into the world of desktop manufacturing last night. Having a couple of small servo motors, I thought it would be cool to make a tiny pan/tilt rig with them. I also thought this would be a good first 3D printing project. A couple months ago, several of us at W&B got together and built a Makerbot*, a small hobbyist’s 3D printer based on the RepRap project. Like RepRap, the Makerbot fabricates objects out of extruded ABS plastic, the same stuff of which LEGO blocks are made.
The Makerbot fabricates things by laying down a thin bead of molten plastic onto a small platform. The platform moves in two dimensions beneath the extruder, creating a cross-section of the model being built. After one cross-section is complete, the extruder rises and the next cross-section begins. It is a little like creating something from cake icing — I wonder if that’s the origin of the Cupcake name.
(more…)
I was thinking about ways to create multiplayer games/toys using the Arduino platform and realized a key difficulty: telling different Arduinos apart when there are more than two. Optimally, the system should not depend on one Arduino being the ‘boss’ and should be as simple as possible for the programmer. I think I have a solution.
This is the idea: modify the pre-compiler (or, more specifically, the IDE code that calls the precompiler) to automatically include a #define statement, defining MY_UNIQUE_ID as the last sixteen bits of the build time in milliseconds. The chances of two Arduino builds being done in the same thousandth of a second are extraordinarily low, effectively making the ID unique for all practical reasons. In the code, all the programmer needs to do is use MY_UNIQUE_ID as a variable.
I’ll have to take a look at the Arduino IDE source.
Update (9/24): A couple of people have commented on this on Facebook (where this appears via RSS), suggesting some dynamic, real-time solutions. These are good ideas, but the situation I was imagining isn’t one in which all the points would have access to each other simultaneously; instead, temporary connections are being made between units, probably by physical contact.
Since I’m trying to update my project blog to reflect what I’m actually doing, I thought it worth mentioning the workbenches (and now shelves) I’ve been building for Willoughby & Baltic, previously posted only to Facebook.
(more…)
A random train of thought lead me to considering the way some first-person video games represent wearing a gas mask or a space suit with a goofy drawing of the mask or helmet’s eye holes, the same way images through binoculars used to be shown on old TV shows. Limiting the player’s field of view may have a practical purpose (e.g building suspense), but the depiction is so unrealistic that it breaks the suspension of disbelief. To see the individual eyeholes in a helmet, they’d have to be several inches in front of your face.
An alternative: border the sides and/or bottom of the screen with a translucent white gradient, representing the wearer’s breath condensing on the glass surface inside of the mask. Wearing a gas mask/space suit in a video game is usually accompanied by the requisite 2001-style breathing sounds; the gradient could contract with each breath and slowly dilate afterward. For added realism, the rate at which the fog clears could remain constant while the rate of breathing (and thus fogging) is based on the character’s exertion, so panicked running around could leave the player momentarily blind. That would work well in a game of the “survival/horror” genre.
Just to see if it would actually work, I decided to build a mock-up of a mechanical spider leg. I simply drew all the components in a graphics package, printed it out, glued it to a piece of paperboard and cut it out with a pair of scissors. I then stuck all the parts to a bulletin board, using backwards thumbtacks for the moving joints and forward ones for the fixed pivot points.
To my amazement, it actually worked. Maybe I’ll actually build the real Spider-Bot.
NB: Despite the date, this actually works.
Andrew Sempere recently credited me for giving him an idea for a pressure sensor he’s currently using in a project. It was something I discovered accidentally, but further research revealed that the technique has been documented elsewhere. Regardless, I still think it’s pretty cool.
I haven’t had much time to work on any of my previously-posted projects in recent weeks (or months, for that matter). I’m just finishing up work for the Computational Art course I started in February; I did some interesting things that I’ll post here once I’ve finished the write-ups. Most notable is a small Propeller-based robot for teaching little kids some of the key concepts of programming. At the moment, however, it’s still more of a sculpture than an interactive piece.
But, on the topic of robots, I had an idea for a mechanical spider and used a little downtime at work a while back to produce a 3D sketch. I roughed out an animation to see how it worked. No, the animation to the left does not loop correctly; I’ll explain that later.
Like almost all the mechanical spiders that people have been producing lately, it’s based on the brilliantly clever Klann Research and Development design. Apart from cosmetic details, I made two small changes:
First, the inner and outer pairs of legs are offset slightly; the inner legs are slightly forward. The mechanical spider design is really more crab-like than spider-like, as all the legs operate on parallel planes. Moving one set of legs forward attempts to give it a slightly more spidery feeling.
Second, the motion of the leg pairs has been offset by 30 to 120 degrees. This was also an attempt to give the ‘bot a more spider-like appearance by roughly approximating the asymmetric gait of a stalking spider. I’m not sure if it’ll work in the real world. Putting the legs out of phase is what made the animation non-looping; the animation would have to be much longer to contain a looping cycle of all legs. Plus, I wasn’t very precise when it came to offsetting the motion, so I wasn’t entirely sure where the loop was going to occur, anyway.
I’m not sure I like the serrated edges on the front of each leg. Most of the mechanical spiders people build seem to have them. I thought they may have a practical purpose, possibly in climbing, but I’m now fairly certain that they’re just cosmetic. But being overdone, I may try to think of something else. I’d also like to make the front and back legs somewhat different-looking; the uniformity is another feature that makes such spider designs look crabby. I might also try to make the inner and outer legs slightly different, should I actually build the monster. I think I could very probably do it; axles and spacers aside, it is designed to be constructed from flat stock of the same thickness, which I could probably laser cut at the Fab Lab in an hour. Preparing the vector files in order to do the cutting would take longer, however.
But, that’s yet another project for the pile.
Last month, I briefly mentioned the serial LCD I’d dug out of storage. I have a number of ideas for it, such as using it as the display for a Python-based MP3 player. Whatever I do with it, however, I need to put it into an enclosure.
A while back, I saw something interesting: the LEGO Quatro system. Whereas Duplo is twice the side of a standard LEGO brick, Quatro is twice the size of Duplo brick. It’s very clever: toddlers can be given Quatro bricks, then use them with Duplo bricks when they get older. The kids can then use the Duplo bricks with standard LEGO bricks when they get older still. In any case, some gargantuan LEGO bricks seemed perfect for some sort of project or another. I didn’t have any specific idea in mind when I bought them, but a pair of 2×4 bricks ended up being the perfect size for the serial LCD.
