VK-01 Off-World Bartender

The year is 2040, and you could use a good drink. People say the best drinks are made in the off-world colonies, by robot bartenders programmed only to serve the elite. Lucky for you, one of those robot bartenders never made it off-world. If you can make it past its security system, you’ll be drinking like an outer space aristocrat.

That’s the concept behind the VK-01 off-world bartender, my Blade Runner-inspired cocktail machine. This machine was my second entry into the Cocktail Robotics Grand Challenge, an annual event in San Francisco where machines are judged on their ingenuity, popularity, and the quality of their drinks.

It’s one of my favorite events. It’s like a Maker Faire without the kids, where every exhibit dispenses alcohol. Sadly, this year it was canceled for COVID. But by the time I heard about the cancellation, I was too deep into this build to give up. I figured, at least it’ll make a good Instructable! So here we are.

If you’re crazy or stupid enough to remake this particular cocktail machine, here’s what you’ll need:

• Raspberry Pi 3B (Not the B+. For some reason the HelloDrinkbot image works best with the 3B.)
• Raspberry Pi A+ (or whatever you have around, just not a Zero)
• Raspberry Pi 7-inch touch screen
• Parallax RFID Reader (Serial, not USB)
• Adafruit Feather Huzzah with ESP8266
• ¼ sized Perma-Proto boards x4
• Adafruit ItsyBitsy 32u4 - 5V 16MHz (x2)
• 4-channel DC 5V Relay Module
• 12V DC Peristaltic Pump 3mm ID x 5mm OD (x8)
• DC Panel mount female power jack
• Silicone Tubing
• Barbed Fitting for 3/16" Tube ID (McMaster# 2808K105)
• 4x4 Matrix Keypad
• NeoPixel Ring - 24 RGBW
• NeoPixel Ring - 16 RGBW
• NeoPixel Stick - 8 RGBW
• Zippy-style Momentary micro switches (you only need two)
• Adafruit DC & Stepper Motor HAT for Raspberry Pi
• Dupont wires
• Micro USB cables (3-5)
• Power strip with USB
• Audio Amplifier Board
• Speaker
• M2.5 Stainless Steel Socket Head Cap Screws Kit
• Paint
• Wood glue
• Ready Patch
• 12v 5a power supply
• Scrap wood
• Booze

All you need to build a cocktail machine is a way to automatically move fluid from one location (bottle or mix) into another (a cup, or sometimes right into someone’s mouth).

Typically, the most reliable way to move fluid is a pump. 12v peristaltic pumps like the one shown here are common and affordable option, though I’ve also seen people use submersible pumps like these for quickly moving juices or thicker, chunkier stuff you don’t want getting clogged in a tube (though I can’t vouch for them being “food grade”).

You pair up your pumps with a micro-controller of some kind (Arduino typically) and some kind of motor breakout board to help drive the 12v motors when they get directions from the micro-controller.

With a little code to determine how long the motors run, along with some buttons for the user to press, and some creative design, you’ve got yourself a cocktail machine.

My first machine was based on this 1-pump design by John Park. For something more challenging, there are plenty of instructions for multi-pump systems to try on online, including the PiMixMakr, and Arduino Uno Drinkbot Bartender by Ted Kinsman. For another spin on a 1-pump machine, check out Anouk Wipprecht’s Cocktail Dress.

After creating my 1-pump machine for my first year competing in the Grand Challenge, I knew I wanted to move up to a multi-pump system so that I could offer more drink options and let the machine do all the mixing work.

When I learned about the Raspberry Pi-based Hello Drinkbot project by Rich Gibson, I jumped in with both feet. In hindsight, I’m not sure I would recommend it for others. But once I got used to its quirks and limitations, I stuck with it because it was familiar.

The other thing I learned from my first cocktail machine is that no matter how great your drink tastes, what people remember most is how your machine looked and the experience of using it. If popularity is a factor in winning the competition, I needed a better looking machine, and I needed help to make that happen.

Having attended many of these events (and more Maker Faires than I can count) I don't think it's controversial to say that many engineers have a blindspot for aesthetics. If a project is both beautiful and well-engineered, it’s most often the result of a group effort where at least one person was tasked with making sure the end result would photograph well.

If you want to stand out at an event like this, outsource some help to define how your project should look. For this machine, I did this right out the outset, and it was invaluable in helping to guide design choices every step along the way.

My help came from my friend Jim Burke. I told him my concept, and some technical details like the number of pumps (7 at the time), the size of the screen, and the rough dimensions I’d be working with.

I also had an idea that I’d have an animatronic head that looked at customers as they approached to give them a sense of an added layer of security they had to overcome. It didn’t make it in the final design, but I still want to add this later.

After some feedback, Jim refined his sketch into a more concrete blueprint I could start basing my dimensions on.

With a project this complex, I sometimes get paralyzed wondering where to start. Making a full-size cardboard mockup was a great way to unblock my momentum. Having a full-size reference also came in handy quite often when I later created a 3D model of the design in Tinkercad.

With a cardboard mockup you can explore all kinds of design considerations before wasting any valuable materials.

Can a cup fit in here?

Is the machine too tall/short?

Does the screen need to be more angled back/forward?

Fixing it now helps to avoid bigger problems down the road.

Once I was feeling confident with the general design, I moved on to planning out what interactive elements were needed to pull off the concept.

Let me take a minute here to briefly explain the importance of interactivity in a cocktail machine. No one wants to simply come up to your machine and press a button. The very act of automating the human process of making a cocktail robs the user of a familiar ritual.

Part of your job as a cocktail machine engineer is to use interaction design to replace that ritual with something clever. I didn’t understand this with my first machine, and so every time someone came to order a drink, they pressed a button and we just stood there together in silence as the machine slowly pumped out their drink (in my defense, it was a very tasty drink).

I think it’s also important to consider any feedback the machine provides as a form of interaction. If a light starts to blink, or a pump starts to spin, or a sound starts to play, the user takes that cue as a sign of progress and is able to stay engaged.

For this machine, the interaction comes in four main ways: instructions provided on the screen, using a keycard to bypass security, placing and removing a cup on the tray, and entering an order number on the keypad.

In addition to that, feedback is provided by way of lighting changes, music, video dialog, pump motors whirring, and even the clicks of relays at each stage of the drink process.

Once I had a handle on each interaction element, I then broke those elements down into distinct systems that I could develop on their own. Unfortunately for me, every one of these systems was something new for me to learn. The systems for this machine include:

This needs to allow people to enter in a number to trigger their order, just like a vending machine. To complicate matters, it needs to send that drink order to the Hello Drinkbot software running on the Raspberry Pi 3 that controls the pumps. There’s probably a way to do this using serial communication over USB. The only way I could figure out was to communicate wirelessly. More on this later.

I needed a way for the machine to be able to tell when a cup was placed under the dispenser spout, and when it was removed. Initially I had a lot of lofty ideas on how to achieve this with distance sensors (IR, ultrasonic, break-beam, I tried them all). None of them proved reliable when you account for the fact that there's no guarantee what kind of cup or glass you’ll be using, or how light or dark the environment will be. A lot of these sensors work fine with opaque glass, but not clear. Some work well in bright environments, but not in dark ones.

When in doubt, keep it simple. I went with a switch under a 3D printed tray. Provided the glass had at least one ice cube in it (which this drink benefits from), even the lightest plastic up is heavy enough to trigger the switch.

When the user approaches the machine, they are asked to scan their ID card (which I provide) to start. Again, I had an ambitious ID that I would have multiple ID cards, and the user would have to figure out which one would work. Or maybe every user would get a unique ID card so I could store their preferences for future orders. All of that would be possible, but require another computer to store and manage a database and frankly it just seemed too complicated for me. To keep it simple, I adapted a sample script that blinks the card reader’s internal LED when any RFID card is detected.

There are a few ways I could have gone with this. First, I could have redesigned the Hello Drinkbot/Bartendro interface to better match my cyberpunk aesthetic and just have customers use the touchscreen UI that's already there. This was the approach I thought I would take initially.

Second, I could have created a series of custom-designed web pages that run locally on a Pi and include buttons for specific drink orders. Those buttons could send commands to the Hello Drinkbot server and trigger a drink to be poured.

Third, I could have used some kind of kiosk software to create a hardware controlled slideshow of looping instructions. I even considered using Unity on a PC to create a kind of 2D game with custom hardware controls. Again, simplicity brought me to MP4Museum, a bare-bones kiosk video player software that the Pi automatically boots into. By hooking a switch to a few pins on the Pi, you can advance through the videos one by one. It presents its own design restriction, but it’s one I was able to work with.

As I mentioned in the beginning, I decided on using the Hello Drinkbot software as the brains of my machine, which is a fork of the Bartendro project. With it I can configure what liquors or juices are connected to what pumps. I can send it instructions on exactly how much to pour of each ingredient. And best of all, because it acts as a local area network, I can configure everything over a web interface.

It’s fickle to configure, and if you’re a developer who’s comfortable with Raspberry Pi and Python, I encourage you to contribute your time on helping to improve the software. There’s some seemingly simple things to iron out that we just don’t have the expertise to do.

That said, once you get used to the quirks, it’s powerful software that eliminates a lot of the headaches of configuring an Arduino-based machine over the long-term.

Another aspect of the software I enjoy is that you can send drink orders to it using web-based REST commands. This means that any device connected to the hellodrinkbot network can send it a drink request in the form of a URL.

For example, this URL (http://hellodrinkbot.local/ws/drink/12?booze14=75&booze11=75), tells the software to dispense 75ml of the ingredient associated with ID number 14 (let’s say vodka) and 75ml of the ingredient associated with ID number 11 (orange juice). These ID numbers are visible in your ingredient database, which you can browse and edit using the Bartendro web interface, found by pointing your browser to 10.0.0.1.

Anyway, I could write a whole other Instructable just on Hello Drinkbot. Long story short, the ability to request drink orders using URLs turns out to be one of the most reliable ways to get drinks made with the software, and it opens up all kinds of custom interface possibilities. You could make your own local HTML site, with a drink menu that sends URL requests. Or, like me, you could set up an IoT micro-controller to send drink request URLs when the correct sequence of keypad keys are pressed. More on that later.

With a sense of all the pieces I needed to consider, and an idea of the shape and features of the machine, I went to task creating a working prototype with scrap wood, cardboard, coroplast, craft plywood, and various bits of hardware.

I also had several individual 3D printed elements I knew I needed to start designing, including the RFID card reader, the drink platform/tray, the dispenser, and a panel to hold the keypad along with a few LEDs to light it up.

This is a prototype that evolved over many months, and there was nothing precious about it. Anytime I had 30 minutes to a hour to spare at the end of a day, I would screw or glue or carve some new feature into it. The goal was simply to get the shape roughly right, and then start in on making it functional with electronics.

Three things I learned with this particular prototype build:

-Years of hoarding of scrap wood and craft materials can serve a purpose.

-Though I’d probably not use them on a final build 1-1/4 inch drywall screws are a great size for attaching panels to clumsy 2x4 framing. They can also set flush, so you can cover them with more material (like cardboard) without them sticking out.

-Cables pre-wired with Dupont connections are great, and you can chain them together for longer connections. But at some point, you just need to invest in a crimper and kit to make your own custom lengths of Dupont cables. This is the one I got, and it allowed me to tame a fragile rat’s nest of cables in mismatched colors and awkward lengths. Level up!

Let me say up front that for all my years playing around with Arduino and Raspberry Pi, I am a circuit bender at heart. My instinct is always to take what someone else has made and poke it and transform it until it works for my needs.

My code is a hack job, and some of my circuitry methods are unconventional, but I’ve done my best here to accurately represent what I did. If you’re able to improve upon anything here, I’m thrilled. Just please share the results so that I can improve as well.

I’ll also add that I’m aware of some of the approaches I could have taken to consolidate some of this into a neater design. Instead of using multiple boards for specialized tasks, it would certainly be possible to have just one or two Arduino boards juggle multiple tasks by using different states. For me, going with multiple boards was the path of least resistance (no pun intended).

Here’s the complete overview of the wiring diagram. Don’t worry, I’ll break down each section in more detail.

First let’s go through the Arduino elements. These are like the nervous system for the machine and they all link up to a bank of relays responsible for advancing the directions on the screen. So when a cup is placed, an Arduino triggers a relay, which advances the screen to the next instruction. When a drink number is selected with the keypad, an Arduino triggers the relay, advancing to the next screen. When the cup is lifted, Arduino, relay. When the RFID card is scanned, Arduino, relay.

It’s not the most sophisticated way to do things. There’s nothing preventing people from taking things out of order and typing in a drink number before they even place a cup. It would be much smarter if each stage of the machine were aware of the other, and only allow certain actions to take place in a specific sequence. But, I’m not yet smart enough to figure out how to make that happen. I am smart enough, however, to include a reset button for when things go off the rails.

So let’s go though these in the same sequence a user would. The first thing they’re asked to do is to scan their off-world ID card to initialize the system. This means popping the RFID card into the reader and removing it.

The code for this action is the simplest of all the Arduino sketches. Pin 10 is connected to the relay and is set low on startup. The code looks for the RFID card, and when it finds it nearby, it sets pin 10 high, waits a little bit to give the relay enough time to react, then sets it low again and waits a long time to prevent the relay from being triggered multiple times if someone leaves the card in too long.

Even though we don’t have many things wired to the board’s pins here, I’m using the power rails to send power out to a lot of stuff just because it’s convenient. I’m also powering this board from the nearby USB port on the Raspberry Pi 3.

Next up we have the board that handles the drink tray interaction. This part needs to trigger the relay to advance the instructions when a drink is placed, start a light show in the dispenser LED ring above the cup, and then trigger the relay again when the cup is removed.

One tricky aspect to this one was finding a way of getting the relay to trigger both when a cup is placed, and when it’s taken away. After a lot of trial and error, I used the “StateChangeDetection” example to make this work.

The other challenge was figuring out how to get a lengthy LED animation sequence to trigger when the cup is placed, but not have its timing beholden to the length of the loop. I still don’t really know how to explain this one except to say that some LED animation sequences do better than others when it comes to their own distinct timing and loops. After a lot of experimentation, I have a better grasp on how they tick, but not enough to competently explain it here.

In terms of wiring this board, most of it is called out in the code. For power, I’m pulling in the 5v and ground from the Feather Huzzah, and plugging that into BAT and GND here. I’m also extending a ground wire from this board to the RFID board. In general, we want all of the components, from the Pi boards, to the Arduinos, to the relays, connected to a common ground somehow. I think the diagram contains all of these ground connections, but when in doubt -- ground it.

The last of the Arduino boards is the Feather Huzzah used for the keypad. It’s unique because it includes an esp8266 Wi-Fi chip that allows it to send URL requests to the Hello Drinkbot server running on the Pi 3.

Adapting an example code to make the keypad work should have been relatively easy. Passcode lock projects, jukebox projects, vending machine projects, all employ the same concept. Still, for the life of me, I couldn’t find an example that got me within my comfort zone.

Humbled, I reached out to my friend Fuzzywobble, the genius behind the 90 from the ‘90s payphone project. He was able to get a keypad passcode structure in place that I dressed up with Neopixel animation code and HTTP GET request code that I think I adapted from this guide. It’s a bit of a blur now.

The code essentially has 4 acceptable 4-digit passcodes at the outset and connects over wi-fi to the server you define (in this case, your Hello Drinkbot server). Even though there are letters on the 4x4 keypad, I could only get numbers to work. When you successfully enter one of the four passcodes, the URL associated with that code is sent over to the Hello Drinkbot server, triggering it to start making your drink. It also sets off a Neopixel animation that starts with the lights turning green, indicating a successful passcode. If a code is unsuccessful, the LEDs turn red.

For each drink code, you can adjust the length of the LED animations using the numbers within the parenthesis next to the animation. This way, once you know how long it takes for that particular cocktail to pump out of the machine, you can use the numbers to tailor the animation sequence to that particular drink.

For example, when the first drink is successfully entered, the lights turn green: colorWipe(strip.Color(255, 0, 0) , 50);

Then they pulse white: pulseWhite(40);

Then they do a crazy rainbow lightshow: rainbowFade2White(2, 20, 15);

In each case, the numbers in the parenthesis can be adjusted up or down to tailor them. The definitions of each of these numbers is made clear further down in the code where the specific animation sequence lives. For example, the definitions for the rainbowFade2White are:

(int wait, int rainbowLoops, int whiteLoops)

So in the above example we’ve requested a wait time of 2, 20 rainbowLoops, 15 whiteLoops. Anyway, just play around with it until you have a timing that makes sense for your cocktail.

What a tangent! Don’t let me do that again.

Now, there are two Raspberry Pi computers in this build. As you already know, the Pi 3 is running the Hello Drinkbot software and acting as a server that the keypad communicates to to send drink orders. In the circuit diagram, I represented this Pi as the Adafruit DC Motor Hat, since that what's doing the heavy lifting as far as the rest of the electronics are concerned.

So, that blue motor hat in the bottom left is the Pi 3. It’s connected up to the eight motors, along with a separate 12v DC input used to power the motors. You’ll also notice a lone ground wire sneaking off to connect up to the Arduinos. I don’t think it matters that it connects to the Feather Huzzah specifically, but just make sure everything gets grounded.

If this isn’t your first time with the Adafruit DC motor hat, you’re probably wondering, “How the heck did he connect 8 motors to a hat designed for 4 motors?”

Because the pumps are only ever meant to run forward, the Hello Drinkbot software treats the reverse direction of each pump as a separate pump. It’s a terrible idea if you’re using this hat for a robot that needs to turn or reverse, but for an array of pumps it’s pretty smart.

Now for the other Pi (the Model A+ or whatever you have aside from a Zero), there’s some notable use of the board’s GPIO pins. I even wired up the RUN pins on this for a quick way to reset the menu.

To understand why all these GPIO pins are in use, let’s spend a minute talking about the MP4 Museum software image that’s running on this Pi.

MP4 Museum is a rock-solid kiosk video player. The software itself is read-only, so there’s no danger corrupting the image when you switch off the power. It boots fast, and then immediately gets to work playing back the MP4 video files you have stored on a connected USB thumb drive in numerical order, looping around when it reaches the end.

The software is really designed as a set-it-and-forget-it solution for museums or artists who want a Pi to boot into a loop of video files that play non-stop until the power is switched off. It’s infuriatingly uncomplicated. Its only allowance is that it allows you to connect up a button or switch between a few pins on the Pi that, when activated, will skip to the next video in the list.

For our purposes, we’re using the MP4 Museum’s skip function to advance through the on-screen instructions. The skip function is what we have connected to the relay board. Each relay is doing the same thing -- momentarily connecting the Pi’s GPIO pins in a way that will skip to the next video.

The videos I have loaded up on the Pi’s thumb drive have the following titles, which are hopefully self-explanatory:

01_place_glass

02_order_screen

03_pouring

04_remove_drink

05_scan_card

Aside from the “Now Pouring” video, which plays for just 10 seconds before automatically rolling into the remove drink screen, most of the other videos are more than 10 minutes long. The “Scan Card” screen, which ideally is the screen that greets new users, runs for around 15 minutes -- but could just as easily run for an hour.

This is all to say that the time you need for each user interaction is simply built into the length of your video. If I was installing this somewhere unattended, I would probably include some kind of motion sensor to shut the MP4 Museum Pi down after 15 minutes of solitude. But for the context of the Cocktail Robotics Grand Challenge, there’s always an operator nearby to guide or reset the machine. Unless something goes horribly wrong, most people aren’t going to start with their drink order and abandon it midway through. So as long as the greeting video is significantly long, the rest of the videos needn’t be more than 5-10 minutes long to minimize the chance of them rolling into the next video prematurely.

Sure, doing it this way is riskier than using a system that clearly understands where the user is in each step of the ordering process and waits an infinitely long time for each step. But there are some awesome advantages to using MP4 Museum too.

For you, the clearest advantage is that replacing the menu UI is as easy as cutting 5 new videos in whatever software you have handy. There’s no coding required to replace the on-screen prompts -- just drop 5 videos on a thumb drive and you have your UI.

And because each screen is a video, you can use whatever font you like, you can make it animated, you can add sound, you can run ads -- it’s all just a video playlist, sequenced by Arduinos. Cool, right?

For what it’s worth, I deliberately built my system around an older version of MP4 Museum (version 2, I believe) because it doesn’t have a logo image on the boot screen. Initially I thought that the Pi running MP4 Museum would reboot with each drink order, and I didn’t want users to see the logo each time.

The downside of using this older version is that the circuit needed to skip between tracks is a little more complex (shown in the diagram). My version is even a little stranger, as I found the resistance in the circuit wasn’t sufficient with all the other power draws in the system. For whatever reason, a 33k resistor and a 10k resistor in parallel did the trick. Again, I’m not smart enough to understand why, but my circuit bender instinct found a solution that worked.

Bottom line, if I had to do it again I would use a newer version of MP4 Museum and the simpler circuit for advancing videos, now that the system is designed to loop and not reboot. But, I got in too deep and didn’t feel like rebuilding what was already working.

For the 3D printed elements, I’m embarrassed to admit how many revisions I had to make for all of these -- but I learned so much along the way.

One of the first elements I created was the drink platform, which needed to act as a momentary switch and also include some lighting. I knew it needed to hinge like a clamshell, and my first designs were more like a box or giant button that you’d place your cup on.

I actually kept this design until pretty late in the build. Ultimately, though, it just looked out of place. Looking around for alternatives, I came across this footswitch design by the awesome Ruiz brothers. I rebuilt the shape from scratch and made mine much larger, but you can tell that they’re related.

I’m really proud of how this design evolved. My favorite aspect of it is the two-piece, snap-in lid. This allows me to print the topmost piece in clear filament so that the light from the LED ring inside shines through. The filament hinge is also a handy feature.

The hardest part of designing a drink platform like this is getting the balance just right. Unlike a footswitch, the whole thing is being triggered by an empty cup. You need to lid to be light enough for the switch to disengage when there’s no cup, but heavy enough that an empty cup (with an ice cube or two) offers just enough force to trigger the switch.

The smart thing to do would probably be to introduce some standard size of spring as a counteracting force. My compromise was to use two of the same type of microswitches side by side. Only one is wired up. The other is just there for extra support, helping to lift the lid back up when the cup is removed. You can’t argue with results.

Another design I’m proud of is the dispenser, which gathers all of the various tubes coming off the pumps, and also includes a cavity for a 16-LED neopixel ring.

I borrowed a few existing designs to make this happen. The first is this design from dwmartin805 on Thingiverse, which makes up the main nub that bundles the tubes together. I elongated the back of that design to extend it out further, shaved off the sides, and created mounting holes that work vertically. I also sliced it in half horizontally and sandwiched in this Neopixel ring holder by oshoham, which perfectly encircles the arrangement of tubes.

By slicing it, I was able to do the same two-tone trick I did with the platform, allowing me to print the bottom half in clear plastic so that the LEDs should shine through. It’s not a snap-together design, though. You have to glue this one together, which makes more sense since there’s a greater chance of liquids leaking in. I also included a space for the ring wiring to pass through, up and out.

My other 3D designs aren’t quite as noteworthy. I made a panel that surrounds and holds the 4x4 keypad in place. I will say I’m as surprised as anyone that I was able to get the fit so snug, especially on those rounded corners, all just using Tinkercad.

Built into this, above the keypad, is an area that holds an RGBW Neopixel stick along with space for passing the wiring up and out. A clear cover pressure fits over the space for the LED stick.

Lastly, there’s the holder for the RFID reader. I made this to sorta look like a floppy disk drive. It holds the RFID board horizontally so that the card passes over it when you push it in.

The problem I had to solve on this one was building in some elements that would help to guide and gently stop the card when you pushed it in -- similar to how a real card reader feels. I played around with different shapes to help pinch the card on all sides and arrived at the current design.

To provide force from the bottom of the card, I made a panel that sits on top of the RFID reader and mounts using the same mounting hole pattern. As a bonus, it helps protect the reader from wear and tear. I should also mention that it’s worth sanding down the wedges a little to make it easier for the card to slide in without catching.

In order to get a high quality final build, I knew I was going to need some help from friends. Whether that meant designing the body for laser cutting, or milling, or 3D printing, I first had to create a dimensionally accurate digital representation of the machine that I could hand over to someone.

Having a new enclosure designed from laser cut parts seemed like the right move. My friend Jordan Bunker was able to take the 3D model I provided into Fusion 360 and create a series of interlocking panels he could cut on his laser cutter on 3mm ply.

His laser cutter isn’t huge, so there were a lot of panels to match up and glue together. The good news is that the design should be easy for most people to adapt to their own laser cutter.

I don’t think Jordan knew it was my birthday when he texted to let me know the panels were all cut and test fit, but it was the best present I could have asked for.

I probably spent a month of afternoons obsessively glueing, sanding, painting and reinforcing all of the panels before I even started in on moving the electronics over from my prototype. In hindsight, a lot of that was wasted time, but it was still a useful exercise in playing with finishing techniques.

One of the awesome, but tricky aspects of the laser cut design is that Jordan used living hinges to round off the corners and create the rounded drink tray. With the thin ply, these hinges were extremely delicate and needed reinforcing, plus a lot of patching and sanding for a smooth look.

I don’t have the perfect advice to offer on how to properly finish this enclosure. In fact, I still feel like I’m working on it. Ultimately, it took a ton of Titebond 3 wood glue, some strategic reinforcing with scrap wood, some generous layering of Ready Patch, many coats of sandable filler primer, and a lot of sanding in between.

[image of finished assembled panels before transfer]

Even after all that, once the guts from the prototype were moved over, new holes had to be drilled, some panels began to sag or expand, and there was a lot of repair and improvisation. Had I known how much I would have to continue repairing the finish of the panels once the guts of the machine had been over, I would have spent less time trying to get it perfect at the outset.

The weekend of the Cocktail Robotics Grand Challenge was almost here. Granted, the event had been cancelled at this point for Coronavirus concerns, but I’d spent most of the year considering it my deadline and it seemed useful to see it through.

Removing all of the pumps, wiring, circuit boards and hardware from my prototype was a huge pain. In the heat of passion, there were aspects of the prototype that were done in a way that were not easy to undo (E6000 is one hell of a glue).

With everything out, the harder challenge was delicately placing these same components in their shiny new home. The prototype was built like a tank, but the new enclosure felt more like a Fabergé egg.

Of all the reinforcements made on this enclosure, the most critical is finding a way to support the neck that the pump array sits on. The way these pumps cantilever out over the tray is an affront to gravity. With some small scraps of plywood and a length of cherry hardwood that I think was part of a bed frame, I was able to glue and screw and clamp together something sturdy. Nothing pretty, but it works.

I’m not sure if it was the smart thing to do, but most of the electronics (the Pi 3 and the two Arduinos) are up in the top section with the pumps. I did this because I’m not as afraid of the pumps leaking as I am of a spilled drink. There’s lots of room inside the base, but a few spilled drinks could find their way in and gunk things up.

The other Pi and the relay board are tucked away in the kiosk section. This is another area that could use some spill-proofing. I’m thinking of adding a 3D printed hood that fits over the whole kiosk bit. If liquid finds its way to the bottom lip of the screen, that’s okay, I just need to prevent it from getting in through the top. Plus a hood may help conceal that I’m using one of those ubiquitous Pi screens.

There are a few extra holes I drilled in the enclosure. I made 8 holes in the front and back of the pump array, allowing the intake tubes to pass through to bottles in the back. This might be a bad idea, and it definitely means that I need to find a way to regularly open and close the back panel for maintenance and cleaning.

I drilled hole in the back of the tray area (tucked away out of sight) so that I could run wires from the platform unit up to the Arduinos. Also, a hole out the back of the base was needed to run out the power strip cable, along with the 12v adapter cable that I route to the back of the pump array.

Like most projects, the end never feels like the end. Not only were there features that I wasn’t able to work in by my deadline (the animatronic robot head, for instance), but there are plenty of tiny improvements I can already see making.

The first improvement I’ll probably make is to add a steel frame around the base with angle stock. Not only will this make the base more durable, but it will eliminate the need for me to glue in the bottom panel, which I’ve been putting off. It will also just look cooler, and allow me to weld on other attachments down the road (like the robot head, or a stand for a small TV monitor).

I’d also like to pay more attention to the RFID card. This is supposed to be the elusive key to the whole system, but right now it just looks like a basic white RFID card. Maybe I could encase it in something, or make a bunch that I print different labels for and give away as a souvenir.

I’d like to add some texture and greeblies to the whole thing. I sorta like the smooth, high-end look I wound up with, but it’s way off the mark from the concept design aesthetic. I’ve already started creating 3D printed panels that could be glued or screwed around the base. There’s also the 3D printed hood idea for the kiosk that I mentioned earlier.

The menu screens! Though I enjoy my touch with the Orson Welles Japanese whisky commercials, I really feel like I could come up with some better video prompts.

My hope is to work with an animator or graphic designer to hone these screens into something cooler. Maybe I could even remove the text completely and have every screen be an animated visual prompt of what to do. Or maybe a combination of visual prompt with Japanese-only text, to complete the aesthetic.

For audio, I’m really not doing much right now. I have a subway jingle for the Shibuya train station playing at the beginning, and then the original Orson Welles commercial audio (which is already starting to drive me crazy). I think it would be neat to have some Japanese language prompts for some of the screens. Better yet, with two channels of audio, I could have a male voice in one channel and a female voice in the other, and you could use a switch to select one voice or the other.

Finally, there’s some more general improvements I should make for splatter and spill resistance. Even after making just a few test drinks, I can tell that little bits of drink splatter out of the cup while the drink pours out. Inevitably, a drink will spill on this thing too. Whatever planning I can do now to channel moisture down and away from the electronics and nooks and crannies will help improve the machines lifespan (and good looks).

Cocktail machines don’t have to be complicated. I just happened to make one that became more complicated than I intended. If you’re feeling inspired, I encourage you to try some of the designs I mentioned in the Basic Anatomy of a Cocktail Machine section.

If you really want to give this one a shot, I hope I provided everything you need here, but I’m sure I overlooked some useful details. Please ask questions here. You can also email me at donald [at] makerprojectlab.com. If my other projects on Instructables are any indication, I’ll probably forget half of these project details in a few months, so apologies in advance if future me isn’t as helpful as you’d like. My hope is that by dumping my brain into this Instructable, dumb future me won’t have as many questions to answer.

Cheers!

🥃🤖