Military Issue video, code & audio sources

Thriving in a military environment requires a value system that is very different from that of the civilian world. It requires that you give up a part of yourself. The process of reclaiming the lost pieces when reintegrating after service is one of profound confusion, anger, and grief. How can you focus if your mind constantly runs through the procedure for correcting a malfunction in an M16 rifle? How do you respond to folks who gush about how fashionable military uniforms are? How do you connect with those around you when you’re overcome with guilt at leaving friends behind, friends that continue to spend every day in harm’s way? How do you cope with the realization that these questions have no clean, simple answers? Military Issue is an installation that exists as an artifact of my own exploration of these and many other questions. It seeks to capture the fragmented nature of this unpacking process. It demands a long attention span and a willingness to confront discomfort and confusion, just as the reintegration journey does. It begs users to consider that service doesn’t end when a person takes off the uniform for the last time.

Continue reading

Military Issue prototyping and testing process

Once I had decided to use a collection of objects, photocells, and audio, my first task was to make the technology work with a single object and audio track. I started with the boot, as it had been an object I had been working with through several past iterations of the project, and felt I had strong sense of what it meant to me. I’ll be honest, it didn’t take long and wasn’t difficult to get it working. This isn’t terribly surprising, since the technology was no more complicated than one of the first labs we did this semester, the analog input lab. When the reading from the sensor exceeded a certain amount (when the flashlight was shining on it), the audio played. Otherwise, it paused. I tested this with several people, and received a positive response: Continue reading

Military Issue Brief

Thriving in a military environment requires a value system that is very different from that of the civilian world. It requires that you give up a part of yourself. The process of reclaiming the lost pieces when reintegrating after service is one of profound confusion, anger, and grief. How can you focus if your mind constantly runs through the procedure for correcting a malfunction in an M16 rifle? How do you respond to folks who gush about how fashionable military uniforms are? How do you connect with those around you when you’re overcome with guilt at leaving friends behind, friends that continue to spend every day in harm’s way? How do you cope with the realization that these questions have no clean, simple answers? Military Issue is an installation that exists as an artifact of my own exploration of these and many other questions. It seeks to capture the fragmented nature of this unpacking process. It demands a long attention span and a willingness to confront discomfort and confusion, just as the reintegration journey does. It begs users to consider that service doesn’t end when a person takes off the uniform for the last time.

Using a government-issue, red-bulb flashlight, users will be able to explore a cutout silhouette of a soldier that has various military objects attached to it. Photocells on or around each object will trigger related audio when the flashlight shines on them.

BILL OF MATERIALS

SYSTEM DIAGRAM:

MISystemDiagram

PComp/ICM final conceptual development

Since I initially listed my project ideas and topics of interest for my physical computing final, I haven’t been able to get my interest in war, trauma, and memory out of my head. I’ve also come to realize that the interest is about much more than war, but about the experience of being in the military in general. Since exploring these issues in the first conceptual iteration, WEIGHT, there have been several ideas that have led to my final project. Continue reading

WEIGHT: A PComp/ICM combined final

“They carried all the emotional baggage of men who might die. Grief, terror, love, longing—these were intangibles, but the intangibles had their own mass and specific gravity, they had tangible weight.”

-Tim O’Brian, The Things They Carried (p. 20).

The wars in Iraq and Afghanistan have officially ended; Operation Iraqi Freedom in 2013, Operation Enduring Freedom in 2014. In the minds and bodies of many of those who fought them, however, the wars continue and will continue for decades to come. Despite this, we as a collective have forgotten. For most, the wars are in the past, the time for political activism come and gone. For my final projects in PComp and ICM, I want to create an interactive experience that forces users to remember, and to consider the invisible weight many combat veterans continue to shoulder.

PHYSICAL COMPONENTS

The project will ask the user to wear a heavily-weighted rucksack. This will not be connected to any physical computing mechanism, but is a standalone physical object to enhance the user’s empathy with the invisible weight present in many stories used in the project.

Several sets of dog tags will be hung from an apparatus (TBD) and will act as touch sensors. Dog tags, which are used as a casualty identification tool in war, have been co-opted by brands and fashion for commercial purposes. This disassociation has aided in America’s collective amnesia regarding the ongoing physical and mental cost of wars that many consider “finished.” When touched, individual dog tags will be connected to specific stories that will play through a JavaScript program.

DIGITAL COMPONENTS

 When a dog tag is not being handled, the names of fatal casualties from the wars in Iraq and Afghanistan will display (in a method TBD) alongside unfiltered images/videos of war. When a dog tag is touched, this will temporarily stop to be replaced with a story of trauma in text, audio, or video form. Throughout the course of the interaction, users will be forced to choose between confronting the visible or invisible destruction of war, all while carrying a large weight of their own on their backs.

This is very much a work in progress, even on a conceptual level, and any feedback would be appreciated.

PComp Final Ideas

1: Device critiquing the concept of the American Dream

In the US, there’s this crazy idea called the American Dream – “the set of ideals (Democracy, Rights, Liberty, Opportunity, and Equality) in which freedom includes the opportunity for prosperity and success, and an upward social mobility for the family and children, achieved through hard work in a society with few barriers.” (Wikipedia). This is, and always has been, BS. Continue reading

Get You Head in the (PComp) Game!

Note: My documentation for the process behind our midterm was pretty abysmal along the way. There are lots of moments in the following discussion where I wanted to have a picture or video but didn’t take anything at the time. It was a great learning experience for next time, though doesn’t improve the wall of text that this has turned into.

My partner for the PComp midterm has been Danielle Butler. We are also working on the same team for Outrage Machine, and we wanted to explore the multi-faceted concept of privilege with our midterm as a warm-up for that larger project. We quickly decided we were trying to tackle too much with a one-week assignment, and pared it back to one dimension of privilege, then gravitated away from that a bit and towards a fun game controlled with the head. In a way, it’s asking the user to try something in a way that they are not accustomed to, and in that way could be seen as a way to begin a conversation about ableism and the privileges enjoyed by non-disabled folks.

Our first step was to get a sensor working the way we wanted. Benedetta suggested either an accelerometer or a tilt switch. We obtained one of each and split up figuring them out, with me taking the accelerometer and Danielle working with the tilt switch. The tilt switch is fairly easy to understand in theory, but I still am not completely clear about the science behind the accelerometer. Nonetheless, I was able to wire it correctly with an arduino and my computer fairly quickly and begin to obtain values. The values were strange to say the least. They ranged from about 250 to 400, with 330 being the value returned when the sensor was flat. Through the use of if statements, I managed to make a ball move when the sensor was tilted past a certain point in one of the four major directions, and stop when it was tilted back. At that point, the midterm became a matter of designing an interesting program in p5.js and ensuring that the physical device would work properly on a person’s head.

We did a lot of brainstorming, and came up with many program ideas that would not have been possible in the time available to us. We settled on a game that involved driving a car around a circular track, but even that ended up being more complicated than expected. The main challenge was constraining the car to the track. Unlike a ball bouncing around a screen, we couldn’t simply multiply the speed by -1 if it hit the side of the track; if we set the speed to 0, however, the program would no longer respond to sensor values but would constantly reset the speeds to 0 regardless of serial input. The circular shape also presented a challenge compared to a square for constraining position.

The solution was to go with the same concept of the bouncing ball, multiplying the speed by -1. It’s not terribly intuitive how that works, but essentially the sensor data will continue to correct this number after it is set. If the head remains tilted in the direction it was tilted in to cause the collision, the speed will be reset to the previous value; if it tilts to flat, the speed will become 0; and if it tilts in the opposite direction, it will continue on the path set by the program after the collision. This eliminates the issue of getting “stuck.”

We are still testing for speed and sensor sensitivity, but we’re very excited to show our prototype in class and see how well people do trying to drive with their heads!

 

Asynchronous Serial Communication

Overall, I found the labs this week to be a lot of tedium, which is understandable. The exercises were largely a rehash of what we had done in class, but even when everything worked it was really difficult to quickly and efficiently work through them because of the way they are structured. I need to push myself in the future to not get so hung up on documenting every little step and focus on expanding beyond the written instructions for those labs that I feel comfortable with. I also need to push myself with PComp more generally, as I feel like it’s often the first class that gets shoved aside when I’m forced to prioritize and manage my time. I’m hoping that the final project will be an excellent opportunity to do this in a major way.

Instead of an accelerometer, I decided to use an FSR and a potentiometer for the first part of the lab, which really just consisted of changing the arduino code and observing different serial monitor outputs. Since my circuit was set up and working, the serial monitor output followed correctly and as a result there isn’t much to say about this (large) portion of the lab. I’m impressed by how quickly the different pieces can convert between binary, ASCII, and characters, but I shouldn’t be since it’s a computer…

There will be a long, boring video coming eventually that shows a screen capture of most of the screen-based outputs of this lab, as well as some of my work process as well.

The one thing that I did find was that my third value was noise when we started to send multiple values separated by punctuation. When I thought about why, I realized that I didn’t have 3 analog sensors hooked up, and neither did the diagram in the lab. The for loop as written would not work with two analog sensors and one digital. It did work in the next part where it accounts for that and writes each sensor separately.

The next section, on handshaking and call and response, could have potentially been an opportunity to be a bit creative. I wasn’t, however. The output can be seen in the video that will be uploaded.

For the serial input lab, I started out using an FSR. I switched to a potentiometer, however, because I kept running into problems where p5 would return an undefined value even though the serial monitor in arduino printed the correct FSR values. When I replaced the FSR with a potentiometer, this issue cleared up and both programs seemed happy. The graph would have been another opportunity for some creativity, but at this point I was ready to be finished. Again, I need to work on pushing myself. The output for this section of the lab is also on the video.

Gravity – Where Physical Meets Digital

The challenge: in 90 minutes, create an interactive experience utilizing javascript, an arduino, and a single digital or analog input.

Today was a really exciting opportunity to blend material from PComp and ICM, and to create a program with javascript that responds to input from a physical button. I had an opportunity to work with Yue Hu for this challenge. She has a much more PComp-oriented mind than I do, and I have a more ICM-oriented mind, so we complimented each other quite nicely. We decided to use the single-ball iteration of my gravity program, but to replace the on-screen switch with a homemade physical switch that also tied into gravity.

Working with a 90 minute time limit and the materials we had on hand, we came up with a prototype that works, but not as consistently as we would have liked. Much of that, we feel, can be attributed to the need to use tape to create connections instead of more permanent methods like soldering, as well as the unavailability of a copper sheet. This meant we had to line the top of the box with strips of cooper tape instead.

We placed a large metal washer inside a small box and connected it to ground, and connected the strips of copper tape on the top to power. This caused the two to act as a switch that would close when the box was shook. It was incredible to watch people’s faces when we opened the box and they saw how the switch was constructed. It was a fun exercise and was certainly the most creative thing I have done with physical computing so far.

IMG_0141

User interaction:

Gravity – Where Physical & Digital Meet from Ian Gibson on Vimeo.