Final Project – Team VARPEX

Richter Threads

Group Name and Number: VARPEX, Group 9

Group Members: Abbi, Dillon, Prerna and Sam

Project Description

Richter Threads is a jacket that creates a new private music listening experience through motors which vibrate with bass.

Previous Blog Posts:

Video

Changes Since P6

  • New protoboard with components soldered on: In our feedback from P5, many of our subjects complained that the box they had to carry around containing the system was cumbersome. To create a sleeker and more integrated experience, we soldered our system onto a small protoboard that could be affixed with velcro inside the jacket. The prototype box is no longer necessary.
  • Velcro fasteners for motors: The cloth pockets were not effective at holding the motors; we needed to sew them in our last prototype. For this iteration we put velcro inside the jacket and velcro on the motors to make them easier to attach and detach. This also enhances sensation from the motors since there is not an additional layer of cloth over them
  • Threshold potentiometer: We discovered in P6 that users liked being able to use their own music, but different music pumps out different bass frequencies. To allow users to change the threshold of bass volume needed for the jackets to vibrate, we included a knob users could use to adjust the amount of bass required to vibrate the motors when listening to their music.
  • Volume knob: We reversed the direction of the volume knob to make it more intuitive (turning clockwise increases the volume now).
  • New sweater: We chose a much more stylish and, more importantly, a better-fitting sweater for our system, since no one found our original sweater particularly attractive or comfortable.
  • Power switch: We added a power switch for just the batteries, to allow people to more easily listen to their music without the jacket on.
  • Length of motor wires: We lengthened some of the wires driving the motors, so that the jacket would be easier to put on despite the presence of a lot of wires.
  • “Internalizing” components: The board is affixed to the inside of the jacket while the controls (volume/threshold knob, power switch) are embedded in the pocket of the jacket to make the entire system more conspicuously hidden.
  • Batteries consolidated: Our battery pack has been consolidated and secured in a different part of the jacket. The batteries impose a large space bottleneck on our design (hard to miniaturize power needs like we did the board), so they require special placement within the jacket.

Evolution of Goals and Design

Our goals over the course of prototyping definitely broadened as we received feedback from users. The original inspiration for the jacket was the dubstep and electronica genres, which are known for being bass-heavy. In testing however, users responded positively to listening to other genres of music through the headphones; by limiting our goals to representing the concert going experience for dubstep/electronica, we were missing out on exploring the potential of the jacket in other musical genres. This development actually lead to a concrete design change when we added a threshold knob to allow users to adjust the sensitivity of the jacket. This actually leads into a different change in goals. Though we set out to replicate the concert-going experience, we succeeded in creating a unique experience in its own right. Our jacket offers users a tactile experience with music beyond mimicking large subwoofers.

As for our design, our early design goals sought to use an Arduino to perform the audio processing needed to filter low bass frequencies to actuate the motors. We quickly learned that this introduced a delay, and unfortunately in music-related applications, any delay can make the application useless. We found an excellent solution however, by implementing a low-pass filter with a threshold to actuate the motors in an analog circuit. This design change also allowed us to work on making the circuit more compact and portable with every iteration of our design. It also eliminates the need for a lot of complicated set-up of a microcontroller; it is hard to imagine that the set-up with an Arduino would have been as easy as plugging in your mp3 player and headphones and turning the jacket on, as it is in our current design.

 Project Evaluation

We will continue to create improved iterations of this jacket in the future. The users who have tested our project have expressed interest in the experience our jacket had to offer, and through the prototyping process we have worked on making the system as portable and inconspicuous as possible. In our last two iterations alone, we moved our system from a bulky box containing our hardware to a much smaller protoboard that we could embed in the inside of the jacket. If we ever wanted to produce this jacket for sale, surface mounted circuits could be made to decrease the electronic size even further. As our jacket stands right now, the jacket does not outwardly appear to be anything but a normal hoodie jacket. It is this sort of form factor that we think people could be interested in owning.

We worked in an applications space we would label as “entertainment electronics.” The challenge this space poses to us is that user ratings are, at their core, almost entirely subjective. We had to evaluate areas like user comfort and the quality of a “sensation,” none of which can really be independently tested or verified. In a way, our design goals boil down to going after a sort of “coolness factor,” and our real challenge was making the jacket as interesting of an experience as possible while minimizing the obstacles to usage. For instance, in P6, people reported difficulty in having to carry around a box that contained the system’s hardware, and while they liked the sensation of the jacket they found the form factor cumbersome. We sought to fix this in our final iteration of the jacket’s design- it is now as comfortable and inconspicuous as a normal jacket, which we hope would allow people to see the jacket as something purely fun at no cost of convenience.

We set out with the goal of replicating a concert-going experience, but in the process created something new entirely. We believe we were successful in the regard of giving something “cool” to people that brought them joy. It is not clear to us what sort of objective measures alone could have achieved this. While we could have strictly timed how long it took people to figure out how our jacket worked, for example, this wouldn’t have informed us about what people really would want out of our system. While we had tasks in mind when we set out to build and test our jacket, the users themselves came up with their own tasks (the jacket’s benefits in silent discos or at sculpture gardens, its uses in a variety of musical genres, etc) that forced us to consider our jacket beyond the narrow goals we had defined for ourselves. It is this sort of feedback that makes designing for entertainment an exciting and dynamic application space.

 Future Plans

If we had more time, we would form a product as sleek, comfortable, and safe as a normal jacket. We would address problems introduced by moisture (sweating or rain) to ensure user safety and proper functioning. In order for this to become a product used in the long term, these concerns must be addressed. Next, we would seek to minimize the impact of the hardware within the jacket. We would use smaller, more flexible wires to attach to the motors. Printed circuit boards would decrease the size of the circuitry and we would optimize the layout of the components. In even further iterations, we would use surface mount electronics to decrease the size of the electronics. We would also like to find a better power solution. For instance, a 9.6V NiCd rechargeable battery would be capable of supplying the necessary current for each of the voltage regulators and can fit in a better form factor. It would also prevent users from having to periodically buy new batteries. We would also test the battery-life of the device to determine acceptable trade-offs between physical battery size and total battery energy. The motors would also be integrated into a removable lining which would hold down the wires and improve the washability and durability of the jacket. We would like to add additional features, including automatic threshold adjustment and a pause button. These new features will require additional understanding of analog electronics and the standards for audio signals on different mobile devices.

The next stages of user testing would inform our decisions about battery type and the long-term usability of the jacket. We would have different sizes of the jacket so we can accommodate users of many body sizes, and we would ideally give the jacket to users for several hours or over the course of days to get quality feedback about practicality and durability. These experiments would also help us understand how users react to the jacket’s sensations after their novelty has worn off. This user testing could further shed light on additional features we might add to the jacket.

 README

How it works:

A male auxiliary cable plugs into a user’s music player and receives the audio signal. The signals from each of the two channels are fed to a dual potentiometer to reduce the volume for the user. The ground of this potentiometer is at VREF (1.56V) because a DC offset is needed in order to keep all the audio information with single supply op-amps. The output of this potentiometer is fed to a female auxiliary cable where the user plugs in headphones. One channel of the audio is also fed to a voltage follower which helps protect the signal from the rest of our circuit. This signal then goes to a low-pass filter which filters out frequencies above 160 Hz. The filtered signal is compared to a threshold value to determine the gate signal for the transistors. When each transistor turns on, current flows through its corresponding motor pair. The circuit is powered through three 9V batteries, each attached to a 5V voltage regulator (L705CVs). Two of the batteries power the motors, which draw significant current, and the third battery powers the operational amplifiers used for the comparator and voltage follower.

Schematics

XRSrJHj zNY6syP bTPJ270

 Budget

Since our project is mostly hardware based, we’ve included a parts list and final budget below.

Item

Quantity

Price ($)

Total Cost/Item

L7805CV Voltage Regulator

3

$.59

$1.77

PN2222A Transistor

6

$.32

$1.92

LM358 Dual Op-amp

2

$.58

$1.16

motor

12

$1.95

$23.40

protoboard

1

$6.50

$6.50

10k dual potentiometer

2

$1.99

$3.98

switch

2

$1.03

$2.06

battery clips

3

$1.20

$3.60

capacitor (.1uF)

15

$0.30

$4.50

capacitor (1.0uF)

2

$0.30

$.60

1N4001

7

$0.08

$.56

misc.

1

$1.00

$1.00

Total

$51.05

 Third Party Code

In earlier iterations, we attempted to use the Arduino to do the audio processing.

http://wiki.openmusiclabs.com/wiki/ArduinoFFT

Demo Materials

https://www.dropbox.com/sh/qxxsu30yclbh7l1/wv1qeXYeM-

 

Group 9 (VARPEX) – P6

Group Number and Name: Group 9, Varpex

Group Members: Abbi, Dillon, Prerna and Sam

Project Summary: Our project provides a new musical listening experience through a jacket that vibrates with the bass.

Introduction

Over the past few months, we have developed a jacket that provides a new means of experiencing music. There are 12 motors that line the jacket and provide sensation. There is a box that plugs into the jacket and produces the sensation. A user puts on the jacket, plugs in their headphones and MP3 player to the box, and connects the jacket to the box. They play their music using their MP3 player and this causes vibration of the motors. In this report, we evaluate the ease of setup of the system and how well it provides an enjoyable experience for our users. This experience includes both listening to music with the sensation of the motors while sitting and walking and the experience when the music is off and participants wear it as they would a normal jacket.

Implementation and Improvements

Please click here for our P5 submission

Changes since P5:

  • New box: We switched to a plastic box because we were concerned about the possibility of the cardboard igniting from a spark should something go wrong with the electronics.

  • We labelled the ports on the box for clarity.

Method

1. Participants

We solicited volunteers through our eating clubs and student organizations. The students that responded expressed interest in trying our prototype, knowing that its purpose was providing a new way of experiencing music. The students that ultimately tried the jacket all enjoyed music, but often of different genres. All enjoyed the feeling of music experienced when listening to live music. We tried to draw from the general student body so these students had a wide range of technical and musical knowledge. Participants were all aged 19-21, students at the university, and live in dormitories.

2. Apparatus

The tests were conducted in the undergraduate ELE lab. We chose to perform the tests there so we could more easily troubleshoot any technical problems with our system. The equipment we used were a set of headphones, a phone-based mp3 player, our jacket of embedded motors and the box containing our system. These items together represent the complete set-up one would need to actually use our system in a non-lab setting, so we are confident that the testing we do today represents well how someone might actually use our system to feel music in real life.

3. Tasks

As in the past, our system does not exactly conform to the “three tasks” paradigm. Our study, however, does try to give the user a sense of how they might use the jacket in one of the three settings we have described previously: listening to music in your room (easy),  listening to music in a public library (medium), listening to music while walking out and about (hard). They are little changed from P5. These tasks represent three times when people commonly listen to music via headphones. In this scenario, participants listened to music first while sitting in a chair as well as while interacting with us for the first part of the testing phase. We then had the users stand up and walk around the lab a few times while listening to music. These scenarios gave us a good idea of how users would react in the three original tasks.

4. Procedure

We first welcomed our participants and they filled out the consent form and the first page of our google form. This form asked demographic information and asked about music preferences. After they filled out this initial form, we explained the system to the user and asked them to set it up. We gave them an overall description but did not give them specific instructions for setup. Participants then set up the system and asked questions when necessary. We asked for their initial feedback on the setup process and confusing aspects of the design. Next, we had them listen to music for few minutes however they felt comfortable. We then asked for their feedback about the jacket without any music playing (and no vibrations). We also went through a series of questions to understand how pleasurable the experience was and where it could be improved. As we interviewed participants, we observed their behavior for fidgeting and signs of discomfort. Participants then walked around with the system to test how it felt while walking. We asked for feedback on comfort and sensation in this task as well. At the end, we opened a general conversation with the participant about the experience and asked how it could be improved.

Test Measures

As mentioned before, our prototype is not directed towards helping a user improve any sort of objective measure of a task. Therefore our testing sought to solicit subjective evaluations of things like comfort, sensation, and likelihood of using the jacket for one of the three tasks we thought would be good usage scenarios.

We ultimately collected a wide variety of subjective measures. Questions regarding ratings were asked on a scale of 0-5. For the full list of questions, see the Google form in the appendix. The subject matter of the data collected included:

Demographic Data:

  • Musical preferences/opinions of electronica
  • Frequency of concert-going
  • Frequency of music-listening outside of live music setting

Ease-of-use data:

  • Logs of users attempting to use jacket with little-to-no instruction
  • Self-evaluation of difficulty in putting on jacket
  • User perception of valuable information in jacket-use instructions

Comfort/Likelihood of use data:

  • Comfort of jacket relative to a non-vibrating jacket when jacket is off.
  • Comfort of jacket while sitting down and standing up.
  • Adjectives used to describe jacket.
  • Likelihood of using jacket relative to amount user currently listens to music in different settings.
  • Desire to own jacket.

Results and Discussion

Our test subjects came to us with a diverse array of musical interests- when asked for their top three musical genres, over 12 distinct genres were named among the subjects. Interestingly only one of them named “electronica” in their top three, which was one of the genres we had targeted as a good candidate for “feeling” music. No matter what their tastes were reported to be we first had the users test the jacket using the song “Thunder Bay” by Hudson Mohawke. One of our users who described dubstep as “overrated, boring, tuneless” still reported a positive experience with the jacket, describing it as “fun” and “interesting.” When we asked users to try the jacket with their preferred music, however, they responded much more positively- that same user with a lower opinion of dubstep and electronica later tried the jacket with music from her favorite artist (“Bad Romance” by Lady Gaga), and reported an even more positive experience. This is a promising development that could expand our target user base, but it will require some modification of the jacket. Currently, the jacket is capable of responding to frequencies below 160 Hz. The intensity of vibrations is controlled by a comparator which allows current to flow through the motors for a particular fraction of the given low frequency wave. In genres like dubstep with lots of heavy bass, this fraction can be fairly low and still produce lots of sensation since the dominating frequencies are below 160 Hz. In other genres, the concentration of bass is lower so this fraction needs to be increased to produce a comparable sensation. We can give the user the ability to adjust this fraction using a potentiometer so they can calibrate it themselves to the best sensitivity of their preferred music. (Perhaps this could even be done in a future iteration on a microcontroller like the Arduino, where a simple pre-processing step could analyze a song to find the ideal threshold level with no overhead for the actual performance of the jacket). It’s certainly a functionality that people seemed to expect already; it appeared that people would play with the volume knob in our usability test in the expectation that it would modify the sensitivity of the bass already, so adding that function is definitely appropriate.

We were also pleased to see that users rated the comfort of the jacket highly- on a scale of 0-5, 0 being not at all comfortable and 5 being as comfortable as any other jacket, the users rated the jacket on average as a 4.1 when worn while sitting down, and a 3.5 when standing up and walking. There were other factors, however, that affected the user experience when wearing the jacket. Users- generally women of shorter stature- reported that the jacket’s loose-fit may have interfered with their ability to receive the full effect of the vibrating motors. Further, no one said that they would describe the jacket as “fashionable.” Three of the users even went as far as to say they would describe the jacket as “ugly.” Jacket fit between users was always going to be an issue, since a men’s hoodie can only fit so many people. In a next iteration however we will try to make the vibrating motor assembly more easily secured to the jacket using velcro rather than sewn-on pockets for the motors. That way, it can be more easily placed in jackets of varying style and size. Another inhibiting factor on user comfort was the fact that while up and walking, the users had to carry around the box containing our system with them. This was unfortunately a limitation on our prototype, which was implemented on two small breadboards attached to the three 9-volt batteries needed. In our next iteration we are exploring the possibility of soldering the project to a protoboard to allow for a more portable form-factor. In the meantime, we have to put the issue of the large box aside as our own version of a “wizard-of-oz” set up, since we never really expected that users would have to carry it around.

People generally found the jacket easy and intuitive to use, but certain prototyping aspects were noted to be cumbersome. The test subjects all said that having to carry around a bulky box was inconvenient, and a more intuitive plug and play interface easily built into the jacket would be preferable. Test subjects also found the direction of the volume knob unintuitive since it rotated in the opposite direction to standard knobs. Both these interface issues are ones which we plan to address and fix in the next prototype. Another important design idea which emerged from this stage of testing was customizability. Fit of the jacket was a problem for some test subjects, and we believe it can be addressed by redesigning the jacket into a frame of motors that can potentially fit into many different jacket sizes. While this design isn’t something we can implement in the next iteration, it is a good idea for future design changes. In summary, we would like to implement the following changes to our jacket for the next iteration:

  • Change the direction of the volume knob to make it more intuitive.
  • Integrate the circuitry into the jacket so the wearer is not required to carry the box.
  • Add a threshold knob so the sensations can be customized based on individual comfort levels.
  • Make the power switches more accessible to ease the plug-and-play interface design.

The three main tasks we listed when thinking of use cases for our jacket were as follows:

  1. Listening to music while walking to class
  2. Listening to music while studying in the dorm room, library or other such quiet place.
  3. Listening to music while in a silent disco.

Our test subjects said they would use the jacket under all the three listed situations. The idea of using it at the Silent Disco was very popular, but while thinking about performing everyday tasks, testers were concerned about the storage of the jackets when not in use. One of the testers was concerned about walking around with the jacket, and how the process would work with motors and wires in the jacket. Final additional concerns that were raised included wearing a jacket in warm weather, its durability, and its washability. These are secondary to our primary goal of creating a new music listening experience but will be key in future iterations of the jacket.

Appendices

Raw Data

 

P5 – Team VARPEX

Group Number: 9

Group Name: VARPEX

Group Members: Abbi, Dillon, Prerna, Sam

One-Sentence Project Summary:

We have designed a jacket that connects to your iPod/other music-playing device to allow users to feel the low bass present in music wherever they are.

Task Descriptions – What we Chose to Support in this Working Prototype

Our working prototype supports the following tasks: first, we want our prototype to help users experience music without disturbing their neighbors at home. We call this task “easy,” since its primary requirement is proper transformation of bass to vibration. It doesn’t need to be portable, very quiet, or inconspicuous. Second, we want to enable users to experience/listen to music in a quiet environment (such as in a library, or on a public bus) without disturbing people around them. We would evaluate this as a “medium-level” task, as it requires us to incorporate a compact, relatively portable and inconspicuous design into our prototype. The third and last task, however, is for our users to be able to walk in public with this jacket while still receiving the full “concert sensation” experience. This task will be hardest, since the jacket must effectively replicate the desired sensation while being inconspicuous, quiet, and completely portable. If our jacket too obviously appeared to be of some value, this would pose a safety risk to the user who might become a target of crime.

Fit Back

Discrete fit on the back. Cannot tell the motors are in there.

Did our Choice of Tasks Change from P3 and P4?

Our tasks did not change much as a result of P3/P4, since P3/P4 focused more on our efforts to see if we could properly replicate the sensation of low bass using vibrating motors. While our results from P4 influenced the design of our jacket, the results reinforced our ability to have our jacket fulfill the tasks we had already envisioned; we found the motors to be effective in replicating the feeling, and our system sound. We will describe in the next section how P4 influenced our design.

The Revised Interface Design

1. Changes from P3/P4 – Motor Placement

Perhaps the largest discovery we made as a result of our first iteration of prototyping was the importance of motor placement on creating sensation. We had earlier theorized that bone conductivity could be an asset in replicating the low bass sensation. Upon testing motor placement in P4 however, we discovered that users responded negatively to having the vibration right up against their bones. The focus of the motors, we saw, should be on more muscular regions of the body. This influenced our placement of the pockets containing motors in our jacket.

Photo Apr 20, 2 58 17 PM

The P4 Jacket (left) and the P5 Jacket (right), showing differences in motor placement

2. Changes in Form Factor

We also showed our participants in P4 and asked them about the likelihood of their using our system through the form factor of the hoodie jacket. Most participants responded that while they would consider wearing the jacket, they felt pleasurable sensations most when the motors were in as close contact with their body as possible. This would have to be achieved through some sort of undershirt or thinner material. We ultimately decided that we were comfortable with the jacket for this iteration of our prototype- the jacket we’ve used is made of relatively thin cotton, and since it will come complete with 12 motors we expect the sensation of twelve motors to be strong enough to compensate for thicker material (in P4, we only tested the sensation of three motors on the body). This jacket is also a tighter fit than the one we showed users in P4.

front fit

Tighter form fit, plug-and-play design

 

P5 Pic2

Motors are now on the inside, discretely placed at locations where sensations are most pleasurable on the back

3. Changes in Technical Approaches

The original design plan for this project was the analyze music using software. Two Arduinos were required for this task since we needed more timers for the application than could be provided by a single Arduino. The first Arduino would accept audio, using 64 samples taken over a window, the arduino would use a Fast Hartley Transform to determine the magnitude of all frequencies below 200 Hz (divided into 32 bins). The frequency bin and magnitude of the largest frequency would be sent to the second arduino which controls the motors. This process is repeated constantly as the audio plays.

The second Arduino, using the information passed from the first, would control the motors in the jacket using a pulse width with a duty cycle oscillating in a sinusoidal pattern. The frequency and magnitude of the sinusoid would reflect the frequency and magnitude of the dominant frequency calculated by the first Arduino.

Links to Arduino Codes:
Code 1
Code 2

It is important to note that the audio fed into the first Arduino would have to be passed through a low pass filter since higher frequencies would alias due to the low sampling frequency. This kind of problem would cause high frequency vocals or symbols to be interpreted as low bass.

This system works, however, the time necessary for the first arduino to obtain 64 samples and calculate a FHT would cause motor actuation to occur after a .21 second delay. Since this would cause a noticeable delay between hearing and feeling the music, it was important for this delay to be eliminated. Two options existed for us:

First, we could build a delay circuit which would delay audio by .21 seconds before it enters the headphones. This would require ordering of a particular chip and a number of accurately valued resistors and capacitors to tune this circuit.

The second option, which we chose was to build comparators after the low pass filter to replace the arduinos. This system would generate a digital signal from the bass tones above a certain threshold, therefore performing the same functionality of the arduino’s software in hardware. We chose this solution since it would in fact be cheaper and even produce a more desirable feel in the motors.

Overview and Discussion of our New Prototype

1. Ease of Use

Our current iteration of our prototype has implemented the fundamental feature of our system- the actuation of vibrating motors to replicate the feeling of low bass in music. The circuit performing this function is implemented and stored inside of a box that allows the user to simply plug in their phone to experience the bass of whatever music they desire. We have discovered that this works well across a variety of devices (from Samsung Galaxy S3s to iPhone 5s). Once plugged in the user can still control regular sound volume on their headphones as before, but from a dedicated knob on the circuit (the voltage output from the device must remain constant).

Otherwise the system displays true “plug-and-play” functionality. Since no general microcontroller like an Arduino was required, our system will be even easier for the user to set up. The motors are likewise completely removable from the jacket- a desirable feature, since we want our jacket to be machine washable.

P5 Pic1

The connecter which plugs into the arduino which controls the motors

2. No “Wizard of Oz”

Technical aspects of the jacket aside, we also wanted to test if the jacket can be worn comfortably while the system is in use. Unfortunately, the box containing the circuit used to implement the audio signal filter is a bit bulky. For the purposes of prototyping, this can be held off to the side while a user tests the wearing of the jacket. In future iterations of the prototype (or in the jacket’s final form), we could order printed circuit boards so we can have a sleeker design, but that is infeasible and too permanent given the scope of our current prototyping phase. Otherwise, our prototype requires no “wizard of oz” techniques to simulate our systems function. With the frequency filtering implemented, and the motors connected to the jacket, the user should have access to all of the basic functionality we expect them to have at this stage of prototyping.

nutter butter

Box containing the circuit

Usage Description Video

A close up of the vibrating Motors

Features not Included in this Prototype

One feature we did not implement in this prototype was the variation of sensation location on the body. We have considered the possibility that something like a lower bass frequency might feel more pleasurable on the lower part of the back while something higher might be felt on the upper part of the back. This would have to be confirmed in further user testing, and for this iteration we want the user to get the experience of this jacket at “full power” before beginning to vary the sensation by location on body. Therefore, we decided to leave off this feature.

Storyboards for Unimplemented Features

1. Different Sensations on Different Parts of the Body

P6 SB 1-1

SB 1-2

Low frequencies on the lower back

SB 1-3

High frequencies on the higher back

2. A Phone Interface that Allows the Wearer to Control the Frequencies for their Own Comfort

P6 SB 2.1

Sliding interface allows the user to control frequencies

P6 SB 2.2

Can change the frequencies based on comfort and situations

P4 – VARPEX

Group Number: 9

Group Name: VARPEX

Group Members: Abbi, Dillon, Prerna, Sam

Project Summary:

We are creating a jacket that allows users to experience their music through vibrating motors.

Description of the Test Method:

Once our subject arrives, we tell them our mission statement and inform them about what they will experience in testing our prototype. Since our system involves a significant amount of physical interaction with the subject, it is especially important that we demonstrate the system to make sure the subject will feel comfortable. We want to make sure that the subject would find the level of physicality required to prototype our system acceptable, so we will describe what will happen in the test before they have to go through it themselves. We also present the subject a consent form more formally detailing the experience. It also informs them that their identity will be kept confidential within the lab group (Click here to see the consent form).

We sent an email out to several listservs soliciting “consumers of dance/electronica/dubstep or just people who like feeling a good beat” to participate in the testing of a system that would allow them to “feel” music. The subjects we ultimately chose perfectly fit into our target audience. Two of them were regular rave/concert-goers who enjoy the physical sensation of feeling music. Our third subject enjoys music more casually, but still goes to the Street regularly. All three, we believed, would offer the best feedback in relating the sensation provided by the vibrating motors to the pleasurable sensations of loud concerts.

For our testing, we were required to work with our prototype the undergraduate ELE laboratory. Only there could we have access to the power supply for the vibrating motors. (We cannot power the motors from the Arduino since the total current drawn would probably burn out the pins) Since the task of “feeling” music can be done anywhere however, location was not a salient aspect of our prototyping phase.

To conduct the study, Dillon greeted the subjects and read them the demo script and acquired their informed consent. He would then introduce the subjects to Abbi, who would proceed to test the prototype band of motors in different areas of the user’s body and solicit their reaction. Abbi’s script was roughly as follows:

“First, we are going to see where you prefer to feel the sensation of the vibrating motors. If you are not comfortable with a motor’s location, please let us know. We are also going to vary how loosely the motors are in contact with your body. [Hold motor band up to different parts of back] How does the vibration sensation compare between different parts of your body? Which motors along your back elicit the strongest sensation? How would you rank the different locations of the motors on your body? How would you compare the different levels of pressure you felt?”

The motors were placed on various parts of the participants’ backs. We tested the shoulder blades, horizontally across the spine from the upper back to the lower back, as well as the sides of the lower back.

IMG_2057

Testing procedure on the lower back

IMG_2056

Testing procedure on the mid-upper back

IMG_2055

Testing procedure on the upper back, between shoulders

This line of questioning proceeded until the user offered sufficient feedback about how different motors’ locations on the back compared to each other. Sam and Prerna recorded the user’s feedback for later consideration. Once this phase of testing was complete, we introduced the user to the jacket prototype and explained how the motors they just felt would be embedded in it. We asked them to rate how likely they would be to wear it/ how they would use it, what sort of articles of clothing they typically wear, and if they believe the best sensations they felt in the first phase of prototyping would be achievable through the jacket.

Results Summary:

We had 3 user testers – 2 female and 1 male student who enjoyed listening to music, albeit under different circumstances. Testers invariably said they preferred the tighter fit of the motors much better than the looser fit. They found it slightly uncomfortable when the fit was looser and felt the experience was a lot more pleasurable when the motors were held tightly against their backs. In terms of location, users did not enjoy the sensation on their shoulders, and preferred the vibrating motors located on their middle and lower backs. In terms of the vertical placement, we found that our male user tester did not experience the sensation around the spine as well as our female test subjects did.

 All three also said they preferred the sensation on their muscular regions of the back rather than on the bony regions, which they said seemed slightly uncomfortable. The most pleasurable sensations were experienced in the mid-lower back region, around the muscular parts. We also asked questions about wearability and usability of our jacket, and test subjects had varying opinions. While one said he would prefer the jacket/ hoodie form due to portability and easy of use, the other two said they might prefer a tighter, undershirt/ vest setup due to closer contact with the skin. They also said they would be likely to use the vest under specific circumstances of artistic immersions such as a silent disco or a visit to a sculpture garden.

Result Discussion:

We had several takeaways from our user testing process for P3. While we had initially played with the idea of bone conduction to create an immersive music experience, we saw that due to the nature of the vibration motors and the close contact they have with the wearers body, it would be better to focus on placing them on muscular regions for comfort. All the test subjects preferred the sensation of vibrating motors on the muscular parts of the back rather than on the bonier regions. We also found a slight difference in the locations which test subjects found pleasurable – since our male test subject did not enjoy the experience along the spine as much due to wider shoulders, as compared to our female test subjects.

The mid-lower back emerged as the location with the best sensations and this gave us useful insight about the placement of the motors in our jacket/ vest. Talking to our test subjects about the usability, we got several ideas about the form of our project – whether to keep it a hoodie or play with the idea of making it an undershirt. Since test subjects preferred the tighter fit, we did decide to keep the form factor, either a hoodie or undershirt, tighter so the motors can be closer to the body.

Future Plans – A Higher Fidelity Prototype:

At this point, we are ready to proceed to a higher-fidelity prototype. This step was very valuable in understanding how our target users respond to the vibration sensations at various locations on their back. Now that we have gained information about the location and pressure of the motors, we will decide on a form factor. We expect that we will next create a more portable device. We will test this device (before P6) on a few individuals to address major usability problems or difficulties with sensation and fit. Because we’re constructing an experience, we are focused on testing sensation rather than task performance.

P3 – Team VARPEX

Group Number: 9

Group Name: VARPEX

Group Members: Abbi, Dillon, Prerna, Sam

In this assignment, Sam was responsible for writing up the mission statement and brainstorming prototypes. Dillon was responsible for writing up the discussion of the prototype and brainstorming prototypes. Abbi was responsible for building the prototypes. Prerna was responsible for describing the prototype and how it applies for our tasks.

Mission Statement:

The purpose of this project is to create a prototype piece of clothing which can take input from an MP3 player and create sensations on a user so that the user can feel lower bass tones. The sensation will be generated using vibrating motors. The device should be comfortable and portable. This product will allow users who are unable to generate loud, feelable bass tones for reasons of cost, noise pollution or portability to overcome these obstacles and feel low bass tones. The current design of the system proposed would use a microcontroller to analyse music tones and actuate motors spaced on the user’s chest. The motors will be incorporated into clothing for ease of use and the microcontroller will be battery-powered and portable. The prototype at this stage aims to discover basically how users will react to primitive actuation from the motors (to determine placement and power). This prototype will also aid in the design of the clothing (fit, weight, etc.). The goal of this team is to produce this final product without going over budget. In particular, our focus is on user experience.

Prototype Description

Since our device does not have a visual user interface, we decided to use the lo-fi prototypes to perform further tests on its usability and functionality. With this in mind, we will have two iterations of our lo-fi prototype. In the first iteration, motors will be placed in a band of tape that can be tightly attached to the users body with the motors contacting the user around the spine. This will allow us to test if the motors (and modulation of their intensity) properly replicate the sensation we found users feel in P2. The second portion of our prototype will implant these motors in a loose-fitting sweater. This will allow us to test our form factor- hopefully the jacket offers the user the appropriate level of sensation, but it is possible a tighter-fit will be needed in order to achieve the desired level of intensity.

Use of Prototype in Testing

In P2, we identified the following key tasks of our users:

  • Experience/listen to music without disturbing the quiet environment of the people around you (in the library while studying, in lab, etc.)

  • Experience/listen to music while being mobile (walking to class, in the gym, etc.)

  • Experience/listen to music without disturbing residential neighbors (roommates, suitemates, etc.)

These tasks have informed the characteristics our system needs: proper replication of physical sensations felt from loud speakers and portability. From these characteristics, we’ve determined two fundamental questions we will answer in P4:

  1. Can the vibrating motors replicate the feeling of powerful bass tones from speakers?

  2. Does the form factor of wearing the motors in the jacket produce the proper sensations?

To answer these two questions, we’ll explore user’s responses to the intensity of the motors and the comfort and wearability of motors worn on a loose fitting jacket. Since the differences in our three tasks are linked with the user’s usage environment, and do not differentiate between the actual design of the device, we decided to use P3 to build a prototype that allows us to test the comfort and wearability of the device, as well as test how users feel about the physical locations of the motors in the jacket. This will help us better understand how and where users want to feel the sensations.

As our mission is heavily dependent on these sensations, a paper prototype or otherwise non-functioning system would not allow us to test anything that would help us see if our proposed system would properly accomplish our mission. At its core, our prototype will have three motors.

For the first iteration, we will see how strongly the vibrations are conducted through the motors when attached closely to your spine via a tight band. It will allow us to understand how comfortable users are with these vibrations and whether they feel it accurately replicates the live music sensation. In the second iteration, we will attach the motors to a jacket, which will allow us to test for fit, comfort and wearability, which is key to every task we listed above.

Basic Prototype Demo

A Closer Look at the Prototype

IMG_2031

Testing the basic fit of the prototype

IMG_2032

Our prototype – understanding how the motors fit in

IMG_2042

Our prototype – attaching the motors to the band

IMG_2045

Fitting the prototype across the back to test sensations

IMG_2046

Fitting the prototype over the spine to test sensations

IMG_2049

Adding motors to the jacket to test wearability

IMG_2051

Second iteration of the prototype – testing comfort and usability with a hoodie

 Prototype Discussion

Our prototypes required us to implement three of our motors- there is no lower-fidelity method to test our system. We want to test if the vibrating motors at all replicate the feeling users get in going to concerts. Our desired system should also be as ubiquitous as possible. An ideal final product would have the user simply plug their “music-feeling jacket” (or whatever form the product takes) into their iPod, with no interface required at all. This led us to conclude that a paper prototype would not offer us the ability to properly evaluate our system, leading to our implementation of several of our motors.

This made our prototyping process a bit more difficult than we had originally anticipated, since it required us to concentrate more on technical questions that might not otherwise be appropriate at this stage of prototyping (but that we have deemed necessary). For one, how we would power the motors in our prototype became an issue, since it might not be possible to power the motors off of the arduino board due to current limitations. It is these sort of questions that we were forced to wrestle with at an early stage of our prototype. On the bright side, it has forced us to think more practically about what we are hoping to build towards with our prototype.

Group VARPEX – L3

Names: Abbi Ward, Dillon Reisman, Prerna Ramachandra, Sam Payne

Group Number: 9

Description

For this lab we built a robot with four legs that pulls itself along a string. Its four legs are the tips of ballpoint pens, allowing for a smooth gliding motion on relatively frictionless surfaces. Our original inspiration for the robot came from an idea we had to build a robot that opened and closed window shades according to how much light was in a room. This robot would move vertically rather than horizontally, doing so by using a motor to pull itself up a string. We decided to test this method of locomotion horizontally first. We were very pleased with the success of our robot- we did not imagine that it would move so well over the table surface, and in future iterations of this robot we could have it do interesting things in how it moves. The ballpoint pen tips were extremely useful tools for motion along a surface. Unfortunately we do not think the method we used to collect the string once the robot pulled it worked well (we simply wind it up on the end of the motor), and in future iterations we think that the robot should have a way of going one direction on the string, then reversing the motor and going the other direction. In total, however, we think that this method of motion could have many applications.

Brainstormed Ideas: 

  1. Helicopter using paper/cardboard blades
  2. Vibrating robot, moves by vibration
  3. Robot on wheels which uses a fan to propel itself
  4. Arms which rotate similar to single blade propellers to promote movement
  5. Three-legged omnidirectional single plane robot
  6. Worm robot, uses a single joint to contract and move forward
  7. Robot that hits the ground hard enough to “jump” forward
  8. Move the motor foward and reverse direction to hit limbs against ground and propel forward
  9. Use servo to wiggle from side to side and move forward
  10. Robot which eats tape/line of string to move forward
  11. Robot which dances to a beat
  12. High five Robot – moves up to you and gives you a high five if you bring your hand close to it
  13. Acrobat robot – does flips at regular intervals as it moves around in a circle

We chose to prototype Idea 10, a robot which eats a line of string to move forward.

Design Sketches

sketch-1

Assembling the robot, use of the string and using pencils to reduce friction

sketch-2

Using only pencil tips to minimize ground friction, instead of rolling pencils

Demo of our System

Parts list

  • Arduino
  • motor
  • PN2222A transistor
  • Diode (1N4001)
  • electrical tape
  • 4 disposable ballpoint pens (plastic)
  • breadboard
  • 330 ohm
  • battery pack to power the Arduino

Instructions to Recreate System

  1. Build the schematic on the breadboard
  2. Attach the motor to the breadboard with electrical tape

  3. Break open one of the disposable pens into the following parts

    1. the outer tube

    2. inner tube (holds the ink)

    3. tip

    4. ink

  4. Cut off about a 1/2 inch of the inner tube that doesn’t have any ink

  5. Use thinly sliced strips of electrical tape to make ridges on the edges of the tube. This will be used to help keep the thread on the axle so that the robot pulls itself and the thread will not rub against the base of the motor.

  6. Push this tube+tape combo onto the axle of the motor so that it fits snugly.

  7. If leads are showing on the bottom/sides of the battery pack, put electrical tape over them so that loose wires don’t accidentally short power and ground.

  8. Tape the Arduino to the battery pack (the batteries should face the floor)

  9. Cut up the outer tube into ~1 inch pieces and place them on the Arduino.

  10. Tape the breadboard+motor on top of the pen pieces such that the axle of the motor is centered on the robot.

  11. On each of the four pens, take off the tips (with the ink cartridge removed) and tape them to the side/bottom of the battery pack such that the assembly balances and can slide easily across the floor or table.

  12. Use a small piece of electrical tape to attach the thread piece

  13. Hold the spool, upload the code, and the robot will traverse towards the spool

Source Code for the Robot

/*
Names: Dillon R, Prerna R, Sam P, Abbi W
Group 9, Varpex
COS 436 S2013
Our robot code. 
This was just for walking across the table. 
*/

int motorPin = 3;

void setup() 
{ 
 pinMode(motorPin, OUTPUT);
} 

void loop() 
{ 
 int motorspeed = 254;
 //walk a little bit
 analogWrite(motorPin, motorspeed);
 delay(3000);
 // stop
 analogWrite(motorPin,0);
 while(1); 
}

 

P2 – Feel the Music!

Group Name: VARPEX

Group Members and Contributions: Abbi Ward, Dillon Reisman, Prerna Ramachandra, Sam Payne

Dillon recorded participant answers and wrote up information about our participants/people we observed and their responses and gathered test subjects.
Sam provided the music and music equipment, recorded the answers to the task analysis questions and gathered test subjects.
Abbi drew some of the sketches and wrote up information about the contextual interviews.
Prerna drew the storyboards, gathered some of the test subjects and helped with conducting interviews and compiled the blog post.

Group Number: 9

Problem and Solution Overview

We are addressing the problem that the concert experience can only be replicated by expensive, non-portable hardware. Further, these systems cause noise pollution in tight-living quarters. We will create an article of clothing worn on the torso that will use vibrating motors to generate stimulus similar to that created by loud bass – that is, a vibrating sensation on the skin. Our solution is portable, relatively inexpensive, and avoids the noise pollution problem.

Description of Users Observed in Contextual Enquiry

The target group of users we observed were students aged 18-22. They all have enjoyed listening to music at eating clubs on weekends or going to the occasional concert. They do these things, however, for a variety of different reasons. Some go to clubs for the social aspect of it (their friends are there, their friends are performing, etc.). Most, however, find the act of listening to the music enjoyable in its own right. The observed users enjoy many forms of music, and for most that includes some form of electronic music, though they had varying opinions on the quality of dubstep specifically. It helps that what is played in clubs is mostly of this type, as opposed to rock or other genres.

Contextual Inquiry Interview Descriptions

We invited six individuals to Sam Payne’s room on a Saturday afternoon. Sam has a good quality subwoofer which we used to experiment with different bass frequencies. We invited individual participants to the room at different times. We introduced ourselves and described the class and the purpose of the questions we were going to ask. For each participant, we walked through a series of questions about their music-listening habits and tried to get a feel for how, when, and why these students are listening to music. We then played a series of frequencies for them (from 110 Hz down to 50Hz) while they stood next to the subwoofer. We asked them to describe the sensation and where they felt it. We then put a foam chair near the subwoofer and had them listen to the tones again. We asked them to describe the sensations again, where they felt it, and how they liked it.

As participants answered our questions, we recorded their answers in this form, which gives a basic outline of the sorts of questions we asked.

Most of our users primarily listen to music in their dorms with laptop speakers. If they go outside, they’ll typically use headphones. These headphones are generally low-quality earbuds rather than slightly higher quality over-the-ear headphones. Many students will listen to music on speakers in whatever lab they’re working in. The participants we interviewed enjoyed a variety of genres, from dubstep and electronica to pop and opera. Even if the participants did not report that electronica or dubstep was very high on their list of favorable genres, they often at the very least appreciated it for its diverse and interesting sound and the “intense” sensation they often got from it.

Users felt the vibrations in very different locations. Some of this difference may have been due to different body types. The tall, thin men we interviewed felt vibrations very strongly in the top of their chest but other participants did not feel these vibrations as strongly. Another area where sensations were strongly felt was in the mid-back, along the spine. Users enjoyed the chair, as opposed to just feeling the vibrations in the air. The chair produces a more intense diffusion of vibration. People likened this feeling to a massage of the back and legs. This suggests that users enjoy the intensity of response and the similarity to the raw air experience may not be as important.

Answers to Task Analysis Questions

1. Who is going to use system?
This system would be for people ages 16-34 who enjoy concerts. They enjoy concerts because of the sensation derived from loud music, and would like to have this same sensation when they listen to music at home.

2. What tasks do they now perform?
They go to concerts when they can, and they play loud music in their home (if they can). Some individuals, such as college students living in dormitories, must listen to music through headphones due to noise pollution.

3. What tasks are desired?
Users would like the concert experience on-the-go and without disturbing their neighbors.

4. How are the tasks learned?
Users already know how to use their headphones and feel music. Our system would be an extension of simply plugging in your headphones.

5. Where are the tasks performed?
People feel music at concerts, parties and in dorms/apartments, if they have good speakers. People listen to music everywhere.

6. What’s the relationship between user & data?
Feeling music is a subjective experience, so our data is the reported experience of users. There may be some loss of data if users cannot describe or are not aware of factors that affect their experience.

7. What other tools does the user have?
Depending on the situation, the user may have headphones or speakers and subwoofers. They also have music-playing devices, such as iPods, computers. This equipment varies in expense.

8. How do users communicate with each other?
At concerts, people communicate through gesture and yelling.

9. How often are the tasks performed?
How often tasks are performed varies between individuals because it depends on the type of equipment they have. Those without subwoofers only feel music at concerts so they may feel music a few times per year. Those with subwoofers may feel music on a daily basis.

10. What are the time constraints on the tasks?
At a concert, the time of the concert constrains when users can listen and feel music. For those with good speakers and subwoofers, the constraint may be the time it takes for your neighbors to call public safety.

11. What happens when things go wrong?
If the concert is cancelled, the police are called, or your speaker breaks, you don’t listen and feel your music.

Descriptions of the Three Tasks

1. Many times, people want to listen to music at a loud volume in their room while     roommate is studying, or without disturbing their neighbors. Many students will listen to music on headphones. However, the physical sensation of listening to music is lost while listening on headphones. This product would allow people to feel that sensation without disturbing those around them. The task of listening to music loudly in your room is easier than the other tasks, but it becomes more difficult as you take into consideration the possibility of disturbing your neighbors.

  • Users working outside of their rooms often listen to music while working. The portability of this device allows users to feel music while studying without disturbing those around them.

2. Many students listen to music while walking to class. This of course is done on headphones since speakers are not portable. However, again, the physical sensations of listening to music are lost while listening on headphones. The portability of this product would allow students to listen and feel their music in any setting, and on the go. The task of listening to loud music while moving is difficult, and is even more difficult when you take into consideration the possibility of disturbing other persons.

3. While at concerts, many people enjoy the feeling of music, and some songs are even written to promote these sensations. While producing music, artists could use this product to feel their music and gauge how their music will feel in a concert setting. Attending concerts is difficult due to availability and cost.

Storyboards

Storyboard 1 

storyboard 1

Listening to music while walking to class and getting the live music experience

Storyboard 2

storyboard 2.1

Listening to music in the library or lab while doing work

storyboard 2.2

Getting the live music experience while doing work!

Storyboard 3

storyboard 3

Listening to music in your room, and getting the live music experience without disturbing your roommate

 Design Sketches

photo 16-54-30

Overview of the jacket, fit and spot to place iPod

photo (1) 16-54-30

Front and back of jacket, and sketch of the motors

photo (2)

Parts of the body affected by the jacket

Interface Design Description

Since our system will be wearable, it will grant the user a lot of freedom over where and when they can ‘feel’ their music. Ideally it will also look inconspicuous in its function; a user should be comfortable simply wearing it as a jacket or other article of clothing. It will still enable the user to simply listen to music should they wish, as they did before, but with the added ability to activate the more immersive ‘feeling’ system through vibrating motors. Currently this ability is not offered by any product on the market- headphones do not offer users the concert-going experience of ‘feeling music’.

L2: Sensor Cymbals!

Group Name: VARPEX

Group Number: 9

Group Members: Abbi Ward, Dillon Reisman, Prerna Ramachandra, Sam Payne

Prototype 1 (The Dog Toy Instrument):

For our first prototype, we use a force sensitive resistor to build a toy that a dog can bite at various places and create music. The force of the bite determines the tone of the music.

Prototype 2 (The Roll-Instrument)

For our second prototype, we use an accelerometer continuously maps the y-coordinate to a unique frequency of the tone that to create music when we roll the instrument.

Prototype 3 (The Clapper)

For our third prototype, we built a clapper that uses a light sensor to adjust the speed of beats based on the amount of light that reaches it through the plates, hence creating music.

We decided to refine our clapper to build a more playable, intuitive instrument.

Project Description:

Our musical instrument uses light to control the tempo of notes that have a pitch set by a user’s sliding finger. In our prototype of the light mechanism we found that the use of light gave the player a surprising amount of control over the sound produced, and could perform interesting, simple beats without even controlling pitch. This mechanism worked by placing a light sensor in a ‘clamshell’ that could be opened or closed- more light to the sensor created a faster beat, while a closed clamshell resulted in a slower beat. For our refined model, we have two black acrylic panels- one with the light mechanism attached, and another with the slider sensor for pitch-control. The player holds each piece in a hand and can pivot, rotate, pull away, or cover up the light sensor on one piece using the other piece. We chose this design because it gave the player two dimensions of sound to control in a very fluid, three dimensional way. In a future revision of this design we might want to give the user more control over the beat, such as the ability to have no beat (right now, the beat is, when the light sensor is completely covered, very slow, but not off).

Schematic

schematic

Project Demo

List of Parts

A list of parts used in your final system

  • Arduino
  • 1k-Ohm resistor
  • 10k-Ohm resistor
  • slider sensor
  • photocell
  • buzzer (speaker)
  • dead battery (This keeps the acrylic pieces from crushing the photocell and provides a pivot point for the pieces to rotate)
  • 2 pieces of acrylic
  • electrical tape to attach the battery to the acrylic

Instructions to Recreate System

Build the given schematic using alligator clips to attach the sensors. Tape the dead battery to one of the acrylic pieces — cover up the terminals. Carefully bend the leads of the photocell and rest it on top of the battery, parallel to the acrylic. Tape the slider sensor to one side of the other piece of acrylic. Load the Arduino code. Use the piece of acrylic with the slider sensor to cover the photocell and change the beat. Change the position of your finger on the slider sensor to change the tone.

Source Code

/*
Names: Dillon R, Prerna R, Sam P, Abbi W (Group 9)
Date: 3/2/13
Class: COS 436 - L2
For a musical instrument using the photocell and slider sensor. 
Light makes a faster beat and the slider corresponds to a scale
*/
// Pins
int sliderPin = A0;
int lightPin = A1; 
int speakerPin = 9;
int sliderValue;
int lightValue;
int tempo = 330;
int beat;
// sensor value ranges
int lightRangeLow = -1*200;
int lightRangeHigh = -1*950;
int sliderRangeLow = 100;
int sliderRangeHigh = 550;
void setup(){
 pinMode(speakerPin, OUTPUT);
 Serial.begin(9600);
}
void loop() {
 sliderValue = analogRead(sliderPin);
 lightValue = analogRead(lightPin);
 Serial.println(lightValue);
 //char note = setNotefromSlider(sliderValue); 
 setBeat(-1 * lightValue);
 playNote(setNote(sliderValue),tempo); 
 delay(tempo/2); 
}
// varies the tempo
void setBeat(int sensorValueA) {
 // for reading light sensor
 tempo = map(sensorValueA, lightRangeHigh, lightRangeLow, 5, 800); 
}
// sets a note c to C based on the slider position
char setNote(int sensorValue) {
 /* sensor value is 100 to 550 */
 int readVal = map(sensorValue, sliderRangeLow, sliderRangeHigh, 0, 830);
 int cmax = 180;
 int dmax = cmax+100;
 int emax = dmax+100;
 int fmax = emax+100;
 int gmax = fmax+100;
 int amax = gmax+100;
 int bmax = 780;
 if (sensorValue < cmax) {
 return 'c';
 }
 if (sensorValue < dmax) {
 return 'd';
 }
 if (sensorValue < emax) {
 return 'e';
 }
 if (sensorValue < fmax) {
 return 'f'; 
 }
 if (sensorValue < gmax) {
 return 'g'; 
 }
 if (sensorValue < amax) {
 return 'a'; 
 }
 if (sensorValue < bmax) {
 return 'b'; 
 }
 return 'C'; 
}
// method from Arduino tutorial
void playTone(int tone, int duration) {
 for (long i = 0; i < duration * 1000L; i += tone * 2) {
 digitalWrite(speakerPin, HIGH);
 delayMicroseconds(tone);
 digitalWrite(speakerPin, LOW);
 delayMicroseconds(tone);
 }
}
// method from Arduino tutorial
void playNote(char note, int duration) {
 char names[] = { 'c', 'd', 'e', 'f', 'g', 'a', 'b', 'C' };
 int tones[] = { 1915, 1700, 1519, 1432, 1275, 1136, 1014, 956 };
// play the tone corresponding to the note name
 for (int i = 0; i < 8; i++) {
 if (names[i] == note) {
 playTone(tones[i], duration);
 }
 }
}

 

Assignment 2 – Prerna Ramachandra

To conduct my observations, I spent a lot of time between class observing what people did. Initially, I chose to observe and talk to people in the same classes as me but who I did not know very well – Byrd Pinkerton and Kirsten Parratt in ENG 339: Jane Austen in Context; Patience Haggin and Saahil Madge in HIS 310: Imagined Languages; Stephanie He and Sebastian Gold in COS 340: Reasoning About Computation.

I found that when people had time between class, they usually answered emails, checked the day’s lunch menu or read through the notes from the previous lecture for that class to refresh their memories.

I also interviewed acquaintances and friends to ask them what they did between classes – Izzy Kasdin, Alex Kasdin, Dillon Reisman, Erica Portnoy, Bonnie Eisenman, Mengyi Xu, Michelle Yakubisin, Ballard Metcalfe, James Bedell and Alexander Patton.

For people who were running between classes in 10 minutes, their biggest concern was being late and missing the beginning of lecture which sometimes lead them to miss important assignment information or even the base of the lecture which was hard to catch up on.

People also complained about not being able to find resources such as printers, water fountains, bathrooms, etc. in time when they had class in an unfamiliar building.

Many people merely spent time playing games on their computers or relaxing between class and said it would be fun to have more recreational games before class to rejuvenate.

I came up with the following list of ideas based on the observations I made and conversations I had.

List of Ideas

  1. Legos in the classroom – fun way to keep people engaged before class (add sensors to prevent students from taking them)
  2. Magazines and newspapers in or right outside the classrooms
  3. OnMyWay: Wirelessly transcribing the first 10 minutes of lecture to your phones so you don’t miss the beginning if you’re running late
  4. Outline Transmitter: Transmitting lecture outlines to the phones before class so students can skim through them
  5. Campus wide puzzle challenge: Form teams within your class to solve a semester-wide puzzle challenge in which clues are scattered around the classroom right before the class starts
  6. Video monitoring for students who have experiments running in the lab – video feed sent live to phones so they can keep track right until class begins
  7. FindIt: Compilation of locations of students necessities such as printers, water fountains, bathrooms and prox hotspots so students know where to look before class
  8. Email Filter: App which filters only the most important emails which must be answered urgently so students don’t have to sift through tons of emails finding the ones which must be answered before class
  9. Mood-based music filtering: App which selects the right music for you as you walk to class depending on your mood – happy, sad, want to workout/ race walk, etc.
  10. QuickSnack: Snack trucks or coffee bars right outside or near classroom for a quick hunger fix or coffee boost
  11. Audio feed summary of the previous lecture for the class you can listen to before the next one so it is fresh in your mind
  12. MoodCheck : App which posts your mood – happy, sad, stressed, etc. so your friends can see it; you can check friends’ moods and offer to chat, hang out, small gift to cheer them up if they’re sad
  13. LunchMenu: App which consolidates menus from various dining halls/ eating clubs for the day’s lunch so you can pick where to eat when walking from class to class
  14. Day Progress Report: List of tasks you need to finish for the day, and how you’re keeping up, i.e. personalized day tracker to check before class.
  15. Daily Calorie Intake: What did you eat (pick from d-hall menus), how many calories, track physical activity including walking, etc
  16. TechTracker: An app which lets students who are the first to enter the class send a complaint regarding technology in classrooms which does not function.
  17. Sustainability Check: An app which informs students of all the empty classrooms in which lights are on giving students near those classes to walk in and turn them off.
  18. Best Paths: An app which optimizes your path to class and gives you the best routes by foot and by bike (taking rain/ cold weather into account).

The two ideas I chose to prototype are:

1. OnMyWay: Wirelessly transcribing the first 10 minutes of lecture to your phones so you don’t miss the beginning if you’re running late

I chose this idea because many students, especially freshmen engineers have back to back classes and invariably miss the first five or so minutes of lecture and find it hard to catch up. They also miss important homework information which professors talk about in the beginning of lecture. An app which relays this information to them while they are walking would be very useful with a simple UI.

2. FindIt: Compilation of locations of students necessities such as printers, water fountains, bathrooms and prox hotspots so students know where to look before class

I feel this is an important problem because students generally use time between classes for tasks such as filling their water bottles, printing things for class, going to the bathroom, etc. but don’t find the amenities required because of being in an unfamiliar building or part of the building. An app which helps them find these things is simple to design and very useful.

Prototypes

1. On My Way!

omw1

1. Opening screen which lets you select the class for which you are late

omw2

2. Second screen which displays the time and relays a message saying it is waiting for the class to begin before transcripting

omw3

3. Transcript of lecture begins when lecture starts, can be viewed while walking to class

omw4

4. Transcript stops 10 minutes after lecture begins – enough time to get to class

2. FindIt!

f1

1. Opening screen – option to select building manually or use GPS location

f2

Optional second screen (only if user chooses to select building manually) to choose from list of buildings

f3

3. Screen to choose item being searched for

f4

4. Screen specifying floor location of said item in the building

f5

5. Tap on each floor for further info about location or look in a nearby building

User Testing

I decided to user test the prototype for Find It!

I decided that students who test my prototype would not be Computer Science students and those interested in interface design since I believe they would not give me a completely accurate picture of the regular user. Emily Wibberley, Izzy Kasdin and Temple Douglas tested my prototype, and here are the pictures from user testing:

Emily Wibberley

IMG_1880

1. Decides she does not want to use the GPS

IMG_1881

2. Trying to figure out how the building selector works

IMG_1882

3. Selects the Friend Center!

IMG_1883

4. Looking for a water fountain

Izzy Kasdin

IMG_1884

1. Decides not to use the GPS

IMG_1885

2. In the Friend Center

IMG_1887

3. Looking for a water fountain

IMG_1888

4. Found the location! But…how to get more info?

Temple Douglas

IMG_1889

1. Decides to use the GPS

IMG_1890

2. App finds that she is in the Friend Center. Chooses to find a water fountain

IMG_1891

3. Gives the floor location…but how to get more info?

IMG_1893

4. Decides to find a fountain in a nearby building instead

Observations and Conclusions from User Testing

The initial screens seemed to be a simple enough interface for testers to figure out, especially when they manually selected the building. However, those who used a GPS locator said it would be nice to have a confirmation screen asking them if they were actually in the location it found out, which would be useful if they were outside or near a certain building.

I also observed that none of the users tried to find more information about the location after the floor locations had been displayed. They were tired of clicking through too many screens, and hence it taught me a lot about simplifying the interface so necessary information is quickly and clearly displayed. Thus, I feel having the detailed location displayed next to the floor location is a better interface than waiting for the users to tap on the floor locations for more info.

One of the users also said that having a ‘nearby buildings’ options might only be necessary if the required item is not available in the building the user is in, or is hard to find (eg. the bathrooms in McCosh are extremely hard to locate). This lessens the amount of text on the screen and prevents too much confusion.

Overall, I got positive feedback about the usefulness of the app, and users testing the prototype said they would definitely use it. The functionality is simple and some minor tweaks in UI will improve usability. I am happy with the reception of the app and gained some valuable insights from user testing.

 

Lab 1 – Intuitive Computer Navigation

Group Members: Abbi Ward, Dillon Reisman, Prerna Ramachandra, Sam Payne

Group Number: 9

Ideas and Sketches:

1. Etch-A-Sketch – a version of the famous Etch-A-Sketch game using 2 rotational potentiometers

EtchASketch

2. Intruder Alert – An alert if someone opens the door to your room while you’re asleep using photocells and a potentiometer

CreeperInTheRoom

3. Intuitive Control for the Computer – Use of finger flicking movement to quickly minimize windows on the computer.

FlexFinger

We decided to select Idea number 3, since it seemed the most intuitive and feasibly implementable for the lab.

Project Description:

For L1, we built a glove that allows the user to navigate the Internet more naturally. For this implementation we sought to enable a user to do a simple “flick” gesture to minimize the browser quickly for privacy. Currently, the process of minimizing all windows at best requires the user to enter a key macro on their keyboard. The problem with this is that when surfing the Internet the user is not always engaged with the keyboard. This glove uses a flex sensor on the user’s non-dominant index finger so the user does not have to inefficiently engage the keyboard in the event that they have to close their browser quickly. The difficulty with this project was that the Arduino Uno does not have a native API to override the keyboard. To accomplish the task of associating a flex sensor with the keyboard macro to minimize all windows, we used Processing and had the signal indicating a flick written to a file that would be simultaneously read from by a Java module. Java’s “Robot” class allowed us to trigger the keyboard macro we needed to minimize all windows. We are very pleased with the final result- our Java module could be adapted to implement even more functionality by simply triggering different keyboard macros given different signals from Processing. In the future, however, we would like to be able to find a more efficient system to get the Arduino to interact with the computer’s hardware than this write/read process that is happening between Processing/Java.

Project Storyboard

Frame 1

storyboardf1

Frame 2

storyboardf2

Frame 3

photo

Frame 4

photo (1)

Project Schematic

Photo Feb 23, 2 48 58 PM

Demo Video

List of Parts Used

  • Software
    • Arduino
    • Processing + our keyeventsprogram program
    • Java + our KeyboardInteractor.java
  • Hardware
    • flex sensor
    • Arduino
    • 10 kOhm pull up resistor
  • Other
    • glove (to hold the sensor)

Instructions to Recreate Design

  1. Follow the given schematic.
  2. On the Arduino, upload FirmataStandard (in the Example Software, under Firmata) to enable the Arduino to work with Processing.
  3. Go to https://github.com/pardo-bsso/processing-arduino to get an arduino-processing interface library with fixed bugs.
  4. Open our Processing code(keyeventsprogram), Java code (KeyboardInteractor.java) and a command line. You will need to adjust the pathnames stored in the files for your own computer.
  5. With the circuit all hooked up, start the Processing program. A small gray box should pop up.
  6. At the command line, type “tail -f desktop.txt | java KeyboardInteractor”. This takes the output of the Processing program (that is stored in desktop.txt) and pipes it to our Java program. Now, when you interact with the sensor (i.e. by flicking your finger), the shortcut should happen (i.e. windows+d takes you to your desktop)

Source Code

Code for Arduino

/**
* Names: Sam Payne, Abbi Ward, Dillon Reisman, Prerna Ramachandra
* Dates: 2/22/13
* COS 436, L1
*
* NOTE: since Robot objects are not allowed due to graphical
* interference, this program interfaces with an external application
* to trigger desktop results
*/
import processing.serial.*;
import cc.arduino.*;
Arduino arduino;
int desktopPin = 0; // pin reads from flex sensor
int desktopReading; // reading from flex sensor pins
PrintWriter output; // write to file when triggered
//Paramters for sensor reading
int FLICKTOP = 280; //threshold to trigger flick motion
int desktopCounter = 0; //number of times which flick has triggered
//setup
void setup()
{ 
 arduino = new Arduino(this, Arduino.list()[0], 57600);
 arduino.pinMode(ledPin, Arduino.OUTPUT);
 //create pipe file for Robot helper to read
 output = createWriter("C:/Users/Abbi/Programming/hcilab/src/desktop.txt"); 
}
void draw()
{
 // for this prototype only perform the shortcut once
 if (desktopCounter == 0) {
 desktopReading = arduino.analogRead(desktopPin);
 //output.println(desktopReading);
 }
// if above the threshold, then go do desktop
 if (desktopReading > FLICKTOP) {
 desktopCounter++;
 desktopReading = 200;
 //Send command to buffer file for robot object to interpret
 output.println("D"); 
 output.flush();
 }

 //exit the program after 5 triggers, this is a prototype function
 if (desktopCounter > 5) {
 output.flush();
 output.close();
 exit(); 
 }
 //arduino.digitalWrite(ledPin, Arduino.HIGH);

 delay(20); // delay 20 ms
}

Java Code with Robot class as workaround for using a different Arduino

/**
* Names: Sam Payne, Abbi Ward, Dillon Reisman, Prerna Ramachandra
* Dates: 2/22/13
* COS 436, L1
* Keyboard interacting program to interface with Arduino
* since robot class is not allowed due to graphics interference
*/
import java.lang.Object;
import java.awt.Robot;
import java.awt.AWTException;
public class KeyboardInteractor {
 public static void main(String[] args) {
 Robot rob; 
 //In in = new In("C:/Users/Abbi/Programming/hcilab/src/desktop.txt");
 try {
 rob = new Robot();

 //character mappings in java
 int VK_D = 68;
 int VK_WINDOWS = 524;
 int VK_BACK_SPACE = 8;

 char c;
 String line;
 while(true) {
 //c = StdIn.readChar();
 line = StdIn.readLine();
 if (line != null) StdOut.println(line);
 if((line != null) && (line.equals("D"))) {
 //StdOut.println("Desktop Command Detected");
 //trigger keypresses
 rob.keyPress(VK_WINDOWS);
 rob.keyPress(VK_D);
 rob.keyRelease(VK_D);
 rob.keyRelease(VK_WINDOWS);
 }

 //example for additional functionality
 //with additional sensors and triggers
 if((line != null) && (line.equals("B"))) {
 rob.keyPress(VK_BACK_SPACE);
 rob.keyRelease(VK_BACK_SPACE);
 }

 }
 } catch (AWTException e) {
 e.printStackTrace();
 }

 }

}