Sunday, 18 January 2009

UAF - Advanced Prototype Evaluation

Because the PIR sensors were unable to be implemented into UAF, the final stages that will be shown in this journal will be considered as an "advanced prototype" of the original proposal, that has the majority of elements the original plan detailed, but during implementation, some may have had to be removed.

Here is the finished result...





This artefact differs from the proposal only slightly, in where the idea that the user would not be able to directly interact with the piece, had to be removed because of the problems with the PIR sensors. Other than this, the piece pictured above follows the proposal almost perfectly, the only difference being the user will have to directly interact with the object, but still feel the satisfaction of using it.

I feel the fan still has the "unusual" characteristics that were listed in the proposal and where the idea for UAF stemmed from. This piece is a much more of an "obediant" house fan (rather than a "dominant", or "bossy" fan), that users have to interact with directly in order to get it to change, and such things as programs and speed settings associated with regular fans have been completley removed.

In regards to what has been accomplished in this project, the majority of same components were used as were listed in the proposal, the code is all contained on the Arduino and the Arduino powers all of the components via a single mains power cable, making the UAF a self-contained unit as was planned.

Thursday, 15 January 2009

UAF Stand Design and Concealment

To stay as true to the proposal as possible, the wiring and Arduino must be concealed within the stand of the UAF. In order to not make the stand appear out of place, the same black colouring will be used, and a similar plastic will be used as the material.

Because the servo motors need room to move they will have to be mounted to an edge of a sort of 'trough' so the 'pitch' axis of movement is as wide as possible.

The stand for UAF is intended to look like this...



With this design, the UAF will be entirely enclosed, with only one external mains power connection needed to power the entire piece.

Monday, 12 January 2009

UAF Progress

There has been a lot of progress since the last post on UAF. The progress made has shaped the possible outcome for UAF and what it is evolving into. A previous post mentioned that the PIR sensors used for detecting movement would unlikely be able to be included in the project as they weren't outputting any useable/readable data, this is still the case. However, the sensors after they are successfully turned on and are allowed to configure their range, do detect movement, and after researching through various brands of burglar alarm systems and finding out what pins on the sensor's PCB are the output, it seems the sensor does require a special pulse from an alarm control box in order to return a signal.

Also mentioned in this post was the idea of adding a second potentiometer to the circuit so that the user would be able to control the two motors individually (and so move the fan on two separate axis). This idea is now implemented and working successfully...




To finalise the project and make it seem as close to a consumer product as possible, UAF will have a base, that will hide most of the cables and Arduino from view, and stabalise the movement of the fan...

Sunday, 4 January 2009

Using Fans with Arduino - Other Projects

The use of Fans with the Arduino seems to actually be a highly popular form of input. Many designers have used the same type of fans (albeit smaller, so they're easier to blow) that UAF is using to give input to the Ardunio, instead of the Ardunio outputting to the Fan. Here are some interesting examples that use Fans and the Arduino to control lighting...





The designer behind these pieces seems to have taken the same train of thought as I have with UAF, where he thought of an alternative use of the Fan, to make it an input device rather than an output device.

Wednesday, 24 December 2008

UAF Development Progress

UAF's servo motors are still operating from a single potentiometer, and unfortunately the PIR sensors purchased seem unable to offer a readable output for the Arduino. Although the sensors could successfully be powered from a 12V source (by indication of the LED on the sensor flashing), there is no clear way to get a safe reading the Arduino could use.


Image of Parallax PIR Sensor from: www.parallax.com

It does seem, that it is only the brand chosen that seems to be the problem, as there are pieces using the Arduino and a particular PIR sensor manufactured by Parallax in the US. Unfortunately, importing these sensors is not financially feasible so a compromise must be sought in order to still offer user interaction, I am thinking that using a second potentiometer so users can control the two axis of movement separately would be a successful compromise, as it will still offer interaction and user satisfaction, but, unfortunately, the 'uncontrollable' aspect will be removed.

Friday, 19 December 2008

Alternative and Innovative Public Products

Because the UAF is designed for ease of use, so it could be used by the general public, I decided to look at interesting interfaces that are being made available to the public...


Image of OCZ's NIA from:
techreport.com

Pictured above is the "Neural Impulse Actuator Controller" (or NIA) by OCZ. This device is essentially a motionless "joystick" aimed at PC gamers, that through the device's drivers, outputs various facial movements and brain waves as regular keyboard keystrokes. This makes it usable in any application that can have keystrokes bound.

Unlike UAF, it is mentioned in reviews that the NIA takes a lot of getting used to, and users have to 'train' themselves to use the device. With UAF, the device will be plug and play, where only a power supply would be needed.

Here is a video review of the NIA, which notes that it is a fresh, innovative and forward thinking device that will make gaming never be the same again...

Friday, 12 December 2008

Abstract Data Visualisation

I have come across an interesting electronic piece titled: Dept. of Rhythmanalysis: Dupage, by Kevin Hamilton. This piece shows viewers True/False answers to unusual questions in a very basic electronic Green/Red LED display...



Images of Dept. of Rhythmanalysis: Dupage from: www.kevinhamilton.org

... some of the conditions displayed include:

  • WAR IN IRAN / WAR IN IRAQ
  • BORDER SECURE / NO BORDER
  • DEMOCRATIC WHITE HOUSE / REPUBLICAN WHITE HOUSE
  • IT WILL GET BETTER / ITS PRETTY BAD
This piece and other versions of it are mentioned in an article on Rhizome that mention Hamilton as an artist that is "clearly invested in questioning the nature of interface and display".So Hamilton seems to have followed similar principles that UAF follows, in that he is exploring alternative ways of display for interfaces. Which is the same thought process of UAF, where alternative thinking will provide users with an unusual and innovative interface.

Tuesday, 25 November 2008

User Auto Fan Prototype

After some work on creating the structure, the UAF has reached a usable prototype stage. In this stage, the fan rotates and moves a substantial amount of air and for demonstration purposes the servo motors can be controlled by the use of a potentiometer.




There are still obviously more development stages that UAF will have to go through before it becomes like the proposed design (not requiring direct user interaction, being a self-contained unit, etc.), however this prototype shows the potential for the project.

Thursday, 20 November 2008

Servo Motors with Arduino

Servo Motors are a kind of motor that can read its position, and turn to a position, rather than just 'run' until stopped. These are a good choice to include in my UAF project as the tools to move the fan.

The Arduino code that will control the motors is freely available on the internet...
/*
Two-servo control from an analog input

Moves two servos based on the value of one analog sensor,
in opposite directions.

The minimum (minPulse) and maxiumum (maxPuluse) values
will be different depending on your specific servo motor.
Ideally, it should be between 1 and 2 milliseconds, but in practice,
0.5 - 2.5 milliseconds works well for me.
Try different values to see what numbers are best for you.

by Tom Igoe
Created 28 Jan. 2006
Repurposed for Dual Servos by Carlyn Maw
24 Mar. 2006
*/

int servoPinL = 2; // Control pin for servo motor - L
int servoPinR = 3; // Control pin for servo motor - R
int minPulse = 500; // Minimum servo position
int maxPulse = 2000; // Maximum servo position
long adjustedAV = 0; // Analog value adjusted for determining pulse values
int pulseL = 0; // Amount to pulse the servoL
int pulseR = 0; // Amount to pulse the servoR
int delayValueMax = 200; // the 20 microsecond maxiumum pulse range for the servo
int delayValue = 200; // the actual value the code should wait, determined later

int analogValue = 0; // the value returned from the analog sensor
int analogPin = 0; // the analog pin that the sensor's on

void setup() {
pinMode(servoPinL, OUTPUT); // Set servo pins as an output pins
pinMode(servoPinR, OUTPUT);
pulseL = minPulse; // Set the motor position values to the minimum
pulseR = maxPulse;
}

void loop() {
analogValue = analogRead(analogPin); // read the analog input (0-1024)
adjustedAV = (analogValue / 10) * 19; // convert the analog value to a number
// between 0-2000 (difference between min and max)

pulseL = adjustedAV + minPulse; // set value for left motor
pulseR = maxPulse - adjustedAV; // and the inverse for the right

digitalWrite(servoPinL, HIGH); // Turn the L motor on
delayMicroseconds(pulseL); // Length of the pulse sets the motor position
digitalWrite(servoPinL, LOW); // Turn the L motor off

digitalWrite(servoPinR, HIGH); // Turn the R motor on
delayMicroseconds(pulseR); // Length of the pulse sets the motor position
digitalWrite(servoPinR, LOW); // Turn the R motor off

delayValue = (delayValueMax - pulseL) - pulseR; // determine how much time you have before the 20 ms is over...
delayMicroseconds(delayValue); // 20 millisecond delay is needed between pulses
// to keep the servos in sync
}


Code from: www.tigoe.net
I edited the code to represent the timing for my specific motors, so the electrical pulse that the servo motors use to move and read position never goes too high or too fast. Here is the result using a potentiometer as the user input (as a method for easy testing)...

Thursday, 13 November 2008

Fritzing and "Virtual Prototyping"


Image of Fritzing from: www.pixelsumo.com
"Fritzing is an open-source initiative to support designers and artists to take the step from physical prototyping to actual product." - www.fritzing.org
Specifically, Fritzing is being designed (is still in alpha stages) to prototype for Arduino-based PCBs (Printed Circuit Boards), and they compare it as a software metaphor to the electronic breadboard, which is designed to be a speedy prototyping base to 'mess' about with.

This kind of Electronic Design Automation software is designed for the Arduino, and is also Open Source much like Processing or the Arduino software. However, this kind of prototyping software is not a new thing...


Image of Eagle from: cadsoft.de

The immediate picture above shows screen-shots of Cadsoft's PCB prototyping software: "Eagle". This software is not primarily targeted at artists in the same way Fritzing is, and is also not focused on the Arduino (but any custom PCB), but still has a freeware version available.