The Vision

We have all been there standing in line on a hot summer day, waiting for a frozen treat. Without question, there are a countless number of inefficiencies in the world and problems to solve. For some reason, we decided on ice cream. The goal here was to make the freshest small batch ice cream in the most automated, scalable manner possible. What I’m talking about is beyond a vending machine, beyond a batch freezer, beyond a point of sales system. This was a robot.

A machine capable of carrying out a complex series of tasks all focused on the manufacture, sale, and distribution of ice cream. The possibilities here were limitless, far beyond what could be accomplished by a person or even a group of people. You and your best friend may both have the same favorite ice cream: vanilla with chocolate chip cookie dough. But it’s likely your preferences deviate in ways that can’t be addressed by mass manufactured ice cream. Designed especially to be as pleasing as possible to as many people as possible, but not designed with a specific person in mind.

Imagine, if you can, the power of artificial intelligence and modern technology focused on your taste preferences for a single type of food. We’re not talking plain old market basket analysis the way companies like Amazon predict the next thing you’re going to buy. We’re talking about a deep intimate knowledge about the things you love, all the way down to minute detail. How thinly sliced do you like the almonds when you have them mixed into your caramel ice cream? Do you like your ice cream prepared at a different temperature to create a slightly different texture? Do you have special dietary needs that you have to inquire about every time you’re out to eat? Imagine now when you’re ordering dessert that the person preparing it knew all of this and more.

That was the dream at least... not the best ice cream in the world, but the best ice cream for each individual.

If We Can Build a Fridge, We Can Build Anything...

So, with our minds racing about frozen dairy delights, we set out to get started. Our educational and professional background has been almost entirely focused on software development, and we decided to take an "agile" approach. We would build the robo and the surrounding business in a series of revisions. Start small with something that proved it was possible, and then incrementally improve until we had something great.

The approach, perhaps, was sound in theory. In reality, we had jumped into the deep end... We made a plan to build hardware we had no idea how to build, and adopted the motto "If We Can Build a Fridge, We Can Build Anything". Revision 1 was to include a refrigerated box, a pump that would put milk into an ice cream machine, and some software that could turn things on and off at our command.

With our background in carpentry and lumber prices being what they were at the time, we settled on wood as the obvious way to make most things. Here is our insulated box made out of scrap fencing material sitting on top of a lacquered (to improve food safety) wooden frame.

And another excellent photo of Matt following proper safety protocol before plugging in our compressor for the first time.

Needless to say, this fridge we attempted to build never worked. After much hard work studying up on refrigeration, becoming EPA Section 608 certified, and brazing copper tubing together, the machine did absolutely nothing. Stone dead and silent, the "fridge" mocked us.

We recognized our failure and decided we would later try to buy a fridge. To finish our first revision, we would wrap up the remaining steps of what we deemed necessary for an MVP. To augment our wooden frame of a robot and bring it to life, we would need a microcontroller and some software. Being developers for our entire careers, this ended up being the part of the project where we would shine the most. We got an Arduino and went to work making all the components of the architecture diagram you saw earlier. There were three main pieces of software we wrote to make this work...

Command Service and Operator Interface

A web application which issues commands to the robot and provides a GUI for operators. This would allow customers to place orders for ice cream and give us an admin panel to manually manage the robot.

Controller / Middleware

The middleware was an application running on a computer which was part of the robot. This application polls the command service via an API. This application also communicates with an Arduino through serial to allow us to interact with the physical world. The middleware would accept and handle high level commands like running a clean cycle.

Firmware

This runs on the Arduino and is responsible for maintaining the robot in a safe idle condition. It also processes basic commands which are issued in batches by the middleware. The firmware commands were lower level like turning on a pump for a certain duration.

Rev 1 Finishes and a Tradition Begins

So, we didn't build a fridge, but we did have the beginnings of a robot. In the garage sat a special wooden box that was connected to the Internet. It would wait until it was directed to make ice cream, the result of a "customer" placing an order on our website, and it would run a pump to dispense liquid dairy product into an ice cream machine which would run for a preset period of time. Very proud of what we had accomplished, we decided each revision of the robot would end with an ice cream social. We would invite friends to come have a pint and some beers taking the opportunity to show off our progress.

Reviewing the bill of materials shows that we were just shy of $1,000 deep into this project already. Most of the expense was spent on the failed attempt to make a fridge from scratch... a compressor, a vacuum pump, a manifold gauge, copper tube expanding tools, and the prettiest nitrogen tank you've ever seen.

Multiple Flavors and Another Attempt at Keeping Things Cold

The major goal of this 2nd revision was to construct a linear rail which creates support for multiple flavors of ice cream. The linear rail would move an actuator and pump between jars containing different flavored ice cream bases. The robot would then place the customer's selected flavor into the ice cream maker.

Having multiple flavors at the ready for multiple batches meant jars with milk product would be potentially sitting out for several hours. This, of course, introduced the requirement of holding the product a safe temperature. This time, instead of trying to build our own fridge, we decided to enclose the interior part of the wooden frame housing the linear rail and jars. We would then insulate this space and route duct work to a chest freezer where cold air could be sourced.

Linear Rail

With various ice cream flavor bases stored in jars, we would need some way to move a pump between them. This is the problem the linear rail was meant to solve in our Rube Goldberg machine of an ice cream maker. The idea is that a tube would be attached to the platform and lowered into the appropriate jar. Here's an early iteration of the linear rail when we first got things moving.

Frame to Fridge Conversion, Jars, and an Actuator

Once the linear rail had moved the platform to be positioned over the jar with the customer's desired ice cream flavor, we needed some means to lower a tube into the jar to suck up the product. Matt, in a sudden bout of passion, just showed up at my house with an actuator he had made himself. The thing was shockingly refined and functional for something held together with JB Weld. We mounted this actuator to the platform on the linear rail and also added a project box to contain the wire mess. With a variety of switches, we gave the linear rail the smarts to know when it reached the edge or when it was positioned by a jar. Finally, we boxed in the entire frame, insulated it, and attached it to a chest freezer that we use to pump in cold air. Here you can see all these pieces starting to come together...

We had another ice cream social and called it for rev 2!

Robo Revision 3

I'm sure you are left wondering how we could possibly continue to improve after the pinnacle that was our second revision. Allow me to introduce revision 3... Up to this point, the first questions we would always get were "is this safe to eat out of?" or "it's made of wood?". Matt had a fear of feeding this ice cream to his own grandmother, so people were probably onto something. In an effort to not kill our friends and family, revision 3 would be dedicated to improving food safety.

This revision introduced a peristaltic pump instead of the initial one which would sometimes leave behind plastic flakes in the food product. A peristaltic pump operates by squeezing the tubing carrying a liquid from the outside unlike a traditional pump which has some sort of rotating inner component with fins (lots of places to trap food product). We made a number of changes like this essentially trying to target ANY food contact surface to make sure it was something that could easily be sanitized.

We had also been having a lot of trouble with bad or low-quality relays throughout this, and decided that we needed a more elegant solution. We ended up constructing a rack mounted relay box that had 120V and 12V outlets all of which could be turned on or off via a DB15 plug connected to our microcontroller. I think this is one of the pieces that we were most proud of making. It turned out looking very polished and worked better than most of the hardware we had tried to build before that.

It was around this time too that we started trying much harder to design our physical components with a lot more intention. We would draw up actual CAD drawings like big boy grown up engineers, and we were much better about precision when it came to actually making these things.

If I recall correctly, Matt's grandmother had a to-go pint of peach ice cream from our third ice cream social and suffered no gastrointestinal upset. I'm sure a health inspector would have shut us down in the blink of an eye, but we were doing much better.

The Software Revision

For our fourth revision of the robo, we decided to pause on hardware changes and make the software a little more robust. We had a better idea at this point of how things should have been done, and took the time to rewrite/refactor some things. We set up continuous deployment for our website (the one you're on now actually) and changed the API it hosted to better accommodate the way we were sending batches of commands to the robot. The website also ended up getting a slick real time (SignalR) admin panel that would show us what the robot was up to.

On the robot itself, the app running on the robot computer that issued serial commands to the microcontroller was significantly expanded. It now had a GUI and would log diagnostic information to a sqlite database.

While all of this was cool and made the robot work better, this was an easy low effort revision for us. As professional software developers, we kind of set the bar low on this one. We were losing steam and needed an easy win. This one wrapped up pretty quick, but didn't feel we had done enough to justify another ice cream social.

The Final Revision That Was Not to Be

The fifth revision was going to be an ambitious one where we would replace the store-bought ice cream maker with a batch freezer. We wanted to have automated in and out for the batch freezer which would have the robot in a state close to allowing for near continuous production of ice cream.

We never got past the planning stage on this revision. The cost and complexity of doing what we wanted was starting to intimidate us. This was also around the time I (Baer) was going to start grad school, and lose a lot of free time for the next two years. Ultimately, the robot sat the garage accumulating dust until it was finally disassembled when I moved a few years later.

So if you were wondering why we didn't publish games for a couple years, it's because we were building a robot.

Good night, sweet prince.