Close
0%
0%

RoboBarista: A Coffee Brewing Robot

A flexible, open source robot arm that grinds, pours, and serves only the best robotic brewed Coffee.

Similar projects worth following
Originally a refurbishment of an old Microbot Alpha robot arm as a present for my girlfriend to make her coffee in the morning, the project has transformed into much much more. The vision for the project is this: to make low cost, reliable, accurate, documented open source robot arms that are easy for a beginner to get up and running. This MUST be a robot that the average user can interact usefully with their environment.



...But it's an expensive robot arm! I can't afford that!

Just hang in there! I have the unique ability to use an expensive (albeit late 70's vintage) robot arm to develop code for. One of the key aspects of this project being a success is expanding it to a low cost arm! The steppers make this concept easily expandable to another robot arm based off stepper motors (or servos!).

Note that this is a LARGE project! I am working on writing up what I've done so far, as I'm a few months behind on documentation... But, here's a video with the current progress level!: https://www.youtube.com/watch?v=mwVzRYI0Vrk

  • 1 × Freesoc PSOC 5LP (Arm Cortex M3 CPU) based development board
  • 5 × A4988 Power Management ICs / Motion, Motor and Servo Control
  • 1 × Robot Arm Microbot Alpha 5 Axis Robot ARm
  • 1 × ATX Power Supply Power Supply for all components
  • 1 × Wii Nunchuck Robot Control Joystick

View all 8 components

  • Motivation to Use Steppers over Servos

    Jim Shealy05/19/2014 at 23:44 0 comments

    In my quest to derive a robot control scheme from scratch, I've been working to figure out how to control a stepper motor. Stepper motors are great because they're cheap, relatively simple to control, and can maintain a constant torque without burning out. Unlike a hobby brushless motor or brushed motor, stepper motors don't burn out when they stall. They're designed to go to a position and stay there as long as it's below the rated torque. By changing the current going through the windings you make the motor "step" (hence "stepper motor") in a direction and stay there. You can see a simplified image below.

    If you imagine driving the coils, the magnetic rotor will align with a set of coils. Energize the other ones and it'll "step" to align with the other coils. What's neat is that if you power the coils in various arrangements you can actually achieve fractional steps (albeit these steps tend to become less accurate as you divide them finer).

    Why Not Use a Servo?

    Servos are also (generally) meant to create large torques through a geared drivetrain. They also include control circuitry to go to a postion that you command, eliminating most of the control logic necessary. Albeit very convenient there's a few major disadvantages:

    1- Jittery: Servos have a tendency to not hold an exact position and jitter. Cheap servos have control logic that makes them act like a really stiff spring from a commanded position. (This is proportional control; the force exerted is proportional to the distance from the desired target, IE a spring). Because cheap servos have a very low resolution they tend to jitter around the desired position due to their accuracy errors.

    2- Inaccurate: Cheap servos don't necessarily go to the position commanded. Hysteresis (or the the inability to return to a state due to losses such as friction) and various loading conditions will prevent the servo from going all the way to the desired point. This is typically due to the proportional control lowering the output torque near the target position. While this doesn't make a difference on an RC system due to the human being able to compensate, on a robot arm these inaccuracies will be propagated, amplified, and compounded by the physical arm to result in very poor accuracy. This is not to say that there aren't accurate servos! they're just quite expensive (typically >$90)

    3- Fragile: Servos definitely have higher holding torque per size than stepper motors. However, when a servo is over torqued and back driven, the gears have a tendency to break or strip. Stepper motors will instead just skip a magnetic pole and settle into the next allowable position. This is especially nice if for example the robot arm runs into an obstacle or is hit (ie bumped) by an object. These impacts are especially prone to breaking servos.

    4- Expensive: Nice servos are expensive! There's a reason for this though, the accurate sensors, high speed, high torque drives cost more to produce.

    5- Typically Limited range: Servos rarely are continuous rotation. This can present serious design challenges (and reduces the flexibility of the design!)

    Now, that's all not to say that stepper motors are the god of all motors. Servos are extremely convenient and provide a very compact mechanical control package. They're very easy to control and if you're ok with low accuracy, they're definitely cost effective. The main difference here is that with a good mechanical design and control logic, stepper motors are more robust and potentially significantly cheaper. Especially with the proliferation of 3D printers that rely on stepper motors, it's become progressively cheaper and easier to use steppers.

  • A Dive Into the World of Coffee

    Jim Shealy05/05/2014 at 22:16 0 comments

    Coffee as it turns out is a complicated and VERY subtle process. Here's an overview of what can affect your final outcome:

    Growing Location --> Time of Season --> Rain --> Quality of picked beans --> Handling --> Shipping conditions --> Storage conditions --> Roasting Style --> Time from roasting to grinding --> Time from grinding to brewing --> Temperature of water --> Brewing method --> Temperature of drinking.

    Seriously, it's ridiculous! But, assuming you've bought your beans from a reputable source, what you do starts with the roasting/storing part of the process.

    So, First things first:

    Buy Freshly Roasted Coffee Beans

    Look around on the internet and you're likely to find some coffee roasters in the area! I get my beans for $6 a 1/2 lb (0.23kg) at my local farmer's market. She roasts every day, and so I get them hours after they've been roasted! Now, as an aside, all roasting is not equal. There are darker roasts, lighter roasts, and different roast styles (drum roasted vs air roasted). You'll need to decide what YOU like and find a location, color roast, and your preferred roast style. Fortunately you can help weed out poor quality coffee by seeing if the roaster is passionate about what they do. If they are, and you feel like giving it a shot, then ask them for a suggestion! I guarantee that just about anything you get freshly roasted will be better than something sitting on a shelf for a month at the store.

    Store Your Beans Properly

    What's cool about coffee is that the chemical reactions of the coffee isn't done once you roast it. Coffee actually can take up to a week to mature (depending on blend/roasting style). When you first get your beans they won't smell like much and are pretty dry. Over the next few days you'll find that the beans start to bead up with volatile oils, and will eventually be glistening and soaked in it. I'll try to post some day by day pictures of coffee beans as they mature, but this is essentially the point where the coffee is at it's peak. After this your coffee will start to get more bland as the volatiles continue to evaporate out. 

    So, take your fresh beans and keep them at room temperature. If you put them in the fridge or freezer, you'll risk moisture ingress from condensation when you open the bag. The freezer can also damage the flavors, so in my opinion it's not worth it. Just buy what you're going to use in less than 2 weeks. You can always try another blend if you run out ;)

    Grind Your Beans When You're Ready to Brew

    Don't grind your beans until you're completely ready to start brewing, IE the water is heating and you've got <5 minutes before you're going to pour the water. Grinding exposes the flavors, and like an apple, the coffee will start to oxidize right away! Now, mere mortals like you and I may not tell the difference between 1 or 2 minutes delay, it's just good habit to be ready to pour once you're done grinding.

    Use a Burr Grinder

    Coffee is a steeping process. You are attempting to extract specific flavors from a coffee bean without extracting too little (weak and bland coffee) or too much (very acidic and astringent). Whatever method you use, in the end you're trying to get a consistent coffee grind that each particulate has the same surface area to volume ratio so they all extract evenly, ideally the same size as well. When you have grind that is too fine, it over steeps very quickly. When you have coarse grind, it takes significantly longer to pull out the desirable flavors and you need to modify the water temperature accordingly. When you have a large variety of grind size, you will result in under extracted large particulates, and over extracted fine particulates with the resultant brew both weak and astringent. Burr grinders are the defacto standard as they generally produce consistent desireable grind sizes as opposed to blade grinders that typically results in inconsistent grind. Blade grinders also heat up the coffee significantly more and drive out the tasty volatiles!

    Note...

    Read more »

  • Learning PSOC and Some of its Idiosyncrasies

    Jim Shealy05/04/2014 at 19:07 0 comments

    I went over some of the reasons I really like the PSOC architecture as a platform in the "Intro to PSOC" update. But I want to get into the actual issues and things to know for the new user to prevent wasting tremendous amounts of time.

    1- Microcontrollers

    Let's start with micro controller hardware differences. If you've only ever used the Arduino, it turns out the programming/debug port is not the same as the communications port! I spent countless hours trying to figure out why the serial port wasn't enumerating (read 8+ hours). It turns out that it's normal (and apparently obvious) that many micro controllers have more than one port, and programming/debugging is handled separately. I couldn't find any answers online, well because no one had the same problem, there wasn't one! upon plugging my usb cord into the other port I applied my head directly to the table because suddenly the serial port worked. Oh, and just remember to check if your pins are not actually micro controller pins, but power pins. It'll save you some rewiring.



    2- Floating Pins

    I had some interesting gremlins in the wires when I started coding for the stepper motor controllers. As it turns out, if your reset, sleep, or enable pins aren't tied to a polarity, you'll have very flaky control of the stepper motors! But, that's not limited to just those, ALL signal pins must be attached to a polarity or enabled pin to prevent floating. While it's neat to be able to hold your hand near the wires and have the robot arm start moving on its own, it's extremely frustrating to figure out!

    Additionally, make sure the Microcontroller pins that the signal pins are connected to are actually defined by the PSOC controller. All of this is done through the PSOC Creator software as shown below:

    If you have yellow auto assigned pins, you should make sure they're actually the pin you want! On the FREESOC the pins have silk screened labeling that calls out the port (P4[7], etc.) instead of the pin number. While all the breakout/development boards may not do this, it's not a bad thing to keep in mind. Part of my floating pin issues were due to pins being plugged into micro controller pins that weren't defined, and thus didn't have a polarity!


    3- FPGA Hardware (or UDB components) Must be Started

    This is something that took me ages to figure out, but components must be started before they do anything! Many component data sheets say this, but it's not always explicitly called out. That's a major difference you'll see with PSOC and a CPU only architecture like arduino. Not only that, but there are ~4 commands used to start components.

    componentName_Start()

    componentName_Begin()

    componentName_Init()

    componentName_Enable()

    Some components need to be initialized before they can be enabled. Others only need to be enabled. The key to this is is that if there is a _Start() or a _Begin() command, use these as they'll take care of initializing and enabling in the correct order. Because Cypress' PSOC Creator auto fills, just try one of these two commands first before worrying if there is a specific initialization order.

    While PSOC creator auto-fills, make sure you've built your project BEFORE trying to code! The build command creates the code handles you will use, and they'll be unavailable if you didn't build after inserting a hardware component.


    4- Clocks

    PSOC allows for tremendous flexibility and ease of setting clocks. Unfortunately that ease can make communications protocols break down because you messed with the wrong one (IE the USB clock!). Let's dig into that a little deeper:


    By double clicking the clock frequency box, you'll be taken to another page with the clocks, showing how they're all interdependent  or dependent depending on how you set them. The lines show what connects to what, and which clocks you can base other ones off of.

    I won't pretend to understand what all the clocks actually mean, but the important thing is this, The faster the bus clock, the faster your CPU. 

    BUT, you wanted...

    Read more »

  • Intro to PSOC

    Jim Shealy05/01/2014 at 21:23 0 comments

    So what is PSOC? Why the heck would I use this over an arduino? 

    The simple answer is this: FPGA (esque), large libraries, tons of documentation, useful IDE, Debugging

    Doesn't make sense yet? It took me a while to get it also! I saw a cool kickstarter project for this development board (FREESOC) and after watching the video, it got me thinking that this chip had leaps and bounds more capability than the arduino!

    Here's John Morello's video of the FREESOC, even if you don't know half of what he's saying (I didn't), it's really useful to start imagining all the possibilities of what you could do:

    https://www.kickstarter.com/projects/18182218/freesoc-and-freesoc-mini/widget/video.html

    If you didn't watch, PSOC stands for "Programmable System On a Chip". What makes it so special is that there are digital, analog, and communications components that work in PARALLEL with the CPU! If you look at the picture below the different boxes each represent a "parallel" component that operate independently of the CPU. 

    Pretty neat isn't it? It's like your CPU is a person driving a car, you design the hardware on the digital and analog systems to be capable of navigating the track, and then teach your CPU how to sit at the helm and drive the vehicle you designed. The CPU doesn't have to do both at the same time!

    Having used arduinos a decent amount, I've found that I get to a certain point of complexity and I suddenly have to start digging into interrupts. This is where the simple arduino code begins to break down and starts to get really ugly and confusing.

    I've constantly run into this working with counters on Arduino. I need something to count to some varying value, but I can't afford to use "Delay" or "Millis"  because it makes my code really laggy, or isn't consistent enough. So, I turn to interrupts. They're neat because my code can jump from one thing to another, but all of a sudden I'm bit shifting control registers in the ATMEL and everyone's code that I'm trying to follow doesn't look anything like what I normally use in the IDE. Then, suddenly things start to break in ways I don't understand, and I won't even start on using multiple interrupts...

    This is where the PSOC starts to become really neat. I can place a "counter" component, hook up a time source (clock), set the clock to a specific frequency, tell the counter "go" and it does what I tell it to do. Not only that, but your code can "set and forget" the counter because the counter will keep on counting, even if the CPU is asleep, or using "Delay", or whatever! Neat! And all I have to do is drag and drop a component, click it to set what I want, and we're done. 

    So that's the long story of why I chose the PSOC to run this project. The CPU does the calculations to drive the arm, and the hardware and counters take care of the mechanics of actually incrementing/decrementing the stepper motor drivers to the correct positions. The CPU says how far and how fast, and the hardware takes care of doing it.

    Now, that's not to say PSOC isn't without pitfalls, ESPECIALLY for a complete novice like myself at C and programmable logic. Check out the lessons learned with PSOC to get a better idea of what you need to do to actually get started and save (literally) hundreds of hours of frustration.

    (I'll add the link once I get that page up, patience ;) )

View all 4 project logs

  • 1
    Step 1

    The first step to a good coffee brewing robot is to figure out how to brew good coffee. I've got some tips and tricks to brewing good coffee in the project logs ("A Dive Into the World of Coffee"), so I'll get directly into how I achieve good, full bodied coffee without much bitterness. I'm not usually able to drink coffee black, but when it's brewed right, it's pretty good and I think you'll be able to too! You'll need everything in the following Picture:

    1x measuring Cup (at least 250cc, Pyrex brand pours very nicely which is important!)

    1x Burr Grinder (I use the Hario Skerton. <$35 online)

    1x Drip Cone (I use the Hario V60, ~$8 for a plastic cone, $25 for ceramic)

    1x #02 Hario Filter ($5 for about 100)

    1x Thermometer (preferably digital for quick reading)

    1x Mug

    ~17g Coffee Beans

    I've chosen these particular utensils because I want the robot arm to use implements humans typically interact with. Realize before you go much further that brewing coffee like this requires a bit of patience! You can't just push a button and walk away, but the results are worth it!

    By the way, if you're following along, make sure your grinder is dialed in for drip brewed coffee. I'll put up a project log to describe how to do this and what it looks like on the Hario Skerton.

    The Math: (skip to brewing if you don't care ;) )

    By international coffee standards, the following SCAA chart shows a good formula to follow when brewing coffee. 

    This chart provides a pretty good basis of how to figure out where your coffee brewing is. You start out with with weight of coffee to water volume (note the right side of the chart). To achieve optimal balance we'll want to follow the 55g per liter line. If we're using ~270cc of water, this turns into about 15g of coffee... Conveniently the size scoop the hario V60 comes with ;)

    Ok, but what about the rest? Well, the X axis is the amount extracted into solution, and the Y axis is the concentration in the solution. Using a TDS meter (as shown in the picture as the clear blue gadget) or refractometer we can estimate the amount of solids dissolved in the brewed coffee on the Y axis, trace over to the grams/liter line we brewed at, and find our extraction as well as where in the optimum balance our particular brew landed. Every coffee blend is different, and the chart is no substitute for taste! It'll get you close enough that you'll start getting delicious coffee and enable you to refine the process until you get what you like best.

    Brewing (My method)

    Before beginning, get a #02 filter out and place it in the cone. You'll need to fold the seam down to help it retain it's conical shape. Go ahead and run some water through the filter to wet it and place it over your clean coffee mug. 

    Step 1- Put about 270cc water into the measuring cup and throw it into the microwave for 2-3 min. We want it to reach 195°F, but it's ok if it boils a bit.

    Step 2- Take the scoop included with the Hario V60 (15-16g or I believe about 1 TBSP), throw it into the grinder, and get that grinder moving!

    Step 3- Take your ground coffee and dump into the prepared filter

    Step 4- Remove the water from the microwave (it should be just finishing) and stir with the thermometer. We're waiting for the water to cool to 195°F

    Step 5- Gently pour water over the pile of grounds, evenly wetting all the grounds. We're looking for them to start foaming (freshly ground new coffee will foam!) and really to evenly saturate the grounds. Only pour 1/5th the water and then let it sit for ~30 seconds. This step is important to make sure the coffee extracts evenly. This is called the "bloom" because the coffee foams up!

    Step 6- Begin slowly pouring the water (which has cooled to abut 191°F and should be perfect!) in a spiral pattern. We're looking for a stream that's just less than steady and you'll know if you're going too fast because the pouring will get significantly quieter! It should take about 1-2 minutes to pour completely. Avoid pouring on the sides! While we want to keep the coffee evenly agitated, we don't want to push all the coffee off the filter and allow the water to bypass the coffee altogether. The water level will likely rise up to about 1/2 or 2/3rds of the height of the cone, but if it starts to get higher you'll want to slow down.

    Step 6- Let the coffee finish dripping, throw away the used filter, and clean up! you're ready to drink your delicious coffee! And hey, if you did it right you might even enjoy it black!

    Now, you might notice that while it produces great coffee, it's a slow process and takes a lot of work for something that could (should!) be automated. That's the plan for this robot is to be able to perform all these tasks at the push of a button!

  • 2
    Step 2

    Effective Bardware Based Stepper Motor Control

    In my quest to derive a  robot control scheme from scratch, I've been working to figure out how to control a stepper motor. Stepper motors are great because they're cheap, relatively simple to control, and can maintain a constant torque without burning out. Unlike a hobby brushless motor or brushed motor, stepper motors don't burn out when they stall. They're designed to go to a position and stay there as long as it's below the rated torque. By changing the current going through the windings you make the motor "step" (hence "stepper motor") in a direction and stay there. You can see a simplified image below. 

    If you imagine driving the coils, the magnetic rotor will align with a set of coils. Energize the other ones and it'll "step" to align with the other coils. What's neat is that if you power the coils in various arrangements you can actually achieve fractional steps (albeit these steps tend to become less accurate as you divide them finer). 

    Why Not Use a Servo?

    Servos are also (generally) meant to create large torques through a geared drivetrain. They also include control circuitry to go to a postion that you command, eliminating most of the control logic necessary. Albeit very convenient there's a few major disadvantages:

    1- Jittery: Servos have a tendency to not hold an exact position and jitter. Cheap servos have control logic that makes them act like a really stiff spring from a commanded position. (This is proportional control; the force exerted is proportional to the distance from the desired target, IE a spring). Because cheap servos have a very low resolution they tend to jitter around the desired position due to their accuracy errors.

    2- Inaccurate: Cheap servos don't necessarily go to the position commanded. Hysteresis (or the the inability to return to a state due to losses such as friction) and various loading conditions will prevent the servo from going all the way to the desired point. This is typically due to the proportional control lowering the output torque near the target position. While this doesn't make a difference on an RC system due to the human being able to compensate, on a robot arm these inaccuracies will be propagated, amplified, and compounded by the physical arm to result in very poor accuracy. This is not to say that there aren't accurate servos! they're just quite expensive (typically >$90)

    3- Fragile: Servos definitely have higher holding torque per size than stepper motors. However, when a servo is over torqued and back driven, the gears have a tendency to break or strip. Stepper motors will instead just skip a magnetic pole and settle into the next allowable position. This is especially nice if for example the robot arm runs into an obstacle or is hit (ie bumped) by an object. These impacts are especially prone to breaking servos.

    4- Expensive: Nice servos are expensive! There's a reason for this though, the accurate sensors, high speed, high torque drives cost more to produce. 

    5- Typically Limited range: Servos rarely are continuous rotation. This can present serious design challenges (and reduces the flexibility of the design!)

    Now, that's all not to say that stepper motors are the god of all motors. Servos are extremely convenient and provide a very compact mechanical control package. They're very easy to control and if you're ok with low accuracy, they're definitely cost effective. The main difference here is that with a good mechanical design and control logic, stepper motors are more robust and potentially significantly cheaper. Especially with the proliferation of 3D printers that rely on stepper motors, it's become progressively cheaper and easier to use steppers. 

  • 3
    Step 3

    Develop kinematics and robust control mechanisms

    *Link to project page to be added*

View all 5 instructions

Enjoy this project?

Share

Discussions

telot3828 wrote 03/24/2023 at 12:35 point

 It's truly perfect engineering! It's been very baffling to "graduate" from Arduino, yet I'm wanting to do an entire instructional exercise on the fundamental do's and don'ts. Whenever I've made it work,flat white coffee is really flawless how much documentation they give you with every part!

  Are you sure? yes | no

Jasmine Brackett wrote 06/11/2014 at 23:21 point
Hello Jim, what more could a girl want? This has coffee and robots!

Anyway, I thought I would let you know we've updated the submission process for The Hackaday Prize, so If you want to officially enter this project - login and use the 'submit to' under your project images on the left hand side.

Also, we are starting community judging soon, so now is the time to make sure you've added all the details to the project to give it the best chance of winning.

Got any questions. Give me a shout.

  Are you sure? yes | no

Dan Royer wrote 05/17/2014 at 06:08 point
Hi! I have an open source robot arm that is already up and running and kits are for sale. It's also part of the contest. Care to join forces? http://hackaday.io/project/945-6DOF-Robot-Arm

  Are you sure? yes | no

Jim Shealy wrote 05/17/2014 at 15:58 point
Dan, I saw what you were doing and it's pretty neat! I think it might be a good idea to join up, as working alone is definitely a bit of a bummer! I think if we did work together we could potentially shoot for a much higher objective. I'll try to contact you offline (using the contact form on your website) and see what you're thinking.

  Are you sure? yes | no

Greg Kennedy wrote 05/16/2014 at 02:41 point
Any plans to support RFC2324?
http://tools.ietf.org/html/rfc2324

  Are you sure? yes | no

Jim Shealy wrote 05/17/2014 at 15:53 point
ok, that was an excellent read! I'll need to make sure I incorporate the correct firewalls per RFC2324. ;)

  Are you sure? yes | no

Eric Evenchick wrote 04/30/2014 at 04:34 point
This combines my love for coffee and robots! What do you think of the PSOC? I've seen some cool application notes but never tried it myself.

  Are you sure? yes | no

Jim Shealy wrote 05/01/2014 at 01:33 point
It's a really neat architecture! It's been extremely frustrating to "graduate" from arduino, but I'm hoping to do a whole tutorial of the basic do's and don'ts. Once I've gotten it working, its pretty neat how much documentation they give you with each component!

  Are you sure? yes | no

Jim Shealy wrote 05/01/2014 at 22:14 point
I've added an "intro to PSOC" section, let me know what you think! I'll be adding actual coding and logic I've done so far, as well as what to know when you get started (IE lessons learned the hard way).

  Are you sure? yes | no

Eric Evenchick wrote 05/04/2014 at 08:06 point
Thanks for that, it's a nice overview of why you might want to move on from the Arduino. Looking forward to watching this progress!

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates