SmartSurfaces, Day Three, 9/25

Day Three wasn't really anything substantial in-class. We did more work with Schmigital Schmroject, showed off our (extremely neat) light tracker, and that's about it. However, we were assigned an out-of-class project to create a solar tracker. I will not be discussing this project in detail until Thursday or Friday. I will say that we are not using light sensitivity, but instead are using a predetermined equation.

I will say that I still think that Schmigital Schmroject is extremely clumsy, unintuitive, poorly designed, and overall not a quality program for use in the student environment.

Arduino Solar Detector

So, now that the project is over, I have decided to post the code that directed our Arduino units, in the interest of keeping this class as open source as possible. Our code was mostly derived from the Arduino meets Processing project.

/*

* ap_LDRAiming

*

* Reads an analog input from the input pin and sends the value

* followed by a line break over the serial port.

*

* This file is part of the Arduino meets Processing Project:

* For more information visit http://www.arduino.cc.

*

* copyleft 2005 by Melvin Ochsmann for Malm� University

*

*/

#include

Servo myServo;

// variables for input pin and control LED

int PhotoA = 3;

int PhotoB = 4;

int PhotoC = 5;

int LEDpin = 13;

int pos = 0;

// variable to store the value

int valueA = 0;

int valueB = 0;

int valueC = 0;

// a threshold to decide when the LED turns on

int threshold = 750;

void setup(){

// declaration of pin modes

pinMode(PhotoA, INPUT);

pinMode(PhotoB, INPUT);

pinMode(PhotoC, INPUT);

pinMode(LEDpin, OUTPUT);

myServo.attach(9);

// begin sending over serial port

Serial.begin(9600);

}

void loop(){

// read the value on analog input

valueA = analogRead(PhotoA);

valueB = analogRead(PhotoB);

valueC = analogRead(PhotoC);

// if value greater than threshold turn on LED

if (valueA <>

// print out value over the serial port

Serial.print(valueA);

Serial.print(",");

Serial.print(valueB);

Serial.print(",");

Serial.print(valueC);

// and a signal that serves as seperator between two values

Serial.print(";");

// Checks if right is greater than left, if so move to right.

if (valueB > (valueC +20))

// +20 is the deadzone, so it wont jiggle back and forth.

{

if (179 > pos)

pos++;

myServo.write(pos);

}

// Checks if left is greater than right, if so move to left.

if (valueC > (valueB +20))

// +20 is the deadzone, so it wont jiggle back and forth.

{

if (pos > 1)

pos -= 1;

myServo.write(pos);

}

// wait for a bit to not overload the port

delay(10);

}

The code includes a serial input that we used to judge whether or not our solar detection was working properly in a numerical sense. By slowing the program down to a delay of 250, we were able to tweak the code in order to ensure that the readings were proper, and that we could utilize the changes in direction properly.

The biggest issue was ambient lighting, which we were able to counteract with a shade of sorts while in design, but in final display we could not, because of the amount of ambient light in the center room. We set our thresholds slightly too high for the situation that we were in.

Conceptual Ideas: Physical Computing

In a nutshell, physical computing is the interface between digital and analog. An action is performed, a stimulation is presented, electrons are transmitted, algorithms are run, a result is computed, a response is triggered - either digital or in turn analog as well. It's very basic in concept and yet very advanced, because the possibilities are almost endless.

Interaction with a keyboard or mouse - that's physical computing. It's a very basic input scheme, but it is the most advanced input that many people come across, or at least think they come across. Unfortunate for them, as there is so much more to the idea, if only you understand it. Everyday interactions that nobody thinks about are handled with physical computing all the time. Thinking about it is somewhat scary, because there is margin for error, albeit low.

Take traffic control. Traffic lights are all on timers calculated by an extremely complex algorithm to optimize traffic flow (or by a monkey who really has no idea what it is doing, depending on what city you are in.) However, during periods of low flow, and in less urban areas, traffic lights are controlled by physical sensors - either a camera that recognizes the presence of an automobile, or a coil underground that detects the presence of a rather large body of metal by how conductive it is. It's an analog input - the image being taken by the camera - feeding a digital output - the changing lights - after itself being run through an algorithm that says 'okay, you can change the lights if you really have to'. Imagine if the traffic system had a glitch, or if something broke down. It'd be chaos. Unless you're in Chicago, because they have traffic cops at every stoplight reminding people what each light means by yelling at them to go or stop or walk or don't walk, when the light says exactly what you need to know. Taxpayer dollars at work.

An iPhone is a brilliant piece of technical work, and a good example of physical computing, because it represents direct control through touch. Conceptually simple, beautifully executed. I love my phone. Apple knows what they are doing - they have mastered the art of the technological consumer good. Now if only they could lower their prices a bit more - paying for quality has its merits, though... for one, you get quality.

Tinkering with an Arduino is a perfect introduction to physical computing. It is open source, it can be adjusted to interact with any input (someone set one up to be controlled by a Wii remote), and it can be coded to operate just about any output device. You could run traffic control for a stoplight, and likely a small grid of stoplights, off of the computing power that an Arduino has available to it - it is quite robust.

As time passes, everyday devices will become less analog and more digital. We are careening towards a future of digital displays and voice commands that do everything for us, where we will no longer drive in anything not considered a relic of a bygone age. The world is changing, and the best way to not get behind later is to get ahead now.

Introduction to Schmigital Schmroject

This week's project was to work with Schmigital Schmroject, an AutoCAD clone.

I really don't have a whole lot to say concerning Schmigital Schmroject. Unlike the Arduino, I am not much of a fan of what I have seen so far with it. The program appears to be extremely clumsy. I spent 30 minutes after finishing the tutorial trying to get some lines to interact properly, in a very simple way that should have been intuitive to the program. It is not user friendly in the least, the controls for navigation are overly complex (you can ctrl + mid-click to zoom, but there should be more intuitive pushbutton navigation, using the mouse is just awkward in the ways they want). Once 30 minutes were up and I had attempted to get the lines to interact properly multiple times, I gave up and left, because people were waiting for the computers.

I can't stand working with software that frustrates me. I hope that this software isn't an essential part of our final projects, or that I can find a way to warm up to it before the final project, because right now I am just not feeling it.

SmartSurfaces, Day Two, 9/18/09

Day two was a massive improvement over day one, in every way.

We led out by introducing my lamp, which was pretty awesome I suppose, but I didn't expect to be in the spotlight for it... other people had much better lamps, especially the rangefinder - that was extremely impressive.

I am a huge fan of the work with physical computing, and I have been experimenting with the Arduino since we got it. I found a program called Processing, which can be set up to interact with inputs from the Arduino and uses the data for other things, such as compiling graphics. I intend to look deeper into this, hopefully designing an extremely neat program.

Day Two: Project

Our project for the day was to design and construct a light tracking device utilizing photoresistors to detect where a light source is. We were divided into groups, and almost immediately our group was off to the races. I had been working with code for Processing which interacted with the photoresistors, and was able to help jumpstart the coding. Marc and Damien jumped into developing the code for interacting with the servos, and the remaining members of the group either helped me work with the photoresistors or worked with the cardboard, whatever was needed.

The worst part about this project was the amount of time given - we only had an hour, and only discovered the code for the servos existed already 45 minutes in. Our group pulled together well, however. Everyone did their parts, and we were able to come up with a finalized design with finalized code, at the very least, even though we did not construct the actual unit completely. Other groups were in approximately the same boat as us.

After the presentations, we were told to meet later on to finish construction of our unit. We met Sunday night, and after a couple of extra hours and several wires that wouldn't stay where we wanted them, we were able to construct our unit and get it operational, if a little jittery. The unit will track light, though it is not the best at tracking small point light sources - it is just not feasible without a full array of sensors. Also, ambient light is the enemy of this project, so we built a shade for it in order to keep ambient light off of it.

I felt our group worked much better than last week's group. There was a definite cohesion, everyone knew what they had to do, and there were very few moments where someone was 'lost'. The work got done, and we were all very proud of the final result.

Day Two: Thoughts Going Forward

I have worked with Allison twice now, and I am hoping she winds up in my final group - she has done a great job each week to learn quickly when she doesn't understand and to do what needs to get done when she does. She brings great ideas to the table, and has been a valuable member of each group.

I feel like the Arduino is going to be great to work with, and look forward to whatever this class has in store for us next. I haven't quite gotten to play with Design Studio, that is my next project, for tomorrow.

Introduction to Arduino

Our first major task outside of class was to prepare an Arduino lamp.

I have never used an Arduino before this, and let me just say that I am extremely impressed with how versatile the little thing is. I found a large collection of Arduino projects online that are inexpensive and yet extremely useful, as well as things that are just plain neat. If I had the time or patience, I would develop something controlled by a Wii Remote.

Development of the lamp was fairly straightforward, following the tutorials I came up with this (shredded toilet paper in place of tissue paper).

After I got everything set up, I started to consider the neat things that I could do with it. I had a Guitar Hero controller sitting right in front of me, and the button colors got me thinking - why not have it play a Guitar Hero song?

I went on a hunt online for an idea for what song to use, and came up with this guitar hero pattern, pulled from a full-length pattern at SlowHero:

Which corresponds to the opening to Guns N' Roses' Sweet Child O' Mine. I can't think of anything that would be more fitting... too bad I don't yet know how to get the Arduino to play music (the Arduino can interact with AppleScript, so it may be possible to get it timed to play the song with iTunes, and restart it every time the loop resets).

The code for the loop is really quite easy, though it took a little bit of experimentation to get the Arduino timed to the music correctly. I used a constant set of on/off triggers to get through the notes, and then set it up so that the loop would restart properly, without leaving a light on at the end.

Two issues came up. One, timing. It took me about 10 minutes to tweak and record until I got the Arduino to line up to the music for 15 seconds, which was all I really needed. Second, the cover. I came up with something that I thought would look better than it does, but on the plus side that isn't a cube.

Overall, I'm happy with the lamp, especially with the fact that it syncs up to Sweet Child O' Mine... Enjoy!

SmartSurfaces, Day One, 9/11/09

With the first day of class over, it is time to make a few reflections on how this semester will work. I feel that the class is an intriguing idea, and that the whole semester is going to turn out excellently.

Day One: Project

Our first project was to design and construct a system for transporting sand from point A to points B and C in space, at distances of under a meter.

The result of the first day's project can be described as nothing but a resounding failure, but through failure is the only true way to learn. The failure was nearly universal, spanning from communication to design to implementation, and though our idea looked excellent on the drawing board, it really should have stayed on the drawing board. Every group had very similar problems, and no group truly had the same grasp on what the problem was and what the parameters were. As such, three of the four groups had significant failures, and one of the groups, while successful, had a project that still could have been improved with more time.

My group was more than up to the task as individuals, but as a team we failed to achieve the cohesion necessary for making such a task a success in such a short period of time. The overall design was truly understood by only half of the team, who delegated tasks to the other half of the team without enough explanation. Overall, my group makeup was excellent. I feel that the advantage in this class will lie with people who are able to think with a background in more than one discipline, such as Eric. People will have different strengths on different projects, based on their backgrounds, so when we reach more technical portions requiring knowledge of programming the engineers will have advantages, while when we are doing more hands-on projects the artists will have definite advantages. This project was one in which the artists in our group excelled, while the engineers got bogged down with grandiose ideas and the architects were not in their element.

There were two major design roadblocks for our team. The first was that we thought that the entire system had to be built to be free-standing. Two of the groups utilized the tables as structural support, which we were led to believe could only be used as a 0 surface, not as a structural support. This may have been just our interpretation of what we were told by the professors, but the point is moot. I feel that if we had known that, we would have had more time available to work on the more complex aspects of our project, instead of having two members solely devoted to building free-standing structures. The second was that our system, which we thought was fairly simple, was in fact extremely complex. With a different medium than cardboard and duct tape (i.e. wood), we would have been more than able to complete the task to our design specifications, but we over-engineered our project for the medium available.

Day One: Thoughts Going Forward

I feel that I need to re-tool my thought process for this class. The way I think, I am a designer, and I am an improver, but I am not quite as good at the implementation steps that take place in between - the big picture is my forte, you could say. My strength within the group, which can also be seen as a weakness, was that I looked at the downside to most design ideas, in terms of how they would impact the idea as a whole. I think next week I will approach things differently, and hopefully things will work out better. I look forward to seeing how other people in the class do things.