Get Me Coffee
Sana Shepko and Sean Harkin
A messaging system intended to notify members of a group, class, or office space when someone is going to get coffee, in case others want coffee too. This system would be materialized in the form of a small device in the shape of a symbolic coffee cup (perhaps a keychain) with a toggle and two LEDs. The toggle, when moved to the side of the green LED, can have two meanings: either, that you are going to get coffee; or as a response to the message that someone is getting coffee, indicating that YES, you want coffee. When moving the toggle to either side, it lights up the other person’s device. When it’s moved to the side of the red LED, it indicates the response to the message “do you want coffee” as NO, you don’t want coffee.
We envision this project as being used for groups larger than 2 people; especially if used in an office or studio setting, it could save time rather than having to message a large group.
Talked about our initial idea. We are planning to build a message notification system that would communicate who is getting coffee and how many people would like coffee in a group. Basically, the way it would work is that each person (whether in a class, or in an office setting) would have a small button device with an LED.
We are planning to build this in a similar way to the Amazon Dash (see below).
There are two parts of the device: an LED button and a small LED light. Each of these components will signal different messages.
If person A is going out to get coffee and wants to let others know they can get coffee for them too, they press their LED button. Person A, who sent out the initial signal, would see that their LED button fades High-Low. Everyone else in the space will receive this message through their LED light flashing consistently.
If, for example, person B wanted to confirm with person A that they wanted coffee, they would press their LED button which thereby would turn off the flashing LED on their device but turn on the LED button light, which would remain on until person A turns off their outgoing signal.
When person B presses their LED button, and if, for example, person C and D also press their LED button, person A will receive a notification that allows them to know how many people would like coffee. Person A would receive a signal in their LED light; the number of times the LED flashes is the amount of people who want coffee. This LED flash would be on a loop, and would be a series of flashes which would stop, and then repeat.
This is our initial idea and starting point, and we will see how it develops!
– begin to explore code with featherboard
Planning on 3D printing our devices. Some sketches:
The original idea was design the casing to be small enough to be attached to a key-chain or be attached to the side of your work monitor. However, due to the size of the Feather and the battery, we realized very quickly that this would not be possible. If the product was to be developed further, we would plan to design and build a custom board which would shrink the overall size of the product.
For the battery we chose a lithium-ion polymer 3.7V 1000mAh. We chose this as the voltage required to power our relatively simple device could very easily be done with 3.7V, and would not require the use of transistors which may be required with larger voltage batteries. Since the LiPo batteries are also rechargeable, both Sana and Sean would be able to reuse the power-source for future projects.
We revised our sketches to these designs:
Thinking about our coffee theme and the color palette we might use.
Also talked to Nick during class about our current plan and our progress.
Some interesting points that came out of this:
- Although we were originally planning on having only one button, it seems that this complicates our project, since there would be more than one meaning of button push (for example, an initial button press would mean “I am getting coffee” and essentially functions as an ask to other people with the device; BUT there is also the second button press that others would send back as an answer to the ask, which would function as a “yes” or “no” to the “I am getting coffee”. SO, that being said, Nick initially suggested modes but it seems that we won’t be able to achieve this easily. THE EASIEST SOLUTION: include, along with the button, some sort of toggle or switch that would function as an answer to the ask. One value of the toggle would be a yes, and one value would be a no.
- This being said, we will now have the following components: The feather, an LED button (to be purchased today), an orange LED, and a toggle, and the main functions of this Get Me Coffee device would be to ASK and ANSWER.
- Another problem: Sana’s button does not seem to be sending to PubNub consistently. Hopefully this will not be a long term issue!
Sana testing a tactile switch code:
Got tactile button to somewhat work:
Ok, so we have gotten some things to work, which is a great sign!
For documentation purposes, we have decided that both of our
myval1 = button switch
myval2 = toggle switch
This way when we are subscribing to each other’s messages we will be able to know that yourval1, when writing functions or whatever, will always refer to the button value, and yourval2 will always refer to the toggle value.
We have had to move from our original idea of having both the button and the toggle, to just having the toggle as the main communication component. We managed to print our casing today, however there were some issues. To begin with, the parts were designed using Autodesk’s Inventor software. When exporting as .STL files for printing, they seemed to scale in an unpredictable manner, meaning that we had to very quickly resize the components. Unfortunately this meant that the fit for the case and lid was slightly tighter than designed. With some extra fabrication we were able to compensate for this. The other issue was that due to time constraints, the casing had to be sent for printing before we were able to build the full circuitry, meaning that we underestimated the height which would be required for the internal components. This required us to rethink the casing.
We also have found that although we originally only wanted to have the message to be sent to PubNub ONCE on toggle switch, it turns out that having it constantly publish the toggle state was a more achievable and realistic way to go about the code.
Sana came up with the idea of using actual coffee cups to contain the internal components.
Unfortunately the product was not fully functional for the critique, though we have included video of when we had both devices communicating successfully (the video can be found here: https://www.dropbox.com/s/buww21m29l2080w/WorkingVid.mp4?dl=0 )
As you can see, the product was working as intended (if a little slow due to the connectivity issues working with PubNub). The issues arose when we began soldering the components to the protoboards. Unfortunately we never found the exact cause however Sean’s board would not communicate after being soldered. The obvious cause was a short in the soldering, however we could not find a problem under examination. We remedied this issue by removing the components from the protoboard and using a mini-breadboard – allowing us the flexibility of a more mobile device, while ensuring functionality.
The next issue came the next day when we realized we would have to upload the code to the devices at the same time to boot the sequence. If we did not upload the code at the same, or if we disconnected the boards from our computers, the devices would stop publishing/subscribing from PubNub. Unfortunately we realized this issue the morning of the presentation and were unable to correct this before presentation.
Figuring out how to use the tactile switches:
Some more information on the Amazon Dash buttons:
Everyone loves coffee. The idea for the initial concept came from months spent in the studio with everyone grabbing coffee for each other. Many times we would be travelling to the studio and would think about messaging our team and asking if anyone wanted a coffee, however this requires the time it takes to send a message. It would be far more convenient if we were able to send out a signal letting our peers know we were getting coffee and enable them to ask us to bring them one with 1 click of a button. The initial concept also included a p5 page which could track how many times individual users had been for coffee so the group would know was slacking on coffee-retrieval responsibilities.