This project started in grad school as an excuse to use the 3D printer that my friend had just purchased - a DaVinci 1.0A which I modded with the Repetier Firmware. We were both excited about it and wanted to build something.
You can skip to the GitLab page here
Initial Concept
We started our design by first looking at other similar projects. We stumbled across one called the BarMixvah and decided we would start out by copying that design since it was fully open source. We fired up the 3D printer and started churning out the parts. We purchased steel rods from Blue Collar Supply in Elk Grove for cheap to use as the frame and we purchased some peristaltic pumps on Amazon. The BarMixvah was the creation of a front-end engineer, he ran a nodeJS server on his computer connected to an arduino and had some javascript libraries to send commands to an arduino which controlled the peristaltic pumps. I wanted to take my own spin on things - and have an excuse to learn something new - so I started working on a new software architecture for the system.
Choosing frameworks
I am not a web developer. I have dabbled in some small creations here and there but barely scratched the surface of any web development work beyond following tutorials. I decided this was a good chance to get my hands wet and learn a thing or two so I started researching frameworks for the front and back ends of the system. The only thing I really knew going into this was that I wanted the back end to be in Python since I know that much better than the few javascript tutorials I have done.
I ended up decided on Flask for the backend because it seemed simple yet extensible enough for my purposes. For the front-end framework I decided on React after trying out small tutorials on Angular, Vue, and React and deciding that React just ‘clicked’ with me better than the other two, Reacts model of passing props and modifying state just seemed fairly inuitive to me and I liked the amount of support that was behind it.
For the database model I decided to use SQLite with a SQL Alchemy interface since I know nearly nothing about SQL.
After following some more Flask and React tutorials I got a basic site up and running with a basic database. Upon loading React would query Flask for a list of drinks, Flask would get these from the database and pass the mup to React which would render them each in their own little boxes. Each box would have buttons to make the drink or modify the ingredient ratios/amounts.
Database Design
The databased design for Bartomaton was a little tricky for me since i’ve never worked with any databases, but I knew what kind of architecture for it I needed. There would be many drinks, each with a list of ingredients and amounts for each ingredients. These Drink Ingredients would need to know which (if any) dispenser would dispense it. I made the assumption that a single ingredient would only be loaded into one dispenser but if need be this relation can be modified to get many dispensers for a single ingredient, and choose which one to use based on some other criteria (such as some sensor or mechanism which determines how full each dispenser is). Each Drink Ingredient maps to an ingredient entry which maps to a Dispenser entry (or None/null if no Dispenser currently has that ingredient). In additon the Ingredient entries have one to many relationship that can be used to query all drinks that use this ingredient, allowing one to filter down any possible drinks based on the loaded ingredients. The Dispensers need to know which output of the multiplexer to map to so each has a gpio_id which determines where the multiplexer outputs the signal to the motor relays. This formed a relatively simple database structure:
Mechanical System Architecture
I knew we wanted at least 8 liquids and driving that many motors was impossible from the Rasperry Pi directly. Instead of using 8 relays connected to 8 different GPIO I decided to use a multilexer. The drawback to this was that only one ingredient could be pours at a time.
We started out with peristaltic pumps but realized quickly that cheap peristaltic pumps are far too slow to make a drink quickly (pouring at about 2.5 mL/s), we either needed beefier peristaltic pumps or change how we delivered the liquid. My mechanical engineering friend went to work and designed a new system architecture wherein the different liquids would be pressurized with air pumps and the liquid would flow out when we turn a valve. This required us to actuate valves but increased the pouring speed by nearly an order of magnitude (at full pressure). The other drawback to this is that we needed a new way to measure the amount poured, since peristaltic pumps are very linear in the amount they dispense vs their actuation time, this air ressure based architecture would vary depending on a lot of factors. As a result we needed some pressure/weight sensors under the glass to detect how much was dispensed.
Since the movement to air pressurized cannisters with servos to actuate the valves required a small change to the database as well. Now a dispenser is by two different peripherals, one pump_id which defines which air pump is used to pressurize the ingredient cannister as well as another servo_id which maps to which serve must actuate to release the ingredient.
It was during this abandonment of the peristaltic design that we also dumped the design files for the BarMixvah as well and decided to make our frame out of linear rails that we had left over from another project.
All parts of the system that the liquids touched were rated food-grade or higher (blood-grade in the case of the cannisters).
Hardware
The main brain of the Bartomaton is a Raspberry Pi 3 which runs the webserver and controls peripheral devices over the GPIO. The Pi interfaces to a board I designed in KiCAD which contains four half H-Bridge motor driver ICs each with two paired outputs (for up to 16 unipolar outputs total) as well as an I2C bus to a PWM peripheral that can manage up to 16 PWM signals to control the servos.
Initial Tests
With the bare-bones completion of the Bartomaton it was time to get an initial test of the system.
This test only used a timer to decide how long to actuate the servos and release the fluid. The weight sensor was not currently working - although you can see it through the clear acryllic bottom underneath the nozzle.
The next step is to get the weight sensor working with fast enough response to accurately stop the dispenser from pouring after a certain amount of each ingredient is poured.