Choose your own adventure! Any system configuration goes for the final project.
|------| D_out---> | mp | ---> D_out |------| ^ ^ . | . | . | v v |------| |------| A_in ---> | mc | <---> | mc | |------| |------|
The final module of the class is an open-ended exploration of system configurations we have explored in class. Students are required to use a minimum set of sensors, actuators, and digital outputs in their own designs.
Due Friday April 23 (absolutely no late work can be accepted per college policy!)
Proposal due Sunday April 4
The final project is a chance for you to synthesize the topics we have covered so far in class (and the topics we will soon cover). This project may be a group project of groups of up to three. If this is a group project, at least two ESP32s must be used and communicate directly with each other using wifi, bluetooth, or ESP-NOW (the ESP32 specific communication protocol - covered briefly in class 13).
(5 points) A short plaintext description of your idea submitted to CourseWorks. Include in your proposal:
- a high level description of the idea (1 paragraphs)
- a plan for the major checkpoints (with dates) you need to hit in order to accomplish that idea (a list including at least 4 checkpoints)
- the new piece of hardware or software you will include (1 paragraph - why this piece and what resources will you utilize to learn how this work)
(25 pts) A link to your git repository with a program that runs on at least one ESP32 (possibly also the Raspberry Pi).
The formal requirements are even more open ended than previous modules.
You must utilize some technique we have not yet covered in class. That could take the form of a new piece of hardware from your kit, a new piece of hardware you own/buy on your own, or a new software technique. New software techniques might include utilizing the multicore processor (as covered in class 27 on March 24), communicating between multiple ESP32s, or using the ESP-IDF development toolchain (to be covered in class 30 on March 31).
Beyond this, simply follow the same documentation guidelines we have established in prior assignments.
Standard Documentation Deliverables:
In addition to the project specific deliverables lists above, you must also meet the following “standard documentation deliverables”. Throughout this course, we will ask you to document your work in order to slowly build a portfolio of your projects. Going forward, these types of standard documentation deliverables can be assumed to be required for all assignments unless specified otherwise.
A blog post
Using the CoursePress site available through Canvas, make a blog post describing your art. The post should give an overview of your artistic vision. In particular for this assignment, you should address how you have specialized your generative art to the space. What creative decisions did you work lead you to, and which decisions did you take? How were your decisions motivated by your large creative vision for this project. In the same vein, also address any technical issues you encountered in your work. Particularly focus on issues that other artists may encounter when developing a generative art display for this space.
On your github repo add a readme that contains a short description and key information on reproducibility/installation/usage. This key information should be sufficient for a knowledge third party, outside the class, to replicate your design. This readme can/should be a subset of the material used in your CoursePress blog post.
A video of your art
Include in the README a link to your video. The video can be a simple video shot on your phone - the only goal is to have a record of your art in action. You can host the video wherever you like as long as the hosting platform supports in-browser playback (e.g. YouTube, Vimeo).