I used to run a coffee roastery and roasted several thousand batches. This is pretty much how it works. I spent hours of trying to match those curves to the target profile.
Back in the day we had software called Artisan and a few probes inside the machine. It would have benefited of from having much more data being recorded.
For example: environment humidity, the number of the batch (machine itself heats, so batch 1 of the day is very different than batch 11), bean temp and moisture before going in, actions the roaster takes etc.
(Nice work! This is really nifty. I wish I knew more about coffee so I could better understand the dynamics of the controls and how to achieve a perfect roast.)
If you ever did a writeup on how your ML modelling worked and what real-life data you needed, I'd learn so much point of view of someone who's applied a little bit of control theory to robotics and aquarium controllers, but with traditional models.
(Hell, I'd even pay $CUP_OF_COFFEE_PRICE for it, since I'd get that much learning time out of it.)
Also: you advertise custom models for roasters. But can you make a digital twin of my toaster?
I'd like to see you tackle the problem of figuring the opposite, let the user draw the curves and generate the inputs. Then I could replay with Artisan.
Working on it! In fact, this was my original goal; Model Predictive Control for my roasters. I've been able to get this working on a fluid bed roaster but I've yet to try it for my drum roaster. Stay tuned! I'm hoping to have a control demo posted on the site soon.
If I understand this correctly, calling it a "digital model" would be more appropriate. Digital twins require sensor input from a real system as well as the ability to alter the real system, not just prediction.
Yeah, as shown it's just a bunch of models. The real magic happens when this is connected to hardware and we can do things like data assimilation and control.
I thought the whole point of roast curves is that the beans are the exogenous variable, even the same beans at different times of the day. And that those changes influence the outcomes (bean temp) even if it's nearly imperceptible.
I've never paid attention to the minute differences, but if you're the kind of roaster who believes in the art of it versus the science, I think it'd be cool to try to map this model to certain outcomes - eg more or less fruity, chocolate, etc. Or actually throw in stuff like humidity, bean age, time of day, etc.
I've done a few hundred roasts, but by hand cranking a flour sifter over a heat gun. My model inputs are noise, smell, appearance. I've never been interested in pursuing a roast curve or profile, because I'm a barbarian.
I'm a barbarian too. I roast with a 15+ year old Gene Cafe with the analog dials.
I put in 265 grams of dry process coffee - usually some Ethiopian from Sweet Marias - set the temp to 449°F, set the time to 19 minutes, start it up and the set a timer for 16 minutes. At that point I start watching it and hit the stop button when it is a little lighter than I want.
The Gene Cafe is notorious for its slow cool-down cycle, so if you stop the roast when it looks perfect, it will end up too dark. But I've gotten pretty good at guesstimating it. And I do two roasts back to back: a lighter one for myself, and a darker one for my friend who prefers that. So if the first roast is lighter or darker than I planned, I adjust the time for the second one.
One time I thought I would get more precise, so I bought a cooling device on eBay. With this, you run the roast until it looks perfect, hit the emergency stop, and dump the beans into the cooler. (Use a hot pad because the handle will burn you!) But this left way too much chaff mixed in with the beans. So I went back to my imprecise guesstimating method.
I used to have to replace the heater element every couple of years when it burned out, but the last one has been good for ten years. The only current problem is that the rotary knobs - especially the temperature knob - have gotten twitchy. If you turn it a bit, it doesn't reliably go up or down smoothly but jumps around randomly.
Having had some prior experience with rotary encoders, I knew right away what the silly mistake was that the designers made, and how they could have prevented it at little or no additional parts cost. Just for fun, I also described the problem to ChatGPT, and bless her silicon heart, she figured it out too.
Would anyone like to take a stab at this question? What was the mistake, and how could they have kept these rotary encoders from getting jumpy after years of use?
When this machine finally does break down completely, I won't be getting another Gene Cafe. Not because of the problems above, but because of a new "safety" feature they added a few years ago where twice during the warmup, it beeps at you and you get 30 seconds to push a button to keep it going. I roast outside, and I like being able to ignore the machine for 16 minutes.
very cool. If you're looking for machines to add, it would be awesome to model a cheap roaster based on a popcorn popper since it is probably less reliable than commercial sample roasters (and might benefit from less trial-and-error). During my undergrad I made an arduino-controlled popcorn popper that connected to the open source artisan software: https://github.com/lukeinator42/coffee-roaster.
100% agree - each roaster is slightly different, with different measurement schemes and other device peculiarities. This makes sharing coffee roasting profiles basically impossible!
I'm also working on letting people upload their roast profiles for training and serving their own models (including a "library" of bean models!).
As someone doing PhD in digital twins, I’m obliged to point out that this is a simulation, not a digital twin, as there is no two way data interchange between the models. Having said that, this is extremely cool and I love it.
A 'digital twin' is a model that evolves over the lifetime of a physical asset. So if the state of the real device changes, so does the model (data assimilation). Likewise, one can use the model for control/planning/"what-if" scenarios. This is the bi-directional information flow that's being mentioned.
So what I'm showing on the website is just the model part. I'm not a fan of exposing my hardware in a public demo (the digital twin part), but the idea is that this model evolves with the roaster during the roast (data assimilation) and can help the operator guide the roaster to a desired end goal (e.g. medium roast along some profile or with minimal energy usage).
> A digital twin is a digital model of an intended or actual real-world physical product, system, or process (a physical twin) that serves as a digital counterpart of it for purposes such as simulation, integration, testing, monitoring, and maintenance.
> A digital twin is "a set of adaptive models that emulate the behaviour of a physical system in a virtual system getting real time data to update itself along its life cycle. The digital twin replicates the physical system to predict failures and opportunities for changing, to prescribe real time actions for optimizing and/or mitigating unexpected events observing and evaluating the operating profile system."
Not trying to knock your project, which is executed very nicely, but it does make me wonder where the boundary of human-ability quality discernment lies, beyond which is audiophile territory. Is “bean physics” the event horizon? Can you really tell the difference in a double blind test? If so, that’s amazing!
Super interesting. I had plans to do something similar with my roaster but life got in the way as always. What are you roasting on? We just purchased a venta18 and my goal this fall is to get it hooked up with PID. Something like this could be very useful for tuning
Gotta admit, when I read "digital twin" I though it was the kind that Nvidia likes to show off. Would be really awesome future work if you were able to pull that off. I mean, this already super cool! but you know, gaussian splatting...
You could interface with an Artisan LCD maybe? I’ve got my 1 lb drum roaster hooked up to that and watch the degrees-per-minute display to estimate the roast curve.
This takes me back.
I used to run a coffee roastery and roasted several thousand batches. This is pretty much how it works. I spent hours of trying to match those curves to the target profile.
Back in the day we had software called Artisan and a few probes inside the machine. It would have benefited of from having much more data being recorded.
For example: environment humidity, the number of the batch (machine itself heats, so batch 1 of the day is very different than batch 11), bean temp and moisture before going in, actions the roaster takes etc.
It seems like I have forgotten some nuances.
Artisan is still very popular and still in use today.
I overclocked the roaster and now the kitchen is gone: https://i.imgur.com/qRcGm64.png
(Nice work! This is really nifty. I wish I knew more about coffee so I could better understand the dynamics of the controls and how to achieve a perfect roast.)
https://m.youtube.com/shorts/nRNKfd35Wqg
This is extremely fun to play with – congrats!
If you ever did a writeup on how your ML modelling worked and what real-life data you needed, I'd learn so much point of view of someone who's applied a little bit of control theory to robotics and aquarium controllers, but with traditional models. (Hell, I'd even pay $CUP_OF_COFFEE_PRICE for it, since I'd get that much learning time out of it.)
Also: you advertise custom models for roasters. But can you make a digital twin of my toaster?
I too am curious about the modelling methodology.
I'd like to see you tackle the problem of figuring the opposite, let the user draw the curves and generate the inputs. Then I could replay with Artisan.
Cool website !
Working on it! In fact, this was my original goal; Model Predictive Control for my roasters. I've been able to get this working on a fluid bed roaster but I've yet to try it for my drum roaster. Stay tuned! I'm hoping to have a control demo posted on the site soon.
If I understand this correctly, calling it a "digital model" would be more appropriate. Digital twins require sensor input from a real system as well as the ability to alter the real system, not just prediction.
Yeah, as shown it's just a bunch of models. The real magic happens when this is connected to hardware and we can do things like data assimilation and control.
This is correct.
I thought the whole point of roast curves is that the beans are the exogenous variable, even the same beans at different times of the day. And that those changes influence the outcomes (bean temp) even if it's nearly imperceptible.
I've never paid attention to the minute differences, but if you're the kind of roaster who believes in the art of it versus the science, I think it'd be cool to try to map this model to certain outcomes - eg more or less fruity, chocolate, etc. Or actually throw in stuff like humidity, bean age, time of day, etc.
I've done a few hundred roasts, but by hand cranking a flour sifter over a heat gun. My model inputs are noise, smell, appearance. I've never been interested in pursuing a roast curve or profile, because I'm a barbarian.
I'm a barbarian too. I roast with a 15+ year old Gene Cafe with the analog dials.
I put in 265 grams of dry process coffee - usually some Ethiopian from Sweet Marias - set the temp to 449°F, set the time to 19 minutes, start it up and the set a timer for 16 minutes. At that point I start watching it and hit the stop button when it is a little lighter than I want.
The Gene Cafe is notorious for its slow cool-down cycle, so if you stop the roast when it looks perfect, it will end up too dark. But I've gotten pretty good at guesstimating it. And I do two roasts back to back: a lighter one for myself, and a darker one for my friend who prefers that. So if the first roast is lighter or darker than I planned, I adjust the time for the second one.
One time I thought I would get more precise, so I bought a cooling device on eBay. With this, you run the roast until it looks perfect, hit the emergency stop, and dump the beans into the cooler. (Use a hot pad because the handle will burn you!) But this left way too much chaff mixed in with the beans. So I went back to my imprecise guesstimating method.
I used to have to replace the heater element every couple of years when it burned out, but the last one has been good for ten years. The only current problem is that the rotary knobs - especially the temperature knob - have gotten twitchy. If you turn it a bit, it doesn't reliably go up or down smoothly but jumps around randomly.
Having had some prior experience with rotary encoders, I knew right away what the silly mistake was that the designers made, and how they could have prevented it at little or no additional parts cost. Just for fun, I also described the problem to ChatGPT, and bless her silicon heart, she figured it out too.
Would anyone like to take a stab at this question? What was the mistake, and how could they have kept these rotary encoders from getting jumpy after years of use?
When this machine finally does break down completely, I won't be getting another Gene Cafe. Not because of the problems above, but because of a new "safety" feature they added a few years ago where twice during the warmup, it beeps at you and you get 30 seconds to push a button to keep it going. I roast outside, and I like being able to ignore the machine for 16 minutes.
Is this not just the general issue with mechanical rotary encoders that they eventually have contacts that oxidize and interfere with operation?
https://www.modwiggler.com/forum/viewtopic.php?t=226170
very cool. If you're looking for machines to add, it would be awesome to model a cheap roaster based on a popcorn popper since it is probably less reliable than commercial sample roasters (and might benefit from less trial-and-error). During my undergrad I made an arduino-controlled popcorn popper that connected to the open source artisan software: https://github.com/lukeinator42/coffee-roaster.
100% agree - each roaster is slightly different, with different measurement schemes and other device peculiarities. This makes sharing coffee roasting profiles basically impossible!
I'm also working on letting people upload their roast profiles for training and serving their own models (including a "library" of bean models!).
As someone doing PhD in digital twins, I’m obliged to point out that this is a simulation, not a digital twin, as there is no two way data interchange between the models. Having said that, this is extremely cool and I love it.
I didn't know digital twin had an official definition. Could you please share a bit more on what makes a simulation a digital twin?
A 'digital twin' is a model that evolves over the lifetime of a physical asset. So if the state of the real device changes, so does the model (data assimilation). Likewise, one can use the model for control/planning/"what-if" scenarios. This is the bi-directional information flow that's being mentioned.
So what I'm showing on the website is just the model part. I'm not a fan of exposing my hardware in a public demo (the digital twin part), but the idea is that this model evolves with the roaster during the roast (data assimilation) and can help the operator guide the roaster to a desired end goal (e.g. medium roast along some profile or with minimal energy usage).
From Wikipedia:
> A digital twin is a digital model of an intended or actual real-world physical product, system, or process (a physical twin) that serves as a digital counterpart of it for purposes such as simulation, integration, testing, monitoring, and maintenance.
> A digital twin is "a set of adaptive models that emulate the behaviour of a physical system in a virtual system getting real time data to update itself along its life cycle. The digital twin replicates the physical system to predict failures and opportunities for changing, to prescribe real time actions for optimizing and/or mitigating unexpected events observing and evaluating the operating profile system."
Digital twins are bidirectional.
Change something in real life, thebdigital twin changes.
Adjust something on the twin, and so adjusts the real machine.
Not trying to knock your project, which is executed very nicely, but it does make me wonder where the boundary of human-ability quality discernment lies, beyond which is audiophile territory. Is “bean physics” the event horizon? Can you really tell the difference in a double blind test? If so, that’s amazing!
Does it run on Java?
Super interesting. I had plans to do something similar with my roaster but life got in the way as always. What are you roasting on? We just purchased a venta18 and my goal this fall is to get it hooked up with PID. Something like this could be very useful for tuning
Coffee grounds are compostable. Re: collectd-python-plugins, LoRA, MontyHome BLE + a Pi: https://news.ycombinator.com/item?id=42200099#42201207
A Tuboencabulating Roaster
Gotta admit, when I read "digital twin" I though it was the kind that Nvidia likes to show off. Would be really awesome future work if you were able to pull that off. I mean, this already super cool! but you know, gaussian splatting...
You could interface with an Artisan LCD maybe? I’ve got my 1 lb drum roaster hooked up to that and watch the degrees-per-minute display to estimate the roast curve.
this is nuts! beans? whatever, it’s super cool!
Did i win?
>Drum 745°C
Keep going! Getting close to the melting point of Stainless 316 (1400C? I forget.)
I'm curious -- did you make the interface with Claude? I have a hunch you did, can you confirm/deny?
Yes! Claude created nearly all of the interface.
I had Claude make a web interface and it was very similar stylistically. Looks like Claude has some design preferences of its own!
This is one of the nice thing i saw today!
super cool
cool!
cool
[dead]
[dead]
[dead]
There is a perfectly good word for this. Simulation.
Can we stop using the expression "Digital Twin" ?