Simple Overview

This image is a quick overview of the major technological components and how they interact. For more detailed images as well as video, please check out my previous posts!

Attention Whore Concept

Attention Whore Concept

For this assignment I wanted to create a piece of wearable technology that reflects present youth culture and the obsession of drawing attention to one's self. While the tactics used to call attention have changed over many generations, using sex or visual sexual stimulation have remained a constant. While it has always been a part of our culture, it seems that flaunting one's sexuality, as well as one's body, has become a wide-spread fashion trend.

I recently visited a club and took the chance to watch people and look at what they were wearing. Most everyone in the club was at the least well groomed (or it seems that they at least started that way), and I would say that over half were wearing clothes that were revealing or sexually inspired.

Witnessing a growth of these trends throughout such a small period of time made me wonder what the next step in fashion would be for our sex-hungry generation. While our generation may be obsessed with sex and fame, our generation is also obsessed with new technologies.

Our generation, commonly referred to as the Me Generation, is filled with hungry consumers with a strong desire to have every aspect of their lives personalized to reflect their individual style. Whether our style is reflected through the clothes we wear or the songs that we have on our iPods, we are making a statement about who we are in relation to those around us.

Using the trends of our generation, I wanted to create a piece of wearable technology that not only was personalized to the wearer, but a garment that reflected our overwhelming desire for attention. In a time where each successive piece of clothing further stretches the boundaries of acceptability, I wanted to continue on with this trend and take it to the extreme.

Creating an evening dress that was covered in two layers of organza (a shiny semi-transparent material), I installed LED displays on the breasts that act as a music visualizer. Each display (which was made to reference a nipple) consisted of eight blue LEDs arranged in a circle with their lights shining towards a center point.

The two layers of organza were used as a diffuser for the light that gets emitted, creating a soft display that moves and flows with the garment. I chose the color blue because it is a color that I commonly associate with youth. I specifically stayed away from red as I felt that the lights on the chest would be more than sufficient attention grabbers and that using a color such as red would be more of a distraction than an enhancement.

Conductive threading was used to connect the LEDs to the Arduino, which were all able to be hooked up to the same PWM (Pulse Width Modulation) slot. The setup also includes a headphone splitter wherein one of the jacks is used for a wire that inputs the electrical signal from the music device into the Arduino.

While the current design only allows with audio from a computer, the goal is to get the system to work with a MP3 player or any other portable music device.

The dress is designed to allow the wearer to listen to their favorite music and have their breasts display their individual music style.

The organza as well the dress design allow for maximum fabric movability; because of this, the light display not only mimics the music that is being played, but it also moves in time with the wearer's movement.

The name "Attention Whore" was chosen as the title of the piece after its completion and while acting as a pun, I chose it because I felt that it summed up the essence of my work.

I plan on continuing working with wearable technology in the future, but other than attempting to make this piece work with a portable music device, I will not be making further changes to the piece. While an advantage of using technology is its ability to be easily updated, I feel that changing any other components would be changing the dress itself. Instead I plan on taking my other ideas and iterations of this dress to create new pieces.

Set 5

Inside Pocket of dress that houses the Arduino unit. If I can manage to figure out a way to use the device with a battery, there is enough room to enclose the power source as well.

This is a map that I made to show how my LED array works. Each breast contains 8 LEDs which are all oriented on a circle with their light shining towards the center. The Positive and Negative marks show how the conductive thread was run in order to prevent short-circuits.

This is a view of my computer hooked up to the Arduino. For this iteration the computer was playing the music as well as powering the microcontroller.

This is a top-down view of the Arduino, labeled to show how the project was wired to the board.

This image shows how the conductive threading is hooked up to the microcontroller.

Set 4

Here are the buttons on the collar. I had to reinforce the buttons because they end supperting the weight of the entire dress.

Here is another image of the collar with buttons .

This is a look at the LED display from the inside of the dress that shows off the circuitry.

Another inside shot of the nipple display. Some of the wires look like they are touching in the image, but this is because the dress is not being worn. When the area is stretched by someone wearing it, the wires are not nearly as close.

This image is also of the LED displays except that they are being viewed from the proper side.

Mapping Project Process (Partly)

Here's what I managed to recover from my mapping project post; unfortunately, I never found the time to fully rewrite it...

---------------------------------------------------------------------------------

For this project, I went through quite a few different ideas over the course of the few weeks.


Idea 1

The very first idea I had was to do something with the thousands of pictures and video footage I have from Japan. While these things are not local in respect to my current whereabouts, there were five weeks over the summer in which these areas were very much my local; it will hopefully become my local again sometime in the future as I plan to go back and possibly live there. My original thought was to basically recreate my experience in Japan by means of putting together what I would consider a virtual memory (hopefully I can make this term become more clear in its definition). I wanted to piece together all of the photos and video I have in chronological order. The result would be the visualization of images and video in the order they were taken, which, in turn, would take the viewer through a virtual experience identical to mine in Japan. For example, we first arrived in Narita airport (the viewer would see hundreds of images/videos; enough so to hopefully allow the viewer to create a mental space for this place they've never visited and to

Imagine, if you will, if it were possible for someone to record exactly what they see, from their eyes. Unlike a video camera, this video would not be from an external device, held out at an arm's length, constantly bouncing around due to arm/hand instability; this video would be from the person's eyes. Whatever the person were to look at, the video would see; anything that's out of the person's field of focus would be blurry, anything that's out of the field of view would be unseen. For all intents and purposes, the viewer would be looking out of the "cameraman's" eyes. Now what if there were no limit to the amount of video recorded? What if a person could record their entire life that could be later viewed by the individual as well as others? If this technology existed, how would (if at all) this change experiences? For example, would watching a recording of someone who visited Japan be the same as going there in person? If the experience is so complete, how would it be any different?

This technology wouldn't be true virtual reality, but it would certainly be very close. While there is no tactile responses from this recorded footage, it would be insurmountably more complete an experience than simply looking at a few snapshots and some videos from a selection of a dozen or so.

Obviously, the idea for this project has some flaws (it is NOT this technology, it is NOT a complete visual experience of my trip, etc.), but it is working towards it. This is the kind of thing I was thinking about when I wanted to do this idea. That being said, I did take tens of thousands of pictures and hundreds of videos --waaaaaaay more visual record than any other person would take over a five week period; I believe this huge amount of data I have would be a very complete experience of my trip, and I thought about that while taking the pictures/videos --I wanted to capture everything, even if it wasn't or didn't seem important --I wanted every experience recorded.

Often people (usually tourists) who do nothing but take pictures are made fun of or pitied because they are experiencing everything through a camera. The point (or at least the supposed point) of going somewhere different is to experience that place first-hand, yet how can one do that while constantly looking through a camera lens? The camera-person is more fixated on getting things in the frame, stopping to pose, or thinking about what to take pictures of than actually experiencing the place. Also common in this kind of discussion is the notion of authenticity. The only way to have something be "authentic" is to experience it first hand --to see it with his or her own eyes and remember the experience by pure memory alone. These experiences become tainted, sometimes even skewed and distorted thanks to the aid of things like photos and videos. You may remember something different than the way it actually happened, you may notice something later that you didn't notice the first time. These things may distort your original experience --perhaps in good ways, perhaps in bad; regardless, the distortion is still occurring, which, many would say, detracts from the authenticity of the original experience. With that said, the person who is constantly taking photos is missing out on these original, authentic experiences in order to relive them later in a (usually unknowingly) less authentic and certainly less real way.

I'm not saying I didn't succumb to this, but what I will say is that I was completely aware of it. I KNEW I was taking a lot of photos, I KNEW I was missing out on some authentic experiences, I KNEW reliving the experiences through photo would not be the same as experiencing them in the now. Because I was aware of this, I protected myself from it (or at least constantly tried to). What I mean is that many (many, many) of my photos and videos are shot without my even looking at the camera; I was looking at these things with my own two eyes but at the same time, aiming the camera at it, snapping a shot, and hoping for the best. Obviously many of the photos didn't turn out ideal, but I did get quite good at getting the photo I wanted. By these means, I was almost using this imaginary technology mentioned above --I was recording my experiences very fully, but I was doing so without losing the chance to experience the authentic (as would be the result of a constant video feed from one's eyes). Defending myself is aside the point. What IS the point is that I knew what I was doing in anticipation of creating a very full experience for both myself and others by means of a project like this.

Onto the project itself. In short, it would create a very full experience of my trip --ideally enough so that the viewer would feel as if he or she had gone on the trip in place of me. What I would do would be something like this: I would collect all of my photos, videos, and collected objects (brochures, magazines, newspapers, random small objects, etc.) and organize them chronologically. In addition to doing this, I would map where each photo, video, etc. was taken to create a visual path on a map (the first batch of images where from Narita airport, the next from the train, the next from the train station, the next from another train, the next from the Shinagawa train station, the next from the road to our hotel, etc., etc.)


Idea 2

My second idea had to do with a locale much closer to home. In short, what I would do for this was map my individual paths throughout the course of the weeks before the crit via GPS. Visually, I had imagined it to look like what Katie's project turned out to be. However, I did not plan on having a static image. This would be something interactive. The viewer would be able to toggle different paths on and off (to view all, some, or just one at any one time). These paths would also hold information about what activities I was doing while inhabiting these different areas (personal activities, schoolwork, relaxing, sleeping, eating, walking, driving, etc.). The different activities would be denoted by different colors. In addition to this, I had planned on deforming a map of the area in accordance with my GPS findings. The longer I was in a certain area, the more deformed that area would become. I had thought about two different ways to deform --locally and globally. The former basically meaning that the deformed areas would appear bigger but would not take up more than their original space on the map. The latter meaning that the deformations would bleed into adjacent areas. Here are examples of each - original, local deformation, and global deformation:







I thought this project would be interesting for a few reasons, one being I'm curious to see how exactly I spend my days. I consider myself somewhat unusual in that I hardly ever go out anywhere. This is especially true this semester as myself as well as all of my friends are constantly busy and hardly have time to hang out. The vast majority of my time is spent either in my room or in FAC 302 (I have all of my non-online classes in this room this semester). Over the course of the three and a half years I've been here at UF, I have easily spent the most time in either FAC or my room (Jennings Hall for two years and the Courtyards apartment complex for the last year and a half). How long exactly do I spend in these places? How long is it compared to other places I visit throughout my days here? Where all do I go other than my apartment or FAC? How many times have I gone over the exact same path to get from one place to another? How many times have I stepped on the mulch surrounding the Courtyards' plants? How many times did I ride over the on Jennings' lawn? How many times have I traveled up and down the west staircase of FAC? Have I created some kind of path over the years? Have I affected the ground over which I tread at all? If so, how?
I'm also interested to see how much time I spend doing certain activities. Time and time again, I find myself working on projects for hours on end. An entire day goes by without me even realizing it. The same often happens when I play games or read books that I really enjoy. Time just completely escapes me. I'm really eager to see what those numbers would be as well as those indicating how long I spend in a certain place. People say that humans sleep one third of their life away. I think it'd be neat compare that to my sleep cycle. Regardless, I think people (myself included) would be surprised by the results that arose from this project.

Mapping Project Process

I wasted a lot of time on the mapping project trying to find a way to get a usable fingerprint scan image off of the little gadget on my brother's laptop that reads fingerprints in lieu of passwords. The only time they actually let you see the image scanned, though, is when you first input your fingerprints to set up your account, and even then it's only a tiny little useless thumbnail. It was very frustrating.

I eventually gave up on the fingerprint scanner as a lost cause and defaulted to the classic fingerprinting method of ink on paper. Even then it was a lot harder to get a usable print than I would have thought. My fingers would always either be too wet and the lines would blotch together or the ink would dry too much and not leave solid lines at all. They always make it look so easy on TV. I don't know, maybe the ink-pad I bought wasn't the right kind, and there's something special about ones you take fingerprints with. I don't think fingerprinting was it's intended purpose.

When it came to actually making the model, I was disheartened to find that there was no easy function for drawing three-dimensional shapes in processing, which basically meant I would have to do a lot of trigonometry. I had to use the pushMatrix and popMatrix methods to move and rotate the coordinate plane around, and then always draw a triangle on the x-y plane, which means I had to create some arrays to hold the distances between points both vertically and diagonally, which would change based on a given points elevation (which itself would be taken from an array whose values would depend on the referenced fingerprint image). If two adjacent points were wildly different in elevation, that side of the drawn triangle would need to be longer, etc.

I had a really hard time debugging this project. I think a lot of it was that I spent so much time checking and re-checking my trigonometry that I overlooked a lot of problems that didn't have a lot to do with that. For a long time I couldn't figure out why the upper-left set of my triangles between points would seemingly diverge and curve away in a plane away from the lower-right set of triangles, so that instead of one solid landscape I'd have two diverging sets of shrapnel. It turned out I only ever had the triangles turn in one direction, so that they'd turn up when there was a mountain, and then when there'd be a valley, instead of turning downward, they would turn upwards again.

I had to make a tic-tac-toe-sized grid on a model to figure out exactly what was wrong. I also used it to work out the order in which to do the transformations that enable the model to be navigated, so that everything's done in the right order and the camera movement works like expected.

The version I actually turned in utilized Processing's box function to act as a three-dimensional pixel in rendering the landscape. In order to get a smooth transition between the peaks and valleys of the fingerprints I ended up having to actually manually blur the edges of the black-and-white fingerprint images in Photoshop, so that when the program read the image to calculate elevations and calculate the shifts in color for each 'pixel', there'd be no abrupt transitions. I tried to work out an in-processing way to alter the fingerprint image to get a similar effect, but nothing I tried worked very well.

A sample of the fingerprint image I used:
I would have liked to have been able to use a higher resolution image to sample from, so that I'd be able to make larger dunes in the fingerprint landscape without getting too boxy, but the performance speed was pretty horrible even the way it was.

The trigononometric-landscape I developed ended up with a lot of cracks in it between triangles due to rounding, and I ended up making a single, flat, skin-toned rectangle underneath everything to mask them a little bit.

And then, of course, I realized that you *can* easily draw three-dimensional planes in Processing, just by adding a third, z-coordinate argument to the vertex function when using beginShape, which pretty much made all the work I did on the trigonometric version obsolete, since this way you didn't have the rounding cracks, worked faster, and was about a billion times easier to code.

One thing I never managed to figure out how to do, that I really wanted, was to have the camera bob up and down according to the elevation of the pixel beneath it, so as to give the impression of actually walking over the fingerprint landscape rather than just the camera hovering over it. There's no easy way to do this since the push and pop methods used to perform the camera movements alter the origin, which means there's no easy correlation to where the camera is in relation to the image pixels.

I'm pretty sure the way to do this is to just track the location of the camera in a couple of variables that get modified whenever camera transformations are performed, and then you just use an equation to figure out where the end camera position ends up on the coordinate grid, dividing by the size of the drawn pixels to compensate for the scale change: x = distance traveled * sin(angle changed) and y = distance traveled * cos(angle changed).

I haven't managed to get this to work right, yet. Maybe I'm compensating for something wrong somewhere. Or maybe there's soemthing wrong with my original camera transformations, which is why it doesn't correlate. I'm convinced there's still something wrong with the camera rotation. It doesn't seem like the pivot is always quite where it's supposed to be, which is directly under the camera location.

It would also be useful to know the camera location in relation to the image array in terms of improving performance. I'd be able to just draw the pixels directly in front of the camera, instead of always rendering the whole landscape all at once, even if you don't see most of it.

Mapping Project Applets:

the trigonometric version - high resolution

the box function version

the beginShape version - low resolution, better performance

Wearable Project Process

In retrospect, I kind of wish I'd perused my first vague musings about his project, which was to default to my interest in interactive projections. I actually thought if I made people wear LED's as easy indicators of their positions this would solve most of the implementation issues that impeded the project I tried developing for artbash, where different hat-things would be projected on peoples heads. I decided against this mostly because 1) I thought the actual technology utilized here wasn't wearable enough, 2) I thought I wanted to do something similar to this for my senior project, and 3) I kind of considered the use of LED's to be cheating.

My first more serious idea for this project was to do something having to do with reusability/disposability, ideally something that would reverse the normal relationship where a person wears and wears out and replaces clothing. I wasn't sure how this would actually work, practically, since making something that would alter the human body that wears it without changing itself is a pretty tall order. The most pure implementation of the idea would have been clothing that actually kills its wearer, before moving on to a new one, which wouldn't be really practical for obvious reasons.

I was thinking maybe something wearable that would leave some sort of stamped or stenciled design on a person's skin, and over time the design would get more and more overlapped over itself and messy and unreadable, thereby 'using up' the human canvas it was marking upon. The only semi-practical implementation of this I could think of is maybe some sort of large bracelet thing with an inked design on the inside, and when you spun it around your wrist hoola-hoop style it would leave behind markings. The hurdle I couldn't really overcome was how to keep the design always inked, especially since I wanted contrast between the wearer being disposable and the wearable being reusable. Having the user re-ink the clothing themselves seemed like it would undermine the agency of the clothing itself and the reverse power relationship I wanted to build.

My next idea was to make something where both the wearer and the clothing would be worn out over an accelerated period of time. This seemed more doable since I could do something where the act of the clothing falling apart would stain the wearer. My initial thought was to use some sort of paper, whether that's tissue paper or paper towels or actual tissues, and construct a garment where the material would be soaked in some sort of pigment that would rub off and stain the skin.

I was concerned the project wasn't technological enough, though technically I guess you could consider ink and paper to be a type of technology. I thought about how I could enhance my potential garment to make it more hi-tech. LED's seemed random and superfluous. I needed something that would maybe work as a catalyst to the disintegration of the garment. The thing I finally stumbled upon was this little hand-held fan I had, which I thought I could use to speed up the entropy of my project, either by directing the wind it produced at some particularly delicate section of tissue, or by actually attaching something to the wings of the fan, where it would spin around and gradually break off or knock other things off. Tassels seemed like a good idea all around - they could catch the wind, tear off, snag on other things, fly around and stain stuff, etc. I could maybe cut my material into strips and weave them directly into the structure of it, which would have the added bonus of emphasizing the garment as a textile.

The problem with the fan, of course, was that it was pretty heavy itself and would need to be attached to some non-disintegratable surface. I didn't consider this a huge obstacle, since I could use the same thing as a sort of skeleton for the rest of my garment, so it would disintegrate in place and hopefully not just fall off me - I even had this blue belt thing that I'd gotten for free in mind. A bigger problem was that the influence of the fan would need to be pretty localized, and I couldn't really think of a way around that, and I couldn't really reconcile with the sort of lopsided aesthetic that would mandate.

Worse, my preliminary tests re: staining, conducted with food coloring, didn't go so well. I figured food coloring was a strong enough pigment while being non-toxic and probably wouldn't mess anything up too badly if I got it on things that weren't just me. When it was wet it transferred its color immediately and pretty much all at once, which wasn't what I wanted, and when it was dry it didn't transfer over very well at all, which was surprising, given my experience with the stuff. I was pretty unsatisfied.

I considered other materials, including something organic (which had implications I didn't really want to pursue) and the cotton candy idea Katerie came up with. Cotton candy was good in that it would probably stain as it melted, and in that it probably would melt pretty easily, considering the humidity. The problem would be with getting it to maintain even momentary structural integrity. Anything bigger than a bracelet would be pretty hard to manage, and I thought I would need something bigger to get past the impact of those novelty candy-bracelets. The recipe Katerie emailed me, while definitely intriguing, also seemed pretty finicky, and I was not at all confident in my ability to implement it and get any sort of usable result. If I'd had access to commercially produced cotton candy I probably would have considered it more seriously, but as it was the ginger-bread house associations of an edible garment would have probably clouded what I was trying to communicate anyway.

I decided I needed a new idea. After some brainstorming I decided to concentrate on the identity-altering property of clothing.

In practice, clothing is a large part of how we determine the identity of the people we come across. We expect certain people to be dressed in certain ways, and we make a lot of assumptions about them just based on presentation, including, a lot of times, value-judgments.

I wanted to make something that would use technology to instantaneously flip between two or more contradictory 'presentations' in order to emphasize their inherent unreliability. It would pretty much have to be something symbolic, since I wouldn't realistically instantaneously change a person's whole attire to get a different effect.

I thought about making a set of devil horns and a halo with LED's, with the user being able to switch between them, so one is dark while the other one glows. It occurred to me I could use the fan I was previously considering for my first idea in order to make a halo.

Upon further reflection, I decided against making the devil horns - it seemed a little too gimmicky, and there's not a lot of reason for anybody to want to present themselves as evil, and that's what it was supposed to be about. The halo itself would have an on/off state, which satisfied my desire for instantaneous transformation. The good thing about the fan-halo also would be that unlike, say, a glow-stick halo, is that in the off state it wouldn't be immediately obvious what it was in the on state.

The first problem that became immediately obvious when I actually tried to build the halo was that there would be no way to power the LED's from the same circuit as was powering the fan motor, since the one part would be spinning and the other wouldn't, which meant I'd need two separate switches, one to turn on the LED's and one to turn on the actual fan. I wasn't particularly pleased with this.

Luckily, I used my brother, who is just getting his masters in electrical/computer engineering, as a technical advisor, and he suggested I do a makeshift accelerometer type thing where the centrifugal force of the top, spinney part of the fan spinning around would cause two loops of wire to touch, thereby completing the surface and effectively acting as a switch that auto-detects whether the fan's motor is on.

(He also told me how big of a resistor to use, and let me borrow his soldering iron and this cool little tool that looks like a screwdriver with the end chopped off, with two tiny holes at the end where you stick wires, and it makes it really easy to wrap one end of the wire around the other for a really secure connection.)

Deconstructing the fan was really easy, though I was pretty worried at the time I was going to accidentally break something I'd need later. The top spinney part had an easily removable pair of fan blades, and came pre-prepared with a pair of notches where the blades used to be which I could use to feed my LED wires through, and a convenient hollow space inside where I could put the accelerometer, the resistor, and most of my connecting wire bits. Only the batteries needed to be stuck outside of it, and they conveniently sized to fit onto the spinney part's flat top.

I used white LED's on my first attempt at constructing the halo, making a prototype circuit where the accelerometer was omitted (so the circuit was always closed and the light was always on) and nothing was actually soldered yet, just securely wrapped together. The prototype halo was around a foot in diameter and had one LED at each end, connected in parallel to a single quarter-sized batter. The initial result was somewhat less than satisfactory. The LED's weren't all that bright, and with the circumference of the halo being so large it didn't make a very convincing illusion of a seamless circle. Adding a second battery in series on top of the one already taped down helped a little, but not that much.

When I cut a hole in the hat and stuck the fan into it, between the layers of fabric, to test out what it would look like, the LED wires would knock against the hat and get stuck a little whenever I moved my head. It probably didn't help that the two 3volt LED batteries weren't very well balanced on the spinney part, so they were slowing it down a little. It occurred to me it would help if the fan was spinning faster, so the disk of the halo, so to speak, would stay flatter. This might also help with the continuous circle illusion.

It turned out that the fan still contained the original batteries that it came with, and they were a little weirdly sized (the end bits stuck out more than they usually do), and I had to bend some stuff around to get my standard sized AA's to fit. The new batteries made the fan go a lot faster, and this did help a lot, but it was still too dim and still getting snagged on things, so that when it finally got a little too snagged and fell apart I decided I needed to start over with new LED's.

I didn't have any other ones that were a suitably angelic color, but I did have some marginally brighter reddish-orange and green ones, which would make yellow additively, which I thought might look cool. Halo 2.0 had two sets of 2 LED's connected in series, with the sets themselves connected in parallel to the batteries (which were connected in series).

The legs of the LED's were trimmed and securely wrapped, folded over, soldered, slathered in hot glue and covered in electrical tape while still hot for an aerodynamic effect. I made the wires a lot shorter this time around, too, since I figured any glowing, vaguely yellow circle hovering over a person's head was probably going to read like a halo, even if it isn't that big. I re-taped the batteries to the top of the spinney part with the electrical tape under tension, so they wouldn't wiggle around and become unbalanced like they did last time.

Getting the accelerometer working took a lot of fiddling. The inner end of the wire had to be precarious enough so that it would get pushed into the outer wire by centrifugal force and springy enough that it wouldn't touch it when the fan was off. I ended up rolling a loop of uninsulated wire at the end of the inner wire and sticking a drop of hot glue on the back end of it, for added mass (and therefore added precariousness). I think the problem I had for a long time was that the inner wire was being pushed outwards by the centrifugal force - but so was the outer wire, so they never connected securely. I ended up hot gluing everything inside the hollow spinney fan part in place, so it wouldn't move around and mess up the balance of the accelerometer connection.

An unintended but pretty interesting side-effect of the accelerometer was that when the fan was being turned on or turned off there would be a moment where the connection between the wires wouldn't be all that secure, and the LED's would blink for a little while while the fan sped up, causing an interesting pixilated effect on the halo, especially with the sort of three-dimensionality it had as a result of the multiple LED's. I thought this really worked to emphasize the digital nature of the halo, which was important to my concept in that the halo itself was supposed to be a very digital, technological solution to a problem of perceived morality.

I was a little concerned the hat's intent as a representation of the limitations technology has in its potential to solve humanity's problems would be lost under the gimmicky factor of a halo-hat. I thought I could make some sort of fake website where the hat would be advertised with the stated purpose of a device which improves a person's moral standing, to contextualize the work a little.

The addition of sound was also supposed to help emphasize the hat as something that's supposed to make you seem more genuinely angelic. The guy at Radio Shack actually demonstrated the recording apparatus for me in the store, and it seemed to work well enough. I don't know, maybe I accidentally damaged it in some way while sewing it into the hat, because it didn't record my angelic bells very well.

I think I might have had more trouble with the sewing on the hat than with the soldering. I tried to hem the hole around where the fan would stick out, to keep it from fraying and getting in the way of the halo, and at one point the seams of the hat started to fall apart a little, and I had to sew those back together too. I mostly tried to stick things in between the layers of the hat and do as little sewing as possible. I think I eventually decided against following through on making the hat into an optional grocery-store sock-mask disguise in fear that if I started cutting into it it would fall apart altogether.

I eventually decided against a website as being a little too far removed from the actual hat. Instead I wrote up an advertisement, formatted in black and white somewhat like a traditional artist statement, and stuck it and the hat on a podium, in order to emphasize the hat's nature as both a pseudo-commercial prototype and an art object. I'm not sure how well this came across in the critique.

The text of my advertisement:

Improve your moral character today with

The Saint–O–Matic

Do people find you untrustworthy? Unreliable? Do the snags in your web of lies interfere with your credibility at work or at home? Having trouble regaining a sense of respectability after that prison sentence?

Look no further! The scientists at instaTech corporation have found the answer to your problems!

People have been relying on apparel to signify their moral values for millennia – now instaTech has taken propriety to the next level with a unique technological approach that cuts straight to the heart of the matter. The Saint–O–Matic cranial-apparel system is 100% guaranteed to instantly improve your respectability: simply don the unit over your head and activate instaTech’s patented halo-technology - anyone gazing upon you now is sure to be impressed by a visible manifestation of your moral purity!

Not saintly enough? For an extra boost, simply depress the discreetly-placed aural-enhancement button to release a near-subliminal bolt of heavenly chimes from the unit’s on-board speakers – straight into your friends’ and coworkers’ subconscious minds, forever altering their associations with your presence.

The Saint–O–Matic: become a better person – instantly!

deCerteau Post

Understand the middle two paragraphs on p. 93 starting with “The ordinary practicioners…” How is a city or any other landscape a text? Get an understanding of what might be meant by the term, operations, and how it relates to the aspect of the city that is not represented as “geometric” or “geographical.”

There is the city and the concept of the city. Please define each and describe their relationship to each other.

I think the most obvious answer is when you find elements of a city or landscape that resemble letterforms for words. I think aerial views lend themselves to this kind of thing. It's easy to see some shapes forming with so many objects clustered together. Forms like this are certainly not limited to aerial views;

A city or landscape can also be defined by text in terms of language. For example, a city in Spain is perhaps defined by all of the Spanish text advocating bull-fighting, a city in Japan is perhaps defined by all of the hand-painted text written on wood planks advertising fish at a local fish stand, an American city is perhaps defined by its indefinite texts as a merging of cultures and languages can be found.

As for the second part of the question, to me, the city includes the physical location, the people, creatures, buildings, politics, ideals, customs, etc. The concept of the city is more of a "what does all of this stuff defined as a city do to things within it (as well as outside of it)," basically, what is the city for and how does it affect things? The two are very related to each other in that they talk back and forth. A location (part of the city) is certainly going to affect the people, the buildings, the customs, and so on (concept of the city). An industrial city is definitely going to do different things to its surroundings than a rural area. An island city is going to focus on a navy rather than a land-based defense.




Why does deCerteau claim that the concept city is dying? Make sure you have a clear ideas what is meant by concept city before you try and answer this question.

It seems to me that he blames the concept dying because of those who have become aware of the concept and are thus able to control and contort it. The city is controlled by few rather than by all, and therefore, the effect that is created by everyone moving together and averaging out, the effect is being swayed heavily under the influence of the powerful (usually rich, corrupt, of out touch with the everyman).


How can focusing on the negative privilege a discourse?

Both sides should always be reviewed and understood to make an informed decision. By studying the positives, one knows what worked, how well it worked, and if it should be done again; with the negatives, one knows what didn't work, how to improve, and what not to do.


How does deCerteau relate the decisions we make when walking to speech acts? You may first have to understand what constitutes a speech act. See bottom of p97.

These sentences seem to describe it very well: "…it is true that a spatial order organizes an ensemble of possibilities…and interdictions (e.g., by a wall that prevents one from going further), then the walker actualizes some of these possibilities. In that way, he makes them exist as well as emerge." Through the act of realizing something, we think about something; while thinking, we come up with uncountable circumstances that become real, become thought-speech, through our imagination. Merely by suggesting they exist, they come into existence.


How does deCerteau define myth in the context of this chapter?

It seems to be related to tradition and how things work, or at least, how they've worked in the past.


Understand the notion of “local authority”. Examples of local authority?

This can mean many different things. First you must define local. Is local limited to the city, the household, the school, the workplace, the individual moral, the country, the universe, etc.? Going in order, examples of such could be: police force, parents, teachers, bosses, moral codes, national laws, the laws of physics, etc.


What purpose/s could be served by eradicating stories and legends that inhabit places? What are the consequences of this? How is this related to walking?

Instead of looking at things the same way they've been looked at for ages and ages, a completely new view could be found due to no previous notions or bias or clues. These views could be good or bad, right or wrong, some better than others. I think a good example to relate this to walking can come from my time in Tokyo. It would always amaze and surprise me by how many people took the escalator at different places rather than the stairs (particularly the train stations). While the stairs are much faster, more people take the escalator, causing it to become crowded and even slower. Most of these people are business men and women who are constantly in a hurry to get places, yet they continue to take the slower path. I think at least some of the reasoning behind this is because it's engraved in many of their minds. In such a technological society, I imagine it would become easy to fall prey to letting machines do work for you.


Think of place that you where you have spent a lot of time. “Walk” that place. Pretend that you are describing the landscape to a person you know quite well. As you “walk” and talk differentiate between the parts of the conversation that describe what is currently there now and the parts of the conversation that detail what is not longer present.

*Please refer to my post about my old house.


Is it possible to see memory as negative space?

I think it's more accurate to see memory as positive space. Just because it's negative space in the physical world does not at all mean that it's negative space in the mental world of my mind. For example, every time I go past where my old house used to be, I don't see a metaphorical hole in the property, what I see is my old house simply overlaying the one that is there now, not because it was bigger (it wasn't) but because I remember it so vividly.


In your own words, what does the practice of space mean?

Perhaps it has to do with the continual return to and movement through an area in space, whether it be a physical space that , say, you travel through everyday to get to school or work, or be it a mental space that you travel to to relax and get away. I think the repetition and acknowledgment of traversing this space is the "practice of space."

Wearable project pictures

Here are several pictures of me wearing the wearable. The first one is before I added the LED right after I made the first prototype with the weak magnets.


The other two are from the final crit of the complete product.

THE BODY IS OBSELETE: STELARC

Stelarc, formerly Stelios Arcadiou is an Austrailian artist whose work primarily deals with combining technology with the human body. His work has a tone that seems to inquire about where we will be able to take the human body in the future, with technology merging with flesh, evolving us into an entirely new race, of our own creation.

His earliest work, in the 90s, involved 3D models or "bodies" being manipulated by internet traffic. He later worked with prosthetics on his own body that controlled these internet bodies.

One of his more interesting later pieces, Exoskeleton, was exactly that, a six-legged walking machine with an additional left arm. Aesthetically, the exoskeleton looks like something out of a mad scientist's laboratory. Stelarc seems drawn to the anti-aesthetic and almost cyberpunk look of blending technology with human physiology. He has continued to explore the form of the exoskeleton with later pieces like Hexapod and Muscle Machine.

In a more recent piece, Blender, Stelarc collaborated with Nina Sellars to create a machine which blends surgically removed fat and blood from both of their bodies, in another machine that could be described as having the super-science aesthetic.

One of his most recent and popular projects was the recent execution of a long-planned Prosthetic Ear. Originally imagined as placed on his own cheek, it was finally placed in the inside of his forearm. Sculpted of Medpor, it used skin expanded by subcutaneous injection of saline solution. It had a microphone which wirelessly transmitted audio signals, but it had to be removed due to infection. He plans to perfect the microphone and re-insert it, so that it can broadcast audio to other listening devices over the internet.

Stelarc's fascination with blending flesh and technology forecasts in a way the actual advances that could take place in the years and centuries to come. Ideas put forth in popular culture seem to be possible influences, such as cyber-punk culture, coined by William Gibson, and the popular Japanese comic and animated series Ghost in the Shell, which explores the effects of partially- and fully-prosthetic bodies. In this way, his work holds a great deal of relevance today as well as in the future, as this technology becomes commercially available.

Wearable Project: Picture Proof

Attention Whore

These are videos of the dress working with a few songs (Including a Christmas Carol by Lady Gaga). I am still trying to convince a friend of mine to wear it so that I have someone wearing it for the videos. In the first clip I show the dress in multiple light settings as well as with movement. For the second video I just let the LED display work without interfering with it. I have titled the piece "Attention Whore," as I feel it sums up best the idea that I am working with for this project.

As a side note, in the first video around 35 seconds in you can hear a loud pop. That's my head breaking a light bulb (we have a hanging lamp). Luckily I didn't hurt myself, but that was one of the lights I was going to be using for the shot :/

Wearable technology: Artist Presentation

Final Project Process

*NOTE: I managed to process all my videos in another window, then just copied them over to this one, so please ignore the other draft posts of mine.



I've done two "wearable technology" pieces before in one of my other classes. The first of those pieces was about creating music with only the body. At first, I had planned on using an Arduino with flex sensors and a piezo speakers. Unfortunately, I never got it to work; all I was able to manage was to program a song into the Arduino to be played by the speakers; I could never get the flex sensors to work out. What I ended up doing for that piece was to show what I had managed to do with the Arduino, then I built a flash app that simulated a keyboard (music keyboard, not a computer keyboard). Users were able to control which note was played by holding a Wii remote and moving it from side to side (simulating lower and higher notes on a keyboard/piano).

The second piece was about being able to control something with no physical contact with the object being controlled --the user could directly influence an object by doing nothing more than thinking it (obviously inspired from the idea of telekinesis). In order to do this, I created a wearable glove that had infrared (IR) lights coming out of the fingers; the glove also held batteries to power the lights. A Wii remote was used in conjunction with these lights to be able to tell where the glove was in relation to the stationary Wii remote. The object being controlled ended up being a remote controlled car. The final result of the project was that the user wore this glove and moved his or her hand parallel to the ground, with palm facing downward; the car followed the motion of the users' hands. For example, if the user moved his/her hand forward, the car would move forward, if the hand was moved back and the the right, the car would go in reverse while turning right, and so on and so forth.

I later redid the keyboard piece utilizing the glove that I had made for the car project. The setup was the same --users held their hands palm down, moving them parallel to the ground. This time, however, sound was emitted from my computer (hidden) as the hand was moved. Left and right movement allowed playing of higher and lower notes while forward and backwards movement allowed for switching between flats/sharps and naturals.

These projects were the start of a series of projects that I have wanted to do for the past few years. With that in mind, I knew that I wanted to continue this series with this project. Eventually, I want to have a full-body system that uses this kind of technology and creates a kind of augmented reality for users. So the fist step was the arms and hands, and I figured the next step should be the head.

So when the time for this project came, I knew the basics of what I wanted to do: make some sort of head-mounted device that had something to do with augmented reality. I also knew that I wanted to be able to track where the users' heads were moving, so I started working on a way to track the movements of users' heads. I had ideas on how to do this in the past, so I started with those. Basically, my first idea was to create a first-person shooter (FPS) type of control. This would interface with a Wii remote attached to a person's head and a sensor bar in front of the user, facing him or her. Before I go any further, I feel I should explain how the Wii remote works as this directed much of how I went about figuring things out.

The Wii remote (wiimote from now on) can sense a variety of different motions. It can sense roll, pitch, and yaw; acceleration in the X, Y, and Z directions, and it can detect where it is in 3D space with the use of the sensor bar (roll, pitch, yaw, and acceleration are all done without the need of the sensor bar).






























Motion detected by the Wii remote: roll, pitch, yaw, and directional acceleration


The sensor bar is simply a plastic bar that houses a series of IR lights. The IR sensors in the wiimote pick up the incoming light source, and triangulates its position in an X, Y, Z space. This space is created by a 3D grid using values from -1 to 1. Negative one to one on the X-axis being left to right and up to down on the Y-axis. I have yet to figure out how to manipulate or get readings from the Z (back and forth) axis; technically, I know that the angle between the two light sources (left 3 IR lights and right 3 IR lights) will change depending on the wiimote's distance from them, but programmatically, I have yet to figure it out. Also notable is that once the wiimote is pointing to far left, right, up, or down (away from the center of the sensor bar), the IR signal is lost. The extreme values (-1 and 1) are the points just before that signal is lost. (These axes are different than the acceleration axes seen in the picture above)

With this in mind, I wanted to create an FPS-type of control. The user would wear something on his or her head that would hold the wiimote; the wiimote would be facing forward towards the sensor bar. By doing this, I could, at any point in time, know exactly where the user was looking because I could see where the wiimote was pointing on the 2D XY grid. This had limitations that I did not fully realize at the time (more on that later).















Basic drawing of setup

By this time I was pretty sure that I wanted to present this project in the crit room, and that I wanted to use the model of the room that's available to the DMA students. By doing this, I could create a virtual space of the space that the user was physically in. I intended to display the portion of the 3D space in direct correspondence to where the user was looking in the physical space. For example, if the user was looking at the front of the room (where the project screen is), that part of the 3D model would be displayed; if the user looked at the computer on the right side of the room, that portion of the 3D model would be displayed.

Now what I did realize was that this would be a very limited space of movement. The user could only move within the 2D grid's space; if the user looked past the range of the IR lights, the signal would be lost, and neither the wiimote nor I would not know where the user was looking. This is where the FPS controls came in.















Possible range of movement/detection looking at a projection (with imaginary 2D grid)

In FPSs there is a term called the "dead zone." What this is is the area on the screen the user can move the mouse (as FPSs are traditionally computer games) before the camera starts to rotate. If the cursor is within the bounding box, the camera does not move and (what is usually) the reticule of a gun moves around the screen. However, once the cursor goes outside of the box that dictates the dead zone, the camera will start to rotate, allowing the player and character to turn left, right, up, and down. This is where I started. I created a box invisible to the user) that would become the area of the dead zone. I believe the box started as a .5 x .5 box, meaning that the box went from -.5 to .5 on the X-axis and -.5 to .5 on the Y-axis. If the wiimote was pointing anywhere in that box, the camera would not move, but once it was pointing somewhere outside the box, the camera would rotate.

The original way I programmed it was that the camera would look where the wiimote was pointing in the 2D grid (this location on the grid will be referred to the "pointer" from now on). This had very serious limitations, however. The user could only view a VERY small portion of the room (aka, the camera would not rotate very far). What I could do was to multiply the location of the pointer by some number; this would allow the camera to rotate farther within the same limited space the head could move without losing the IR signal. This didn't seem at all ideal however, so I moved to another idea.

The next idea was originally programmed in a way that was not the way I meant it to work. Basically what I realized was that, outside of the box, there were only eight directions that the camera would rotate:
left and up (if the wiimote was pointing anywhere less than x = -.5 and greater than y = .5 --this xy coordinate of where the wiimote is pointing on the grid will be referred to the pointer from now on),
up (anywhere between x = -.5 and x = .5 and greater than y = .5),
right and up (anywhere greater than x = .5 and greater than y = .5),
left (less than x = -.5, and between y = .5 and y = -.5),
right (greater than x = .5, and between y = .5 and y = -.5),
left and down (less than, x = -.5, and less than y = -.5),
down (between x = -.5 and x = .5, and less than y = -.5), and
right and down (greater than x = .5, and less than y = -.5).

This created very jagged movement when the pointer moved from one area to the next; the camera would, for example, be rotating up, then would all of a sudden start moving right and up --there was no fluidity between these areas, so that is what I worked on next.

Basically what I did to fix this problem was to combine the first two ideas --I would use the dead zone as well as coordinate the rotation with the direct pointer location. Before, I was telling the camera, "Hey, if the pointer is less than -.5 and greater than .5, rotate one degree up and one degree left every second that the pointer is there." Instead what I did was to take the direction that the camera was supposed to rotate (defined by the eight different areas outside the dead zone) and multiply it by the decimal location of the pointer. I was basically using the decimal location of the pointer as a percent of how much to rotate. So where before if the pointer were at, say, (-.75, .63), the camera would rotate up and right on degree every second. Now, however, it would rotate right 75% of one degree every second and up 63% of one degree every second. As you can imagine, 75% and 63% of one degree every second was not very far; the camera was rotating so slow that you could hardly tell is was rotating at all. Simple fix. All I did was introduce a "sensitivity" value. This value was multiplied to the previous values. So taking the previous example point, (-.75, .63), the equation would look like this:

rotate right by this much: (one degree * 75%) * sensitivity
rotate up by this much: (one degree * 63%) * sensitivity

I started the sensitivity at 10, so with that number, the camera would rotate 7.5 degrees right and 6.3 degrees up every second. This was much better (the camera could actually be seen moving!). I then made it so both the dead zone and the sensitivity could be changed on the fly by holding certain buttons on the wiimote. This would allow me to play around until I found the most "realistic" settings. It could also potentially allow users to customize the controls for themselves (if someone wanted to move slower than others, if someone wanted the camera to move with smaller versus bigger movements of their head, etc.). However, after playing with this for a while, I realized that this wasn't really all that realistic. While this allowed the user to see the entirety of the virtual room, the person's head would only be moving a very small amount in real life. This is not what I wanted. I wanted the virtual camera to be looking wherever the person was looking, whether it be in front, behind, above, below, etc. of him/her; I wanted a direct relationship between the two so as to create a sense that the user was not looking at a screen, but was in fact simply looking at real life.



The first thing I had thought about before I even started to program was which orientation the wiimote would face and which would be the most effective for what I wanted. Did I need it to face forward? Backwards? Up? Down? Left or right? I had decided forward as I could use the pointer location to control 2 out of the 3 directions of rotation with roll taking care of the third. The X-position would control the camera's left and right rotation, the Y-position would control the up and down rotation, and the roll would control the rolling rotation (imagine tilting your head to your left or right shoulder). Plus, this would allow for easy placement of the sensor bar and would automatically force to user to be looking forward.

Because of these limitations, I had to rethink my method of orientation. What would allow me the same free of rotation? With any orientation running parallel to the ground (sideways, backwards, forwards), I would run into the same limitations, so that only left an up and down orientation. Downward would not the very possible; if the user is wearing the wiimotes on his/her head and they were pointing down, then the sensor bar would have to be below the user facing up. The user might step on/knock over the sensor bar, the user's body would block the IR light, etc. --there were too many obstacles. Seemed like an upward orientation was the way to go. How exactly I would mount an upward-facing wiimote to a person's head would come later --this is how it needed to be, so I needed to make it work first.

The most important motion (to me at least) was the left and right rotation which would simulate a person looking left and right. This motion would allow the user to see the majority of the room while looking up and down came second, followed by the side to side (from shoulder to shoulder) motion which I wasn't even sure I needed to include. So then how would I accomplish left and right rotation? Well, if I moved an upward-facing wiimote in the same way a head would move, the measurement I was looking for was roll. However, I quickly remembered that roll, pitch, and yaw are measured via gravity, therefore, roll cannot be detected when the wiimote is facing up (Imagine a marble inside of a larger plastic ball. Roll, pitch, and yaw are measured by the location and movement of the marble within the ball. If the wiimote is facing up, the marble is at the bottom of the ball. If the ball is rotated left and right, the marble inside will not move). So if that didn't work, how would I detect this motion? Unfortunately, the IR detection wouldn't help with this as it only detects the point in a 2D grid while the roll, pitch, and yaw take care of the wiimote's orientation detection.

While I didn't run into this problem in my other projects, I did ponder how this is tracked --how does the wiimote know if it's upside down? The roll, pitch, and yaw can only track 180 degree of rotation rather than a full 360 degrees, yet games using the wiimote, and in fact, Nintendo themselves are able to track whether the wiimote is upside down as is seen in the Wii's very own home menu (seen as soon as you turn the Wii system on). A person navigates this menu with the wiimote. The pointer seen onscreen is a simple cartoon hand with a pointing finer. The hand follows where the person is pointing as well as rotating in respect to how the person rotates the wiimote. So, for example, the person is holding the wiimote pointing forward at the screen with the buttons facing up (keep in mind the sensor bar is directly above or below the TV screen), the hand points up. If the person rotates the wiimote so that the buttons are facing down, the hand on screen will point down. So there is obviously a way to determine this (which is what I needed to do), but I have yet to figure it out.

So how then can I measure this? Well, why did I have to use only one wiimote, couldn't I use two? Of course! This would be simple! The head moves along a circular path, so why not set up two wiimotes on the circumference of this circle? One wiimote would be, say, on the left side of the head and the other would be on the right side of the head. As the head turned left and right, the wiimotes would move in a circle around the center of the head. Knowing that I have a circle, the center of that circle, and two points a diameter apart on that circle, I could find the angle that the head was turned and rotate the camera to that same angle! Very unfortunately, it was not at all this simple.

Throughout all of this, I had a square being displayed onscreen that showed where the wiimote was pointing; I used this visual cue for reference to make sure things were pointing where I thought they were pointing. Now with two wiimotes, I had two square. I sat the two wiimotes on the bottoms, facing up and held the sensor bar a few feet above them. As one would expect, the two squares were displayed, so both wiimotes were being detected: good news. However, as I rotated the sensor bar (the same thing as moving the wiimotes/head), I noticed that this circle I had expected was not happening. Instead of the two points moving along the circumference of one circle, each point was moving in its own separate circle. This did not make sense, and I'm still pretty uncertain as to why this happens. Here's what I had:

I had one source of light --the sensor bar --and two points looking at the light source. So imagine a cone, with the top point of the cone being the light source (sensor bar) and the two wiimotes below it being any two points. If these two points rotate around the center of the cone while staying a static distance from each other, the paths of the points will create a circle. Because I expected this circle, I would, for example, have one wiimote at point (1,0) --the wiimote on the right --and one at (-1,0) --the wiimote on the left. If I rotate the wiimotes 180 degrees around the center of the circle (0,0), then the right wiimote would then be at (-1,0) and the left at (1,0). Right? Wrong. Like I stated before, instead of having this one circle, I had two independent ones. So what was actually happening was that the right wiimote started at (1,0) and the left at (-1,0). If I rotated them 180 around the center of the circle, the right wiimote would be at (0,0) and the left would be at (0,0). So basically, I had two cirlces on either side of the grid that would converge at the origin. Well okay, just find the center of these two independent circles and programmatically move then to the origin. This wasn't that easy either. Say the wiimotes are at (1,0) and (-1,0). This means that each wiimote is at the very edge of the IR signal. Now if I move the wiimotes closer to the sensor bar, they are outside the range and the signals are lost, but if I move the wiimotes farther away from the sensor bar, the points get closer and closer to the origin. Imagine that cone I mentioned --the sensor bar is the top point and the wiimotes are two points on the circumference of a circle created within that cone. Instead of ending the cone at that circle, keep extending it. The edges of this cone is the range of the IR lights. The wiimotes are to remain at the edge of this range. As the wiimotes get closer to the top point, they become closer together (because the edges of the cone converge onto one point), and as they get farther from the top point, they get farther away from each other. However, the wiimotes aren't going to be changing distance between each other ever; they will remain on the left and right sides of the head. The problem is the varying distance of the wiimotes from the sensor bar. This distance will vary depending on how tall a person is; a shorter person will have the wiimotes farther away from the sensor bar while a taller person will have the wiimotes closer to the sensor bar. Keeping this in mind, move the wiimotes closer to the sensor bar. If they started at the edges of the cone, and get closer to the top point without changing distance from each other, then they are now beyond the edges of the cone (past the IR range). If the wiimotes are moved farther from the top point without changing distance from each other, then they get farther from the edges of the cone (-1 and 1), resulting in the points on the 2D grid getting closer to the origin.





So, because these points change, this means the the midpoints of the two circles will change. This in addition to the distance the wiimotes are from each other (this would vary in testing, because I didn't know how far the wiimotes would be from each other ultimately, and because I was certain that even once I had constructed a mount for the wiimotes, there would be no guarantee that the would not move --even a tiny bit of movement would offset everything) kept both the midpoints and the diameters of these two circles constantly varying. Because of this, I could not take these measurements and simply move them to the origin.

After some thinking I realized that I actually did have something that I could keep track of. The individual points of the wiimotes changed, the diameters and midpoints of the two circles changed, the distance from the wiimotes and sensor bar changed, and the distance between the two wiimotes themselves would change. All of these things would change both from test to test AND during presentation after everything was physically set in place. The one thing I did have was the midpoint between the two wiimotes themselves. As long as both wiimotes were inside of the IR range, I could dynamically calculate and find a single point that was directly in between the left and right wiimotes. This point would become the origin of my circle.

In a perfect situation, the user would ONLY move his or her head left and right, keeping the exact center of his or her head in the same spot at all times. If this were the case, I could simply use the center of the screen as my circle's origin. This would be beneficial because the origin of the 2D grid created from the sensor bar (the center of the screen) would be the same as the origin of my circle. However, this would never happen as people's bodies move, the people would NOT only be looking left and right but most likely up and down and side to side as well. So what I would end up with was the 2D grid created by the sensor bar (this never moves --the top of the screen is always y = 1, the bottom y = -1, the right side of the screen is x = 1, and the left x = -1) as well as a fabricated grid that my circle was on that I needed to keep track of (this would be constantly moving as the person's head moved). To reiterate, I have two grids: a static one that tells me the location of the wiimotes, and a dynamic one that tells me the location of my circle I need to keep track of.

Now I have a midpoint of the two wiimotes. Because the midpoint moves WITH the wiimote pointers, I now have a point that I can create a circle around. However, I still have not gotten rid of the fact that the two pointers are moving in their own circles. So now I have created an additional circle that I will use. It is the same size as the other two circles. The difference is that this circle is in the origin of the moving grid.
I neglected to mention before that I found the midpoints of the two circles to be (-.5, 0) and (.5,0) if the circles went from (-1,0) to (0,0) [left] and from (1,0) to (0,0) [right]. I didn't mention this before because these points are always changing and are only so in perfect situations, but in figuring out the following, I was using these "perfect" situations.
So this third, middle circle's center is at (0,0), its diameter is 1, so it goes from (-.5,0) to (.5,0) [left to right] and from (0,1) to (-1,0) [top to bottom]. The left and right extremities are also the midpoints of the outer two circles.

So here's what I needed to do. I need to find the angle between the pointer on either side, let's say the right side, and that side's circle's center. I then needed to take this angle and tell the camera to rotate by that much. Again, the problem was that I could never, at any given point, find the centers of the outer circles; this is where that third, middle circle comes in. Aside from the location of the two wiimote points, I have their midpoint which was the center of the middle circle. So what I could measure was the angle from the center of this middle circle to the point of either wiimote (again, let's use the right wiimote as example). So say the user turns his or her head 45 degrees to the left. If the right side started at (1,0) and the diameter of the circle is 1, then after rotating 45 degrees left, the right wiimote will be at (.83, .33). However, the computer cannot find this angle as I still don't have the center of the right circle. So in order to tell the computer that the person has rotated 45 degrees left, I have to somehow get that number from the angle between the middle circle's center and the right pointer (.83, .33). So what do I know? I have a point (0,0) and a point (.83, .33). So in order to find the angle, I draw a line the the origin to the pointer, from the pointer straight down to the x-axis, and from there, back to the origin; this gives me a right triangle. I know that the bottom of the triangle is .83 units and the height (from x-axis to pointer point) is .33. From here I do:

tangent(angle that I'm looking for) = .33/.83 [tangent = opposite/adjacent]

I still need the angle so I do:

angle = arctan(.33/.83)

angle = 22.5 degrees [.33 and .83 are a little off, but the angle in this problem is in fact 22.5]

Okay, so now I know that the angle between the middle circles center (the moving origin) and the right pointer is 22.5 degrees. I now need to convert this 22.5 degrees to 45 degrees. I bet you can easily see how to do this, but I didn't see it as I was working with varying numbers and was working in radians converted to decimals (as this is what the computer outputs when using trig functions). So in order to make the resulting angle the "correct angle" (take the angle between the origin and the pointer and convert it to the angle that the person's head actually moved), I do:

sin(angle) = y1/1

and

cos(angle) = x1/1

x1 and y1 are the two points on the middle circle that are at 45 degrees, and 1 is an arbitrary hypotenuse of the right angle created (doesn't matter what it is as long as it's consistent). Following:

y1 = sin(angle)*1

y1 = sin(22.5)*1

y1 = .383 [truncated]

and

x1 = cos(angle)*1

x1 = cos(22.5)*1

x1 = .924 [truncated]

"Wait a minute… This just gives me the angle of 22.5 degrees in the middle circle… x1 and y1 are the points in the middle circle that are at 22.5 degrees, not 45 degrees!" I thought. I then realized that this was the formula I would use if i HAD the outer circle centers: I would take the angle of rotation from an outer circle (again, an angle I can't find), then use that to set the same angle on the middle circle. Okay, so this didn't help… But wait! couldn't I just take the first angle and multiply it by two? Twenty-two and a half times two is forty-five! Okay, okay, so I take the angle from the middle circle's center to the right pointer, then just multiply it by two:

tangent(angle) = .33/.83

angle = arctan(.33/.83)

angle = 22.5 degrees

22.5*2 = angle that the person has actually rotated

45 degrees = angle that the person has actually rotated

This works until the angle of rotation starts getting close to 180 degrees. Here is another thing I have not mentioned: the two outer circles often overlapped, so instead of simply meeting and touching at (0,0), they would go past each other --the left side of the right circle would be, say, (-.1, 0), and the right side of the left circle would be (.1,0) rather than both of those points being (0,0). Ideally, there would be no problem and the angle between the middle circle's center and the right pointer (from now on referred to as rightTheta) would go from 0 to 90, then switch immediately to -90 and go to zero (once 180 degrees had been passed). However, because of this overlapping, things got a little screwy. The rightTheta was only supposed to go from -90 to 90, nothing below, nothing above. But because of the overlap, rightTheta has the potential to go past these values. So, for example, let's take the values from before (left side of right circle is (-.1,0)). If the person has rotated just under 180 degrees, then rightTheta is greater than 90 (because the point on the right circle is to the left of the origin). Unfortunately, I could not (and still have not) figured out a solution for this; this is why you may have noticed some weird movement if you turned your head more than 180 degrees. Now once past 180 degrees, the process was the same as before, simply making the values negative.























Notes and equations

Great! All the math works, and everything's perfect! Now it should all work. Wrong. Computers do not use the same grid system as we do. Whereas we have (0,0) in the middle, (0,0) for computers starts at the top left side of the screen; x increases to the right and y increases downward (therefore, there are no negative values on the screen only positive). I know this as I have had to work around this and use this in multiple other projects. However, I did not even think about it while doing all my trig functions. Instead of taking angles from the middle circle's center like I had been doing on paper ((0,0) in my head), the computer was taking angles from the top left of the screen to the wiimote points. Because of this, the angles never went past 0 or 90, so everything was off.

After much thinking, I realized I could use slopes to find the angles rather than trig functions; this way I could measure from the desired origin (center of middle circle) rather than the computer's origin (top left of screen). So I would find the slope between the middle circle's center and the right pointer:

slope of 22.5 degrees = 1/2 = .5

and then

.5 * 90 = 45

Bingo. So I'd just take the slope and multiply it by 90. Much easier than the other method, plus it worked! However, I had to change the formula slightly for each quadrant:

Quadrant I (0-90 degrees): angle = slope*2

Quadrant II (90-180 degrees): angle = 90+[(slope*2)/4]

Quadrant III (180-270): angle = 180+[(slope*2)/4]*-1

Quadrant IV (270-360): angle = 270+(slope*2)

And that was it; I had the left and right rotation down (save for the messiness near 180 degrees). The rest was easy. The x-coordinate of the midpoint (midpoint of the two wiimotes) would control the shoulder to shoulder rotation (which I ended up not putting in) and the y-coordinate of the midpoint would control the up and down rotation. Of course these two rotations were still limited, but I figured that no one would be moving their head past their shoulders (shoulder to shoulder was still in range), and no one would look straight up or straight down. Even so, I'd like to figure out how to get past these limitations in the future as these situations, while unlikely, are possible.

Now that all of the math was done, I added in some finishing touches. I added some lighting, a way to turn the displayed debug stuff on and off, and the ability to float above the room to see a Google Maps image of the area surrounding the Fine Arts complex as well as the ability to float back down into the room.



It wasn't until a few days before the crit that I decided on using the glasses. Beforehand, I didn't know that Alan and Greg had bought them, but once I found out that they did, I decided to ask if I could use one of their pairs. Originally I was going to project this in front of the user, but this was never a very good solution to me as this would subtract from the reality of the piece; even though the user's head would be facing one direction, the user's eyes would still have to be facing the front of the room, looking at the projection instead of looking where the head was pointing.

So I was able to borrow Alan's glasses for a few days. The glasses came allowed for 3.5mm audio and video out as one output. I needed to get the stuff happening on my laptop to display on the glasses. I have a ton of cords and adapters for this sort of stuff, so I figured it wouldn't be too hard to get what I needed. Guess what: wrong again. Ultimately, I needed to get a DVI (from my laptop) to the 3.5mm on the glasses. I have 3.5mm to RCA cable that I've used lots of times before, so now I needed to get DVI to RCA. I have an RCA/S-video to VGA cable, however I've never gotten it to really work the way it's supposed to. So now I needed VGA to DVI. Easy: this came with my laptop. So I had DVI to VGA to RCA to 3.5mm. No dice; didn't work. I have an RCA/S-video splitter that I use for different media going to my TV. I tried different variations with that: didn't work. I tried using S-video cables and adapters: didn't work. I looked online for solutions: couldn't find any. I looked at electronic stores for a solution: couldn't find any and none of the employees could shed any advice on the situation either. Luckily, I found the solution with Jack. He let me borrow his DVI to RCA/S-video adapter --an adapter that I didn't even know existed. He informed me that he had used the adapter before to display computer monitors on TVs, which was essentially what I was trying to do. Surely this would work: DVI to RCA to 3.5mm. Nope, still nothing. After spending a few hours with Mike Christopher, trying a few things, I did finally manage to get something. If I held the 3.5mm pin slightly, but not all the way in the glasses input, I could see a very fuzzy, badly-aligned display of the computer screen.

Later that day, I was able to try Greg's glasses. Apparently, his came with an adapter that Alan's didn't; it was another RCA to 3.5mm adapter. The only difference between my adapters and Mike's adapters that I had tried was that this one worked perfectly. DVI to RCA to 3.5mm and everything worked. The only explanation I could come up with was that this RCA to 3.5mm adapter was very specific to the glasses and others (even though they're the same adapter) would not work with the glasses. So, thankfully, everything was working.

Now there is one last piece of this that randomly reliable. In order to use the wiimotes, I connect them to my laptop via bluetooth. In order to do this, I have to set up the two wiimotes with my laptop, turn them off, start the program, and then connect them again as the program searches for bluetooth devices. Here is the problem: both my laptop and the program itself are looking for bluetooth devices. So sometimes the wiimotes connect to the program, as desired, but other times they connect to the laptop. Sometimes it's one than the other, other times one connects to the program and the other connects to the laptop, and sometimes they don't connect to anything. It is seemingly completely random, and I am not one to hide the fact that I was very lucky that everything worked during crit. In trying to document the project, I have spent over 30 hours trying to get everything working. Nothing has changed since crit, and nothing changed before crit. Sometimes is works and sometimes it doesn't. Unfortunately, it's that simple.



Pictures: