Here’s the code I uploaded to our microcontroller:

int vibPin = 13; // vibrating motor is connected to digital pin 13

int setDebugMode = 2; // connect pin 2 and - pin together to turn on debug mode

int debugValue = HIGH;  // a variable to keep track of when we’re in debug mode or not

int incomingByte = 0; // for incoming serial data

void setup()

{

Serial.begin(9600); // opens serial port, sets data rate to 9600 bps

pinMode(vibPin, OUTPUT);

pinMode(setDebugMode, INPUT);

digitalWrite(setDebugMode, debugValue); // defaults debug mode to HIGH (off)

}

void loop()

{

debugValue = digitalRead(setDebugMode); // check to see if we’re in debug mode

if (debugValue = LOW) {

digitalWrite(vibPin, HIGH);         // turn on vibration motor all the time (so the rest of the circuit can debugged)

}

else {

if (Serial.available() > 0) {

// read the incoming byte:

incomingByte = Serial.read();

// say what you got:

Serial.print(“I received: “);

Serial.println(incomingByte, DEC);

if (incomingByte == 108) {

// vibrate w/ a novel pattern

digitalWrite(vibPin, HIGH);

delay(500);

digitalWrite(vibPin, LOW);

delay(500);

digitalWrite(vibPin, HIGH);

delay(1000);

digitalWrite(vibPin, LOW);

delay(200);

}

else {

digitalWrite(vibPin, LOW); // turn the vibration motor off all the time

}

}

When the microcontroller was connected to the computer through the breakout board (USB), we could control the vibration motor by entering different keys into the serial monitor. The same effect could be achieved by connecting the microcontroller to the Bluetooth SMIRF module instead, setting up a COM connection to the Bluetooth module, and connecting to that COM port within the serial monitor.

Just thought I’d post in case someone is looking for how to do the same thing!

So, the system did not work as we had hoped it would. Bluetooth is so flaky!!

We also experienced some current difficulties. We read on Leah Buechley’s blog that we should “… avoid powering a tri-color LED and vibrator motor at the same time if you can.” which is exactly what we were trying to do (*plus* a bluetooth antenna). Reprogramming our system so that the light was never powered at the same time as the vibrator motor really helped to reduce the fluctuations in vibrator motor strength that we had previously experienced.

All in all, a bit disappointing since it didn’t seem like there was any “real” roadblock that should have set us back — we knew how to do everything we needed to do - it just… wasn’t working :(

More later on how the system turned out!

Our bluetooth modem arrived today! It is this one, from SparkFun electronics. I can’t wait to get started programming it since we don’t have very much time before the demo on Friday. First, I’m going to try and get it to communicate with my laptop wirelessly. Next, we’re going to look into connecting it to a mobile device like the iPhone or Google Android. Finally, (I doubt we will get this far), I’d like to connect the host to the Google Maps API so that it can issue instructions based on the next turn. Time to get back to work!

.

Ishii and Ullmer’s paper described three prototypes as concrete examples of Weiser’s ubiquitous computing vision. Unlike Weiser though, they envisioned displays that would contain output not constrained to the traditional icon/window desktop metaphor seen on most of today’s GUIs. They also included physical objects, called phicons, that were coupled with digital information and interacted with the prototypes, which was not part of Weiser’s original vision.

Their vision seemed much more tangible than Weiser’s vision, although Weiser (probably intentionally) did not detail exactly how a user would input information to the tab & pad devices. The transBOARD can also display digital information, which Weiser’s “smartboards” could not. They also introduced collaborative elements, by allowing multiple users to control the system.

I think the most similarity between the two visions was in the idea of capturing people’s ability to subconsciously glean ambient information from the environment with.  I mentioned the example of the woman monitoring her coworker’s work in my summary of Weiser’s paper. There are many types of information where the most important thing to know about it is not an absolute value, but if it changes a lot, and background/peripheral outputs are perfect for this. Most of the information for our bicycle system is like this. Absolute values for traffic, road slickness, temperature, and air pollution are not near as important as radical shifts. The example outputs they use, raindrop noises and reflected light patterns, would be difficult to adapt to a bicycle though.

Mark Weiser presents an attractive vision for the future in his paper “The Computer for the 21st Century” where computers are location-aware, invisible, portable, and embedded to enhance many everyday objects. His main opinion is that “machines [should] fit the human environment instead of forcing humans to enter theirs”.

As I read this paper, I was struck by how in some ways, we’ve made a lot of progress towards his vision, but in others, very little. I feel like we still use a “complex jargon that has nothing to do with the tasks for which people use computers”, unfortunately. We also don’t have a great way for locating computers in physical space. GPS is becoming more popular, but it simultaneously seems like overkill (using satellites when surely something simpler, and on earth, would do), and unreliable, or with highly variable accuracy at best.

As for the ubiquitous network though, I think we are moving steadily towards that, with a combination of cellular data networks, wifi, ethernet, and bluetooth. The functions described by tabs and pads seem to be well met by smart phones and e-readers (and netbooks?).

I love the idea of shrinking a program down to a “tab”. It actually reminds me of mainframe computers — it seems like a similar idea would be necessary, where programs, and potentially files, are stored in one central space and can be accessed by many external terminals.

I think the value of the interaction described here: “She can’t see what any thing says, but she feels more in touch with his work when noticing the displays change out of the corner of her eye…” is more valuable than most people realize. Similarly, the idea of people being isolated in front of their computers all day is more harmful then most people realize, and that is a situation that is prevalent today.

Finally, when Weiser talks about “find[ing] the designer’s name even though it did not interest you at the time” make me wonder if perhaps, in my bike project, we could guess the user’s destination depending on the route and direction they start biking in, rather than forcing them to input it. This would be less obtrusive, and more “invisible”. It’s a bit of a catch-22 though — our system can’t provide as much valuable information to you if you’re going someone you’ve been before!!

• Incorporate road slickness output in handlebars instead of on dashboard
• Get rid of wind and temperature widgets because they’re distracting
• Use bluetooth functionality of iPhone
• Add heart rate (taken from helmet)
• Distinguish before/after use cases with iPhone (since a lot of information only needs to be presented once
• Consider how a dashboard might detract from the experience of biking
• Make collaborative
• Use audio signals
• Include a “missed turn” button

My team is going to meet this week and talk over what suggestions we want to incorporate into our next version of our prototype.