WWMD allows a user to control a wall of water with the wave of their hand. I built this project along with Mark Breneman for our ITP Intro to Physical Computing final project.
Water control comes from a Kinect tracking hand movement, communicating the data to Processing, which then sends it to an Arduino controlling a stepper motor. The motor turns gears on a tube of water which has holes drilled on one side. The wall of water is open when the holes face down and closed when the holes are above the water level.
From Idea to Execution
Mark and I began just by thinking about a way to control water. I have been keen to learn more about using the Kinect since arriving at ITP, so I welcomed the chance to incorporate it into a project. When we started, we were focused on the water control system and learning the Kinect code (the start and end points of the system). But after meeting with Greg, the ITP resident and Kinect specialist, he suggested we instead learn about the middle part of the equation where Processing and Arduino determine motor movement.
On his advice, we looked into data transmission from Processing to Arduino. We used simple X position from mouse movement to control a motor’s movement forward, backwards or still. All our class examples had dealt with Arduino to Processing communication, so we first worked out the details of the reverse process. We drew a simple sketch in Processing and Arduino that divided a window into three parts. The left zone moved the motor in one direction, the middle stopped it and the right moved it in the opposite direction.
Motor and Water Control
Scaling up, we started by using a motor lent to us from our classmate Jackson. The motor was from a discarded drill, so we knew it had plenty of torque to accomplish what we wanted. But the complication was that it drew 4 amps of current, far greater than the 1 amp Arduino can handle. We frantically ordered a motor shield before Thanksgiving that promised it could handle 4 amps. We hooked it up to our Arduino and bench power. It worked for a few minutes, and then all of the sudden it did not. We never figured out the specifics of why, but guessed that at some point the current or voltage must have spiked when we switched from one direction to the other. With just a few weeks until the deadline, we looked for another solution.
Another issue we had at the time was our water control system. We bought a 6′ plastic gutter and drilled holes along the bottom. We then bought 2 3′ threaded rods and joined them in the center. One rod was threaded right, the other threaded left. With a bolt on each, we attached the linked rods to the motor. When the motor spun, the bolts both moved away from center or towards the center.
We cut paddles using the laser cutter and attached them to the bolts. With the gutter full of water on both sides, the paddles were designed to create a dry zone in the middle by pushing the water out. The opening in the wall of water would therefor start in the middle and move outwards. While this seemed like a great idea in theory, we ran into problems. Even with paddles cut exactly to the shape of the gutter and O-rings along the edge, we could not get a tight seal in the gutter.
With both motor and water control problems, we decided to switch our approach. We were lucky that our teacher Tom Igoe was able to lend us a geared stepper motor. It proved helpful to have this because we could assign specific number of motor steps to open the wall of water or close it. Tom also lent us a prototype of an official Arduino motor shield (which they expect to release soon). It allowed us to handle up to 2 amps of current and use the new motor.
On the water control front, we switched from the gutter to a plastic water tube. We drilled holes into the tube in a V shape, allowing the break in the wall of water to start from the center and move outwards.
The challenge with this approach was that it required us to keep the water level inside the tube at half full all the time. If the water level went higher, then water would leak from the holes on the top of the tube when no water should be flowing out. If the water level dropped lower than half, there would be gaps in the wall of water. With a spinning tube, we couldn’t just place a barrier on one end. In the end we cut a piece of plastic on the laser cutter that had a wider opening on the top than the bottom.
With all these complications sorted, we switched back to the Kinect. We began to integrate two sets of code that Greg had given us, one for hand tracking and one that determines center of mass for people in the frame. We chose this type of code because we did not want to use Skeleton Tracking, one method for controlling input from people in the frame. This requires people to stand with their hands up for a few seconds until the Kinect acquires them. We thought a better user experience allows people to just walk up.
We realized that perfecting the user experience for this type of control was going to be a challenge. First, in building what is essentially a door of water, a final version would need to work from both directions. But this is difficult because there is no way to combine input from two Kinects (with one on each side of the door). In that type of scenario, there is no way for the code to know which Kinect is “in charge.” Also, we realized we needed to create some sort of safety mechanism that insured that the door stayed open when people were underneath it (some people get upset when they get drenched in water unexpectedly). But there was a good chance that the zone under the door would be out of Kinect’s view. We would thus need to incorporate other sensors to lock the door open.
This raised another issue, where to position the Kinect. Since it has to track a hand, it seemed best to put it in front. But people need to be at least 20″ in front of the Kinect for it to work. We thought about putting it behind people, but it does not work well from there. Trials from the back position worked less than half the time. In the end, we positioned the camera towards the front and a bit to the side.
Scaling down the prototype
With the complexity of this project, we decided to scale back the product in order to make our class deadline. I originally hoped for a 6′ wide wall of water position 6′ in the air. But the extra weight of this water and the frame would have been a challenge. Also, adding more water into a longer tube would have put added pressure on the motor and the sump pump. We were worried that the motor might not be up for this challenge. Even if it had the required torque, it would probably mean it would turn quite slowly.
We hope to tackle these challenges in a later version when we have more time. We also hope to perfect the Kinect code. Our thinking is to create a limited zone based on X, Y and Z position where one person can control the movement. The wall will lock open when the person approaches the door and triggers a light sensor. A second light sensor on the other side will close the door behind them when it is triggered. Or, if someone approached the door from this second direction when it was closed, it would lock open until the first sensor was triggered. This would probably resolve the majority of the use cases. But if this was in a busy location, there is also potential that there would be multiple people trying to enter and exit from both sides at once, further complicating things from a control standpoint.
Nonetheless, we are happy with what we produced in this first stage. Our class demo worked and people were able to control the water with a wave of their hands. We received good feedback from our classmates and learned a lot along the way. It was great working with Mark. We saw eye to eye on most things during development, which helped. His background in engineering and product design proved essential for building this. After the holidays, we will hopefully return to this with fresh eyes and see where to go from here!
Thanks again to Tom Igoe, Greg Borenstein, Patricia Adler, Zeven Rodriguez, and Jackson “Pasta Alaska” Snellings.