The Intro to Physical Computing final project is to build a device that will help an older friend in way that is unique and specific to them; for us that person was Peter. As he lives in the penthouse of his apartment, the wind gusts on his balcony are really strong. This has caused him to have to tie down all the furniture out there as well as make sure that it is safe enough to go out there. When he babysits his granddaughter, she isn’t allowed on the balcony because it may be unsafe for her. Because of this, we decided to build him a personalized display of the wind speeds on his balcony. For more information about our meeting with him, check more on our process wordpress, and read on to learn more about our final work.

What We Built 

Our project measures the speed of the wind on his balcony and then displays this information in three different ways. The max speed is shown with a speedometer, the current speed is shown on a digital display, and the max wind speeds of the past 7-70 minutes are shown in a bar/line graph based on the setting Peter sets it as. This is all housed on a stand in a compact wooden box with a cloud and the 3 displays on the front with the switches on the right side panel.

Detail 1

Detail 2

Detail 3 Numbers

Detail 4 Side

After a windy day, Peter arrives home wondering just how fast it was so high up, so he heads over to Cool Cloud to see the max speed and the history throughout the last hour or so. He’s not surprised that it was 72+mph, but is happy that his suspicions were confirmed that it truly did get that fast on his balcony.

On a nice summer day, Peter wants to have a barbeque on his balcony. However, the news said that there would be mild winds, which might have meant anything up so high in the past. Now though, he knows what the wind is like on such days because of our Cool Cloud. He now knows that it will be perfectly safe and can now better plan future events outside based off what the weather says and the past speeds on such days. He can also finally let his granddaughter see the amazing view his apartment offers without fear of the wind.

How We Got Here

We started off by picking an off-the-shelf sensor that could detect wind speed. The anemometer we chose was a highly durable and weatherproof model that could measure up to 72 mph winds, which seemed ideal for our purposes.

The anemometer

Next, we started prototyping the indoor portion, figuring out what kind of visualizations we would have and how we would package them. We wanted to focus on the aesthetics of the indoor module, as that would set this project apart from a generic weather sensor.

Lasercut wooden grid for the LED bar graph

Detail shot of prototype LED strip

Functional prototype with a potentiometer dummy input

Showing our prototype to Peter

The biggest challenges at this point were all design choices. The scope of the project was pretty wide open, and we had to decide how we were going to present the information to Peter in a useful and appealing way. We spent a lot of time sketching, CADing, and prototyping different approaches.

For the final version, our challenges were to package everything nicely in a box and to weatherproof the outdoor module. This meant figuring out a secure way to mount the anemometer to Peter’s railing as well as building an enclosure that could keep the electronics from getting wet.

To secure the anemometer, we designed a 3-part clamping system that could bolt together on a T-joint of Peter’s railing.

Brainstorming a clamping system

Making the side panels

Clamp prototype

Creating the mounting box to be 3D printed

We 3D printed a final version of the clamping pieces. For the indoor portion, we still had to build our box and solder all of our electronics.

Lasercut pieces for the enclosure

Making the stand

Back panel with some soldered components

All components soldered and mounted

The toughest part of the final was the small last-minute adjustments we had to make to get everything to work smoothly. For instance, we had to cut some of our lasercut pieces to size because they were off by a little bit. We also added a hole to be able to access the Arduino’s USB port. It also took us a few tries to make the standoffs that the servo and LED matrices are mounted to. Technically, none of the components in this project were that challenging to use, and we were confident we could achieve full functionality. Integrating everything seamlessly and mechanically fabricating the whole thing was challenging.

Conclusions and Lessons Learned

The crit made us feel pretty good about our project as most people said it was pretty cool and worked well. One question we got was as to why our graph read from left to right with the left being the most recent instead of the other way around. This is interesting because we thought this was most logical as you read a book from left to right. It was brought up that in most bar graphs the most recent information is on the right and even for a book, the most recent information is technically on the right. This is a pretty sound argument that we never thought of and would have been a pretty quick fix if we chose to do so. One criticism we received from the written feedback is that our indoor component could have looked better, more specifically as two people pointed out that it may have looked better if we used “a different material than wood” because “you can see the burn marks.”  We liked the contrast the wood provided with the frosted acrylic and thought it would have a nice aesthetic on a table or wall; however, we could have chosen another material like a different color acrylic that would have had contrast without burn marks. Another concern was that “it will not survive PGH winter.” This is a concern that we also have about our outdoor component, but the anemometer is said to be able to take the weather and the screws should be able to hold up. One feature that Peter mentioned would have been nice is if he could plug his  computer in and see the history of it over its entire time running or if data could have also been transmitted to his phone. These sound like pretty interesting features, that we may have been able to include had we been informed of the desire earlier as well as if we had more time on the project. Other than that Peter was happy with our cloud display and really liked that we decided to include the toggle switch for him to go between a bar and line graph.

This was a really refreshing and fulfilling experience because we got to build something that we know will be used and is helpful to someone other than ourselves or simply to meet an assigned task. It was surprising how long it took us to figure out that this project is what Peter clearly wanted from the very beginning. Talking to Peter throughout the designing and building process was also a lot more seamless than originally anticipated. We do however think it would also be a good idea to ask if there were any additional features that he wanted us to include while making the final product (after the prototype meeting). This way we could discuss with him the feasibility of such things and maybe incorporate an aspect of it. Overall we are really happy with how our project turned out in that it worked exactly as we meant it too.

While we are happy with our project, there are still some things that we would have done differently if we were making it again. Hinging the back of the box so that it can be opened back up in case something somehow went wrong with the wiring last second is something to keep in mind for all our future projects and would have been very helpful for our peace of mind. Additionally, it would be a good idea to test everything together earlier in case there wasn’t as simple of a fix as we found and it were to take longer to figure it out.

Technical Details

/*
 * Cool Cloud
 * 
 * Alton Olson, Vicky Zhou, Seema Kamath
 * 
 * This is the transmitter that lives outside and sends
 * wind data to the receiver indoors.
 * 
 * Pins:
 * A0 - anemometer output
 * 7 - radio CE
 * 8 - radio CSN
 */

#include <SPI.h>
#include <nRF24L01.h>
#include <RF24.h>

RF24 radio(7, 8); // CE, CSN
const byte address[6] = "00001";

void setup() {
  // set up radio
  radio.begin();
  radio.openWritingPipe(address);
  radio.setPALevel(RF24_PA_HIGH);
  radio.stopListening();
}

void loop() {
  // read anemometer value
  int reading = analogRead(A0);
  // send anemometer value
  radio.write(&reading, sizeof(reading));
  delay(1000);
}

/*
 * Cool Cloud
 * 
 * Alton Olson, Vicky Zhou, Seema Kamath
 * 
 * This is the receiver that lives indoors and displays
 * all the visualizations.
 * 
 * Pins:
 * A0 - slider pot for adjusting graph interval
 * 3 - switch for line graph/bar graph
 * 7 - radio CE
 * 8 - radio CSN
 * 9 - servo
 * 10 - LED strip
 */

#include <PololuLedStrip.h>
#include <Wire.h>
#include <Adafruit_GFX.h>
#include "Adafruit_LEDBackpack.h"
#include <SPI.h>
#include <nRF24L01.h>
#include <RF24.h>
#include <Adafruit_TiCoServo.h>

const int LED_COUNT = 49;
const int SERVO_PIN = 9;
const int LED_PIN = 10;
const int POT_PIN = A0;
const int SWITCH_PIN = 3;
const int RADIO_CE_PIN = 7;
const int RADIO_CSN_PIN = 8;
const int TENS_MATRIX_ADDR = 0x70;
const int ONES_MATRIX_ADDR = 0x71;
const int GRID_WIDTH = 7;
const int GRID_HEIGHT = 7;
const int DAY_MILLIS = 86400000;

// binary data for the 8x8 matrix images
const uint64_t TENS_IMAGES[] = {
  0x0000000000000000,
  0x7020202020203020,
  0xf810204080808870,
  0x7088808060808870,
  0x8080f88890a0c080,
  0x70888080780808f8,
  0x7088888878088870,
  0x10101020408080f8,
  0x7088888870888870,
  0x708880f088888870
};
const uint64_t ONES_IMAGES[] = {
  0x0e1111111111110e,
  0x0e04040404040604,
  0x1f0204081010110e,
  0x0e1110100c10110e,
  0x10101f1112141810,
  0x0e1110100f01011f,
  0x0e1111110f01110e,
  0x020202040810101f,
  0x0e1111110e11110e,
  0x0e11101e1111110e
};

// display one of the binary coded images
void displayImage(Adafruit_8x8matrix matrix, uint64_t image) {
  matrix.clear();
  for (int i = 0; i < 8; i++) {
    byte row = (image >> i * 8) & 0xFF;
    for (int j = 0; j < 8; j++) {
      matrix.drawPixel(i, 7 - j, bitRead(row, j));
    }
  }
  matrix.writeDisplay();
}

// convert from (x, y) to an LED index on the strip
int getLEDnum(int x, int y) {
  if (y % 2 == 0) {
    return (6 - x) + 7 * y;
  }
  else {
    return x + 7 * y;
  }
}

// convert from a speed to a bar graph height
int getYval(int currentSpeed) {
  if (currentSpeed <= 5) {
    return 0;
  } else if (currentSpeed <= 15) {
    return 1;
  } else if (currentSpeed <= 25) {
    return 2;
  } else if (currentSpeed <= 35) {
    return 3;
  } else if (currentSpeed <= 45) {
    return 4;
  } else if (currentSpeed <= 55) {
    return 5;
  } else {
    return 6;
  }
}

// color coding (red, yellow, green)
rgb_color getColor(int y) {
  if (y == 6) {
    return rgb_color(255,0,0);
  } else if (y == 5) {
    return rgb_color(255,0,0);
  } else if (y == 4) {
    return rgb_color(255,255,0);
  } else if (y == 3) {
    return rgb_color(255,255,0);
  } else if (y == 2) {
    return rgb_color(255,255,0);
  } else if (y == 1) {
    return rgb_color(0,255,0);
  } else {
    return rgb_color(0,255,0);
  }
}

// global variables
RF24 radio(RADIO_CE_PIN, RADIO_CSN_PIN);
const byte address[6] = "00001";

Adafruit_TiCoServo servo;
PololuLedStrip<LED_PIN> ledStrip;
rgb_color colors[LED_COUNT];

Adafruit_8x8matrix tensMatrix = Adafruit_8x8matrix();
Adafruit_8x8matrix onesMatrix = Adafruit_8x8matrix();

// history for bar graph
int maxRecentVals[GRID_WIDTH];
// toggle for line graph/bar graph
bool isLineGraph = false;
// interval to shift bar graph
unsigned long graphShiftInterval = 1000; // in ms
// timer for bar graph shift
unsigned long loopStartTime;
// variables to track peak speed
int currentSpeed, peakcurrentSpeed;
unsigned long peakcurrentSpeedTime;
// servo angle
int motorAngle = 0;

void setup() {
  Serial.begin(9600);
  pinMode(POT_PIN, INPUT);
  pinMode(SWITCH_PIN, INPUT_PULLUP);
  servo.attach(SERVO_PIN);

  tensMatrix.begin(TENS_MATRIX_ADDR);
  onesMatrix.begin(ONES_MATRIX_ADDR);

  loopStartTime = millis();

  radio.begin();
  radio.openReadingPipe(0, address);
  radio.setPALevel(RF24_PA_HIGH);
  radio.startListening();

  for (int i = 0; i < GRID_WIDTH; i++) maxRecentVals[i] = 0;
}

void loop() {
  // get radio input from transmitter
  if (radio.available()) {
    int anemometerVal = 77;
    radio.read(&anemometerVal, sizeof(anemometerVal));
    // convert raw analog value to wind speed in mph
    currentSpeed = map(anemometerVal, 77, 412, 0, 72);
  }
  // track daily peak speed
  if (currentSpeed > peakcurrentSpeed || millis() - peakcurrentSpeedTime > DAY_MILLIS) {
    peakcurrentSpeed = currentSpeed;
    peakcurrentSpeedTime = millis();
  }
  // get graph shift interval
  int potVal = analogRead(POT_PIN);
  // map to 1 minute - 10 minute range
  unsigned long graphShiftInterval = map(potVal, 0, 1023, 60000, 600000);

  int prevMotorAngle = motorAngle;
  // convert speed to angle
  motorAngle = map(peakcurrentSpeed, 0, 70, 15, 180);
  // only write to servo on angle change
  if (motorAngle != prevMotorAngle) servo.write(motorAngle);

  // shift graph
  if (millis() - loopStartTime > graphShiftInterval) {
    loopStartTime = millis();
    for (int i = GRID_WIDTH - 1; i > 0; i--) {
      maxRecentVals[i] = maxRecentVals[i - 1];
    }
    maxRecentVals[0] = 0;
  }
  // continuously update newest graph column
  maxRecentVals[0] = max(currentSpeed, maxRecentVals[0]);

  // clear LED strip
  for (int i = 0; i < GRID_WIDTH * GRID_HEIGHT; i++)
    colors[i] = rgb_color(0, 0, 0);

  // display bar graph
  isLineGraph = digitalRead(SWITCH_PIN);
  for (int x = 0; x < GRID_WIDTH; x++) {
    int val = maxRecentVals[x];
    if (isLineGraph) {
      int y = getYval(maxRecentVals[x]);
      colors[getLEDnum(x,y)] = getColor(y);
    } else {
      for (int y = 0; y <= getYval(val); y++) {
        colors[getLEDnum(x,y)] = getColor(y);
      }
    }
  }
  ledStrip.write(colors, LED_COUNT);

  // display instantaneous reading on 8x8 LEDs
  int tensIndex = (currentSpeed / 10) % 10;
  int onesIndex = currentSpeed % 10;
  displayImage(tensMatrix, TENS_IMAGES[tensIndex]);
  displayImage(onesMatrix, ONES_IMAGES[onesIndex]);
}

design files

With our meetings with Mark, we discussed what he would want or what he would benefit from the most. Mark enjoys to spend time in his kitchen and although he is in the process of making alterations to better fit his needs, something that he needs more help with is his oven. The criteria that Mark set out for us is that he needs something to put his baking trays on and off of/ in or out of the oven while also supporting the weight. Additional factors would be mobility and to be able to set it on top of a side table he has within his kitchen.

Physical Prototype

For the physical prototype we built something that would represent the form of the product as it needed to be a shape that would be able to fit under his over door while it was open, while also providing the height it needed to slide the baking trays on and off onto the oven trays.

Also has wheels to allow movement, there will be 4 on each corner. Do not yet know where it will stick out on sides or from the bottom.

Here is a video of if working more as a “looks like” prototype with it going up and down.

Process

Wiring and coding the linear actuator with two buttons

Linear actuator with battery

Drawings of how the linear actuator may work and the wheels

Rough sketch of marks wheelchair comparative to the oven and device

Measurements of the oven to make sure of physical prototype

Sketch on how device would be situated relative to oven through side view

Modeling out of foam core and other components.

Our Final “Works Like” Prototype

Discussion

Challenges

A challenge that we ran into while prototyping was discussing, should we simply build a prototype that looks like or have a scale for it? Through this there were certain measurements that needed to be looked back upon and other design considerations needed to be made so we went without having to do it by scale. Another challenge was also trying to find something to imitate the movement we were looking for while also maintaining the shape we wanted. For the wiring part, it was a bit difficult to handle the different voltage for the actuator.

Talk with Mark

When presenting the idea and prototype to Mark, Mark was glad that he could imagine it actually working for him. During the discussion, Mark brought up the same points that we were discussing such as material and mobility of the device. Also, the tray design was a factor that Mark was invested on.

In the beginning of the talk, we had all agreed on having the device be mobile on omni-directional wheels, and having the device be made out of some sort of metal or heat-resistant material to be sturdy. A point that we discussed a lot about was the tray part of the device, in whether it should have sides or not. At first, we discussed why sides might be more good than bad, but Mark had inputed he wished there to be no sides at all. So we discussed further, and decided to lead towards the direction of having a platform that wont slide of when needed to. This input helped us greatly into moving to a different design thinking that was more suitable for Mark, rather than just one of our ideas.

Future Plans

We plan on researching about more material as well as implementing Marks comments on mobility and having a surface that wont allow the tray to slip off. This will require to explore more about the form of the tray portion of the device. Another factor that we are thinking about is what kind of handle it should have along with the placement of various things such as controls on the body of the device. For future plans, more sketching and communication with Mark will be involved as well as another home visit to finalize dimensions so that we can think more about what materials would fit best for this device. Along with this, we ordered a part(a longer linear actuator), which will be considered within the sketches/dimensions as well.

In March 2019, our student group began working on the final project for our introductory physical computing course: to design a build a useful device for an older person.

Not just any older person. We were assigned to work with Mark: a retired lawyer living in the South Hills with a love for videogames, baking, his wife Renée, and his huge, adorable, couch-hogging dog. We set out to build Mark something, anything, that might make his day-to-day life easier or even just provide some short-term fun. Of course, before we could design anything for him, we needed to get to know him a bit.

Mark in his home office

The Team:

• Mark: the muse
• Stefan: a second year electrical and computer engineering student
• Nina: a second year design student
• Katie: a human computer interaction masters student

The Agenda

On the afternoon Wednesday 3/27/19, we arrived at Mark’s house for our first interview. We were armed with a list of questions (most of which we never made it through) and a pen and notebook.

Mark greeted us on his front porch and led us inside to his living room table, where he told us he often spends the majority of his day. Mark is bound to an electric wheelchair, which he expertly flies around his house in, and in this moment, docks next to the table.

Our Planned Agenda

We planned for things to not go as planned. The goal of this interview was for us to get to know Mark, and for him to get to know us enough to be be comfortable talking freely with us about his thoughts, feelings, and problems.

Our planned agenda (RIP)

What Actually Happened

After we had made it through our stuffy icebreaker questions, there was a long awkward pause as we all tried to decide how to start the real conversation. Nina saved the day by noticing that Mark had a phone case printed with the logo for Hearthstone, an online card game.

Videogames and Computer Use

What followed was a very natural conversation about videogames. The great thing about this conversation was how much we were able to learn about Mark by talking to him about games. We got a rough picture of Mark’s interests, likes, dislikes, and importantly, his motor skills and physical capabilities and limitations– all in a way that felt relatively conversational. Mark explained the symptoms of his acioscapulohumeral muscular dystrophy to us in the context and what he could and couldn’t do comfortably while playing a game:

Then we all moved over to Mark’s home office so he could show us his computer and give us a little demo of Hearthstone. At this point, Mark went into more detail about the games he watches on Twitch, and the games he would most like to play. We floated the idea of creating a customized game controller for Mark to use, but he was skeptical that it would be possible. We then headed to the kitchen to discuss some ideas for innovations that he thought would be more useful to him, and along the way he demonstrated how he controls his wheelchair for us so that we could better understand the limitations of his dexterity.

Baking and Kitchen Challenges

Mark loves to bake, and he cooks dinner for himself and Renée nearly every day. He lead us into the kitchen to demonstrate how he uses various appliances, and works on his custom wheelchair-height countertop. He told us that one of the biggest problems he has in the kitchen is that he is unable to take things out of the oven for a few reasons:

• The baking tray is too heavy for him to hold while it has anything on it
• The oven door blocks him from wheeling his chair close enough, so he has to lean forward to reach the tray, which makes it harder to lift
• The baking tray is hot, making it more difficult to transport to the counter

Mark next to his oven

Measurements of the oven, which is an ADA compliant model

We could tell it was important to Mark to be able to cook dinner as independently impossible, and that this was an important problem to solve. We quickly got to work brainstorming how we might solve the problem, with Mark contributing ideas and feedback.

Simple sketches of our ideas for solving Mark’s problem, which we showed Mark for feedback

A concept sketch for the device

Reflections

In the car on the way home, we went over our notes and debated which idea to proceed with. We all agreed that the meeting had gone well, and that we had lucked out getting to work with Mark. We decided to proceed with the oven idea because Mark had indicated that he preferred this course.

The meeting was difficult to start at first, but after trying to connect with him through Hearthstone it became a lot easier because he became very interested in talking about the game to us. In retrospect, if we had to do something differently it would be to maybe ask his wife more questions on what he is interested in or wants that he may not realize.

Additional Notes

Description: Bright Balance is like a game where you change the brightness through a pressure sensor and see the motor change the angle of the ramp according to the brightness level.

Images:

Process Images:

Schematic:

Code:

Bright Balance
Nina Yoo and Connor Maggio

Summary: The code below implements an FSR that maps brightness to an LED, which is sensed by a photoresistor that maps angle to a servo motor. There is also an exponential filter on the photoresistor values so the servo motor is normalized.

Inputs: 1 FSR, 1 photoresistor Outputs: 1 LED, 1 Servo


Collaboration: Robert Zacharias helped us with

using a power source for a few elements in our project.

He also helped us implement a transistor in order to

create a 12V switch.

Challenge: This project had more elements than any

previous project. Thus, there were a lot of wires to keep

track of and it was a challenge making sure everything

was in tact. For instance, at some point our servo was not

grounded correctly and it would not move.

Next time: It would be beneficial to use a smaller arduino

that we could fully house the project. In addition, I will

check the entire wiring of my projects before linking the

power to prevent burning out elements.




*/

#include<Servo.h>

int fsrAnalogPin = 0; // FSR is connected to analog 0
int LEDpin = 6; // connect LED to pin 6 (PWM pin)
int fsrReading; // the analog reading from the FSR resistor divider
int LEDbrightness;
int motorAngle;
int servoPin = 3; // pin the servo data line is plugged into
int photocell = A4;

float cur_reading;
float filtered_val = 0; // this variable, of type float (decimal), holds the filtered sensor value
const float PREV_WEIGHT = 0.85; // this variable, of type float (decimal), determines the previously filtered value's weight.
const float CUR_WEIGHT = 1 - PREV_WEIGHT;

Servo myLittleMotor;

void setup(void) {
Serial.begin(9600);
pinMode(fsrAnalogPin, INPUT);
pinMode(LEDpin, OUTPUT);
myLittleMotor.attach(servoPin); // set up the servo on that data pin
pinMode(photocell, INPUT);
filtered_val = analogRead(photocell);

// Print the intial value so we can see it
Serial.print("initial filtered value: ");
Serial.println(filtered_val);
}

void loop(void) {
fsrReading = analogRead(fsrAnalogPin);

// convert the integer value returned by analogRead 
// to a float by casting it
cur_reading = (float)analogRead(photocell);

// Calculate the next filtered value
filtered_val = filtered_val * PREV_WEIGHT + cur_reading * CUR_WEIGHT;

// Print the filtered value so we can see it
Serial.print("filtered value: ");
Serial.println(filtered_val);

// change the range from the analog reading (0-1023) 
// down to the range used by analogWrite (0-255)
LEDbrightness = map(fsrReading, 0, 1023, 0, 255);

// LED gets brighter the harder you press
analogWrite(LEDpin, LEDbrightness);

motorAngle = map(filtered_val, 50, 1000, 35, 120);
myLittleMotor.write(motorAngle);
}

Discussion: From the start we just started to brainstorm ideas that were interesting. We settled on Bright Balance and when we first began we started with a schematic giving the overall view of how it would work and what components it would require. However, though this step did help us begin the project, we did not really follow it as much when proceeding with our project. We turned to website tutorials to help us with our code as well as the wiring. It would have been easier for us if we had mapped or continuously updated our schematic as we went through the process.

The first component that we set up were the lights. At first, we had used the simple LED lights that were provided from earlier projects, but we needed something stronger. We then proceeded to go to a stronger LED, but that was also too weak. The professor then introduced us to an LED panel that had more than enough light, but required a 12 volt battery. We then proceeded to learn how to use bigger batteries and how we can connect it to the light source as well as the Arduino. It was helpful that the professor was with us during the wiring of the 12 volt battery to make sure everything went smoothly.

The next components we tackled was the pressure sensor and the photocell. It was easy to wire and code, but the data was noisy so we implemented “float” in order to filter out the data. This allowed for a much smoother response when printing the numbers/ looking at the graph.

After implementing the FSR and photocell, we converted that data into the motor. We used the filtered value that the photocell got from the light, which was read from the FSR, to then move the motor at different angles. We played with values of the motor to see how much angle it needed to move the marble around as well as keeping in mind the space around it. In the beginning, we had a small servomotor that was given to us in class, but then was introduced to a larger servomotor which required 5 volts. We broke the first motor, and after trying to rewire and code for a while, we realized we just needed another one.

Project Creator: Matthew Poage

Project Description: The LED umbrella is a customizable, blinking LED art experience. In my opinion it must be classified as art because it obviously cannot serve the purpose of a regular umbrella, as is would break (and possibly hurt you) the minute you took it out into the rain.

Materials needed:

• 1 x Microcontroller — Arduino Diecimilia
• 1 x Umbrella
• 1 x MIC2981
• 1 x Protoshield for Arduino with tiny breadboard
• 80 x LED
• 8 x resistors

Skills needed: Soldering, patience.

Project Link: https://www.instructables.com/id/LED-Umbrella-with-Arduino/

Response:

This piece caught my eye because unlike a lot of Arduino projects it doesn’t even pretend to have a pragmatic purpose, and is pretty clearly art. I am generally interested in wearables and costumes that incorporate electronics. This piece reminded me of costumes from Taylor Swift’s 1989 World Tour, designed by

Information on Taylor Swift tour outfit: https://www.instyle.com/news/taylor-swift-led-light-outfit-costume-1989-world-tour

This is a Arduino project that is a little tank that is designed to follow around a human. The Arduino is inside the tank and it controlled remotely using software on a Raspberry Pi.

The Raspberry Pi utilizes voice control to turn on/move the tank around. This project is more related to robotics as opposed to arduino, but it definitely makes good use of one to control servos to make the tank move.

Changes:

I think I would try to adjust the actual shape of the lamp so that the area spread of the light bulb is better/higher (from the top rather than a ring) in order to effectively use this like a lamp.

https://www.instructables.com/id/DIY-Heng-Lamp/

Project Title: Touchless MIDI Controller

Project Creator: Evan Kale

Short Description: A neat guitar mod for easily automating MIDI effects just by the wave of your hand. The idea is that there is a sensor inside the guitar body that detects the distance of your hand from the sensor. This project uses an Arduino Nano.

Response: As a guitar enthusiast, I appreciate this idea because it is a cleverly designed way to create new sounds. It also has a wide variety of applications as you can pick which kind of effect you would like to automate. To improve it, I would 3D print a more sturdy box to house the circuitry.

Project Title: Friend’s Light

Project Creator: Jihye Jeong, Heeju Kim, Youbin Nam

Response:This project was to create an interactive light, which had different outputs depending on both the light and level of interaction. They had created three different types of lights with little characters that went along with them. This project really intrigued me because they took the basic idea of light, but turned it into both a fun and almost living object. It’s one thing to simply create a product, but to integrate characteristic through light makes it that much more fun and valuable. What I may do to change it is to more clearly distinguish where the area that is supposed to be touched to turn the light on. Also, another note would be that if this was to be a product, I would have two modes where there was a simple light mode and an interactive mode this way, a person could have a simple light or have a character. The blinking of the light I understand brings life to the light bulbs, but practically speaking it would be nice to just kind of have a light since the form itself is already playful.

The arduino is hooked up to moisture sensors as well as tubes connected to water in order to auto pump water to the plants whenever the soil becomes too dry.

This project is really good for those who own plants and travel often or are forgetful. I further like this project since I am interested in agricultural automation with robots or embedded systems. I would improve this by having an interface to change moisture thresholds, or if it should be watered at specifics times. As well as infographs on when / how many times it has been watered.