Cocktail Maker: Software Architecture

As mentioned earlier the hardware side of the cocktail maker will be controlled by a Raspberry Pi with a user interface running on an Android tablet. The Raspberry Pi will make interacting with the valves simple via it’s builtin GPIO ports while the Android interface will mean we can have a nice touchscreen based client.

For ease of development the two devices will likely communicate with a RESTlike API. Luckily enough I’ve recently been working on a major plan at work involving a substantial bit of work to do with RESTifying our current API. In both cases this will probably be the popular conception of REST, ignoring the Hypertext As The Engine Of Application State (HATEOAS) constraint.

There is actually two mostly distinct sets of resources that the server will have to provide for the client. The majority of the resources will be a generic collection of cocktails with pictures, descriptions, recipes etc. Then there will also be the resources specific to the cocktail maker, list of available ingredients to allow filtering the cocktails, calibration information¹, current processing state, starting and canceling the current task. The first of these sets is also very widely applicable, anyone and everyone² could be interested, including other people building automated cocktail makers.

For that reason I’ve decided to separate the cocktail database from the main cocktail maker server. I haven’t been able to find any appropriate databases existing so I’ve taken it upon myself to create the first online crowd-sourced cocktail database. I’m hoping to have a very basic version up within a few months, the work on it will obviously be sporadic seeing as it is a part-time after work project. Actual time frame will probably depend a lot on how much stuff I get up to in America, if I find there’s not really that much to do in Austin I may end up spending a large part of most evenings working on it.³

As part of developing this database I do want to experiment with HATEOAS, especially HATEOAS as implemented via JSON. There are some really good examples of how to implement it in XML using the rel attribute for metadata about the resource. There are also a few libraries that do attempt to implement it with JSON, but just from what little I’ve seen of the libraries something seems off with them. Once I get some time to research the current libraries, I’ll try and write a post about what it is that bugs me about them and how I’m going to try and avoid the issues in my implementation.

In the meantime we’ll probably have a simple hardcoded list of cocktails to use. Worst case we’ll just be stuck drinking Tom Collins’ continuously.⁴

---

1. Especially if the pipes flow rate is affected by viscosity, sugar syrup can be a few hundred to over a thousand times as viscous as water. ↩

2. Above the legal age for alcohol consumption in their country. ↩

3. What’s the chance of that in The Live Music Capital of the World. ↩

4. I could think of much worse things in life than a nigh unlimited supply of automatically prepared Tom Collins’ *Cough*kscrew . ↩

Cocktail Maker: Overview

So far these are the components we have:

Ten metres of 10mm silicon piping (food grade¹) and fifteen solenoid valves.

The current plan is to have all the spirits and mixers in upside down bottles above a bench, tubes will come down from these bottles, pass through the valves then all come together in some form of tap above where you place your glass. The valves will be controlled by a Raspberry Pi with an Android tablet hooked up to allow selection of which drink you want.

It will of course look much fancier than this sketch, personally I’m thinking some nice dark stained wood with brass fixtures, some form of laser cut drip tray grate with an icon representing the limitless potential of this device, and of course only top shelf liquors allowed.

Designing it this way means there is very little mechanical design that needs doing, really the most complicated part will be ensuring the bottles are held securely while being easy to replace as they get empty.² Which is all for the best, while we have 3 mechatronics engineers on the project only one has done any hardware work since leaving uni.

The biggest disadvantage of this is the limitation of only working with liquids. It would be amazing if we could have ice and garnishes added automatically, but (at least for the first iteration) we are going to require the user to manually add these.

Since we won’t have much mechanical design to do we can instead spend longer on the software side. If we get a really nice client designed for the Android tablet, complete with all the background info about cocktails and the ability for the user to adjust the strength on the fly, then this will be re-usable if (once) we build a version 2 with more capabilities.

---

1. Supposedly. Not really sure how much you can trust that sort of claim from cheap online stores. ↩

2. Although it would be nice if it detected the bottles getting empty and warned the user of this, or even hook it up to an online store and get it to order new bottles automatically. ↩