Note: My documentation for the process behind our midterm was pretty abysmal along the way. There are lots of moments in the following discussion where I wanted to have a picture or video but didn’t take anything at the time. It was a great learning experience for next time, though doesn’t improve the wall of text that this has turned into.
My partner for the PComp midterm has been Danielle Butler. We are also working on the same team for Outrage Machine, and we wanted to explore the multi-faceted concept of privilege with our midterm as a warm-up for that larger project. We quickly decided we were trying to tackle too much with a one-week assignment, and pared it back to one dimension of privilege, then gravitated away from that a bit and towards a fun game controlled with the head. In a way, it’s asking the user to try something in a way that they are not accustomed to, and in that way could be seen as a way to begin a conversation about ableism and the privileges enjoyed by non-disabled folks.
Our first step was to get a sensor working the way we wanted. Benedetta suggested either an accelerometer or a tilt switch. We obtained one of each and split up figuring them out, with me taking the accelerometer and Danielle working with the tilt switch. The tilt switch is fairly easy to understand in theory, but I still am not completely clear about the science behind the accelerometer. Nonetheless, I was able to wire it correctly with an arduino and my computer fairly quickly and begin to obtain values. The values were strange to say the least. They ranged from about 250 to 400, with 330 being the value returned when the sensor was flat. Through the use of if statements, I managed to make a ball move when the sensor was tilted past a certain point in one of the four major directions, and stop when it was tilted back. At that point, the midterm became a matter of designing an interesting program in p5.js and ensuring that the physical device would work properly on a person’s head.
We did a lot of brainstorming, and came up with many program ideas that would not have been possible in the time available to us. We settled on a game that involved driving a car around a circular track, but even that ended up being more complicated than expected. The main challenge was constraining the car to the track. Unlike a ball bouncing around a screen, we couldn’t simply multiply the speed by -1 if it hit the side of the track; if we set the speed to 0, however, the program would no longer respond to sensor values but would constantly reset the speeds to 0 regardless of serial input. The circular shape also presented a challenge compared to a square for constraining position.
The solution was to go with the same concept of the bouncing ball, multiplying the speed by -1. It’s not terribly intuitive how that works, but essentially the sensor data will continue to correct this number after it is set. If the head remains tilted in the direction it was tilted in to cause the collision, the speed will be reset to the previous value; if it tilts to flat, the speed will become 0; and if it tilts in the opposite direction, it will continue on the path set by the program after the collision. This eliminates the issue of getting “stuck.”
We are still testing for speed and sensor sensitivity, but we’re very excited to show our prototype in class and see how well people do trying to drive with their heads!