Bubbles Final Presentation

In this presentation, our team discusses the creation process of the fuzzy responsive robot named Bubbles. Take a look at earlier posts for a fuller description of the project and technical breakdowns.

You can view a brief interaction with the creature! The orange tentacles are a bit under the weather but the sound is working!

PCOMP: Final—servo noise solution 1

For the final project, my team is continuing to build out the creature we designed and prototyped for the Midterm. One of the issues we were unable to solve for the Midterm presentation is the noise caused by the Servo Motor that was resulting in false analogRead values.

We got two useful solutions from the Phys-Comp listserve:

  • Put the servo motor on a separate power supply
  • Use a decoupling capacitor

I am in the process of learning about decoupling with a capacitor. In the meantime, using a separate power source for the servo solved the noise issue.

Setting Up a Second Power Supply

The fastest setup I could manage based on the tools at hand was using a 9V battery with a snap attachment. I used a 7805 voltage regulator to limit the voltage to 5V.

 

My first attempt failed because I did not connect the ground to the Arduino. As a result, the servo turned on, but would not respond to the Arduino program even though it was connected to a pin. The voltage regulator began to overhead, though I’m not sure it was related, since there was path to ground via the battery. The setup on the left is wrong—DON’T DO IT!

 

Below is the image of the successful setup. The ground from the voltage regulator goes into the Arduino ground. The servo is connected to ground via the Arduino.

With the second power source in place, the servo motor noise issue is gone.

PCOMP: Midterm prototype 2

I made a very basic mockup of our creature’s “bristle” mechanism with a paper towel tube, a CD cylinder cover, some wire and toy stuffing.

The code is telling the servo motor that if the fsr feed is 0 (actually it’s 0 – 15, because of some noise I was getting), the servo motor is in a neutral state of 80 degrees, leaving the bristle half-in, half-out.

At a pressure value between 15 and 700, the servo goes into a happy state and turns to 180 degrees, expanding the bristle all the way out.

If the pressure goes beyond 700, the servo goes into an angry state and goes down to 0, retracting the bristle.

I added a 3 second delay after the happy and the angry state is released to neutral, so that the creature has time to react and make the user aware of its reaction. The delay might have to be even longer.

I need to spend more time on perfecting the delay behavior. At the moment, it’s causing a delay not only between happy/angry states and the neutral (which we want) but also going from happy to angry (which we don’t want). I’ll try to use boolean vars to set up rules of when a delay should occur.

I set up three LEDs to correspond to our three states (not sure if you can see them lighting up in the video). For some reason, they are not getting enough power to light properly (only the red LEDs are bright enough for visibility—the green is almost imperceptible while the yellow doesn’t light at all).

ISSUES TO CONSIDER:

As Mike mentioned, we’ll need a sturdy wire to drive our bristle. The wires I have at home are too flexible and thin for the job. However, the servo motor has pretty small holes for attachments so a hanger or thicker wire will need a fancy rig to attach (they don’t fit).

With the attachments we have in our kit, the servo provides a fairly small range of up/down motion. If we want the bristles to expand and retract at a greater range, we’ll need to add an extension to our “servo arms”.

NEXT STEPTS:

  • Perfect delays between happy/angry states and neutral state.
  • Play around with a breathing cycle for the neutral state.
  • Figure out the LED power issue (might have to ask Benedetta about this—I’m drawing a blank).
  • add more FSR’s to create diversity in the “happy” bristle states.

CODE:

#include <Servo.h> // include the servo library

Servo servoMotor;
int servoPin = 8; // servo pin
int servoAngle = 80; // initial servo angle for “neutral” state

const int ledRed = 4; // red LED pin
const int ledGreen = 2; // green LED pin
const int ledYellow = 7; // yellow LED pin

void setup() {
Serial.begin(9600);
servoMotor.attach(servoPin);
}

void loop()
{
int analogValue = analogRead(A0); // read the analog input
Serial.println(analogValue);

/* I am putting a servoMotoer.write into each of the “state” conditions
so that a delay can be added after each state, giving our creature time
to play some sounds and for the users to process the change. I am still
working on this part to remove the delay between happy and angry states.*/

// HAPPY STATE condition
if (analogValue > 15 && analogValue < 700) {
servoAngle = 180;

servoMotor.write(servoAngle);

digitalWrite(ledRed,LOW);
digitalWrite(ledGreen,HIGH);
digitalWrite(ledYellow,LOW);

delay(4000); // four second delay

}

// ANGRY STATE condition
if (analogValue > 700) {
servoAngle = 0;

servoMotor.write(servoAngle);

digitalWrite(ledRed,HIGH);
digitalWrite(ledGreen,LOW);
digitalWrite(ledYellow,LOW);

delay(4000); // four second delay
}
// NEUTRAL STATE condition
if (analogValue == 0 || analogValue < 15) {

servoAngle = 80;

servoMotor.write(servoAngle);

digitalWrite(ledRed,LOW);
digitalWrite(ledGreen,LOW);
digitalWrite(ledYellow,HIGH);
}

delay(50); // this delay is just a safety precaution – not sure we need it.
}

 

 

PCOMP: Midterm prototype 1

In our Bubbles project, we want to use force sensitive resistors to trigger different reactions from the creature as people pet its furry surface. Because long RSFs are fairly expensive, we are considering making a DIY pressure sensor.

<iframe src=”http://player.vimeo.com/video/52896001″ width=”500″ height=”281″ frameborder=”0″ webkitAllowFullScreen mozallowfullscreen allowFullScreen></iframe>

In this test, I used conductive foam (a small pad that protected my HBridge in the Arduino Kit) sandwitched between two pieces of foil. It seems to work quite well, though the values are not as sensitive as from an actual pressure sensor. The values skyrocket from 0 into 300′s at the slightest touch and reach only upper 900′s at the highest pressure. It helped to use rubber gloves to cut down on conductivity from my hands.

We’ll need to experiment with conductive foam of different densities (high-density seems to be recommended for this type of project) and thickness. It might also help to substitute foil with a conductive fabric or flexible copper material for better durability.

For now, I will use the fsr that came with my kit to develop Arduino code

 

PCOMP: week 3 (lab 1)

For the servo motor lab I used a pressure sensor as an analog input to drive the motor. Even though I am mapping the 0 – 1023 values from the pressure sensor to fit into the 0 – 180 degree range, my motor does not seem to actually turn a full 180 degrees when the sensor is under maximum pressure.

When I used the Serial.println command to print the value of the variable holding the motor’s angle, I confirmed that the degrees never went above 174, no matter how hard I pressed or how evenly I tried distributing the pressure across the sensor.

What could account for the missing 6 degrees? Does it not register into the sensor due to lack of sensitivity? Am I not covering the full surface area of the pressure sensor with my thumb, causing less input? Or could some of the information be getting lost on the way from the sensor to the Arduino?

Solution:

I tried to make up for the 6 degrees missing from a full 180 turn by tinkering with the mapping numbers. Instead of mapping 0 – 1023 to 0 – 179, I bumped up 179 to 185 and got a full turn.

 

Intimidation design: Moscow’s metro turnstiles

The old-style Moscow metro entrances are equipped with “optical turnstiles”—infrared-beam-triggered sliding gates that are by default in an open position. When a person drops in a token, or more recently, presses a metro card to a magnetic strip, the gate remains open. Should someone try to walk in without paying the fare, the gates will slide shut in front of them.

Of course things don’t always work as intended. If the fare-skipper is moving fast enough, the gates will slam shut on her hips (or, in the case of an unruly child, on the shoulders or ribcage). The result is some mild bruising and a life-long, paralyzing fear of entering the Moscow metro.

In case there is some part of you that thinks law-breakers deserve a little kick in the shin, imagine how easy it is to become distracted in a shoving, suffocating crowd and absentmindedly stroll into an open gate. Even in New York, I’ve been known to walk full-force into a turnstile without sliding a metrocard (sometimes holding out my housekeys or an ID card). In Moscow, it’s an even easier mistake to make, since there is no physical barrier to bring one back to reality.

In “Emotional Design: Attractive Things Work Better”, Donald Norman suggests that objects created for use in stressful situations should have good, human-centered design. A Moscow metro station during rush-hour is the epitome of stress.

Sometimes I wonder if the creators of these clunky soviet hip-traps were designing an intricate mind game to instill a sense of fear and worthlessness in a human being. More likely, they simply made the most economical use of any materials their limited budget could afford. Whatever the design process, little thought was given to the practical use of the turnstiles.

Take a close look at the top photograph. Once you pay the fair (which is no easy feat since the recently-introduced metro cards come with no directions and are used differently from station to station), you have to decide which turnstile to use. Being a somewhat experienced, right-handed Moscovite, I instinctively walk to the left of the column. But my left-handed, New Jersey born fiance was in real danger of getting a hip bruise.

Even if you managed to enter unscathed, you still have to master the art of exiting. The turnstiles look almost identical going in and coming out. In either direction, they have the same affordance—to let one pass. There are almost no signs around to help guide the crowd. This is probably for the best, since those that exist cause more confusion. The exit sign can be green, blue or black, depending on the station. Besides the metro maps and advertisements, almost all text is Cyrillic.

After a few days of using the Moscow subways, Vas (the aforementioned left-handed fiance) and I were speed-walking out of a station and got separated in front of a long row of turnstiles. The right half of the turnstiles was for exiting and the left half for entering. The only cue for where one ends and the other begins was a guard booth in the center. A subway-savvy New Yorker would not stop to think which turnstile to use, since an MTA turnstile can work in both directions. This is not the case in Moscow where the exit turnstiles have disabled gates while the entrance turnstiles will close on you in either directions.

Since both sides looked identical, and there were no signs to say otherwise, Vas darted into an entrance-only turnstile and got promptly slammed on the hips. Discombobulated, he made another panicked rush at the turnstile, receiving another hit. By the time we got out of the metro, we were both saying a silent prayer to our less-than-perfect but better labeled MTA system.

PCOMP: week 2 (lab 2b)

PRESSURE SENSOR

I started with setting up the board with one pressure sensor. It took a while to get all the wiring right. To extend the distance between the board and the sensor, I clipped and stripped the edges of two wires in my arduino kit and tied them to the two sensor pins. After some experimentation I realized the sensor is not polarized.

Applying pressure to the sensor makes the LED get brighter.

PCOMP: week 2 (lab 2a)

POTENTIOMETER

I set up the potentiometer exercise and then added an extra LED, to better understand what the code does. My potentiometer turns two LEDs on and off. I tinkered with the code a little to make one LED dim while the other brightens, but eventually gave up. Maybe next week!

This is my final result:

Code:

const int ledPinRed = 9; // port for pin that the RED LED
const int ledPinYellow = 10; // port for pin that the YELLOW LED
int analogValue = 0; // value read from the pot
int brightness = 0; // PWM pin that the LED is on.

void setup() {
// initialize serial communications at 9600 bps:
Serial.begin(9600);
// declare the led pins as an output:
pinMode(ledPinRed, OUTPUT);
pinMode(ledPinYellow, OUTPUT);}

void loop() {

analogValue = analogRead(A0); // read the pot value
brightness = analogValue /4; //divide by 4 to fit in a byte
analogWrite(ledPinRed, brightness); // PWM the LED with the brightness value
analogWrite(ledPinYellow, brightness); // PWM the LED with the brightness value
Serial.println(brightness); // print the brightness value back to the serial monitor}

Image:

 

PCOMP: week 2 (lab 1a)

After building the one-switch/two LEDs example from the blog, I decided to try setting up separate switches for each LED. The setup looks like this:

For about 30 minutes I hit my head against the table trying to figure out why only one of the LEDs (the one plugged into port 3) was lighting up. Port 3 worked for either LED, with or without a switch. Ports above 3 did not work at all.

I tried re-wiring several times before realizing that the problem was in the code! I was re-using the code from a one-switch / two-light setup. I changed the “void loop” statements to work for my new setup, but not the “void setup” info.

Finally, this code allowed me to light up the red LED while pressing the first switch and light up the yellow LED while pressing the second switch. Both of the LEDs were off when switches were not being pressed.

Code:

void setup() {

pinMode(2, INPUT); //switch 1
pinMode(3, INPUT); //switch 2
pinMode(4, OUTPUT);//RED LED
pinMode(5, OUTPUT);//YELLOW LED}

void loop() {

if (digitalRead(2) == HIGH){
digitalWrite(4, HIGH);
digitalWrite(5,LOW);
} else {
digitalWrite(4, LOW);
digitalWrite(5,LOW); }

if (digitalRead(3) == HIGH){
digitalWrite(4, LOW);
digitalWrite(5,HIGH);
}else {
digitalWrite(4, LOW);
digitalWrite(5,LOW);
}}

Images:

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

By commenting out both of the “else” statements, I got the LEDs to stay on after their switches were pressed: