Introduction: Smart Cup

Picture of Smart Cup

We're prototyping a smart cup for bars and parties. The cup warns the host when the person drinking from it becomes a liability by observing signs of risky behavior. For example, an alcohol sensor notices when the person drinking from the cup is likely to become intoxicated. An accelerometer detects when the cup has been dropped.

The smart cup is designed to help bar and party hosts focus their attention on the guests who are most at risk. We aim to prevent undesirable behavior, which is much better than having to "clean up" after it occurs. Our smart cup is a first-class IoT citizen. Each bar or party host has an account on our Web server. Hosts communicate their risk profile to our server by setting the thresholds that they consider warning signs of risky behavior. Each cup has an identity, is associated with a host, and uses the host's settings to signal risky behavior.

The following steps describe how we built the smart cup, and help explain what you see in the demo.

Step 1: Requirements

We used the following components for our smart cup:

* Intel Edison with Arduino board

* Grove - Starter Kit Plus, Intel IoT Edition: touch sensor, LCD grid backlight, 9V battery adapter, 2 LED lights (red and blue) and sockets (you'll need two kits, or you'll need to buy a second LED light socket)

* Additional Grove sensors: Alcohol Sensor v1.2, Water Sensor v1.1

* Standard 9V alkaline battery

* Plastic Cup

* Heroku.com account for deploying the Web application

Step 2: Assemble the Sensors

Picture of Assemble the Sensors

Our code assumes that the sensors are connected to the board as follows:

* Alcohol: A0

* Gyroscope: A3

* Touch: D5

* Water: D4

* Blue LED: D3 (also, the longer pin on the LED goes in the + pin on the LED socket)

* Red LED: D2

* LCD: any I2C port

The entire sensor wiring is expressed in one place in the source code, so it can be easily changed.

Step 3: Program the Edison Board

Picture of Program the Edison Board

The code we ran on the cup is in the GitHub repository below. We ran CoffeeScript on node.js.

https://github.com/pwnall/edison-cup

You'll need Intel's XDK for the Edison board, which you can download here.

https://software.intel.com/en-us/html5/xdk-iot

Step 4: Test the Board

Picture of Test the Board

Our board software includes a Web server that can be used to test the board's hardware. Before boxing up the board, you should make sure that all the sensors and LEDs respond as expected.

To test the sensors and LEDs, try the following URLs. Replace pwnison1 with your board's name, which can be set by the command

configure_edison --name

http://pwnison1.local:8010/blink?color=red&seconds=2

http://pwnison1.local:8010/blink?color=blue&seconds=2

http://pwnison1.local:8010/blink?color=green&seconds=2

http://pwnison1.local:8010/lcd?color=ff00ff&line1=Hello&line2=World

http://pwnison1.local:8010/s/alcohol

http://pwnison1.local:8010/s/touch

Step 5: Box Up the Board - Version 1

Picture of Box Up the Board - Version 1

In Intel's Boston IoT Roadshow hackathon, we used a box for bank checks, because that's what we had lying around that was roughly the size of the Edison board.

The board fits very tightly vertically, which is good news for us -- it won't move around. It has some room on one of its sides, and we used that to store the battery.

We used transparent tape to keep things in place, and we used nail scissors to poke and cut holes in the box. We taped the gyroscope under the board, and we taped the battery near the end of the box. All the other sensors lie outside the box.

We made a special hole for the water sensor, because we're constrained by its short wire. The sensor needs to be in the cup, as deep as possible, so it'll trigger when the cup is empty or almost empty. Asides from that, we have one hole for the LEDs, and one hole for the other sensors and the LCD screen.

We cut out a strip of the box so we'd have room to plug in the battery right before our demo. We didn't know how long the Edison board could run on a 9V battery, so we used the USB power cable throughout the testing phase. We switched to battery power right before we started the demo.

Step 6: Box Up the Board - Version 2

Picture of Box Up the Board - Version 2

Our second prototype uses a significantly sturdier cup, and a Seven-Select Rice Cracker Zen Mix plastic case.

We went to Seven-Eleven with our board, and picked the box that fit it the best. I really like the fact that the plastic case is transparent, as it makes for much cooler pictures than the bank cheques box. We happened to have a suitable cup at home, otherwise we would have probably also picked up a large Slurpee cup while at Seven-Eleven.

This time around, we taped the battery on the outside of the box, so that it can be easily removed and replaced. We were slightly scarred by our IoT roadshow demo, where we had the battery inside a well taped box, and we had to pray to the demo gods that we wouldn't run out of juice during the demo.

We taped the LED lights close to the bottom of the cup. This is closer to the final product vision, which has the LED lights embedded in the cup's bottom, so that the bottom glows blue or red discretely.

Unfortunately, the water sensor is not on the bottom of the cup. This is a direct consequence of the fact that we're using a bigger cup, and the length of the sensor's wire became a bottleneck. In the final product, we envision having the sensor very close to the bottom of the cup, so it triggers when the cup is almost empty, and the bartender should consider offering the customer another drink.

WARNING: we found that it is really important to tape the water sensor's wires tightly, as shown in the last picture. We didn't do that well during the IoT roadshow demo, and water got into the taped area, which caused the sensor to get flakey right before the demo.

Step 7: Deploy the Web Application to Heroku

Picture of Deploy the Web Application to Heroku

We needed to have the Web application for the cup running somewhere in the cloud, because the demo location had a pretty paranoid WiFi setup, where we couldn't connect to devices on the network. So, we had to point the Edison to a location in the cloud.

Heroku made the last-minute testing and debugging really nice, thanks to the command below.

heroku logs --tail

We'll open-source the Web application code soon. We're still figuring out how to deal with the API keys that are embedded in it. In the meantime, we'll describe some parts of it.

Step 8: Cup Enrollment and Management

Picture of Cup Enrollment and Management

A demo can get away with targeting a single Edison board. However, our system is built for a future where millions of smart cups will be connected to our servers. To that end, we had to come up with a way to associate cups to users.

We implemented a solution very similar to Youtube's big screen device activation. When a board connects to the SmartCup server the first time, it gets a 10-digit code associated with it. The code is shown on the LCD display, using an alert background. Any user that has a bar set up can claim the cup by entering its code.

When a cup is enrolled, we generate a default name for it, using the Edison board's serial number. To make tracking easier, cup owners can assign names to them. Each cup displays its name on the LCD display. We are still evaluating the cost and weight implications of having LCD displays on the final product. We would like to have an LCD display on the cup's bottom, and the Sensei gaming mouse makes us think that it's possible.

Lastly, we have included a locating feature, to facilitate the cup inventory process. When a cup's owner has trouble finding a specific cup, we can help by causing the cup's LEDs to blink for an extended period of time.

Step 9: Bar Rule Management

Picture of Bar Rule Management

In a demo setting, it is tempting to hard-code some rules and just get the LEDs blinking. Once again, we chose hard mode, and instead implemented a UI that allows each bar owner to set up rules that reflect her risk profile.

Our user interface is a highly simplified version of If This Then That (IFTTT). The bar owner can get notifications based on the value of each sensor attached to the cup. The notifications can be discrete blinks of the cup's LED lights, or more obtrusive e-mails and text messages (SMS).

In our example, we have set up a notification that triggers when the cup detects that its patron has had too much to drink. That's a high-liability event, so we cause the cup's red LED to blink, and we also receive an e-mail. We have also asked the cup to notify us when it is empty and it is held by a patron. In that case, we blink the cup's blue LED, to grab the bartender's attention.

Step 10: Putting the I in IoT

Picture of Putting the I in IoT

The Edison's powerful hardware allowed us to use cutting-edge Web technologies and make our Smart Cup a first-class citizen of the Internet of Things.

The Smart Cup uses a REST API to register itself with the server and submit sensor updates. However, in order to get timely updates from the Web server, we forego the standard HTTP protocol, and instead we use a polyfill for the W3C Push API, based on WebSockets. The polyfill includes a node.js server that can be deployed on Heroku with one click, and a JavaScript client library that is intended to polyfill the Push API in a browser environment.

Thanks to the Edison's ability to run node.js code, we were able to use the client library on the Edison board. We use push notifications to tell the board when it is enrolled by a user, and when its name is changed, so it can update its LEDs.

High-tech bars and party organizers can keep a mobile device, such as a tablet, behind the counter, and get an overview of all the cups enrolled in the bar. Our Web UI targets both desktop and mobile browsers, and uses the Push API polyfill mentioned above to update key parts of the UI, such as the "Recently triggered sensors" list. This way, the Web UI updates immediately when a cup senses a potential liability, empowering our users to respond quickly and prevent a potential problem from escalating.

Step 11: Polish and Demo

Picture of Polish and Demo

Comments

Mr Toss (author)2015-03-16

Do you believe me if I tell you I've also done this before?

crank_girl (author)2015-03-16

Interesting concept. How would you ensure that someone with a neurological/physical condition would not be classified as exhibiting risky behaviour? For example someone with parkison's that has shaky hands or a dyspraxic person that might drop their cup/bang in to things.

tomatoskins (author)2015-03-16

This is so cool! I love the idea of a cup that monitors the user and their behaviors! Has there been any field testing of the cup?

VictorC6 (author)tomatoskins2015-03-16

We built and demo-ed this at Intel's Roadshow in Boston. It works as well as you'd expect a proof-of-concept prototype to work :)

About This Instructable

1,353views

11favorites

License:

Bio: I'm a PhD student in Computer Science at the Massachusetts Institute of Technology. My research centers around secure computing architectures. I am very interested ... More »
More by VictorC6:Smart Cup
Add instructable to: