Waterfall Display

Download Report

Transcript Waterfall Display

PROJECT DEWDROP
Alex Shie, Bob Drummond, Chloe Shim, Dean Veleker
Concept & Motivation
 People send image/text through smartphone
 Waterfall displays
 Control array of water valves to display images
 Wireless user interface
Decoration
Super-cool Advertisement
Competitive Analysis
 Commercial product:
Aquascript, Aquagraphics
 Cost: $12,000 - $100,000
 Only bought for high profile locations
 Physically large (smallest: 2-3 meters wide)
 Non-User interactive
Requirements
 Use WiFi to receive user-drawn image/text from










Android/iPhone smartphones
Handle concurrent user connection
Restrict how often images can be sent per user instance
Support 100 users simultaneously with multiple threads
Minimum resolution of 10 valves
Maximum height of 12ft
Display legible text
Possibly implement LEDs
Display preset images in event of communication failure
Have a very stable standing structure to valves/tank
Capable of easy disassembly for transportation
Technical Specifications
 Two reservoirs
 Superior Pump 91250 ¼ HP Thermoplastic
Submersible Utility Pump
 Solenoid water valves (CCB-CS-12vDC)
 BeagleBoard XM, Arduino
 Belkin N300 Micro USB Adapter
 LED
Architecture
SmartPhone
LEDs
Sends
image
wirelessly
Turn
on/off
Too much water in the
top reservoir?
Microcontroller
Valve Array
Relief Mechanism
Send on/off sign
Water Pump
Collects water
Pumps
Water
Drops
Water
Drops
Water
Water Holding Tank (Base Reservoir)
Risks and Mitigation Strategies

The valves leak even when turned off – noise to our image

The valves have too low of a response time – image difficult to see – use capacitor circuits

Too few valves – low resolution – have viewer stand back, raise valves

Water streams spaced too far apart, can’t bring them closer – use tubes, maybe?

The water pump flow is too high – use a relief system on the tank

The water pump flow is too low – lower the height of the system to reduce required lift

Upper reservoir spills water – use a very capable relief system and build a stable standing structure

The water streams have different speeds – use a gravity based system

Standing structure fails – water spills everywhere – build a stable standing structure

Deactivating solenoids may harm our transistors – use high power transistors/diodes

Valves don’t activate simultaneously – use serial to parallel shift registers

Water can splash at any time during development – work in someone’s apartment/room, not lab

Power requirements for the valves are too much for our power supply – buy more power supplies

Power outlet too far away – get an extension cord

The pump may be damaged if activated without water – always keep it submerged

Users send obscene content – create a master control app to censor content in the queue

Users spam content – limit how often a user can send images/text

System fails to receive user transmissions – display preset images, send user error if possible

System may be too physically large to easily transport – design disassembling standing structure

Individual valve failure - continue operations, send error report to master app

Too many concurrent users - limit number of threads

We are a bunch of ECE’s doing MechE tasks -> practice building things to develop skills