2.6. Project 2: Temporal Machine

The goal of this project is to create a behavior in a physical system which engages with the time scale of a human or natural system. The human body has its own set of natural time scales ranging from a single heartbeat to a lifespan. We have a set of familiar rhythms including breathing, walking, and sleeping. Familiar natural processes include the fast vibrations of sound, planetary rhythms (days, lunar months, solar year), and the slow changes of geological time. Perhaps less familiar are the time scales from the femtosecond periods (1e-15) of the vibrations of molecules and light to the exasecond scale (1e18) of the life the universe (roughly 0.435 exaseconds and counting).

Most machines we construct are intended to have constant and perpetual qualities: a spoon or a table are probably most useful if they act the same at every encounter and last as long as possible. But machines with dynamic or active processes behave according to a tempo, pace or rhythm: doors take time to open, washing machine cycles have a duration, bicycle gears relate speed and pedaling rate. If these tempos interfere with our own abilities to perceive or act it can be jarring or confusing. For this project, the goal is to choose a specific temporal quality to control and articulate how it affects an outcome.

There are a number of directions this project might take. A few suggested starting points follow for brainstorming project ideas.

  1. Musical machines which create rhythms.
  2. Machine behavior much faster or slower than human perception.
  3. Behavior which synchronizes to a human or natural process.
  4. Clocks, calendars, and orreries.
  5. Controlling the tempo of an existing device, either to make it more harmonious or more frustrating.
  6. Devices or robots which animate normally inanimate things.
  7. Devices to measure and respond to human temporal cues or performance.
  8. Augmentation devices to extend the range of human time perception.
  9. Machines which sense or guide a process in Nature, e.g., measuring plant growth or sculpting runoff erosion.
  10. Kinetic sculptures with a natural finite lifespan.

Some more specific inspirations:

If a quorum of projects relate to music, we may be able to show them to the outreach educators of the Pittsburgh Symphony as a starting point for future collaborations.

We are also planning an IDeATe open house in late October, so your project may be recommended for a showing within the campus community.

2.6.1. Objectives

A key objective of this project is finding the underlying temporal questions within one of your big ideas. As always, a guiding principle of the course is that all ideas can be rendered at all scales, so the objective is to focus that question into a simple prototype to explore it physically. Our goal is to keep the deliverable objectives modest so the production process is not onerous.

Physical systems interact with time at a wide range of scales. The inclusion of computational processes provide a rich set of resources for how time is addressed. A key learning objective is understanding the computational opportunities including timing measurement, rhythm and pattern generation, and trajectory control. This will help with learning to segment an overall behavior into physical structures with appropriate dynamics and the complementary algorithmic structures.

As before, these are intended to be research and exploration projects. Reasonable ambition is encouraged, so we’d like you to try new things, and failure is part of the process. However, we will attempt to guide you away from directions which we think are unlikely to succeed or require unreasonable levels of effort. But you are the ultimate arbiter of this: we won’t outright say no because we want you to learn to assess your own ambitions and skills and don’t want to stand in your way.

2.6.2. Milestones

(Most of this is the same as the Project 1 milestones, except for bold-face text.)

  1. Pair selection. We prefer that students work in pairs. Solo workers and groups of three will need to make a pitch for an exception. Groups of four are too large for this project.
  2. Proposal. See Proposal Prompt for specifics. Ideas are cheap; it is in the exploration that the interesting work begins. We recommend a strategy of committing to a general idea early and then thinking through as many details as possible at the drawing and planning stage. We find this is much more efficient that jumping into building too soon.
  3. Proof-of-concept. Nearly every proposal plan leads to a set of key questions which form the primary hurdles. We recommend a strategy of choosing a quick experiment to tackle the most difficult part first. Either the unknowns will resolve into a feasible development plan or you can fail fast on one approach and revert to another. Either way, you won’t have wasted effort on secondary development which becomes obviated by a problem. The proof of concept will usually be a partial prototype, and in many cases it can be modified into a full prototype if successful.
  4. Presentation and in-class critique. See In-Class Project Reviews. An important learning goal of the course is clear and efficient communication between disciplines, and the critiques provide an opportunity to hone your skills. Ideally, your project will be functional and you can perhaps give a live demonstration and succinct explanation. If your project has failed, then please explain why and how it failed and whether there is a general lesson to be learned. Our critiques will consider the relative difficulty of the attempt. Ambitious project ideas frequently do not work out as expected but can still be reframed to expose an alternative interpretation as well as explain the hidden traps of the original idea.
  5. Report. See Project Reports. For all of our projects, the documentation is the most tangible and durable work product. It is also an important stage for reviewing and reflecting on the process and outcome. The same considerations about success and failure outlined above also apply to the written documentation. The report due date comes two days after critique to allow incorporating verbal feedback.
  6. Peer evaluation. Each individual should write a brief Project 1 Peer Evaluation Form response about your partner or teammates to be submitted confidentially. This serves two functions: it is the primary opportunity for you to reflect on the collaborative process itself, and it helps your instructors identify potential collaboration issues.
  7. Disassembly. Unfortunately, we do not have enough parts and resources to keep all projects intact even for the duration of the semester. Unless your project is designated to keep for the open house show, please disassemble all components and return them to the storage bins. This may seem obvious, but please be sure to complete all documentation prior to this point: students frequently end up taking something apart and then wishing they had one more photo or video.

2.6.3. Proposal Prompt

(Most of this is the same as the Project 1 prompt, except for bold-face text.)

The proposal is the counterpart to the final report: ideally, it raises all the questions which the project might answer, even though more will be discovered during the process.

The primary review of the proposal will be verbal in-class commentary in order to provide the fastest possible approval. To speed this along, please provide in-class a one-page document which concisely summarizes the project plan. Please also submit a PDF version of the document to Blackboard before the end of the day on which the proposal review occurs. Only one document need be submitted per group, but be sure to include the names of all contributors.

A good proposal will answer as many of the following questions as pertinent. These are prompts, not a checklist, so use your judgment as to how to formulate a brief proposal text or outline with supporting sketches.

  1. What is your big idea, in a sentence or two? How does your prototype relate to a rhythm, tempo, or time scale of that process?
  2. If you apply why-how laddering, can you identify an essential underlying question? What is the simplest abstraction of your idea?
  3. Who is the audience? This might include user, viewers, or passive bystanders. What is the experience of the audience? What might they remember?
  4. Are there existing projects you have referenced? Please include citations.
  5. What will your proof-of-concept entail? Can you sketch it? Can you sketch the engineering elements (circuits, mechanical drawings)? Good drawings at this stage are invaluable, they can identify many potential problems much more efficiently than fabrication.
  6. How do you propose to divide the tasks among the team? What roles will you each undertake and for which parts?
  7. What features do you specifically propose to ignore? E.g., a project involving a wearable device could focus on sensing and actuation but choose to ignore battery operation in favor of a wired supply. In general, we’d prefer you keep your workload under control by emphasizing interesting behavior or interactivity over fit and finish.
  8. What features do you specifically propose to test? How will we know if it worked?
  9. How might the final project look? Can you sketch it?

2.6.4. Summary of Deliverables

The following material is included in this brief by reference. Please familiarize yourself with the details of the documentation requirements and schedule.

I’ve been refining the description of the project reports in response to the first project. Specifically, the purpose of the report is to present the project as a completed artifact or demonstration. The emphasis is on relating its performance to the human needs of the objectives and explaining the technical choices of the implementation. The details of the development process are only important to the degree to which they explain specific features of the outcome.

  1. In-class proposal review and supporting PDF file.
  2. In-class demonstration of proof-of-concept.
  3. In-class presentation of result for critique.
  4. Report zip file package as per Project Reports
  5. Please keep the linked project video to less than two minutes.
  6. PDF or plain text file for peer evaluation.