1 / 29

eBlocks -- Electronic Building Blocks for Everyone

eBlocks -- Electronic Building Blocks for Everyone. Frank Vahid Professor Computer Science and Engineering University of California, Riverside (Also with the Center for Embedded Computer Systems, UC Irvine) http://www.cs.ucr.edu/~vahid eBlocks project: http://www.cs.ucr.edu/eblocks

Jims
Télécharger la présentation

eBlocks -- Electronic Building Blocks for Everyone

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. eBlocks -- Electronic Building Blocks for Everyone Frank Vahid Professor Computer Science and Engineering University of California, Riverside (Also with the Center for Embedded Computer Systems, UC Irvine) http://www.cs.ucr.edu/~vahid eBlocks project: http://www.cs.ucr.edu/eblocks This work is being supported by the National Science Foundation

  2. My Background • I don’t usually starts talks this way, but there’s a reason this time • PhD 1994 with Prof. Dan Gajski, UC Irvine • DA/CAD for embedded systems • Publish in places like DAC, ICCAD, DATE, ISLPED, FPGA, FCCM, ISCA • Funding from NSF, SRC, various companies • Also involved in embedded system education, extensive lab development Completing “Digital Design,” J. Wiley and Sons, 2005 J. Wiley & Sons, 2001 Prentice-Hall 1994 Frank Vahid, UC Riverside

  3. The Beginnings of eBlocks… 1998 – bought a house Garage door Garage door left open at night Oops! Frank Vahid, UC Riverside

  4. tx LED rx AND light sensor contact switch Simple Enough Problem – Solution not so Simple • Alarm company – too expensive • Off-the-shelf product – hard to find, too expensive, not flexible • What I wanted – electronic components (blocks): • Light sensor • Contact switch • Logic • Wireless transmit/receive • LED • Connect them…done Frank Vahid, UC Riverside

  5. LED rx tx AND light sensor contact switch With my Embedded Systems Background, I Should Be Able to Solve This! Not So Easy, Though… • Catalogs, datasheets, power supplies, compilers, drivers, breadboards, resistors, capacitors, debugging (multimeters, logic analyzers), packet-based networking, … Frank Vahid, UC Riverside

  6. completed 40% not completed 60% Is it Just Me? • Gave as embedded-system class project • Three weeks • Students had courses, from various universities, involving digital design, microcontrollers, electronics, and interfacing with sensors/displays • 50 students attempted the project, only 20 completed the project (two different quarters) • Problems • Misunderstanding (or vague) data sheets, interfacing errors, debugging difficulties • A regular person can’t build this seemingly simple, useful system • Not even perhaps an engineer in a different domain • Not even a specialist when he has three kids in soccer Frank Vahid, UC Riverside

  7. Noticed Countless Applications where Electronic Blocks would be Useful • Home monitoring • Garage door open, side fence open, sleepwalk detector, visitor at front door, turn on two lights on porch, extend motion sensor for light in garage, carpooler arrived • Stores • Restaurants (more rice please), car in store parking spot, customer entered store, aisle popularity • Office • Front-desk notifiers, meeting room in use, copy machine in use, mail in mailbox, temperature logging • School • Student voting systems, learning logic, learning arithmetic • Assistance • Hard of hearing (vibration when sound), vision impaired, object locators, sleepwalker detector • Ad-hoc security Frank Vahid, UC Riverside

  8. Individual Applications Don’t Justify Product, but Together a Huge Market • Volume for “garage open at night” or “sleepwalk detector” individually not big • Product not profitable • High-cost product • Hard-to-find product • Typically not customizable • But combination of applications results in huge volumes • Blocks can be low-cost • Key – can we create blocks that people can really use? Frank Vahid, UC Riverside

  9. Need – Electronic Blocks • Decided that what is needed is a set of Electronic Blocks • The “wood and nails” of electronics • Enable novices to build basic useful systems • Enable slightly more skilled people to build fairly complex systems (e.g., electrician) • Not quite my research area (DA/CAD), but passionate about this Frank Vahid, UC Riverside

  10. Existing electronic block products • Board-based – education only, not practical use • E.g., LogiBlocs, MagicBlocks • Home-automation-centric, not general • E.g., Existing X10 products • PC-centric – O.K., but not easy to learn • E.g. Mindstorm, Phidgets (PC-based robotics) Frank Vahid, UC Riverside

  11. eBlock Design Principles • Minimal abstraction – for novices • Hands-on design (PC O.K. for non-novice) • Obvious connectivity using wires • Wireless an optional replacement for wires • Wires lower-power, longer communication (> 2 miles in test of two 98 cent uC w/ 9-volt. Bat.) • Obvious block functions • “Combine,” “Prolong” (programmable O.K. for non-novices) • Option of battery or wall-powered • Battery – should last years • Wall – batteries not always necessary Frank Vahid, UC Riverside

  12. eBlock Basic Abstraction, as in our One-Page User Handout STEP 1:eBlocks are electronic blocks that you connect like Lego’s to build useful sensor systems around the home, office, etc. • Most people don’t do well with abstractions • Whereas engineers and programmers thrive on abstractions! • Our system uses a “yes”/”no” abstraction • STEP 2:Build your first eBlock system – a doorbell! • find a button and beeper block • turn each block on • connect the button to beeper block like this: Press the button, hear the beep! Frank Vahid, UC Riverside

  13. Button Button yes no red means NO yellow means ERROR green means YES eBlock Basic Abstraction, as in our One-Page User Handout STEP 3:eBlocks talk over the wires using YES and NO. The button block sends YES when you press the button, and sends NO when the button is not pressed. The tiny “status” lights blink near an eBlock's wires tell you what's being sent: Try pressing the button and watching the status lights on the button and beeper blocks. Yes/No is the main “abstraction” users need to know Frank Vahid, UC Riverside

  14. Basic Yes/No Blocks • Misc • Wireless transmit / receive • Splitter • Output • LED • Beeper • Electric relay • Compute • Combine (2-input) • Opposite • Yes prolonger • Once-yes, stays yes • Toggle • Pulse generator • Sensors • Motion • Light • Sound • Button • Contact • Switch We’ve built >100 physical prototypes Frank Vahid, UC Riverside

  15. “Smart dust” Courtesy of Joe Kahn button wireless tx eBlock Technology • Tiny PIC processor in each block • Two-wire connectivity • Packet-based serial communication • Extensive sleep time • Agreed upon wired protocol • Research issues • 1. New Boolean digital abstraction • 2. Multi-layer computation / communication codesign • 3. Usability by novices • 4. Tools for non-novices Frank Vahid, UC Riverside

  16. 0.8 channel (wire) Source Sink 0 continuous voltage, two levels time (a) 1 0 (c) (b) time channel (wires or wireless) Source Sink false true false packets containing “true” or “false” time 1. Boolean Digital Abstraction • For packet-based underlying phenomena • Rather than continuous voltage Frank Vahid, UC Riverside

  17. time f t f < < error error (a) time < < > f f t f f t f f (c) (b) > > > f t f t f (e) (d) Boolean Digital Abstraction – “Technology Family” • Send packet for logic change • Block “technology family” includes • maximum inter-packet time • minimum inter-packet time • Akin to a logic gate technology family Frank Vahid, UC Riverside

  18. “1” prolonger node in (a) out prolong time in (b) Toggle node out A (c) Tripper node A Reset Reset out Pulse generator out (d) Boolean Digital Abstraction – Basic Compute Blocks • Definition of basic compute blocks • Combinational • AND/OR/NOT • Truth table • Sequential • Prolonger • Toggle • Tripper • Pulse generator Frank Vahid, UC Riverside

  19. 3.6 3.3 - 3.6 Estimated Lifetime (in years) 3.0 – 3.3 3.3 2.7 – 3.0 3.0 2.5 – 2.7 2.2 – 2.5 2.7 1.9 – 2.2 2.5 1.6 – 1.9 2.2 1.9 1.6 0.5 1 2 3 4 5 14.4K 10 30 60 30 9600 600 4800 2400 1200 Data Timeout (in seconds) Baud Rate 2. Multilayer Compute/Communication Codesign • §PIC Supply Voltage (V) = {3.0, 3.5, 4.0, 4.5, 5.0, 5.5} • §PIC Clock Frequency (Hz) = {32k, 100k, 200k, 300k, 455k, 800k, 1.6M, 2M, 3M, 4M, 5.3M, 7.4M, 8M, 10M, 10.4M, 16M, 20M} • §Communication Baud Rate (bps) = {1200, 2400, 4800, 9600, 14.4K, 28.8K} • §Data Packet Size = {4 bits, 1B, 2B, 4B} • §Data Timeout = {0.25 sec, 0.5 sec, 1 sec, 2 sec, 3 sec, 4 sec, 5 sec, 10 sec, 30 sec, 1 min, 5 min, 10 min, 30 min} • §Alive Timeout = {0.1 sec, 0.25 sec, 0.5 sec, 1 sec, 2 sec, 3 sec, 4 sec, 5 sec, 10 sec, 30 sec, 1 min, 5 min, 10 min} • §Error Check/Correct (ECC) Strategy = {none, crc, parity, checksum1, checksum2, hamming1, hamming2} • Design parameters tightly inter-related • Traditional computer-system-design multi-layered, separation of concerns approach not appropriate for energy-sensitive sensor nodes • Design metrics • Parameters compete in their influence of metrics §Lifetime – the number of days a block can run powered by a 9-volt battery. §Reliability – the absence of undetected incorrect data packets. §Latency – the time for an event to propagate through a block within a network. §Responsiveness – the time for newly connected blocks to receive good input and behave properly, and for newly-disconnected blocks to behave as disconnected. Frank Vahid, UC Riverside

  20. Multilayer Codesign -- Tool • Developed CAD tool for block designer (not for the block user) • Designer specifies design metric objective functions • Tool includes internal estimator relating design parameter values to design metrics • Tool explores millions of configurations • Outperformed hand design • Enables easy re-targeting of blocks to new domain Frank Vahid, UC Riverside

  21. Question Truth table with variables (11 students) Truth table with English (9 students) Motion at night 36% 22% Motion 0% 56% Motion at night or no motion in day 0% 22% 2-Input Logic Motion or night 0% 11% AB Button A B Buzzer Light Sensor A B Output no no no yes no yes no yes yes no no yes configurable DIP switch yes yes no yes Logic Block 3. Usability by Novices • Extensive ongoing user studies • Dozens of kids ages 10-17 • 35 high-school kids • Hundreds of college students • About 15 adults/seniors • Hardest block – 2-input logic • Previous studies show difficulty with logic • Want configurable block, in addition to AND/OR/NOT • Initial truth-table design performed poorly Frank Vahid, UC Riverside

  22. Question (number in parentheses means answer came “close”) Colored truth table embedded in a sentence -15 students Daytime doorbell (AB) 47% (67%) 47% (71%) 88% (88%) Nighttime doorbell (AB’) 33% (52%) 41% (76%) Motion on property (A+B) 33% (33%) 65% (71%) yes no A B B A yes no The output should be yes when: A is yes, B is yes A is yes, B is yes A is yes, B is no A is yes, B is no When the input is the output should be Logic sentence -17 students Combine (Motivated students – 8) A is no, B is yes A is no, B is yes A is no, B is no A is no, B is no out Combine (a) (b) A B yes no yes no When A is AND OR yes no B is A B When the input is The output should be A B then the output is yes A B Combine out A B (d) (c) Combine Usability by Novices -- Logic • Several iterations of block designs • Hundreds of students • Ultimately found a logic sentence best • Colored truth table the runner up • We might provide both • Sentence – easier but less general Frank Vahid, UC Riverside

  23. Usability by Novices -- State • State-concepts perhaps harder to comprehend • But usability tests show surpising success for basic systems • In less than 10 minutes, with no training, mostly novices (non-scientists, non-engineers) • State blocks seem to correspond to common everyday items (toggle light switch, alarm system, beeping alarm clock) Frank Vahid, UC Riverside

  24. 3 5 7 10 3 5 7 10 1 1 1 2 1 2 8 11 8 11 4 6 4 6 1 1 9 12 9 12 0 (a) (b) 3 5 7 10 3 5 7 10 1 2 1 2 -1 -1 8 11 8 11 4 6 4 6 1 9 12 9 12 0 0 (c) (d) 3 5 7 10 1 2 8 11 4 6 9 12 (e) 4. Tools for Non-Novices • Simulator • Optimizer • Replace blocks by smaller set, even by programmable blocks • User-programmable blocks Frank Vahid, UC Riverside

  25. Continuing Work -- Research • Pubs • ISSS/CODES’03 • IEEE SECON’04 • Subs • 3 to DATE • 1 to CHI • Extension to integer blocks too • E.g., temperature sensor, arithmetic compute • Digital abstraction formalizations • More usability testing • Integer blocks, AND/OR/NOT blocks, logic+state systems • More advanced user tools • Need a “functional specification” of system, automatically generate system of blocks • Improve block-design CAD tool • More parameters, easier cost function definition, better analysis • Towards sensor-network CAD tool Frank Vahid, UC Riverside

  26. Motion Sensor eBlock to PC Interface 2-Input Logic Light Sensor Continuing Work – Evolving Towards the Digital Home • Ultimately, blocks can enhance Intel’s Digital Home efforts • Enable user to configure sensor-input to PC-based application • Activate Program A (say video recording) when Event X • Event X may be defined by arbitrary eBlock system that eventually outputs yes/no to PC • Integer blocks provide even more possibilities • Turn on AC when average temperature of three sensors exceeds threshold • Can naturally lead to users wanting to use PC-based tools to build, configure or optimize their sensor systems Motion Sensor Motion Sensor Motion Sensor (Logic blocks) eBlock to PC Interface Motion Sensor Motion Sensor Motion Sensor Motion Sensor Frank Vahid, UC Riverside

  27. Continuing Work – Middle-School eBlocks Project • Goal: Begin bringing this technology to the people • First step: Bring blocks to middle-school kids with aid of major corporate partner • Response by kids and teachers has been great • “Hands on” engineering of real systems • Natural evolution into both spatial and temporal design • State-programming may prove more intuitive than data-transformation-programming • Hope to encourage youth to consider engineering at the critical middle school age, when studies show careers get “excluded,” especially by females • Blocks can help teach logic • A critical skill in the information age, lacking among most Frank Vahid, UC Riverside

  28. Middle-School eBlocks Project • Features • Establish key partnership (4Q04) • Design and user-test interesting projects (1Q05) • Create robust block prototypes for at least two dozen schools (2Q05) • Develop teacher kits with blocks and projects (2Q05) • Actively visit at least one dozen schools, introduce kits, monitor success (3Q05) • Extend kits to PC-based applications • 2006: expand project, begin looking at digital home project, possibly startup company • Costs (2005) • $35-50K grad student design/develop • $30-50K prototypes • $35-50K staff for school visits • Matching funds likely (NSF, UC) Frank Vahid, UC Riverside

  29. Summary • eBlocks stemmed from observation that technology progress seems to have missed something • Still need the electronic equivalent of wood and nails • Took a risk research-wise; got NSF funding; now committed to seeing this have an impact • We designed and tested first set of blocks • Now convinced they are usable, useful and interesting • Want to take blocks “to the people” • First step: middle-school eBlocks project • Need major partner to fund, assist, guide, and provide credibility Frank Vahid, UC Riverside

More Related