After introducing our concept to the class, we went back and adjusted the concept to include a computer using processing and serial input/output rather than running the entire experience off of an Arduino. Unfortunately, NYU won't permit us to install the experience in an elevator at school. This was a dissapointing decision, but we are working to find another location where we can finish the project.
Overall, the playtest feedback was positive and incredibly valuable. However, we experienced a few problems which will need to be resolved before the final.
Response from Playtest
We invited people to ride the elevator without explaining the purpose of the experience and asked them to fill out a survey. (try it out here: https://fnnl.it/hjr) In addition, a number of non-ITP people were riding the elevator and seemed to enjoy the experience and were interested in a moment of soothing lighting/music. We ended up testing with the GE christmas lights, a very simple lighting sequence (white 'normal' lighting at stops & colored sequences while the elevator was in motion). After reading some of the first survey responses where riders wrote that they felt the experience was missing audio, Allie used her iPhone to simulate the music we plan to play while the elevator moves. Later riders responded well to the combination of soothing music and lighting.
Because of the way we were able to temporarily install the lights, they were mostly at eye level. Many people wanted to touch and interact with the lights, which is a concept that we didn't intend to explore.
Comments from Survey
“Keep the elevator lights off the whole time” “liked the soothing happy music!” “(lights on) ceiling and sound activated(ding)!” “more consistent changes, stuff I can latch on to and understand” “problem: distraction for people to realize which floor they will go to" "suggestion: make people closer/ people can play with it” “maybe the color change can be more obvious. Because ppl wont notice color change when they see the lights for the first time” “more lights, more immersive” “more extreme lighting change” “more consistent repetitious movement/ light changes so I could figure out the pattern. it was enjoyable but I was unclear of the point, is it a game or just a pleasant show?” “more lights” “Add more lights! I was also trying to follow the movement of the lights – they seemed to be lighting up in some sort of sequence – maybe if this is more extrapolated the experience would be more immersive” “Hide the hardware – the music was a really nice touch. Maybe the pitch can change with the acceleration too.”
Lighting Script Challenges
For the playtest we used a set of GE holiday lights that let you control each individual bulb separately. A hobbyist wrote an Arduino library to use with the lights, but the code is a complex mix of low level C code and Arduino styled stuff in-between. We spent a significant amount of time trying to write light programs but they didn't really create the smooth effect that we had envisioned.
We ended up creating a script that cycled through different brightnesses of one color [we tried blue, green and orange]. I'm pretty sure that part of the challenge we're having with programming light patterns is we aren't super sure what the best method is for sequencing everything… perhaps arrays? It's surprisingly mathematically complex to program interesting lighting sequences. Our code used nested for loops to cycle through the lighting patterns.
After the experience of the playtest we determined it may just be best to purchase LED strips that are explicitly designed to work with a microcontroller.
Serial / Accelerometer Noise Challenges
Before the playtest, we rewrote our processing code in a more organized and (what was expected to be) simpler setup. We ended up having problems with the handshake serial method & getting the sequences to reset properly and had to revert back to older code. We also encountered strange accelerometer readings that were far out of bounds and caused the logic of the sequence to fail. As a temporary measure, we checked if the value was more or less than 200 from the last value and prevented a jump from 625 to numbers like -4.
The digital accelerometer we are waiting for, which uses I2C to communicate & allows us to adjust the G force sensitivity should resolve this problem. We also had difficulty figuring out the appropriate threshold for activating sequences. Currently, we set a force value and count the number of values that exceed that value. When a number of different values are detected, we start the sequence. (This was an attempt to prevent a false start from a momentarily fluctuation)
We also encountered a problem where the beginning of a stop of an elevator movement would be detected and the lights would reset back to normal, but a new sequence would begin immediately because the elevator still had not come to a complete stop. Placing delays in the code were not especially successful at preventing this issue. Perhaps a timer based on millis would be a better solution?