The Barduino: Pt 1
Those of you who know me know about my projects. Usually, I try to spend my spring breaks building something. My last project was The Device, which was a proof-of-concept camera-based touch screen coffee table. Now that was a design provided by the excellent publication Maximum PC and while not nearly as nuanced as their version, it was cheap and effective, all things considered. This project will be the first of my own design. Armed with trivial knowledge of circuitry, substantial programming abilities, a CAD program and a name shamelessly cribbed from the Matt William’s much more nuanced Barduino, I’ve decided to construct a device so that I can invite people over to have a drink served by my robot.
After doing a little bit of background research, my design will have several differences from Mr. William’s device.
1) While he used windshield wiper pumps to guarantee a constant rate of flow, I’ve decided to use a Mariotte Siphon in order to provide a constant pressure. It will save me a little effort in circuitry, since that’s by far my weakest skillset. A simple Mariotte Siphon can be made from tubing and a two-liter bottle.
2) I’ll also be omitting the photosensor that he uses to check to see if a glass is present. All this means is that if you tell it to dispense a drink, it’ll do it regardless of whether a glass is there or not. Additionally, since I’ve envisioned this being mounted to a wall, there really isn’t a place for it. If it ends up being an issue where my guests are incredibly discourteous and pour drinks on my floor with any sort of frequency, well, I suppose I’ll need to reconsider.
3) Since the device will be mounted on a wall, it will need valve control logic to prevent unintentional flow. This blog suggests using a solenoid valve. His valve setup is being used for low-latency applications, so it’s likely overkill for my device, and at ~30 dollars per valve (sans tubing), I’m definitely on the prowl for low cost alternatives.
4) I’m planning on using a hardware control mechanism to allow for programmable drink menus. While I’ll initially use a dip switch setup in order to select options, the public debut may need a more user friendly solution, such as a key pad. I’m not sure I expect people (myself included) to be particularly accurate in performing binary conversions after a couple drinks, after all…
5) Probably won’t use Ruby.
I’ll keep the blog updated as I design, acquire parts and construct the device. Stay tuned! Also, suggest alternative names, since I really don’t want to totally hijack Mr. William’s brilliant wordplay!