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
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
Step 4: 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
Step 5: 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
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
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
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
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
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.
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.