Introduction to Physical Computing

Spring 2010

Physical Computing is an approach to learning how humans communicate through computers that starts by considering how humans express themselves physically. In this course, we take the human body as a given, and attempt to design computing applications within the limits of its expression.

To realize this goal, you'll learn how a computer converts the changes in energy given off by our bodies (in the form of sound, light, motion, and other forms) into changing electronic signals that it can read interpret. You'll learn about the sensors that do this, and about very simple computers called microcontrollers that read sensors and convert their output into data. Finally, you'll learn how microcontrollers communicate with other computers.

Physical computing takes a hands-on approach, which means that you spend a lot of time building circuits, soldering, writing programs, building structures to hold sensors and controls, and figuring out how best to make all of these things relate to a person's expression.

H79.2301 (Tom Igoe)

Wednesday

9:30 AM - 12 PM

Some time in weeks 1 - 3: Attend a tool safety session in the shop

This course is broken into three main sections. We'll cover the material in each section more or less in the order presented here. We may move slightly faster or slower some weeks, depending on the whole class' level of understanding of the material. You may want to read all the conceptual material for a given section at the beginning of that section. I'll let you know at the end of each class what we'll work on the next week, so you can prepare.

Each week, I'll do one or two of the lab exercises in class that relate to the technical concepts we're discussing. You should bring materials to do the lab in class as well. You may not finish it all in class, but handling the parts as we do it together and talk about it will help you to complete it on your own. The materials for each lab are listed in the lab, and most all of them come from your intro parts kit or are available in the shop or the NYU computer store.

Lab Projects: you'll be expected to show at least one lab project for each of the first two sections. These projects don't have to be complex. They should be the kind of thing you can finish in a week. But they should show that you understood the concept and can use it. You'll be doing a lab each week, so you'll have plenty of opportunity to come up with several ideas; the more you do, the more you'll learn. In addition, many of the labs mention project ideas. You can show more than one lab project per section if you're so inspired. You may work with other students on these if you wish. It's often helpful to do so.

I will be updating the labs with new material as this semester progresses. I'll let you know when that happens.

Weeks 5 and 10 are left open so that we can review any questions and see any projects from people who haven't presented already that section.

Weeks 1 - 4: Control of Input & Output

In this section, we'll cover what physical computing is conceptually. You'll learn the basics of input from the physical world to a microcontroller, and output from the microcontroller to the physical world.

Readings for section 1:

Crawford, The Art of Interactive Design, chapters 1 and 2 (note: you will need to sign into NYUHome to view this. From your NYUHome home page, click "Research" then "books24x7.com" then search for "The Art of Interactive Design" by Chris Crawford. Alternately, try this link. )
Norman, Design of Everyday Things, ch. 1
Norman, Emotional Design, Chapter 1, "Attractive Things Work Better".

Technical readings (may help clarify the class discussions and labs):

Physical Computing, introduction
Physical Computing, chapters 1 - 6

Blogging for section 1:

Observation. Pick a piece of interactive technology in public, used by multiple people. Write down your assumptions as to how it's used, and describe the context in which it's being used. Watch people use it, preferably without them knowing they're being observed. Take notes on how they use it, what they do differently, what appear to be the difficulties, what appear to be the easiest parts. Record what takes the longest, what takes the least amount of time, and how long the whole transaction takes. Consider how the readings from Norman and Crawford reflect on what you see.

Week 1 Assignment:

Join the physcomp listserve
Introduce yourself in the class Journals page for your section. Include links to any external site you're maintaining for this class.
Sign up for two days of shop cleaning.

Week 1 Jan 20	CONCEPTS: What is Physical Computing? What is a Microcontroller? Microcontrollers and sensors in the everyday environment Analog vs. Digital	LABS: Week 1 in-class exercise (in groups): Fantasy Device. Think of a fantasy device you've always wanted. Doesn't have to be physically possible, but it has to have a physical interface. Design what the physical interface was. Document your design on your blog, and bring it in for the class. Your mock-up doesn't have to work, and it can be made out of any materials you're comfortable with. Make this a quick sketch, just enough so that your classmates have a sense of what they would do to use your device.
Week 2 Jan 27	Understanding Electricity Breadboards	Lab: Electronics Lab: Setting up a breadboard Lab: Switches
Week 3 Feb 3	Intro to Arduino and first program. Digital Input and Output high current loads and motors controlling DC Motors	Lab: first Arduino program Lab: Transistors Lab: HBridges
Week 4 Feb 10	analog input analog output pulsewidth modulation sound out	Lab: Analog in; tracking changes with variables Lab: servo/analog out Lab: Tone output

Week 5: Feb 17 I/O review

Weeks 6 -9: Communication

In this section, you'll learn more about communication between computers using serial communication.

Readings for section 2:

Norretranders, The User Illusion, Chapter 6: The Bandwidth of Consciousness
Graham Pullin, Design Meets Disability
Hoffman, Visual Intelligence

Technical readings (may help clarify the class discussions and labs):

Physical Computing, chapters 7 - 8, 12, 14
Making Things Talk, chapter 2, 6

Blogging for section 2:

Sensor walk. Take a walk around your neighborhood, or a different one. Take a count of every interaction with a sensor you see. These might include:
- Pushbuttons on an ATM
- motion sensors on doors, faucets, etc.
- Floor mats
- Cameras
Take pictures or video as appropriate, of the most interesting ones.

Week 6 Feb 24	serial communication	LABS: Lab: Serial Output
Week 7 Mar 3	serial communication week 2 multiple sensors Interpreting bytes: ASCII vs. binary handshaking/call-and-response	Lab: Multiple Serial Output
Week 8 Mar 10	complex data communications configuration vs. communication (command move vs. data mode) addressing XBee serial as example protocols discussion
Week 9 Mar 24	Synchronous Serial Communication Shift Registers Multiplexers

Week 10: Mar 31 Communications Review

Weeks 11 - 13: Construction & Project Development

In the final section, you'll develop a final project that demonstrates good physical interaction design. We'll also cover some advanced topics, as appropriate to the projects you're working on. Your final project will most likely be an extension of one of the labs you've already worked on. Or you may develop a new project. ou may work with other students on these if you wish. It's highly recommended.

Reading for section 3:

Rory Hamilton's notes on preparing presentations and giving presentations

Technical readings (may help with specific concepts, depending on your project):

Physical Computing, chapters 9 - 11, 13
Making Things Talk

Blogging for section 3:

Document your project in the ITP Project Database. You may want to do this over the course of the whole section, returning to the various sections as you develop the work. Fill in all sections:Project Title, Project URL/Website, Elevator Pitch/One Liner, Description, Personal Statement, Background(Research), Audience, User Scenario, Implementation(Work Description), Conclusion, and Reference. If you have questions on any of the sections, we'll discuss them in class.
Keep running blog notes on your progress as well.

Week 11: Apr 7 Project concept presentations

present final project concept. Describe the concept, the interaction, and the proposed technologies

Week 12: Apr 14

Present work in progress. Show interface and any working elements.

Week 13: Apr 21

Discuss any remaining technical issues

Week 14: Apr 28 Present final project

Grading

Participation & Attendance: 40%
Production Assignments: 40%
Journal: 20%

Participation & Attendance

Showing up on time, engaging in the class discussion, and offering advice and critique on other projects in the class is a major part of your grade. Please be present and prompt. Lateness will hurt your grade. If you're going to be late or absent, please email your instructor in advance. If you have an emergency, please let your instructor know as soon as you can. Please turn in assignments on time as well.

Laptops

Laptop use is fine if you are using your laptop to present in class, or if we're in the middle of an exercise that makes use of it. Whenever classmates are presenting or we're in the midst of a class discussion, however, please keep your laptop closed. The quality of the class depends in large part on the quality of your attention and active participation, so please respect that and close your lid.

Mobile Phones

Please put them on vibrate or turn them off before you come to class unless they are part of your project. If you have an emergency that requires you to answer your phone during class, please tell your instructor ahead of time.

Lab Assignments

There is a lab activity for nearly every class in the first half of the semester. They are very short, simple activities. These are the basic steps you need to go through to understand the principle discussed in class each week. They're designed to help you not only to understand the technical details, but also to get a feel for what the technologies we're discussing can do, so that you can incorporate them into actual applications. You should at least complete the steps outlined in the lab activity each week, so that you understand practically what it is we're talking about. Document on your blog any discoveries you make, pitfalls you hit, and details not covered in the class or the lab that you think will be useful for your fellow students and future students in this class.

Production Assignments

For production assignments, you'll be expected to present your project in class on the day that it's due. If you're working in a group, all group members should be present, and should participate equally in the presentation.

Journal & Documentation

You are expected to keep an online journal of your progress. The purpose of the journal is twofold. First, it is a valuable way for you to communicate to your instructor that you are keeping up with the work in the class. We read the journals to see how students are doing, so you should update your journal regularly throughout the semester. At a minimum, reference to each week's work is expected, as well as reference to the readings, and thorough documentation of the production projects and technical research. Second, the journal is a way to document your work for your own use and that of others. Many ITP students have found themselves using their journals as a place to store notes, code samples, and more.

Good documentation habits for this class:

You may choose to document your major projects in a separate individual or group site if you choose, but you will be expected to link your site to the main site, and contribute to the class site as well nonetheless. Please avoid flash, shockwave, or other sites that are not text-searchable, as they won't show up on search engines for others to use.

Blogs are great for documenting your process, as they're usually defaulted to organizing the information chronologically. However, projects summarized in a blog can be confusing. It's often worthwhile to set up a separate page or pages to summarize your projects when they're done.

You should document your projects thoroughly. Plan in advance, and perhaps as a group, to have what you need to document at least your midterms and finals. Photos, video, drawings, schematics, and notes are all valuable forms of documentation. Explain the project at the beginning of your documentation, so that people who come to the site from outside this class will understand the overview before they get the explanation.

Don't overload your notes with code. If you've made a big improvement on an existing piece of code, post your new code, and link to the code you based it on (just as you would in citing a pervious author in a paper). If you only changed one part of an existing program, post only the part you changed, and link to the original. Make sure any code you post is well-commented, so you and others can understand what it does.

Always cite the sources of your code, the places you learned techniques from, and the inspirations of your ideas. This is the equivalent to citing your sources in a written paper, and copying code or techniques without attribution is plagiarism. few ideas come out of the blue, and your readers can learn a lot from the sources you learned from or were inspired by.

Good documentation should include a description and illustration of your project. You should include what it looks like, what it does, what the user or participant does in response. It should give enough information that someone from outside ITP, who's never seen the project, can get an understanding of what your project is.

You should also include a section describing the workings of the project, aimed at a more informed reader (me, or next year's classmates), so that the details of production are clear. It doesn't have to include every scrap of code and circuit diagram, but it should make clear what the major components of the system are, and how they communicate, and what the code, if any, does.

Work on this as you go, don't put it off until the end. Your fellow classmates will find your notes as useful too.

Pictures and video help a lot.

Some good project summary sites:

http://www.tweenbots.com/ by Kacie Kinzer
http://tomgerhardt.com/fireLight/ By Tom Gerhardt. Simple project, doesn't need a lot to introduce it.
http://thomas-gerhardt.com/itp/FeltResistor/ Nice explanation of why, and summary of how it works, in a sentence or two.
http://amandabernsohn.com/pinholepaintercamera/about.html Great summary and detail of the process. Complemented well by her partner Chris' blog, journaling the day to day progress: http://itp.nyu.edu/blogs/cdc214/category/physical-computing/

A few good recent sample journals:

Morgen Fleisig's intro to physical computing blog
Alexander Reeder's intro to physical computing blog - concise, clear notes on what he did, code where it's useful, helpful pictures.
Petra Farinha's intro to physical computing blog
Jason Babcock's journal These are notes Jason kept throughout his time at ITP. Each section covers the technical details of a specific project. Sometimes the task is part of a larger project, and sometimes it's a project in itself. This is an excellent example of how to document the tech details of your projects.
John Schimmel John's journal offers good explanations of all of his projects. His post titles are descriptive, so you can skip around and know a bit about what you're getting.
Saranont Limpananont Though his journal is not for the physical computing class, Nont's journal is an excellent example. He combines thoughtful critical reading notes, details on his technical process, and clear descriptions of his projects. His documentation of Physical SimVillage is a good example of a summary of the project that's independent from his working notes.