Installation Art
System Configuration
|------|
| mp | ---> D_out
|------|
^
.
.
.
v
|------|
A_in ---> | mc |
|------|
In this module, we break the physical link between the microcontroller and the server and explore wireless methods of data communication including wi-fi, BlueTooth, BlueTooth Low Energy. Simultaneously, we encounter and incorporate technical and artistic motivations for autonomous creative systems that are potentially transparent to the viewer/listener. Those technologies include power considerations. The aesthetic considerations relate to the acousmatic - the heard but not seen.
Weighing options
At first glance, WiFi and Bluetooth accomplish roughly the same goal - to have a wireless link that can send data. Upon closer inspection, the technical differences between these technologies has important consequences for the creative design of a system. In asking “how do we move away from tethered interaction?” we implicitly ask, “what is the benefit of going wireless?” and “what are artistically motivated reasons for communicating wirelessly?” In looking at WiFi, Bluetooth and BLE, we need to consider constraints such as power, possible network topologies, device support, and bandwidth.
In terms of power, we generally see a tradeoff where more power allows for greater range, or greater bandwidth. In the case of WiFi, the most expensive communication method of the three, we achieve greater range. When comparing Bluetooth and Bluetooth Low Energy, we see a larger difference in general between the data transfer rate than the range. In all cases, devices may run at different power levels, so giving an absolute range is not possible for each technology. Both bandwidth and range will also depend on environmental interference, such as other networks, or physical obstacles in the room that do not let a signal pass through. As an example, European houses (often made of thick stone walls) have more trouble propagating a WiFi signal than within the smaller wooden/drywall walls of American style houses.
Power will also influence form factor. By going wireless, your device may be untethered, but then must supply its own power. To do this will most often require a battery (usually LiPo - see appendix for more). Some key considerations for choosing a battery will be cost and size (both physical form and total milliAmp hours (mAh)). Before choosing a battery size, think about the use case of your device - how long does it need to run for, can the battery be switched out during a performance, how long is such a performance, how intense is the computation for this application? You should be able to find rough estimates on the power consumption cost of your hardware in various modes of operation (eg. computation vs WiFi broadcast).
Again thinking of the actual use case of the device, consider what network topologies are most conducive to your artistic vision. While we address more complex topologies in Module 6 on Distributed Systems, even with two devices, there are considerations to make. For example, when using WiFi, most devices can only connect to one network at a time. If your device requires users to connect (for example, with their phone) to your local WiFi network, that will force users off of any other WiFi network. Even within WiFi, the ESP32 can work as both an Access Point (also called a hotspot), but also as a Station (a device connecting to an existing network). When possible, using the ESP32 as an Access Point is more reliable, as you do not need to rely on any configuration of an existing network.
Device support is also an issue. For example, if interfacing with mobile phones, Bluetooth only has native support. That is, to communicate with phones over Bluetooth, you will need to write native apps. In contrast, a WiFi network can allow users to open their browser and access interfaces you build and host on your device. In the case of the ESP32, this might include a website that displays a button allowing users to turn an LED on and off (see appendix for activity).
When sending messages over a network, you must also consider the protocol and message format. For most embedded systems UDP (faster, easier to set up, but may drop some packets) is the best solutions, as sensor values are continuously streamed from a device. As always, context will dictate whether, TCP or UDP is the right choice. You may consider packaging messages as OSC, when the language support is available.
Module 3 Project: Cutting the cord
Due Monday March 1
Aesthetic Challenges:
The project for this module challenges you artistically in two ways.
First, you must contemplate and ultimately resolve the effect that removing the traditional or expected 1:1, action/reaction/, cause/consequence or process/product pairs that typical installation art has on the viewer or listener. We will refer to this as the “unseen effect”. To begin to address this you will have to define the high/low latency components of your system, both technically and conceptually.
Second, to reinforce and possibly assist you in answering the above question, you will be required to both conceive of and design your system combinatorially. That is, you must continue to develop new, creative pathways while incorporating your previous experiences through the reuse of components and algorithms possibly in new, transformed ways.
Technical Challenges:
Technically, your project must be designed to take advantage of the new system configuration, specifically 1) wireless communications and 2) battery-powered potential. Previous sensors are in play, as are any other sensors available in your kit.
You also have a battery (3.7V 650 mAh - provided to those on campus) to allow for a true “wireless” experience.
Design Prompts:
If your project is mobile, who will move it and how? How can your (or your classmates) Module 2 project inform your design decisions this time around?
Your system components may be visible or masked, a plexiglass homage to form as function or a black box – impenetrable and imperceivable.
If your project is immobile, but untethered, might its physical form hint at this reality?
Component Quick Info:
Piezoelectric sensors detect vibration – that means that, provided the sensor is mounted tightly to an object, touching the object will result in voltage from the sensor. Useful to detect touch and motion (if the motion results in vibration, such as rolling on wheels across gravel…)
Ambient light sensors (photoresistors) are good (sensitive) and dirt cheap. Useful for detecting… light. But if light is stationary and system is mobile, can be used to detect motion/orientation of the system itself.
Code Deliverables
(10 pts) A link to your git repository with a program that runs on the ESP32 (possibly also the Raspberry Pi) that wirelessly communicates sensor data to a client computer for visualization or sonification. If you do not submit code you will not be awarded any points for the code deliverables section. The program must meet the following criteria:
- (5 pts) require wirelessness (convincingly) by addressing, in physical design and realization, the issue of “unseen effect.”
- (4 pts) Successfully combine earlier system configurations through use/reuse of sensors, config code, and physical design principles.
- (1 pts) Is in the spirit of the class as broadly interpreted by the instructors. Art is subjective, we want you to get comfortable with this ethos.
Standard Documentation Deliverables:
10 points
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.
A README
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).