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:
No comments:
Post a Comment