Main

December 16, 2006

cougar!! cougar!!

So the cougar worked!! This was my first attempt at large scale animatronics, and it shouldn't be my last. From the beginning Meredith, Mandy, and I did a lot of planning and experimentations on what we had to do to make it work. We drew up diagrams on how the cougar would work both mechanically and through software, which really helped us get an idea of what we were up against.

Early on I tested a lot of things with the motor. To make the cougar hug and un-hug, we had to reverse the motor, which meant we needed and h-bridge Initially I wanted to create my own with relays, but I mistakenly bought 9DCV relays, which totally defeated our goal of driving the motor via the arduino (which could only supply 5V max). Good thing I had ordered an h-bridge unit from solution cubed as a backup. I highly recommend this if you want to drive a decent size motor that requires a lot of amperage.

Continue reading "cougar!! cougar!!" »

December 07, 2006

mtrail - thoughts

For my pcomp final I worked with Stefan to improve our light display for the midterm. The project was to create a light display that detects movement and leave behind trailing light. There were too main areas we wanted to improve from our first prototype -

1) Improve the sensitivity of the display
2) Make it portable

Changing the sensitivity required a lot of reworking of the code. We tested several different methods to sense “change” in the environment. We first tried peak detection, but the lights wouldn’t go on until a shadow passes through. This was a somewhat confusing interface. We then switched to raising-falling edge detection, which was more akin to what we had in mind. In the end, we only used raising edge to trigger the lights, because it allowed the display to sense multiple shades of shadows.

Continue reading "mtrail - thoughts" »

November 25, 2006

make your own h-bridge

One of the finals I'm working on requires using an h-bridge to drive a motor (if you don't want to spend $$ on a motor controller). I pretty much followed the example on this site. Because I only had NPN transistors, I had to modify the circuit so that Q3 was linked to A and Q4 was linked to B. Also, I needed to add in diodes for the digital input pins or else the microprocessor would get reset from time to time. Tested this with a low-power motor. Works like a charm =)

motor.JPG

Follow extended text for test code...

Continue reading "make your own h-bridge " »

November 20, 2006

software pwm

I've been trying to figure out how we could create a software PWM via arduino's digital pin. The current arduino supplies only 3 pins for PWM, which wasn't enough to drive our light dislay. The key in making this happen was to not use any delays at all. There are still some issues with the brightness of the LED's, but that should be easy to solve with some tweaking.

Code in next page

Continue reading "software pwm " »

October 26, 2006

pcomp midterm - post thoughts

So we presented our midterm yesterday. I should do a brain dump before my mind drifts to something else.

In the beginning I was mostly messing with sensors. A few that I played with that others might be interested are
- LED as a light sensor. Research can be found here.
- Range finder. Research is here.

The LED as a light sensor actually works, but the range was so restricted it was basically useless for our application. While a range finder would work best, it was probably too expensive for this project. So ultimately we stuck with photo sensors.

The thing with photo sensors (and with a lot of sensors, in fact) is that you often need to recalibrate them as you move them to different environments. As the project location changes, the reading from the sensors changes as well. This proved to be a difficult thing to debug because we were never guaranteed to sit on the same spot with the same lighting in the lab, and the first thing at hand when working on the project was always to recalibrate the sensors (and sometimes changing the resistors to get a higher/lower reading). I think it would be helpful to write some code to automatically calibrate the sensor at start up. Deciding what would be considered “a change” would be difficult though. Need to ponder more about it…

Continue reading "pcomp midterm - post thoughts " »

October 09, 2006

serial communication

For this lab I used a photo sensor and a flex sensor (they were the first sensor I found in my box).

serial-read.JPG


The first two sections of the lab were easy - just copy and paste and run the code. The third part - reading serial communication via hyperterminal - required more figuring out. You have to program the arduino first, close the program (to free up the port), then open hyperterminal to connect to the port. Once you make a connection you can start playing around with the values. I found the readings much easier to interpret if I used println instead of just print (or else they are just a bunch of jumbled up numbres). This actually is a pretty neat program for finding the range of all your sensors.

Next thing was making this talk to Processing. BG and FG color aren't set in the example code, so it helps to set, or else they both default to black. My COM3 connection was actually the 2nd element in Serial.list - Serial.list()[1] - so after setting that I was able to get a reading back. Controlling the dot with flex sensor and photocell is actually really hard becaues of the range of values you get, so it helps to scale it to 0~265. My initial readings were in the 50's range so I just neded to times that by 4.

October 07, 2006

range finder + night rider

To make the range finder work (better), I had to first calibrate it to find the initial state of things. When there's a change in value that exceeds this initial value, I know something REALLY moved infront of it (instead of just noise).

Code is below

Continue reading "range finder + night rider " »

October 05, 2006

LED as light sensors

Been messing around with the code found on this site. The reading I get from val seems to fluctuate a lot, and it's really difficult to find the resistance needed to stabilize it. The best resistance for the lighting on my desk seems about 2k ohms (two 1k in series). The mitsubishi reading is quite interesting.

led-sensor.JPG
red LED is sensor, green is output

Here's the code if you want to read it. It's just exact same code as on the french site, plus my commentary on what I think is happening...

Continue reading "LED as light sensors" »

October 03, 2006

servo lab

First order of business was to figure out what was the min and max of my servo. To find the min, I replaced the equation for pulse to be

analogValue = analogRead(analogPin);
pulse = 400 + analogValue;

analog-flex.JPG

and turned my pot until it was at a stable position. Did the same to find the max value, except I added 2000 instead. The min/max of my servo turned out to be 800/2400. I should find a sticker and note this on the servo.

Now the fun part - putting in a variable resistor other than a pot. I measured the resistance for my flex sensor with the analog in setup. It ranged from 120/450. Then I changed the pulse formula to be

pulse = (analogValue - 120) * 5 + minPulse;
if ( pulse < minPulse ) pulse = minPulse;
if ( pulse > maxPulse ) pulse = maxPulse;

the last two lines prevents the servo from trying to turn beyond its limit.

analog-pot.JPG

September 27, 2006

analog in - digital out

Here's a varation of the analog lab. The basic idea is to convert analog input to digital output. I hooked up a flex sensor and a photocell both as analog input, and combine their values to determine which LED's to light up.

photocell on the left, flex sensor at the right.
analog3.JPG

rows of LEDs.....
analog4.JPG

Continue reading "analog in - digital out " »

September 25, 2006

analog lab

This is the setup with a pot.

analog1.JPG

The reading varied from 1000+ to 0 as I turned the meter.

analog2.JPG

The setup with a flex-sensor was more fun to play with. It runs the exact same code. One thing about this setup is you have to use a high resistor to get a reading. I used a 220 ohm resister in the beginning and the reading was around 1000 with slight variations. As soon as I changed to a 10k resistor the reading varied more, from 570 when it is straight to 890 when it is bent.

September 20, 2006

combo lock interface

combo-lock

I've been fascinated with stikfas figures ever since they came out, so I decided to use them as a combo lock. One thing about stikfas figures is they are extremely flexible, so I thought I could use their hands and feet to create a circuit. I wrapped their hands and feet with foil and connected wires to it. You basically create a circuit by making his feet and hands touch each other. The users presses a button and the arduino pulls the circuit to see if it is complete or not. If you have a complete circuit, the green LED lights up (meaning you unlocked the combo), and if not, then the red one lights up. The coding for the project was actually really simple, since it just requires testing if the different parts to the circuit was HIGH.


combo-lock2.JPG

combo-lock3.JPG

The biggest obstacle for this project was how to correctly test the circuit. When dealing with dangling wires, there are often numerous ways to complete a circuit, so I had to install LED's in different parts on the breadboard to serve as traffic controller. Since LED's are diodes, they only allow current to go one way. This solve the problem where the users could break the lock just by puts all his feet/hands together. However, there are still a couple of ways to break the combo, and I've yet to figure out how to correctly test it.

September 19, 2006

observation - in depth

I decided to study the self-checkout kiosk in the supermarket, because it was the most complex of all the interactions I observed. The kiosk is roughly 5 ft(l) x 3 ft(w) x 4 ft(h). The user would take his/her items and place it in an area before the scanner, and as he/she finishes scanning each item, place it in the bagging area next to it. The scanning was most time consuming part, as each time an item passes through the scanner, the user needed to verify that the item was registered. Users often needed to re-orient the item to scan it successfully, and sometimes a person would swipe the same item several times before it went through. After all the items are scanned, the user pays for the merchandise. If they used a credit card they would just need to swipe their card and sign, which was a very easy process. However, if they paid with cash, they would struggle with putting the bills in the feeder.

u-scan!!

There was constant interaction between the kiosk and the user. The user had to operate the touch screen to indicate when the scanning of the merchandise began and ended. The kiosk was giving constant feed back on whether a transaction was successful or not - through a computer generated voice and by indicating the item on the touch screen.

There were several issues which made the machine difficult to use. There wasn't an area close to the register for the users to place their personal items, so they often put their handbags or wallets on the scanning area, which sometimes caused the machine to malfunction. Whether you have multiple persons or just one person operating the machine did not seem to make a difference, as the user would always have to scan merchandise one by one. This was the most time consuming part of the entire process, and was what most people usually got stuck on. Even though the staff used the kiosks more fluently, their advantage was more of a result of knowing how to orient the items so the scanner picks it up quickly. I think in order to make it a pain-free process for most, the scanning process would need to be redesigned.

observation - daily usage

I did my observation assignment on a Saturday when I was running around town to get errands done. Since I was in public space most of the time, a lot of the interaction I observed only involved one person with his/her personal digital equipment - such as cell phone, blackberry, ipod, etc. One my subway ride from Lincoln Center to Union Square, I counted interactions with 17 cell phones, 7 portable music players, and 1 blackberry. Out of all the activities, the blackberry took the longest time of engagement, as the user was actively reading and typing the entire time.

Cell phone use was particularly interesting because people could do many different things with it. I saw several people just pulling out their phone and glancing at it, presumably to check the time or to see if they had any missed calls. A couple of people seemed to be playing games on their phones during the subway ride, which required enormous attention and as well as usage of both hands. The majority of the people that where SMS'ing also used both hands, but those that were making phone calls where able to operate their phone with just one.

Most of the users seemed extremely familiar and comfortable with their personal equipment, as they were all able to operate them with ease. However, this was not the case devices that were intended for the general public. At the Astor Place station, I saw four people gathering around the MTA vending machine, trying to figure out how to purchase subway tickets. Even though only one person was operating the machine, the others were all standing around him and giving him instructions.

Another public device I observed was the u-scan kiosks in supermarkets - which allowed customers to scan, bag, and pay for merchandise on their own. Even though most people seemed familiar with the process, there were those did not know how to operate the machine. Those that have used it before were able to get on their way rather quickly, in no more than 30 seconds. For others it was a long and arduous task, requiring long periods of fumbling with the items to find the bar code, figuring out when/where to bag them. It took them much longer time to complete the transaction - by about 1~2 minutes.

When using personal devices, the goal was mostly to communicate with others (in the case of cell phones, blackberry) or to get rid of boredom (cell phone games, ipod). Most public devices involved some sort of monetary transactions, such as paying for merchandises or a subway ride.

September 16, 2006

arduino digital i/o lab

The hardest part of this lab was getting everything setup. I ordered my board from sparkfun, and received the NG version as opposed to the base version that most folks have. This did not work well with the school laptops - the COM would never register!! Where as the base board seemed to work without any additional software, the NG boards requried installation of these drivers from FTID. However, since nobody knew the admin login for the lab laptops, there was no way for me to install them. Luckily some folks in the lab also had the NG board, so we were able to work it out together.

I was able to install arduino (and the drivers) on my home computer without much trouble. Here it is in action!

switch off
switch off...

switch on!
switch on!!

After struggling with school's computers for this lab, im seriously thinking about getting a laptop - pc or mac?

September 11, 2006

first pcomp lab

First lab went well. I was able to finish it within an hour on a Sunday afternoon. Did not bring my camera so this will be an all-text entry....

Reminder - if the multimeter doesn't show 0.000 after being turned on, you should probably replace the battery.

First thing I learned this lab - LED's have polarity, so if it doesn't light up on first try, you should try switching them around. If you have a bunch of LED's in series the same board, its worth testing them one by one first to figure out the polarity - that way you don't have a gazillion LED's all in your circuit and no way of knowing which one(s) is put in wrong.

2nd lesson - when measuring amperage (current), the multimeter must be in series with the circuit you are measuring. If you put it in parallel, all the current actually goes through the multimeter instead of circuit. My first time measuring amperage I tried it like how you would measure voltage and my LED did not light up, but the multimeter still showed current going through.

Besides that, there wasn't much mystery to this lab. Just remember a few simples rules -

V = I x R
Voltage is the same across LED's in series.
Current is the same across LED's in parallel.

That's it for today!

September 10, 2006

chips =d

what more can one ask for ...