Project Logs

Collapse

• A 2016 alternative to HTCPCP [updated video]

  Ronald • 08/15/2016 at 18:44 • 0 comments

  As said before, HTCPCP is fundamentally flawed. In two ways: (1) there is no way the amount of coffee can be controlled, (2) it assumes a teapot cannot brew cofee.

  It's time for a new HTPCP-like protocol that solves both of these problems. Things that need to be supported:

  1. Brewing coffee
  2. Small talk while deciding if one wants coffee
  3. Making sure nobody ever believes tea pots cannot make coffee
  4. At least some control over who is allowed to brew coffee.

  As data carrier, pigeons were considered. However, no quality trained pigeons were available, so Telegram was picked. Telegram has a nice bot api. Further, some nice people wrote a Python library for communicating. This solves requirement 4, and eases the development of code for 1-3.

  The core telegram bot communication code can be found in telegram.py and may be a useful example to others. The code for implementing requirements 2-3 is also in this file.

  The koffiezetter.py has been updated to react to telegram, and to be a little more verbose over telegram, too.

  Protocol
  

  As for the protocol, current computers and even the Raspberry Pi have enough processing power to do some amount of written language recognition. Supported commands:
  

  • 'hi' or 'hello': start smalltalk
  • some sentence containing 'tea': tell that shamefully we cannot provide tea
  • some sentence containing 'one cup of coffee': brew 1 cup
  • some sentence containing 'two cups of coffee': brew 2 cups
  • shortcut: if it's really early in the morning and coffee is urgently required with lack of proper verbalisation skills, the word 'coffee' provides for 1 cup of coffee

  Brewing more than 3 cups over telegram is not allowed (yet) since no phyisical checks are being made before brewing starts. Read: it can get a big mess, and for <=2 cups this is considered an acceptable risk.

  Video is updated, as well as the source on Github.
  

• Software part 2 - the coffee parts

  Ronald • 08/11/2016 at 14:46 • 0 comments

  Video is online! Click here to see the machine in it's full glory.
  

  Arguably the most important feature of a coffee machine is its ability to brew coffee. Thankfully, this machine is actually capable of brewing coffee. Earlier I described the used hardware, in this part I will describe the software.

  An advantage of a microcontroller-controlled coffee machine, is that a lot of finetuning of the brewing process is possible. An advantage of an internet-connected coffee machine, is that a lot of statistics can be tracked. For that most exciting part, check http://koffie.ronaldteune.nlAutoBaristaScript (TM)
  

  The brewing code is in the koffiezetter.py module (excuse my Dutch - I tried to at least make it readable with comments). For every number on the quantity dial (1-5), a script is defined:

  ['Z8','M135','Z16','S60','Z120'] for 1 cup of coffee. This means:

  • Give water (Z) for 8/4 = 2 seconds. Due to the control logic, this water is cold. For filter coffee, it's best to first wet the filter. This way, we can spare us the huge effort of doing it by hand.
  • Grind (M) 135 half rotations of the grinder.
  • Give hot water (Z) for 16/4 = 4 seconds.
  • Sleep for 60/4 = 15 seconds. I forgot the fancy 'slow coffee' name for this, but this waiting time after a small bit of water significantly improves the taste of the coffee compared to instantly letting more water pass through the filter.
  • Give the bulk of hot water.

  The amounts of coffee and water is finetuned for this machine and the beans we currently use. Should we choose to switch beans often, new scripts can easily be created and loaded into the machine.
  

  The temperature measurement comes from the HAL in a scale close to degrees celcius. Measurement is done by an NTC / constant R voltage divider connected to an ADC input of the Atmega daughterboard. I did not calibrate it exactly, but it's close enough. Some trial & error helped in getting the good coffee output temperature.

  The script may be extended with a temperature control setting, e.g. to give perfect water for black tea, green tea and coffee. Currently however, a teakettle is still doing a wonderful job for this.
  

  Grinding & brewing process
  

  Both the grinder and the flow meter have two little magnets and a hall sensor. A call back function in the HAL registers the amount of half rotations; the brewing routine waits for the grinding to complete.

  The flow meter has recently been installed, but currently the amount of water is still time-based. The clock ticks at 4 Hz (=4 FPS).
  

  More cups of coffee don't mean a linear increase of coffee powder; the amount of powder per cup slightly decreases.

  One thing that needs improving is that the Senseo has a three-way-valve that 'spits' hot water back into the water tank when not pumping. This makes both the time-based and the flow-meter-based measurement inaccurate, so the exact amount of coffee is always a surprise. I think I can remove the three-way-valve since my output setup is totally different from the pad-based machine, but I need to investigate it more.

  The temperature control is a simple hysteresis based control, with the addition that it tries to leave the boiler at less than 'totally hot' at the end, so the last 2 seconds the water may be colder than in the rest of the cycle. The advantage of this is that the first 2 seconds that are used for wetting the filter can be done by cold water (which means: don't wait for heating up).

  The heater starts after grinding the coffee. The advantage is that while grinding, the water tank can be filled without the three-way-valve spitting hot water over the kitchen floor.
  

• Software part 1 - the non-coffee bit

  Ronald • 08/11/2016 at 11:26 • 0 comments

  The source code of both the software (python) and firmware (atmega, c) can be found on github. It autodetects architecture and can be run on a desktop computer. To make full use of it; an MPD client has to be installed (music), an NS-API token has to be available (train info), and a Dutch postal code + house number combination has to be set (waste collection info). Of course all of this is only neccesary for the home information part, not for making coffee...

  The UI will work well enough without all of this. The code has been written to make sure the UI continues to work at most times, catching and mostly ignoring exceptions - because otherwise it's hard to turn the coffee machine off without SSH.

  Main
  

  main.py, to which koffieui is a symlink, holds everything together. It loads the different modules:
  

  • System menu (SysD)
  • Train time table display (NSDisplay)
  • Music player control panel (MPDisplay)
  • Last but not least... the coffee maker interface (Koffiezetter)

  In this log I will explain the first three of these.

  Read more »

• Hardware

  Ronald • 07/28/2016 at 19:29 • 0 comments

  Block diagram
  

  Numbers are Raspberry Pi GPIO numbers.

  Read more »

• RonaldBoard: ISP programming + I2C communication

  Ronald • 07/14/2016 at 14:00 • 0 comments

  At the time when I started this project, there was no single project I could find, that combined ISP and I2C communication. So I decided to do it myself. Since everything needs to be enboxed and I still want to be able to upgrade firmware from SSH, ISP needs to be possible "without hands".

  warning - warning - warning - warning - warning - warning - warning - warning - warning - warning
  

  This can kill your Rasbperry Pi, be especially careful with 5V-lines

  For the coffee machine this board will handle PWM and ADC, things an ATMega8 is better capable of than a Raspberry Pi.

  Since Gert named his expansion board GertBoard, I decided to name mine RonaldBoard (as a fellow Dutchman? At least Gert's name sounds Dutch...).

  All that's needed is: a Raspberry Pi, At*, and wires. For the Pi I chose the ATMega8 rather than ATTiny45 because of having some more cheap I/O.

  The design is as follows:
  

  Note! While the pin numbering is okay, the GPIO numbering is wrong! Check [1] for correct info
  

  • The /RESET pin is connected to pin 22 of the GPIO-headerPB0 doubles as SDA (I2C communication) and MOSI (ISP) pin
  • PB1 is connected to MOSI, and can be used with care to drive something else when not in programming mode (an LED in this example)
  • PB2 doubles as SCL (I2C communication) and SCK (ISP) pin
  • PB3 is connected to an LED

  Note that because PB1 is used by the Pi when programming the ATTiny, it probably shouldn't be used to e.g. drive a Servo using PWM.

  For Pi <=> Atmega8 communication I chose for I2C, because at the time, I couldn't get (non-bit-banging) SPI working. For the Tiny45 the pins are the same; for my ATmega8 this cost me two additional pins...

  Set up
  

  If you want to use this in your own project, be sure you have the following:

  • Raspberry Pi connected to the RonaldBoard
  • The pigpio library installed
  • avrdude (patched version)
  • Example source (check project files for I2c.tar.gz)
  • /etc/avrdude.conf configured with the pgio programmer on the correct pins:

  programmer
    id    = "gpio2";
    desc  = "Use sysfs interface to bitbang GPIO lines";
    type  = gpio;
    reset = 25;
    sck = 3;
    mosi = 2;
    miso  = 9;
  ;

  Usage

  Before the first run after boot, be sure pigpiod is running and you have the i2c module loaded. I made the following script:

  sudo ./modprobes

  After all is set up, flash the RonaldBoard:

  make
  sudo make fuse
  sudo make flash

  The Makefile makes sure the GPIO's for I2C communication are set to read again, using pigs-commands.

  Then test it:

  ./i2ctest

  You should see something like this in your terminal window:

  i2cdetect:
       0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
  00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 
  10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
  20: -- -- -- -- -- -- 26 -- -- -- -- -- -- -- -- -- 
  30: -- -- -- -- -- -- -- -- -- -- -- UU -- -- -- -- 
  40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
  50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
  60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
  70: -- -- -- -- -- -- -- --                         
  test in getting the value of register 0x42:
  0x42
  testing ADC read:
  0xc0
  0xd5
  0xb7
  testing PWM.
  

  Furthermore, the LED should turn off and then shine brighter and brighter.

  Used work
  

  Eagle libs for the ATTiny & Pi (both modified afterwards in Inkscape, but very useful for the basic symbol):

  • http://bienonline.magix.net/public/undsonst-eagle.html
  • http://bioserver.her.hcmr.gr/RaspberryPi.html

  Libraries:

  • usiTwiSlave by https://github.com/eriksl/usitwislave
  • The pigpio library: http://abyz.co.uk/rpi/pigpio/
  • Using GPIO for avrdude: http://blog.stevemarple.co.uk/2013/03/how-to-use-gpio-version-of-avrdude-on.html

View all 5 project logs