April 16, 2015 | Written by: IBM Research Editorial Staff
Share this post:
I’m an engineer in the Magnetoelectronics and Spintronics group at IBM Research – Almaden. We explore the physics, materials science and potential technology applications of materials we create one atomic layer at a time with our ultra-high vacuum thin-film deposition tools. But I’ve also been making costumes, props and gadgets since I was eight years old. And I’ve been performing on stage on stage in small charity cabaret shows (I sing standards and lounge tunes) for years.
Microbots to barbots
Technically, the first robot I worked on was the thin film deposition system we started at our old lab in San Jose, and completed here at Almaden. It’s the system in which we did our seminal giant magnetoresistance (GMR) work in the late 1990s. GMR was the first of the spin-based technologies by which all data is now read from hard drives. Our car-sized robot layered four magnetic materials on top of one another with atomic precision on substrates smaller than a kitchen match. Today’s system is seven times larger than that machine – and it can build those atomically precise layers out of 80-odd different materials in any one experiment.
Inside the Magnetoelectronics and Spintronics at IBM Research-Almaden
Kevin Roche (left) with his “Tiki Dalek”
While I built plenty of models as a kid out of blocks, cardboard boxes and tubes and later Legos – and am not afraid to incorporate electronics into my theater and cabaret costumes and wearable art – my first attempts at hobby robotics only came a few years ago. I was displaying one of my costume creations (the “Tiki Dalek,” left) at an event called BarBot in San Francisco in 2011. There were a dozen clever contraptions making drinks with various degrees of success.
About half-way through the evening I looked around the room and realized: This is like my day job! I could do this! Dealing with the fluid components of a cocktail is not far off from the gas-handling automation I have to do in our thin-film deposition systems.
So, I started working on concepts for my bartending robot, ThinBot, and had it ready for the next year’s Barbot show. ThinBot has since taken the gold medal for bartending robots at the last three international RoboGames.
How to make a barbot
ThinBot (named in homage to The Thin Man movie series from the 1930s and 40s) was initially conceived as a martini-making robot. I quickly realized that with a few more bottles it could make a large assortment of cocktails. It only makes “up” drinks (meant to be served chilled in an up glass, aka a martini glass) because a) that’s the sort of cocktail Nick and Nora kept drinking while solving murders, and b) it can only work with non-carbonated liquid ingredients. Note: the Art Deco motifs on the robot are deliberate reference to the milieu of the movies.
The ingredients are loaded into bottles that sit in a tray of flowing chilled water, forming a tower-shaped table fountain with color-changing lighting that splashes softly between drinks. They are precisely dispensed using peristaltic pumps (used because the only thing which touches the ingredients is FDA-approved food-rated tubing), through a 9.5 pound anodized aluminum chilling block, then emerge from jets that swirl all the ingredients into the glass to mix. Because they mix in the glass, you never get contamination from the last person’s drinks.
All the control electronics are under a dome in the top of the tower to stay above the liquids, which is capped by a bell. The user places an empty glass on the arm, selects one of (currently 17) drinks from the menu, and ThinBot swings the arm under the nozzle and pours the drink, then swings the arm back out and rings a bell (an actual desk bell) to announce it is served.
The pouring process itself takes less than a minute; it often takes the user more time to select a cocktail than ThinBot takes to pour it.
Kevin Roche (center) with his ThinBot
Inspiring work, inspired robots
We have a fairly large group here in the lab, and our automated systems are used by many of them. Over the years I’ve learned a lot about how people react to an interface and expect or want an automated system to behave. I’ve also learned to aim for design simplicity when possible in the mechanism of a robot because that reduces the possible modes of failure during operation, and makes it more reliable.
When I work on my hobby robotics projects, I’ve stuck to the relatively primitive controllers. This forces me to write more efficient code and deal with things like memory management. The much more powerful controllers and environments I use in the lab insulate the designer to a large degree from those issues. Coping with the limitations of the small scale will, I hope, translate to developing more efficient code in my work projects.