never use pins one and zero to connect most things to your Arduino

reserved they should stay for all things serial; else “Timeout Errors” will be your burial

There are plenty of pins to choose from. Fellow learners: don’t use TX or RX pins (usually 1 & 0) unless [...]]]> A poem in 60 seconds:

never use
pins one and zero
to connect most things
to your Arduino

reserved they should stay
for all things serial;
else “Timeout Errors”
will be your burial

There are plenty of pins to choose from. Fellow learners: don’t use TX or RX pins (usually 1 & 0) unless you really know what you’re doing. Since they’re used in the upload process, you’ll run the risk of having to disconnect your Arduino every time you want to change your sketch if those pins are connected to anything else.

Major steps ‘forward’ on my time machine simulator today. Seeing the beauty of classes to really keep your code clean & efficient. My main draw loop now looks like this:

void testApp::draw() {

ofTranslate(fullWindowWidth/2,fullWindowHeight/2); ofViewport(0, ofGetWindowHeight()/2, ofGetWindowWidth(), ofGetWindowHeight()/2); myMesh->updateMesh(smoothPZ, smoothDiffX, smoothDiffY, transZ); ofViewport(0, 0, ofGetWindowWidth(), [...]]]> Or, at least a few seconds into the past…

Major steps ‘forward’ on my time machine simulator today. Seeing the beauty of classes to really keep your code clean & efficient. My main draw loop now looks like this:

void testApp::draw() {

ofTranslate(fullWindowWidth/2,fullWindowHeight/2);
ofViewport(0, ofGetWindowHeight()/2, ofGetWindowWidth(), ofGetWindowHeight()/2);
myMesh->updateMesh(smoothPZ, smoothDiffX, smoothDiffY, transZ);
ofViewport(0, 0, ofGetWindowWidth(), ofGetWindowHeight()/2);
myMesh->updateMesh(smoothPZ, smoothDiffX+eyeDistance, smoothDiffY, transZ);

}


Everything else happens under the hood. Since I’m building a layered, installation-oriented, theatrical application, one can easily imagine expanding the graphics processing to incorporate playful 2D visuals layered in a “heads-up-display” style. Relying on a class that is external to my main draw loop allows me to clearly see and see the order in which I draw my graphics.

Once I figured out ofViewport (thanks, again, to Kyle McDonald) incorporating 3D has been surprisingly easy. Rotating right eye’s perspective 7.5 degrees from the perspective of the left eye did the trick. I was expecting more complex stereoscopic subtleties to pose significant problems; convergence and other 3D-specific parameters often provide significant challenges to the live-action 3D cinematographer (as my 3D simulcast gig next week may demonstrate).

One bug: sometimes when I connect the sony HMD (think video goggles) I’m using, the top and bottom image sections are offset by about 1/4 of the screen height. It’s not a bug in my coding, since I observe this discordance outside of openFrameworks. I can’t seem to reliably repeat the problem, and only a long restart fixes it (and even then, only some of the time). The order with which I connect the components (the goggles, their control box, the DVI to HDMI adapter) may have something to do with it. The best thing, here, would probably be to look into a proper graphics card that provides true HD 3D output. As it stands, I’m squashing two images into a single 1280×720 output — that’s about 640×360 per eye, significantly less resolution than the 1280×720 pixels the sony HMD is able of displaying per eye — and relying on the HMD to “unsquish” each image into discrete left and right images, a process of encoding 3D that is colloquially referred to as “over-under”. It’s somewhere in this last process, I think, that things are going awry, since the 2D mode seems fine. Since the HMD also supports a “side-by-side” mode, that’ll be the next thing to try.

I sat down with Deqing Sun yesterday and tried to wrap my head around a more formal understanding of the relationship between transform, rotate and scale within an orthographically projected/viewed “3D” scene. We fired up processing and took a gander at a simplified problem: how to manipulate a 2D object within 3D space. Quickly [...]]]>

I sat down with Deqing Sun yesterday and tried to wrap my head around a more formal understanding of the relationship between transform, rotate and scale within an orthographically projected/viewed “3D” scene. We fired up processing and took a gander at a simplified problem: how to manipulate a 2D object within 3D space. Quickly we realized that the order with which these operations are performed is the essential element.

float eyePoint = 1000;

void setup(){
size(600,600,P3D);
}

void draw(){
background(200);
translate(300,300);
translate(0,0,eyePoint);
rotateY((mouseY-300)/300.0*(0.5*PI));
scale(300.0/mouseX);
translate(0,0,-eyePoint);
rect(-20,-20,40,40);
}


Note that we’re translating three times. Here’s why: first we translate to the middle of the screen, then we translate on the Z axis to the point around which we want to rotate and then we translate back to our original position. Another way to say this is, we nest the rotation commands inside of an operation that translates to the coordinate around which we wish to rotate.

I then reworked these operations in openFrameworks / C++. Robby Tilton helped me realize that for my purposes, I could just drop scale all together. I’m not interested in changing the field of view, or truly “scaling” the scene — just in navigating within it based on arbitrary input. As I understand it, I don’t need to change the relative distance between objects — just the distance between objects and a viewpoint, and then angle from which those objects will be “projected” on the screen.

So I dropped scale — but not before I had a little fun (see picture). When it comes to building the impressionistic side of the re(time) simulator, I think some scale distortions will make transitionary aesthetic elements as I try to provide the experience of traveling (briefly) back in time.

infrared (IR) reflective material intended for the covert combat identification of troops, vehicles and equipment. It is [...]]]> As you may have guessed, that’s not what I was hoping would happen. I purchased a few IR reflective markers with the intent of cutting them up into a fiducial marker that would nicely reflect IR light.

infrared (IR) reflective material intended for the covert combat identification of troops, vehicles and equipment. It is most commonly used to prevent fratricide (the inadvertent killing of friendly forces). To the naked eye, GloTape appears to be similar to black duct tape in both texture and finish without a visible reflective glow. When illuminated with the infrared diode on standard night vision goggles (NVGs), the GloTape gives a bright reflection that is clearly visible up to 70 meters away.

No dice — at least with the 15-ILO5 Infrared Illuminator Panel I tested it with. And it’s worth mentioning that it didn’t reflect the IR laser used in the Kinect Camera, either. So, either the frequency of IR diodes on “standard night vision goggles” is way different than the 15-IL05 and the Kinect diode –OR– the squares I purchased are duds.

My fingers appear brighter than the "reflective square". Not what I was hoping for.

As a side not, to get the PS3 camera working under OSX 10.6.8, I had to install macam. Worked like a charm.

At the 2011 ITP Winter Show, I presented my invention, the FolkBox, which I described rather blandly as “a device that allows a person with limited left-hand dexterity to play the acoustic guitar.” The reason I really built is is to let my Dad play the guitar again. And, at the show, he did [...]]]>

At the 2011 ITP Winter Show, I presented my invention, the FolkBox, which I described rather blandly as “a device that allows a person with limited left-hand dexterity to play the acoustic guitar.” The reason I really built is is to let my Dad play the guitar again. And, at the show, he did — for the first time in over a year. Since then, I’ve been building a revised prototype. A full video is going to have to wait until I finish the robust, revised prototype this summer. I’ve documented some of the progress I made over break in an earlier post but I also want to share the first story of how it all came about. Here’s what I wrote for the winter show:

I grew up with my Dad’s songs. Some of my first memories are of him and my Mom singing to me and my siblings. A bad fall last winter left my Dad with a dislocated shoulder and detached nerves. His function in his left arm remains very limited. And he sure can’t play guitar.

I thought,’how about I just build something to allow him to get back to his songs?’ Something of a Luddite at heart, he was a little slow warming up to the idea of an electronic device interfacing between him and an acoustic instrument. Furthermore, he was understandably a bit pessimistic; he said, “Justin, that sounds like a great idea if you’ve got a ten-million dollar research budget behind you, but I just don’t think what you’re talking about is possible”. I said, “let me see what I can do”.

My design revolves around three rows of solenoids, positioned just above the fret board at the base of the neck on the first, second and third frets. A series of buttons near the body allow simple, intuitive control over chord selection.

Pressing and holding the first button plays an “A major” chord; pressing and holding the second button plays a “B major” chord, and so on. Other buttons, for instance, “7th” or “minor”, modify the chords that the root buttons create; pushing “minor” and then “B” plays a “B” minor chord.

FolkBox is a prototype in early development. At the time of this writing, John, who lives in upstate New York, has not yet tested the device. We’re excited and hopeful.

John is experiencing some nerve regrowth, at the rate of about 1mm every few weeks. It’s not known how long this will continue, and even if it does, his range of motion will likely remain limited.

As John warmed to the idea of utilizing an assistive device, I investigated what kind of input might feel most “natural” to him, most akin to playing the guitar. We considered using a combination of buttons on the guitar and a foot pedal, but settled on using buttons solely on the guitar because it most closely resembled the form factor of the instrument. Because of his limited dexterity, the “modfier” buttons are toggle switches; he need only press a minor button to enter the minor “mode”, wherein all chords will be minor until the mode is changed. This way, he doesn’t need to hold down multiple buttons at once, a task that we anticipated might prove difficult for him.

Our conversations first revolved around (1) what it might feel like to use a mechanical/digtal interface, and soon moved to hands-on conversations, where he would hold a guitar and we would examine where his hand could comfortably sit. The idea of having the buttons anywhere near the frets that would actually be pressed was quickly scraped — not only did he have difficulty moving his fingers, I learned, but he also couldn’t move his arm up the fretboard. Thus, we chose the intersection of the body and neck of the guitar as the ideal location for the buttons. I quickly fabricated a piece of wood and taped it to the guitar to see if he could reach it.

Audiance
Because the “folkBox” is controlled by a micro-controller, the input mechanism (the series of buttons placed below the fretboard) can be considered modular; it’s not hard to conceive of other forms of input that could be utilized to put the device in the service of other disabilities. A full amputee, for example, could utilize the foot pedal input module that John rejected.

A few pictures: