Project Logs

Collapse

• The Hardware Story (Part 2: Suck It Up)

  Tyler • 08/17/2016 at 15:35 • 0 comments

  After the many hours that went into the initial hardware design, it became clear there was more work to be done. What followed was several weeks of contemplation, reflection, and mourning, but then it was time to suck it up and try again with a new approach: a vacuum system. (pun intended if you couldn't tell.. I'm guessing you could tell... I hope you could tell....)

  The vacuum idea was different than most drink machines I've seen others make. It would address the problems from our initial design, but there were new challenges that needed to be addressed, mainly with how to plumb the system. Keeping in mind goals for the system to be reasonably low-cost, and simple, yet functional and compact led to the following design:

  To pour a drink, there are essentially 4 steps, using 3 different flows or "cycles". These cycles are identified in the diagram as the "Fill Cycle", "Drain Drink Cycle", and "Drain Rinse Cycle". The different cycles represent different states of the blue solenoid valves, creating different flows in the system. To elaborate, let me walk you through a complete drink pouring process.
  

  Step 1a: (Fill Cycle)

  In the Fill Cycle, arrows having a light orange color indicate the flow. (Arrows with two colors apply to two different cycles.) To start the process, the vacuum pump turns on, and the valve connected between the rinse tank and the hose extending to the top of the mixing chamber opens. This creates a vacuum inside the mixing chamber. Notice that the vacuum hoses from and to the rinse tank do not extend down into the rinse solution. The rinse tank is a solid sealed container, so the vacuum created in the rinse container is also created in the mixing chamber. With the vacuum established, the individual ingredient valves can be opened to bring the ingredient from the bottle into the mixing chamber. The ingredient valves are opened one at a time, and timed according to a calibration factor to retrieve the appropriate amount.

  Step 1b: (Line Purge)

  After the ingredients have been sucked into the mixing chamber, there is still some liquid remaining in the line. To make sure it is included in the mix, the line is purged by opening the AIR (Line Purge) valve at the end of the ingredients valve array. A side-effect of this is that the air purging the line bubbles up through the mixture in the mixing chamber, effectively mixing the ingredients. Once the line is purged, the valves are closed and the vacuum pump is shut off.

  Step 2: (Drain Drink Cycle)

  The Drain Drink Cycle is fairly simple. In this cycle, the DRAIN DRINK valve opens at the bottom of the mixing chamber, and the AIR (Chamber Vac Release) valve opens, releasing the vacuum in the chamber and allowing the mixed solution to dispense into a cup. After a timed amount, the valves then close.

  Step 3: (Rinse - Fill Cycle)

  At this point, the consumer is happy and has left the drink machine. You might be thinking... "Like, ewww now the next person will get any leftover liquid in the mixing chamber contaminating their drink." This is a downfall to this vacuum system approach. The solution, is the rinse cycle. This step is the same as Step 1, but instead of ingredient valves opening, only the RINSE valve, second to last in the ingredient valve array, will open. This will flush the line and fill up the chamber. Then, the line will again purge like in Step 1b, and the air-bubbles will help agitate the rinse in the mixing chamber.

  Step 4: (Drain Rinse Cycle)

  Finally, the last thing to do is empty the rinse solution from the mixing chamber, but we don't want to simply spit this stuff out of the drink faucet! In the Drain Rinse Cycle, the vacuum pump activates, but instead of the vacuum being routed to the top of the mixing chamber, the CHAMBER DRAIN (DRAIN RINSE) valve opens, along with the AIR (CHAMBER VAC RELEASE) valve. In this way, the rinse solution in the mixing chamber is vacuumed back into the rinse chamber for re-use. Now, obviously there may still be some drops of rinse solution...

  Read more »

• The Hardware Story (Part 1: Fail)

  Tyler • 08/08/2016 at 18:53 • 0 comments

  For The Open Bar hardware design, we started off with a simple approach. For the first iteration of the project, the idea was to use a CO2 tank to pressurize the ingredients that would be dispensed. Each one of the ingredients would have 2 hoses -- a pressurized hose from the CO2 tank regulator going in, and a hose from the bottom of the bottle going out to a solenoid valve. From the valve, another hose would go to the faucet of the drink machine. In this way, each ingredient would have a separate path, and to add more ingredients you just needed to add a valve and hose.

  To control the valves, we tried using a cheap ESP8266 wifi module. In our application, the ESP module implemented a simple HTML server. The user GUI, implemented on another device in a web browser, would send a HTML "GET" request, passing a GPIO number and a number of milliseconds as parameters. The ESP module would then activate the specified GPIO for that amount of time. Each GPIO was connected to a TIP120 NPN Power Darlington Transistor through a resistor. The transistors provided open-drain current sinks, acting as switches for the solenoid valves. The valves were powered by a 12V rail supplied by an AC/DC power adapter.

  Although the ESP worked as a controller, there were several limitations. One limitation was the number of GPIOs available. There were about 10 usable GPIOs on our ESP board. This gave us 10 possible valves for ingredients. There was a catch, however. On power-up, some of these GPIOs have specific pull-up and pull-down requirements. This led to some funky valve activation occurring anytime the ESP module was restarted. The solution was adding a switch to the 12V rail supplying the solenoid valves. This way, the valves could only be activated when the system was "armed" (when the 12V switch was turned on).

  To dispense an amount of an ingredient, the valve would be activated for a calibrated amount of time. In theory, this approach sounded easy and simple to implement. This was the approach used in this initial setup:

  The following photos are a quick overview of our first design. Our initial concept was to retrofit a kegerator. The kegerator would serve as the storage place for all the connected ingredients. This is the kegerator with a small ball-lock type keg inside, popular with home-brewers:

  The first thing we designed was a 3D-printed spout that could lock into the hole already manufactured into the kegerator top. Here are some pictures of that:

  This picture shows a close-up of the piece of the faucet which held the end of the hoses in place. They were simply pushed into the holes, which were slightly smaller in diameter. The piece itself fit into notches inside the end of the faucet.

  The ESP8266 and TIP120s were wired up on a small proto-board that was mounted at the rear of the faucet:

  The valves were all mounted inside the kegerator on the ceiling for tube routing convenience:

  As you can see here, the tubing was a tight fit to get through the hole with the wires:

  We chose to also have beer cooled in our kegerator. Since beer isn't mixed with anything we didn’t need to have beer dispensed automatically by the machine. For fun though, we made it dispense with the push of a button, where the button directly activated a valve for the keg. Here are some photos of the installation of the button. The 3D printed part was simply spot glued to the small red push-button I had lying around:

  Here we have the CO2 tank and regulator. The pressure lines to the different ingredients were simply 'T' connections to the main output:

  And then the main trouble we encountered, the bottle stoppers, are shown here. They were first 3D printed, then covered in a food-safe acrylic for strength and to make them air-tight. The outer surface had a molded covering of food-safe silicon to try and seal the 4PSI of pressure provided by the CO2 tank.

  Here is the stopper before being coated in acrylic. The center, smaller barbed fittings are for the liquid and run through the piece...

  Read more »

• A Collection of Web Pages

  Dillon Nichols • 04/21/2016 at 20:41 • 0 comments

  This project has a collection of web pages where each handles a different part of the project. The main page links to the five pages that I have created. The “drinks” page simply calls the drinks API and lists all of the recipes that are stored in the MongoDB database. The “add-drink” page allows anyone to create a new drink to store to the database. When the station is known, the available ingredients are listed, so the user can just enter how many ounces of each they want in their drink and then save it. The “station” page lists some information about the station from its database entry. The station’s local IP address, all the valves and what they contain, along with the amount left in that container (to be implemented) and a multiplier (necessary for converting ounces in a recipe to time to pour that amount) are all listed.

  The “pour” page lists all available recipes. Clicking on one shows the required ingredients. The user can then pour that drink from this page. If any ingredients are unable to be added automatically by the machine, an info box will pop up asking the user to add the remaining ingredients.

  The “queuer” (a play on words for queueing a drink and using a QR code) page is the main interface option for patrons. They would scan the QR code on their wristband to open this page. The URL in the QR code will be appended with a unique ID that will behave as the user’s identification. If this is the first time the user has scanned their code, a helpful message will be displayed explaining how it works. Then the user can choose their drink, view the ingredients, and if they wish, store it to their QR code’s ID. The webpage will then update with the selected drink. The user will then go to the station and scan their QR code. The station will parse the ID from the QR code and query the database to find the selected drink. Then it will determine the recipe and pour the drink. The user could scan their QR code at the station again to pour the same drink, or scan it with a phone to choose their next drink.

• Software Interface Decisions

  Dillon Nichols • 04/21/2016 at 20:34 • 0 comments

  Early on, it was apparent that this project would require some sort of GUI so that the user can easily select a drink. We wanted something mobile-focused so that users can select their drinks from anywhere in the bar instead of waiting in line at some sort of kiosk. We decided to create a website instead of an app for a few reasons. Number 1, it’s a lot easier to get started using a website over an app. In our case, we have a QR code that, once scanned, loads the website directly, and uses a URL parameter to distinguish between users. We didn’t have any use cases that required the phone’s camera or bluetooth access, so we did not require the use of an app. This increases the user’s ability to get in quicker, because they do not need to get into their app store and download it first. Number 2, it’s a lot faster to implement changes and have all users up to date. This is really important in the early stages of development. And lastly, it will run on any device. Be it an android phone, iPhone, or tablet or any size.

  I started on the software side of things at the beginning of 2016. I’ve had an interest in web development for a long time but have never created a large project on my own. I heard good things about the Angular framework, so I decided to use that. At the time, Angular 2.0 just started in beta so I thought it would be interesting to begin a new project with that. I followed the 5 min quickstart and tour of heroes tutorials and they were very helpful in getting started. I loved using TypeScript since it is a compiled language, which is very uncommon in web development. Atom is a great IDE with support for TypeScript. After completing the tutorials, I started on my own project. You can find that code on my personal Github. The branches on that repo are mostly the previously mentioned tutorials, but some of my new code is in there too. At the time, I was frustrated with the online support for Angular 2.0 and could not get very far with the project because I was so new to web development as a whole. I guess that is what happens when you decide to work with a project that is in beta. Due to my frustration, I made the switch to Angular 1. There are almost an endless amount of tutorials and help online for this framework, so I had no trouble progressing at a fast pace. I now feel comfortable enough with Angular that I think I could go back and work with Angular 2 on my next project, but I have no reason to change The Open Bar’s interface from Angular 1 to 2.

  The source code for The Open Bar’s interface can be found on github. I started with the full MEAN stack because a coworker was using it for a project and he was very fond of it. Although I started by using Express for my page routing, I moved away from it and started using Angular’s built-in routing about halfway through the project. Right now it’s a Frankenstein of routing methods, but it would be too much work for hardly any benefit to move to exclusively using one. In the beginning when I was using express, I was also using Jade for my templating. I have a pretty extensive knowledge of HTML so learning a new language to do something that I already knew slowed me down. All of the recent view code is written in HTML and I have no reason to go back to Jade.

  I also knew early on that I wanted to host using Heroku while the app was in development. I love that it uses a very similar command line interface as git, so I don’t need to learn something new to get working. I’ve also set my Heroku up so that it watches for changes in the master branch of the git directly and will automatically pull in changes as soon as they are available. This also enforces the use of branches in git for developing new code. I’m using a mLab MongoDB heroku add-on for my database storage. It allowed me to get started very quickly without any knowledge of databases. It’s a lot more powerful that I need for the simple databases that I have, but I appreciate how it’s linked to heroku.

  Originally I was...

  Read more »

View all 4 project logs