Final Project: Functional Baby Kick Sensor`

The project is alive and functioning — the final fabrication of the piezoresistive pressure matrix that I made out of pajamas, conductive fabric and velostat (piezoresistive material). After staying up soldering the protoboard and sewing to wires with conductive thread until 6am Wednesday night, we finally got to play test this thing the next day.

Unfortunately, there was a problem with the audio of the screen recording, but nonetheless, this is the visualization of actual baby kicks. Click here to read more about the visualization.

We ran into some fabrication problems. With one exception, I had been testing almost exclusively layed out on a table, which behaves very differently than when it’s on a person. We were having trouble getting good readings, and I think it was fundamentally due to the way she was wearing it. Last time we tested it, when it had a bunch of alligator clips dangling from it, we fastened it using a back support belt. I think what happened is that Marina grew significantly since then, and it doesn’t work as well any more. It still fits, but it fits differently.

At any rate, Marina had the brilliant innovation of sewing washers onto either side of the sensor, and using lace to tie it up in the back. Velostat, the resistive material in the middle of the conductive sandwich that makes this whole thing work is strikingly similar to a contractor bag. It’s plastic-y and rigid. This makes it difficult to attach it evenly over a round surface like a pregnant lady’s belly. The beauty of the corset approach is that the tightness is variable, creating a much better fit, and generating significantly better readings. The washers Marina used were actually left over from a previous fabrication project (click here to see it).

Marina sewing washers to make the sensor into a corset.

Here are some more notes on the fabrication. First and foremost, this was my first soldered circuit, which I’m very proud of, and I think it’s beautiful.

View fullsize

I used ribbon wires at David Rios’s suggestion to tidy up the connections between the sensor and the microcontroller. But then I had to attach them to the soft fabric somehow. So I had to spend some more time with my old friend conductive thread. I sewed the ribbon wire tips to the conductive fabric with conductive thread by turning the ends of the wire into little circles, and then I hot glued over it to prevent any shorts.

View fullsize

The original wearable design that I actually presented to class was a little different than the version I mentioned above with the corset lace tighteners. My original idea was to attach it to a shirt with Velcro, but in the end, the data coming out of that version sucked. Here is what it looked like.

View fullsize

That’s it for now, but in the very near future I will be adding some Winter Show documentation here.

Week 13: Sensor Success and Next Steps

I got the baby kick sensor working! I had big dreams of creating the piezoresistive pressure matrix by sewing contacts with conductive thread, but it turns out that making circuits with conductive thread super sucks. So, I used ShieldIt Super, which is a conductive fabric that you can just iron on, and it’s amazing. Using ShieldIt to make a sensor is kind of hilariously ironic, because the company that makes it (Less EMF), creates fabrics to cater to people that are paranoid about electromagnetic radiation. So, while they’re marketing fabrics to protect people from electricity, the irony is that their materials are extremely good at conducting electricity and for creating wearables. I ironed the ShieldIt on to some pieces of old pajama pants that didn’t fit (upcycling for the win), put some velostat in between, and that’s how you make a 40-point pressure sensing matrix.

View fullsize

View fullsize

I also got my visualization sketch working (link to code here). This is what the baby kicks will look like coming out of the sensor:

Click on the box to start the program.
Spacebar for full screen.

My brother, who is a musician, pointed out that I had basically created digital wind chimes. I’m okay with that. I also made a derivative code, which I’m calling Simple Harmonium for Meditation (code here).

Click on the box to start the program

The next thing to do is to map all 40 points of data from the pressure sensor to this sketch, and Bob’s your uncle (at least for getting the real-time sketch working). I also got my SD card module working, although I haven’t connected it to the sensor yet. But I’ve already written the code in Arduino so that it will write the sensor data to a text file over time, including a time stamp of when the sensor data happened (using Arduino’s RTC). Then I can make a similar .p5 sketch that will visualize the sensor data as sort of a time lapse. My hope is to have two screens up at the Winter Show (if my project gets accepted), and have one screen showing real-time kicks, and the other showing a time lapse of logged data from my SD card data logger.

I met with Tom Igoe to figure out how to clean up some of the noise in my sensor. The nice thing about using the ground-switching matrix (I can’t for the life of me keep what the process is actually called in my head), where it reads across the sensor by changing where the ground is systematically, is that while there are 40 data reads coming out of my sensor, technically there are only 5 real sensors being scanned across 8 points several hundred times a second.

What that means for cleaning up the sensor data is that I’m only cleaning up 5 reads, and not actually 40. Tom suggested that I use trimpots (trimming potentiometers) to calibrate them before they even get processed by the code. I hadn’t heard of trimpots before, but they’re basically just potentiometers that aren’t big, unreliable and dumb like the ones we usually use at ITP. They’re tiny potentiometers where you change the resistance with a screwdriver. Click here to buy some. This way I can adjust the resistance in each of the 5 analog reads on the circuit, and get the values to line up with each other at rest. Right now my circuit is employing 220 resistors, so I will either use 500 ohm trimpots or 1000 ohm trimpots. This means that (because I’m using pull-up resistors), if the reading is too low, I can turn the trimpots resistance down to almost zero, and for the ones that are reading on the higher end of the 1023 scale, I can turn the trimpots up. As the sensor stands right now with static 220 resistors, the range of the noise is only about 100 points, which is not that bad actually. It’s going to make my life a lot easier in code to just match up the readings with trimpots on the circuit board though. Then I can take an average of the readings in code to clean up the noise, or probably use a Kalman filter.

This weekend I have to get my sensor off of alligator clips and into a permanent circuit. Again, my original plan was to sew the whole circuit using conductive thread, but I am completely over that. I spent so much time fighting with conductive thread, and I thought to myself, “You know what conducts electricity really, really well? Wires.”

So, my sensor will probably have more of a steam punk vibe. Maybe some day I could revisit the sensor and sleek it up with a conductive thread circuit, but for this prototype I’m going to just use wires and run them to a small solderable bread board, and then I’ll sew all of that with non-conductive thread to a tight-fitting shirt. Then I just have to connect a portable power source, set up WiFi serial, and this thing will be fully wireless. I’ll probably use a lithium polymer battery. More soon, and wish me luck on getting accepted into the Winter Show.

Week 11: Lots of Sewing

View fullsize

This week I focused a lot on building the actual wearable sensor for my final project. So, I logged as many hours as I could on the sewing machine. This sewing machine, by the way, is by far the most complicated machine on the ITP floor in my opinion.

Monday night, my wife, Marina, joined me on the floor, and we tried to figure out the sewing machine together. We brought some old pillow cases to use as practice material, and together we were able to get the thing going.

Marina showing off the complexity of the Juki HZL-F600

Initially we were using regular thread just to get the hang of the sewing machine, which took better part of Monday night. But, by the end of the night I was feeling pretty comfortable on the machine more or less. The next hurdle was getting the conductive thread onto a spool that will actually fit into the sewing machine. If only there were some kind of powered, spinning device on the ITP floor….

View fullsize

How to transfer conductive thread to a sewing machine like a boss

The drill! I was very proud of this problem solving moment. It worked perfectly. I got a spool of conductive thread, and then I put it in the machine and spooled a bobbin of conductive thread for the underside of the stitch, and I was ready to sew some circuits.

I decided to use my newfound sewing skills on my fabrication project, which was to build an enclosure. So I wired up a switch and a battery on the underside of a piece of wood from the Free Store (AKA Junk Shelf), and I completed the circuit on top by sewing conductive thread on an old pillow case.

View fullsize

Cool right? Wrong. It doesn’t work. You can read about it at this link.

As frustrating as it was, this was a very important learning opportunity for building the wearable fetal kick sensor. The sewn circuit’s conductivity falls off with the length of the circuit. Some possibilities for why this is:

1. The conductive thread I used isn’t as conductive as I thought.

2. The pillow case that I sewed onto has conductive properties and is dispersing my voltage.

3. Relating to the first point, it’s possible that the thread is still good enough for a circuit, but the zig-zag stitch I used effectively makes the circuit something like 50 times longer than it looks. So a tighter stitch that makes contact with itself could also help.

Originally I tried the stitch mentioned in #3. It’s also the same stitch Kobakant uses in their stretchy pressure matrix example. But, it was almost impossible (at least with my skill level) to sew that stitch onto the stretchy pillow case material I was using.

Some takeaways on what to do for next week. I will make a wearable sensor prototype by Thursday next week and have it connected to a P5 sketch. However, for now I will hold off on sewing the whole conductive matrix. For now, I can use conductive iron-on fabric to make my matrix that will save a ton of time and be more reliably conductive. By the way, this solution was Marina’s idea at like 1:30 in the morning when I got home after an evening of being frustrated with soft circuits. If I have time once I have my sensor and sketch working, I’ll take another crack at sewing it proper, but for now I think I will have to revert to simpler, more reliable materials.

Week 10: Fetal Kick Sensor Progress

A 2x2 pressure matrix sensor sending data to a P5 sketch

I made some headway on all aspects of my project. I got a prototype of the pressure matrix sensor working, I got my Arduino nano to transmit data over WiFi, and I got the pressure to send data in serial to a P5 sketch.

The sensor was a lot more complicated than I originally thought. Getting analog readings from the positive connections was straight forward. I set up the Arduino using the internal pull-up resistor, so the positive leads just plug straight into the Arduino analog pins, and then the negative ends (the perpendicular / opposite coordinates of the matrix) go to ground. I was so stumped, though… I understood how you get different Y values from analog readings, but how do you get the X values when they’re going to ground?

This is the inspiration for my pregnancy sensor

I spent so much time racking my brain trying to figure it out. Kobakant’s schematics seemed so thorough and so vague at the same time. For “Arduino Code,” they simply write:

GROUND the pin:
pinMode(pin#, OUTPUT);
digitalWrite(pin#, LOW);

IGNOTE the pin:
pinMode(pin#, INPUT);

What????? First of all, why would you put the digital pin as OUTPUT? also, I assume “ignote” is meant to say “ignore?” And, what?

The only other part of the code says:

READ from this pin:
pinMode(pin#, INPUT);
analogRead(pin#);

I just assumed their code was terribly vague, and it kind of is. But then I paid more attention to the schematics. How the sensor works is actually pretty damn brilliant. See if you can figure out what these code instructions are saying.

Pressure Matrix Code and Schematics

So this is how the sensor actually works: It can only read one column at a time, because that’s what is sending readings back to the Arduino. So, the way it generates Y data is by switching the ground back and forth over and over again, and then you record those data into unique sections of your array depending on which ground is active. You set a 1 millisecond delay in between each reading, and 10 milliseconds between each cycle, and you end up with a full reading in what effectively translates to real time data of the whole matrix.

This is the magic that makes it happen:

GROUND the pin:
pinMode(pin#, OUTPUT);
digitalWrite(pin#, LOW);

IGNOTE the pin:
pinMode(pin#, INPUT);

By plugging the ground of each component of the matrix to digital pins, you can convert those pins to ground by telling one pin at a time to write “OUTPUT, LOW.” It’s pretty goddamn brilliant.

I should note that I couldn’t have figured this out without my classmate, Max (whose last name I don’t know at the moment). He and I worked through this together ad nauseam last night. The few examples of pressure matrix code we did find on github seemed absolutely ludicrous until we sort of figured out this fundamental concept behind how the sensor works.

Here’s how the code we wrote for a 2x2 matrix looks:

Basically this is saying: read rows 1 and 2 at column 1, put those values in spots 0 and 1 of the array, then read rows 1 and 2 again, but this time at column 2, and put those values in spots 2 and 3 of the array. It was lot easier to troubleshoot this sensor using a 2x2 instead of my original 4x4 prototype. What was I thinking? But, now I’m ready to move on to a bigger sized matrix.

troubleshooting resistors

One thing I didn’t mention in my sensor troubleshooting (and textile troubleshooting in general) is futzing with resistors. Unlike most breadboard-ready nifty components from Adafruit or Sparkfun, conductive textiles are a moving target in terms of resistance and conductivity.

All of the examples I’ve seen of textile interface schematics use Arduino’s internal pull-up resistor. The nifty thing about that is that you just plug the positive end of your sensor straight into an analog pin, set the pinmode to “INPUT_PULLUP,” and you don’t have to worry about putting resistors in your circuit. When I first experimented with the pressure matrix sensor using Velostat (see last week’s post), I connected it using a pull-down resistor on the breadboard. What I didn’t mention is that which resistor you use with textiles matters, like a lot.

When I first plugged it in I put in a 10K Ohm resistor, because everything takes a 10K resistor, right? Wrong. After a little experimentation I found that a 20K resistor gave me much nicer data readings. Sure, you can always just change the threshold in code, but that doesn’t actually always work. My most successful pressure matrix I have so far is setup using internal pull-up, but my very next step in working with that sensor will be to change it to pull down with 20K resistors on my breadboard.

I suspect textile folks use internal resistors because it’s less crap that you will literally have to wear on your clothing. Unfortunately, the readings I’m getting using Arduino’s internal resistor are kind of sucky, so I will have to use 20K resistors in my circuit. I could still use pull-up resistors physically, but the readings are also backwards and counter-intuitive to me. So, since I’m adding resistors to my circuit anyway, I might as well use pull-down so everything isn’t ass-backwards.

WiFi

On another progress note. I got the Arduino to connect to a WiFi network using the example provided by the Arduino library.

Here is the link on how to do it.

Honestly it was pretty straightforward. I don’t feel terribly obligated to explain it. The hard part is going to be actually making serial communication work with P5 over WiFi. More on that next week….

Week 9: Final Project Revamped

Last week I posted my idea for a final project, which was essentially a photo booth that scared you and took your picture. Just kidding, I’m not doing that anymore for a number of reasons. Most importantly, though, I just wasn’t that into that idea. So, that brings me to my new idea: a wearable fetal kick sensor that transmits real-time data to the web.

My beautifully pregnant life partner, Marina.

This weekend I took Kate Hartman’s “Textile Interfaces” class, and in preparing for it I had an idea for a wearable project for my pregnant wife, Marina. I want to image our baby’s kicks using wearable sensors for her belly. When I say image, I’m not talking about high resolution imaging or anything like that, but more of an abstract visualization that would show the baby’s movements along X and Y coordinates of a .p5js sketch. I also want the data from her wearable to be able to be transmitted wirelessly to a website that would run the P5 sketch. The ultimate iteration being that we could share a URL with friends and family where they could go and see the baby’s movement in real time (Isn’t that nice?). Also, tracking fetal kicks is an important part of monitoring the baby’s health, especially in the third trimester. So, this wearable has medical functionality as well.

I made a prototype during textiles using Eonyx conductive stretchy fabric and a neoprene band. The conductive fabric did generate data, but not the way I had hoped. It basically functioned as a stretch sensor, but any kicks or pushes on it wouldn’t generate any change in voltage. So that material is no longer in consideration for my sensor. Also, because I want to map the sensors to X and Y coordinates (and possibly Z), I probably need a matrix of sensors, possibly using a multiplexer (David Rios’s idea). Kobakant, a sort of soft circuit innovation lab, has a great website for exploring different kinds of wearable (generally nontraditional) sensor tutorials to draw from. Click here for their “How to Get What You Want” website. In all likelihood, my sensor will probably look something like this (click here).

My first prototype in Textiles (and opportunity to embarass myself).

I spoke with David this week about my project, and he seemed into it — more so than my original photo booth idea — and he signed off on it. He offered a lot of valuable guidance about sensor materials, and also helped me create a product schedule. My first milestone is making serial communication through WiFi or bluetooth work in order to make a reasonable prototype to show for the final. So, between now and next week I have to get an analog sensor to send data wirelessly to a computer. Wish me luck.

For the aesthetic of the visualization, Marina pointed out that the aesthetic I was trying to describe to her was definitely being influenced by a mobile video game I’ve been playing called “Tiny Bubbles.” The sound design is gentle, serene, meditative and calming. The colors are primary, but not too bold, playful, approachable. All of these are things I want to incorporate into my baby kick visualization.

View fullsize

Screenshot from “Tiny Bubbles.”

I’m really excited to work on this project. From a technical point of view, it will be both challenging and rewarding to accomplish, and I’m also just excited to share the end result with the people I love. I’m also excited to have an excuse to spend more time with my wife during all of this hectic grad school business.

I’m going to be informally collaborating with some other first years with similar themes or technical hurdles. Oliver Rose is making a project that will be employing soft sensors, so we intend to work together troubleshooting that and wireless serial communication, and also just keeping each other company while we work on our respective projects. Elizabeth Perez and Simone Salva are doing a project involving child-parent interactions, so I’m excited to have them as thinking buddies.

Stay tuned for wireless serial communication and prototyping weird sensors!

Week 8: Scheming a Final Project

For my final project, I think I’d like to make a photo booth that scares the shit out of you and then takes a picture of your terrified face. This was definitely inspired by our Halloween midterm projects, specifically my classmates' Alvaro and Sidney’s skeleton-behind-a-leather-canvas project. I realize it won’t be Halloween anymore, and that maybe scaring people is out of context, but I would argue that this will make the element of surprise that much better precisely because it won’t be Halloween.

I’ve also been trying to think of ways to incorporate my background in photography into my ITP work, and I think this is an interesting way to do it. I also just began my fabrication class, and it would be nice to put some of those skills to use.

Photo booths are relatively simple. You go in, you pay a fee and/or press a button, it takes your picture, and then cute little prints of your pictures slide out of a little slot somewhere. Classic. Timeless. What I want to do is create a photo booth that scares you a fraction of a second before it clicks the shutter on the camera. I would like to create the scare using something physical, also. Some sort of terrifying automaton that jumps out at you.

Small, consumer-grade printers are easy enough to find for a reasonable price, and I’d probably use one of my old cameras for materials. I also have some strobes I can use for it as well, so I think I have the more expensive aspects taken care of.

Beyond that, it’s really just building a small booth with a curtain and wiring and programming the whole thing up. I haven’t decided my scaring mechanism yet. More on that later. But the photo booth parts are pretty straightforward in my mind (famous last words, right?).

Week 7: Midterm! Halloween Dance Revolution!

For our midterm project, I was paired with Mingxi Xu. We wanted to make a version of Dance Dance Revolution that was more based on player input than pre-programmed dance moves. The idea was that one player would dance, and then the other player would have to copy the dance moves in order to win. And because our midterm was Halloween themed, we made the game Halloween themed as well. Mingxi made the very cool animation intro in our sketch that you see at the beginning of the above video.

To start, we order some larger (1.5 inch) force sensors to sense our dance moves. In the very early stages of prototyping we used a wire wrapper and some very thin wire to attach the sensors to our breadboard. We put them under a piece of canvas drop cloth we got at the hardware store in order to create a rudimentary dance pad. We wanted to use a drop cloth because it would be easy to paint on later. In the beginning though, we just marked the spot with some tape Xs.

A force sensor attached to thin solid wire using a wire wrapper.

Mingxi Xu testing our earliest dance pad prototype.

Setting up the sensors was the easy part. Most of our project was spent debugging our P5 sketch ( Here is a link to it). Creating the logic for how the game would work was relatively straightforward, but the biggest stumbling block we faced was performance problems in .p5js. Mingxi really layed the groundwork for our program. Tracking time data is at the heart of our program. Our first prototypes used the frame count to keep track of time, and it worked great at first. Then we realized that if you do any more than four moves or so, the program slows way down and generates a lot of lag. This means that it’s impossible for Player 2 to follow your moves when time is effectively changed when it’s their turn.

So, I met with my ICM teacher, Allison Parrish, who solved our problems in one sentence. “You should use millis,” she said. And that’s what we did. “millis()” is a call in .p5js that keeps track of time since the program began using the computer’s clock in milliseconds. It’s constant, regardless of the program’s performance. Once we plugged it into our sketch, it worked great.

After that we had a million other problems that came up. I can’t even remember half of them now, they were so frequent, and so dumb in hindsight.

There were a lot of dumb mistakes on the Arduino end as well. At one point I swapped out the resistors on my breadboard for LEDs thinking, “This is so great! Now I can visibly see if the sensors are working or not on the breadboard!” Then, the next day we were tirelessly troubleshooting the weird sensor readings we were getting from our FSRs that were fluctuating from 300 to 700 or even 800 endlessly. One of them was especially bad. We were going nuts trying to fix it with Arduino code by constraining the sensor values. Then I remembered, “Oooooohhhh…. It’s because I took the resistors out.” Sure enough, when we plugged the 10K ohm resistors back into the breadboard, the sensor readings returned back to normal. It also makes sense why one of the sensors appeared to have an usually high value — it was the closest to the power source.

The culprit LEDS laying defeated after I removed them in frustration and replaced them with 10K resistors.

While we’re talking about sensor data, we went back and forth several times with whether to use our FSRs as digital data or to map them to digital data from analog data. Turns out you can just plug an analog sensor into a digital Arduino pin and it will inherently generate 1 or 0 values, so it does actually work to just plug an analog sensor into digital. However, we didn’t want the sensors to have a “hair trigger,” so we read them as analog and then chilled them out by saying “generate zeroes unless your value goes over 800,” with an “if” statement in our Arduino code. In the end that’s what we ended up using, and it worked pretty damn well.

The sensors generated a four-digit array of data separated by commas as delimiters. We interpreted that data into up, down, left or right values in .p5js. Oh! I almost forgot to mention our yellow button. We added a yellow button at the end that was just a switch in our game’s control flow. This was value 5 of our data array — just a digital switch.

This is our Arduino code for creating digital data from an analog sensor by creating a threshold from analog data. In this case, it’s 800.

The biggest problem we ran into, as previously stated, was .p5js performance. In the end, we realized that you just shouldn’t load images into P5 and expect the performance to be any good. Originally Mingxi created these nice illustrations that were going to be our arrows for gameplay. When we plugged them into the P5 sketch, the delay was astronomical. So, I recreated his drawings using bezier verteces in P5. It was time consuming, but once we plugged them into the sketch, the performance we infinitely better.

It was also during this time that we finalized our dance pad design. I used my wife, Marina’s, yoga mat folder in half as our dance pad in a nutshell, with the canvas on top and the sensors in between. Then I painted arrows on the canvas and basically put the whole thing together with tape. We also braided some solid wire using a drill and soldered them to the force sensors and hot glued them to avoid any shorts.

All in all, I’d call it a success!

Music credits:

Halloween intro - “Funny Halloween” — royalty-free stock music from Pond5..com
”Crazy” - Gnarls Barkley
”Good Vibrations” - Marky Mark and the Funky Bunch
”Never Gonna Give You Up” - Rick Astley
”Flashlight” - George Clinton and Parliament Funkadelic

Week 6: Serial to P5

We finally married the Arduino and .p5js together. I feel like some Phil Collins would be appropriate right now. Serial communication is pretty finicky. There are so many opportunities for bugs to show up, but the end result is pretty awesome.

I sent the serial data from the potentiometer on my breadboard, and I mapped it to some scale values in my P5 sketch. Pretty cool, right? Also, that’s my cat, Henry, and this video was filmed by my wife, Marina.

I did a lot of work cleaning up the noise of the potentiometer. When I first started running my sketch with serial, the planets would be jittery when the potentiometer was at rest and it was driving me crazy. I did two things to clean up the voltage output. One is that I put a 10K resistor in between the potentiometer and the Analog pin on the Arduino. This helped pretty significantly, but still not enough. I did some research online and I found forum about it (Click here for link).

This is what it ends up looking like. The way I understand it is that it takes two readings simultaneously and uses the reading that has the least amount of variance compared to the previous reading. It looks like this:

We also started scheming for our midterm project this week. We were teamed up to make collaborative projects. I’m with Mingxi Xu. Our plan is to make a dance game using large FSR’s as sensors to detect your dance moves and send that data to a P5 sketch. Our hope is to be able to have one player dance, and program the game so that the next player has to copy the first player’s dance moves.

These are the FSRs we will use (click here for link):

We had to special order some larger, more heavy duty FSRs, which arrived yesterday. We’ll have to figure out how to connect those sensors to our P5 sketch in serial, design the physical dance board on the floor, program the visual appearance of the program, and most importantly, program the mechanism by which P5 records one player’s dance moves and compares them to the other. That will probably be the most difficult part. More on that next week….

Week 4: Making Noise and Turning Nobs

Making noise! I got to make my first electronic instrument from scratch, so that was cool. Also, I finally made a schematic for something. Check this out:

I hooked a flex sensor up to the Arduino, mapped it to a range of frequencies, and then output it to a speaker. Then I added two buttons at static tones and a couple LEDs to those buttons. Here is the result:

Oh, also I figured out how to use constrain to clean up the flicker in my LED that was being controlled by a potentiometer.

I also mapped a potentiometer to a 180 degree servo motor, which was cool. There was a common theme among all of these prototypes, which was troubleshooting my own unanticipated mistakes. I think 9 times out of 10 something didn’t work because of a ridiculous error on my part (plugging something in to the wrong place, forgot to change a variable in my code or any number of silly mistakes). Other than that, the labs went pretty smoothly. Here is my servo setup:

Week 3: Observing Humans and Writing in C

This week we were tasked with observing interactive technology in a public setting, and how people’s experience with it went. I chose Burger King mostly out of the convenience of proximity to ITP campus. Before watching any interaction, or using it myself, my assumption was that this device was there to streamline the process of ordering and receiving food at this establishment. People would walk up, press some touch pad buttons, swipe their bank cards, and then pick up their food without burdening the already bloated queue of customers.

My first observation was incomplete. A young woman had already gone through the ordering process and was paying. She opted to use mobile pay. As far as I could tell, she was waiting 2-3 minutes for her payment to process. In the context of fast-food, that is a long time. The other users I observed chose traditional bank cards for payment, and that process seemed to go much quicker.

My second, but first complete, interaction took probably ten minutes. This thing has a lot of screens that it prompts you through, and a lot of customizability. I recognize that Burger King has a long-standing branding ethos of “Have it Your Way,” but most customers seemed confused and frustrated by it. Most people just want a Whopper with fries and a drink.

The third person I observed made it to the “fire grilled beef” menu, made several attempts at deciphering it, walked over to the analog, human-ordering line to see how long it was, looked at the digital kiosk again, and then walked out the door sans fire grilled beef.

I went through the menu prompts myself. To its design credit, I thought how to use it was pretty intuitive and straight-forward. However, the interaction was still obnoxious. There were seven screens I had to go through that asked me about things I wasn't interested in. It's not easy to get a basic, straight-forward combo meal.

The ingredient sliders were particularly annoying. I think this was in part because the design deviated from the established flow of the interactive menu. It was jarring, and also weird and unnecessary in principle. No human being at a fast food restaurant had ever asked me what proportion I would like my ingredients in, so why is this digital kiosk asking me? In the words of Donald Norman, “...it is an excess of visibility that makes the gadget-ridden, feature-laden modern… so intimidating.”

Analog in, digital out, writing in c

In our labs this week we explored the difference between analog and digital inputs and outputs. Digital meaning a sensor or actuator that works with binary on/off data, and analog meaning a sensor or actuator that works with an incremental range of data.

This was also my first time writing a program for Arduino which was pretty cool. First we simply made buttons, or switches, that turned an LED on and off. First we accomplished this without any code, using the Arduino exclusively as a power source, turning the LED on and off by closing and opening the circuit respectively. Then we built a circuit where operating the LED was dependent on our Arduino program. The end result was the same, but the mechanism was very different in ideology.

The next step was to use an analog input to create a digital output. This meant using a potentiometer (which is basically an adjustable resistor) as a dimmer for the LED. The raw data coming out of the potentiometer was too high in number, so we translated that into more palatable data by simply dividing it by four. The program looks like this:

And here is the result:

Inaugural Post! Breadboard! Musical Switch!

This is my first time building a circuit out of a breadboard, or any circuit since the 7th grade for that matter. The experience was definitely a steep learning curve for me. Mostly it just took a lot of tries to wrap my brain around the flow of parallel circuits, and the flow of the breadboard. Super fun, super rewarding — especially that moment when my funny little switch actually worked.

I’d like to know how to make a switch turn the whole circuit on and off when the components are in parallel. As you can see in the video, my switch only turns one LED on and off. I think I have any idea of how to do it, but I would’ve had to rearrange my circuit from scratch (and I was so close to being done with my homework assignment), so next time!

Here is my circuit pre-switch:

Professor David Rios was super helpful — not just to me, but he was really making himself available to all of us working in the shop last night. Nick Grant (my classmate whom I have pretty much every class with this semester) was also super helpful (he’s the one who shot this video), as was Aswathy (very much so). Sadly I don’t know her last name. Still getting to know everybody.

Anyways, on to the next adventure in physical computing!