If you can’t explain it simply, you don’t understand it.
— Albert Einstein
The big issue I was having with the Solenoids was too much pressure. So while on a trip to Sudbury my Stepfather and I redesigned it. Well, I just told him what I was thinking of doing, and he came up with a much simpler way of doing it.
It’s a good thing too, because I’ve easily broke the budget on this project! So this design uses a cap from a sewage pipe, and some garden hose adaptors. No soldering required. The pressure in the system is regulated by the height of the pipe and how much water is pumped in. When the solenoids are open and the water is draining a plunger falls, triggering an aquarium pump to refill the container. It stops when the plunger rises past a certain point.
Yes, this thing is now an electronically controlled toilet.
Off to buy some more parts, wire up the XBee controller, and waterproof the remote breadboard.
So the guys at the electronics stores are loving me lately. I’m pretty good at destroying things. While electronics is a reasonably affordable hobby, I’ve managed to turn it into something a little more extreme. So without further adieu, here’s my “listo destructo”:
ATMega168 IC — I was using a headless Arduino as a Serial connection. Removing the ATMega IC each time I had to reprogram the XBee chip. Missing one vital component, an IC extractor. The extractor is cheap, at least cheaper than a replacement IC. If you bend the pins once removing the IC by hand, don’t do it again… and again… and again. In the end I bought a new ATMega168, IC extractor, and USB-TTL module so I wouldn’t have to extract it again. (But at this moment the Arduino is sitting on my desk headless)
HM55B Digital Compass — Red wire, Black wire. Its not that difficult is it? I thought it would save time to just use my existing precut Green wire to wire up the Digital Compass. Wasn’t getting the response I wanted. Turns out I had the positive and negative reversed. Whiff of the burning silicone smell. Definitely not getting the results I want anymore.
Battery Holder & Two AA’s — Smelled that awful burning smell again last night. Ripped out the power going to the XBee’s, Arduino, USB-TTL. Now I see wisps of smoke coming through the air but nothing’s plugged in. Start throwing papers off my desk to find the culprit. Where there’s smoke there’s two AA’s shorting out. Unplug the AA’s with my IC extractor and promise myself to wire up a two pin plug and clean the desk. (It’s still messy)
Countless plumbing prototypes — I’ve resoldered the Solenoid structure about ten times now. Still don’t have a final result I’m pleased with. Still have another design up my sleeve but I haven’t spawned the courage to start building it.
DVD Player — This one’s a good one, I’ve identified hundreds of components scavenged from a DVD Player that didn’t work anymore. IR Emitter and receiver, momentary switches, capacitors, RGB Jacks, connectors, motors, and a frickin’ laser beam. To think this DVD player cost $30. Easily aved me that cost of buying all these little parts at Radio Shack.
Inkjet printer — Again, tons of little components. Varistors, servos, gears, USB jack, power supply, zener diodes, etc. I’m thinking someone should make a website documenting all the components we can dig out of discarded things. Made a mental note to get rid of the plastic casing before my basement fills up with junk.
Nintendo Powerglove — I think I just heard hearts shatter. This one was destroyed about two years ago, but it counts in this list because I’m using the parts for one of my project. Recovered Ultrasound emittors and receivers, flex sensors, etc.
One of the guys at work said I probably shouldn’t put a price list on this. I have to agree, it would hurt too much. Oh and this is by no means a complete list, I intend to update as I keep making stupid mistakes.
TED is always an excellent source of inspiration. Arthur Ganson has one of the more magical demonstrations I have ever seen. What a fabulous body of work!
Sometimes its worth venturing out to a disorganized surplus store to see what you can find. This is my latest little toy.
Its a fragment of a pixelboard. Alternate the currents from one pin to the other and you can make the yellow dots flip to black. The cool thing is even powerless it keeps its state. If you manually flip the pixel to the other side it returns based on the magnetic pull.
The guys at the store obtained it from a signage company that was dumping their old stock for TV screens. The destroyed all of the control boards because it was proprietary technology (just a couple relays I’m thinking). The larger versions of these pixelboards also come with LEDs to illuminate the structure.
In the photo above I’ve hooked the pixelboard up to an IR Rangefinder so it could light up based on distance of an object infront of the sensor.
One of the devices I’m most excited about lately is the MaxStream XBee. The problem with this seemingly innocuous little device is that it wouldn’t behave the way any other tutorial I found said it would. I’ve been working through three different sources of information on the XBee. The first was the source was the always helpful Arduino Forum. Then there’s the excellent article on the Arduino Playground by M. Yarza — though this would have been more helpful initially had I spotted the next page links at the bottom of each page. The third resource is this fantastic book put out by O’Reilly called Making Things Talk. (I’d hazard to think that most people getting involved with the Arduino and XBee will be coming into it from this book and Make magazine)
The first issue I had was working out how to configure the XBee module. The Arduino serial interface doesn’t appear to like to send characters as they’re typed, and requires a line break before it executes. This proves to be an issue with the Command Mode in the XBee. The workaround is to move into a terminal application that does support direct TTY. On a Windows machine PuTTY should do the trick, or Screen on the Mac OS. I’m using a Mac, but the PC should be a matter of pointing the terminal at the COM port associated with the USB-Serial adaptor that you’re using. On a Mac you’d point this at /dev/tty.usbserial[identifier].
The Arduino can act as a USB-Serial adapter if you like. Just remove the ATMega168 chip and communicate directly through the TX/RX ports.
To execute Screen type: screen /dev/tty.usbserial-A4001uBD 9600
Replace the usbserial name with the one that is present on your system. The name should only appear when the USB device is plugged in, otherwise you won’t see anything. The connection speed of 9600 baud is the default connection speed of the XBee radio. If you’ve altered this, call your new baud rate here.
Once you’re in type in: +++
This enters command mode. Here you can get or set the XBee parameters: ATID returns 1111. ATID1234 sets the ID for the XBee to 1234. It should return nothing. ATID will now return 1234. ATWR writes these values to the XBee. ATCN exits command mode if it hasn’t automatically done so by timeout (~10s).
The configuration options go on from there, and they get increasingly complex.
Hopefully that helps others in a simillar situation I found myself in. Soon I’ll post a follow up detailing my setup.
Playing around with the Xbee has led to a number of really interesting thoughts and ideas. Part of me is thinking that some of these ideas are far more interesting than the Solenoid project I’m currently working on. I have to keep reminding myself that I should really finish one thing before starting the next.
I’m still wrapping my head around the Xbee and what it does, and I can tell you what it doesn’t. Its not a bluetooth adapter (you might be looking for a BlueSMiRF radio instead). It operates on the 802.15.4 Zigbee protocol. Essentially it sets up a mesh network.
The node points for the Xbee OEM modules are 30m in radio frequency (RF) or 100m line of sight. The Xbee Pro’s go to 100m RF, and 300m line of sight. Where it gets interesting is the Xbee Pro-XSC at a range of 24 km in RF.
The modules are capable of being configured as a peer to peer, one-to-many, or many-to-many. They can hibernate, just broadcast or receive, and more. The spec sheet is quite impressive. If you send a message from one node, it could repeat till it finds its destination in the network. Imagine this on a scale of ~20 km node points.
Lets say we build a telemetry device and outfit it on a vehicle. That device could consist of a couple sensors, say a Hall Effect sensor typical in bicycle computers and ABMs on cars, and a compass module (I’ll explain my reasoning behind this over a GPS later). Other possibilities could include a heart rate monitor, air quality sensors, battery power. I’d love to integrate my heart rate monitor into the mix. A USB stick could connect to the Arduino (I’m loving the new Nano form factor) and act as a data-logger. Finally a localized Xbee controller would sit dormant on the device. As the vehicle moves an onboard timer records the data to a timestamped string:
20080519 20:55:59,4.5204,30
These fields would translate back to “Date/Time, Radians, RPM”. Over specified intervals new data would be recorded and stored locally. When the device comes within range of a broadcast node it would awake out of hibernation and deliver the data into the mesh network. A receiver station collects the data from the mesh and sends a confirmation signal. The broadcaster deletes the store of data and starts over, sending the local Xbee into hibernation mode again.
The data is then processed by the receiving station, plotted onto a mapping API, cross-referenced against other broadcasting modules, etc.
I’m going to play devil’s advocate on myself here:
Why a compass module over a GPS? Would that not deliver more accurate data? From what I’ve read, a compass module should provide a far lower drain on the power supply. It would also operate in situations where no sky visibility is provided. The form factor is much smaller, and no antenna would be required. The disadvantage is you need to know the precise starting point (found via GPS no less), and mounting considerations would apply.
The interesting thing is that I have all of the components working in isolation. Its just the small matter of getting everything to play as a team. Then moving it out into the field for some real world tests. Right now these are just some thoughts, but I can’t explain how exciting this little device is.
If anyone had have told me this project would cost slightly in the range of $300 I would have probably not have started it at all. Individually the components don’t cost that much, Arduino — $60, transistors — $10 for nine of them, copper connectors — $2, and so on. It all starts to add up, and when you factor in the failed attempts things really start to add up.
That’s the beauty of it. It isn’t fast, but the iterative steps of this project let you take a breath and work out the issues one item at a time. If I were to work this whole thing through from scratch and without the knowledge I’ve gleaned through the process the magnitude of the project would have seemed overwhelming.
Individually the process is quite simple. Right now I’m battling some leaks, and the tiny issue that the pressure in the system may be a bit too strong. In one of the early tests I blew a stream of water clear across the room. These issues taken in stride don’t seem to be that daunting. To think only a couple of days ago I was wondering if I should continue.
On the less wet side of the equation I’ve been working with the XBee module for the Arduino. It communicates wirelessly using the Zigbee protocol (802.15). After some initial failures I think I understand how to get this thing to work. I’ve still yet to bring this thing full circle, but its getting there. I’m thinking I’m going to wait for LadyAda’s Boardino USB to reach my local store Creatron before I pick up some more pieces, but the benefit of waiting is I could use this system to build a clustering/mesh network of Arduinos. This is something I’m looking forward to. One of the other advantages of moving to the XBee is that I can keep the computer at a remote location ~100’ (longer with line of sight). With all the leaks I’m having this sounds very appealing.
One other change in scope has to do with the web cam. I’m thinking of ditching it all together for the initial phase of the project. Don’t worry, I’ll definitely return to it later — I already have the code working! One of the early tests I built used LEDs to enact a Persistence of Vision system. This principle should be the same using the water drops as pixels as they fall through the air. Currently I’m developing a 9x15 matrix of shapes and typographic characters that should drop out as an audience member interacts with the system.
Now is this where I thought I’d be when I first drew the idea up? No where close. But the slow pace and iterative process has its advantages. It spawns a whole new set of ideas along the way.
A little background first. I’m an experienced Origami folder. I understand the concepts of designing, and I’ve folded some of the more difficult folds out there. I’ve also taught all ages how to fold and have been known to diagram folds on occasion.
A couple of years ago I was in Singapore for a wedding. Over the course of the reception I found myself hanging out with this one 12 year old kid. He had never folded before, but like most kids his age he could catch on pretty quick. After teaching him a couple of folds I could see he was pretty good at this. So it was time to throw him a curve-ball. I taught him how to design his own folds.
It took about 15 minutes but in the end he had a fold that was easily distinguishable as the object he intended to create. He was impressed with the fold, and I was impressed with his ability, but we couldn’t let it stop there. I managed to dig up a piece of paper and a pen and started to diagram his fold. He picked up the symbols for an inside-reverse fold, mountains and valleys, and in the end he had a piece of paper which he could easily reproduce he fold from in the future. I dated it, and he signed his name so he knew it was his design.
Now, most kids after I have taught them how to fold something will usually say “thanks” but often at the prompting by their parents. This time was a bit different. I easily consider this to be one of the best compliments I’ve ever received in my life.
“You’re an excellent maker.”
And with that we went back to the party.
I often get requests about the projects I’m working on.
“Why are you building this?”
“Are you going to make this into an art installation?”
“You should sell this!”
The thoughts do cross my mind. But I do them for a different reason. I do them to be that excellent maker I was a couple years ago in Singapore. And you can’t be excellent at anything unless you keep working at it.
So really, the projects I work on are more for me to learn than anything else. If someone comes along and finds themselves moved by the project then it’s pleasing. If they happen to call me an excellent maker I’ll be inspired to be more excellent.
This past January I was biking home in the rain when this thought hit me. I was stopped at a red light looking at the pools of water on the ground wondering if it would be possible to calculate the density of rainfall. I thought, even when they’re giving weather reports they never really tell you if it will be a hard rain, soft rain, or a mist. They just say “rain is in the forecast.”
Looking at the pools of water it seemed apparent that you could shine a spotlight on a puddle and perform some motion detection code on the ripples to locate the centre of a drop. You would only need a short sample in order to determine the average drops per minute or hour.
This is all fine a cool, but what would you do with the data? The traffic light turned green.
If you could calculate density of the water, you could no doubt calculate the distance between drops. It would be fascinating to generate an algorithm which predicts a path based on the least amount of rain drops. Does one exist? Could you find a pattern where I’m fairly certain none exists? All of these thoughts are purely hypothetical, and probably wouldn’t work in real life, but given a 20/20 hindsight it would be something to brag about, coming home after biking in a rainstorm, completely dry.
Another red light.
What if you could build a machine that rains, but when you walked underneath you never got wet? This was where the Rain Aversion project began.
First, I’d need the rain. If I produced a mechanism which controlled the flow of water out of some pipes, I could cause the device to pour rain in a controlled manner. Ideally I’d like to collect the fallen water and pump it back into a reservoir so as to not waste liquid. But that would require a much more involved development cycle, so part of that was pushed out of the prototype phase. To begin I’d just attach a hose and feed it off the water supply.
Second I’d need a controller. Something to activate and deactivate each pipe as a sensor detects an object underneath. Having recently received an Arduino it was the controller of choice.
So I had several pieces of technology at my disposal. An Arduino, a webcam, some solenoids, and some Flash and Processing skills. Ignoring the dead ends the prototype phases lead me through, the project is set up as such:
Arduino is loaded with the Firmata Protocol enabling it to communicate through a serial connection to the host computer.
Protolab’s Arduino2Flash Java serial proxy stood in for serproxy when it wouldn’t communicate properly.
AS3Glue handles the Serial Events as they are broadcasted to and from the Arduino.
Joa Ebert’s ImageProcessing library manages the Web Cam manipulations such as the pixel averaging and threshold detection.
The Arduino sends signals to a high voltage circuit through a series of transistors, the schematic can be found on the Arduino Tutorials page.
Water Solenoids (I used 9 to produce a 3x3 matrix)
Each of the solenoids is connected to a 19V power supply. (This underperforms on the amperage side of things when all solenoids are firing at the same time, but seems to do the trick)
The solenoids are also connected to a hose feeding the water, with a series of copper splitters to divide the flow.
I needed a sensor to detect where someone stood so I could disable the stream of water. There’s several alternatives here, but I’ve chosen to go the webcam route. Flash was chosen over Processing due to my inexperience with the latter. I have no doubt that I could entice Processing to work faster than Flash in future renditions of the code.
The copper piping and feeds are simple plumbing supplies. Flexible hosing was used so I could reconfigure the setup if needed. This was the most costly side of the project aside from the solenoids.
The final result is a ~$200 apparatus which leaks, but in just the right places. And it won’t leak on you. I’m still assembling some final videos of the device in action, but in the meantime I have some demonstrations of an earlier protoype in action:
Additional videos are available here. Photos of the process are available here.
In the next couple posts I’ll detail the final assembly of the project, and also discuss some of the future possibilities of the device. The whole setup has massive potential.
The big issue I was having with the Solenoids was too much pressure. So while on a trip to Sudbury my Stepfather and I redesigned it. Well, I just told him what I was thinking of doing, and he came up with a much simpler way of doing it.
Water Solenoids (I used 9 to produce a 3x3 matrix)