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.
In the past couple of weeks, I managed to do a little more work on the soda machine hack. With the hardware to interface 110VAC relays to 5VDC logic done, the next step is to create a means of connecting it to the TINI390 board. This has turned out to be a little more complex than I’d anticipated, specifically because I don’t have direct access to the various I/O pins (at least not through its Java VM). The TINI is set up more like a microprocessor than a microcontroller; all the I/O is done by reading from and writing to specific memory locations, divided into several pages. The board has only eight general-purpose I/O pins, but it has a twenty-bit address bus and five usable “Chip Enable” pins. All communication with the on-board peripherals (such as the flash memory and probably the Ethernet) is carried over the same data pins, so anything I attach needs some capability to decode addresses in order to avoid reading or stomping on unrelated stuff.
(more…)
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.
The W&B soda machine continues its march towards the Internet. Yesterday, Sam Gerstein (another W&B member) and I spent a couple of hours investigating its treacherous inner workings, figuring out specifically where the credit-emulating relay needs to go and testing the selection detection board.
Despite a couple of brief setbacks, the afternoon was a success. Virtually everything in the machine worked more-or-less as predicted. The CONTROL BOX did contain a couple of mysteries: a switch fixed in one position in by a steel plate and a couple of screws, a relay not connected to anything whatsoever, and color-coded wires that didn’t seem to match the schematic. Apart from those, however, it was fairly spacious and tidy inside. The machine had apparently been modified modified so that every item is the same price, so only one of the four circuits that denote credit is actually in use, and shorting this with the ‘hot’ connection registered as money having been deposited. The relay board will be easy to integrate.
(more…)
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…)
Willoughby & Baltic has acquired a vintage soda machine; if I were to guess, it dates back to the late 1950s or early 1960s. It’s a massive steel box with a wood veneer front, its sides an industrial non-color. In contrast to more modern machines, its only text is the words Cold Drink in small, white-on-black, sans-serif lettering above a narrow, horizontal window displaying a representative can of each beverage within. I should have thought to photograph it, but I was distracted by the interior. Inside, the machine is a wonder of space-age technology: as you can see from the schematic, everything operates on 110V AC line current, and its works are almost entirely electromechanical relays and solenoids. Frankly, it’s pretty cool.
Of course, the first thing that needs to be done to the machine is connect it to the Internet. Why? I don’t know. I’m only interested in the ‘how’ at the moment.
(more…)
I’ve long been interested in UI and usability; I took some courses back in school and I’ve pursued it on my own since then. A couple of months back, I performed a thought experiment: what would be the worst (plausible) user interface hardware? It occurred to me that bad interfaces keep the user from performing an activity, but what if the interface itself was the activity? In such a case, the regular rules no longer apply.
From that came my idea for a modular, expandable control panel composed of banks of toggle switches.
(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.
