Author: cllytle@andrew.cmu.edu

Realized this was stuck in my drafts since the assignment failed and was iterated into my second crit, the toaster.  Putting this here for posterity, but most of it is available in my Crit #2 – Grumpy Toaster.

For this post:

Continue reading “Assignment #6 – Toaster Precursor”

Problem: I’ve driven off after my friends have gotten stuff out of my car trunk but before they’ve closed it.  Thinking about this problem, its baked into my usual wait period when dropping someone off, the weirdness of hearing the thunking of the trunk when you’re not the one opening or closing it, and the fact that its all directly behind you.  Audio feedback would be a good way to help differentiate the trunk’s state when the driver is not the one operating.

Solution: More or less, different audio cues based on trunk status.  Traditionally there is a slap slap slap done by someone on the side of the car that means “you’re good to drive off now,” but this could be communicated better.  It is important this does not confuse the driver though, and should be noticeably distinct from any relevant “trunk open” or “door ajar” sounds that they may also be hearing during normal trunk procedures.  So, the system differentiated through kinetic sound when the drunk is closed, and more electronic audio when the trunk is ajar or being fuddled with.  The former is accomplished with a solenoid, and the latter, a normal speaker and ideally a weight sensor.

Proof of Concept:

Video + Code

Problem: Info monitors on the back of seats in airplanes provide nice-to-have information, such as total flight time, time till destination, and nearby locations on the ground.  These monitors are often visual-only, assuredly to not disturb nearby guests, but this makes them inaccessible to the visually impaired.  Converting this information to audio inside earbuds or headphones would be an easy and unobtrusive fix.

Solution: Because these headrest monitors already have audio jacks, reusing them to communicate this information would be easy using established screen reading tech or more elegant selection methods beyond a touch screen.  This introduces the difficulty of limiting audio, and potentially distracting from important announcements.  This leads to the second possible part of this assignment: making often garbled announcements more understandable for those hard of hearing with this audio jack.  More or less, this all boils down to an interruptable info stream of important flight info.

Solution: The solution is simple, two psuedo-threads of audio, switchable between with a button press simulating a pilot or flight attendant’s announcement.  The “information” like distance to destination is simulated with a tone from a pot right now, since I have no idea about playing samples yet.  Being interruptable lets any outside announcement alert the user to plug in and listen, actually give them the info, or more.

Files + Video

Problem: In contemporary cars, its common for backup cameras to have additional visual aids such as guiding lines and audio feedback such as a dinging that gets quicker the closer you are to an object.  Rarely, there are haptics in the seat as well.  These haptics are often bad, and may even be different based on where you’re sitting in the seat or how thick / how many layers are between you and the seat.  Further, its the same feedback no matter the road conditions, something drivers want to be aware of.

The Solution: First, the audio dinging does not really communicate exactly how much left you have to go, instead forcing drivers to rely on constantly slowing their pace to match it.  This can be useful in forcing more exact drivers, but can often be annoying.  It is also not available for hard of hearing drivers.  Therefore, a physical system that represents in miniature how far you have left to go would also be good.  This is constructed here as a rotating servo, ideally fixed to some reference point in the car like a level.

Second, road conditions are not communicated with the current back up camera system.  While it could be obvious to look outside the vehicle and see snow, ice can often be more inconspicuous.  To emotionally communicate this state, I thought it could be fun to have the backup device become “nervous” and shiver/shake, alerting drivers that something is off and they should be extra careful.

Proof of Concept: Primarily, a distance sensor driving a servo, with additional input from a potentiometer approximating “iciness” of the roads.  The servo rotates similar to a weather vein based on distance to and from whatever object is in the rear, and is more or less “nervous” (see video) based on how bad the road conditions are.  These are, respectively, a fixed amplitude and a variable frequency of a sin function.

[Fritzing coming later today]

Video + Code

Problem: I cook almost exclusively on cast iron.  It takes a while to heat up, but retains that heat super well.  There are often times where I have to step away from the skillet for a while to let it cool down.  I also moved in with new roommates recently who promptly touched the handle when it was still scalding hot.  It is difficult to tell how hot the pan is without holding the back of your hand up to it; there is a small visual indicator of heat coming off it, but it is minute.  The primary feedback is physical. A further issue is our individual heat tolerance–I can take and wash the pan / reseason it in the sink when its hotter than when my roomates can or want to.  It is impossible to tell just how hot it is without actually touching it, thermometer excluded.

Solution: Basically, heat indicators built into the pan.  This would allow a user to know at a glance if the pan were hot or not, instead of using their hand. This would be accomplished by a thermometer testing the surface of the pan.  Because cast iron pans heat fairly evenly, it has a fairly large margin of error in terms of where its sampling from.  No idea on how thermometers actually work so that may be wrong.

The embedded LEDs range from green to red, fairly common stop and go indicators. Red fairly clearly means hot when used on cookware as well.  I see the lights lighting up linearly from Not to Hot based on temperature, so only 1 LED would be in use if it were cold, and all in use when Hot.

I think this would at least ease the use of ambiguously hot pans, in a similar way to the audio feedback project by another student from Assignment #2.

Proof of Concept:

Chance Assignment 4

Fairly straightforward code that lights up LEDs in a row based on how large a value is read from a pot, acting as a thermostat stand in.  I am pretty sure I fried one of my pots but this does work fine, so hope for that demo in class!

// Chance, Assignment 4. Not really digital states, but approximations of analog ones

#define Serial SerialUSB

const int buttonPin = 2; // momentary button
const int greenLED = 13; // green LED
const int green2LED = 12; // green LED
const int yelLED = 11; // yellow LED
const int yel2LED = 10; // yellow LED
const int redLED = 9; // red LED
const int red2LED = 8; // red2 LED
const int potPin = 1; // analog 1

float LEDcount = 6.0f; // should just cast this later but fine to be declared as this
int startPin = 8;

void setup() {
// initialize the LED pins as an outputs:
  for (int i = red2LED; i <= greenLED; i++) {
    pinMode(i, OUTPUT);
  }
// initialize the pot pin as an analog input:
    pinMode(potPin, INPUT);
}


void loop() {
  // read in the pot / thermo stand-in
  int val = analogRead(potPin);
  Serial.println(val);

  for(int i = LEDcount - 1; i >= 0; i--) {
    if(val >= (((float)i / LEDcount) * 1023)) digitalWrite(i + startPin, HIGH);
  else
    digitalWrite(i + startPin, LOW);
  }
}