Akash Patel / Mechanical Engineering

Project 05 · Build note

Automated Drink Pourer

Fill a line of cups automatically: a 2.5-DOF Cartesian gantry plus a peristaltic pump, pivoted halfway when icing proved unpumpable.

Context
BU ME 360 (Engineering Product Design)
Date
Fall 2023
Team
4 people
Duration
~1–1.5 months
My scope
Peristaltic pump design (owner) · X/Y Cartesian axis design (co-owner with a teammate)
Status
Gone — the machine hasn't existed for years
Degrees of freedom
2.5 (X, Y + pump on/off)
the half is the pump — dispense or don't, deliberately no Z axis
Timeline
~1–1.5 months
with the pivot from icing to drinks made halfway through it
Team
4 students, self-funded
no class budget — every part came out of our own pockets
Final demo
2 cups filled by one G-code run
the pass/fail proof that axes and pump worked as one system
Watch one G-code run do the whole job: the gantry steps to each cup, the pump switches on to fill and off to move — the half degree of freedom at work.

ME 360 — Engineering Product Design, Fall 2023: four of us, around one to one and a half months, and no class budget — everything we bought came out of our own pockets. The assignment: a 2.5-degree-of-freedom Cartesian system — X and Y motion plus a third degree of freedom that is only on or off, not a Z axis like a 3D printer. I owned the peristaltic pump; a teammate and I owned the X and Y axes; another teammate wrote the G-code with me assisting — and beyond that, everyone sort of had their hands on everything.

The icing failure that made it a drink pourer

The original use case was an automatic cookie decorator, with icing pumped up from a reservoir below rather than squeezed from a container riding on the gantry.

On a dry or cold day, the icing was essentially a solid.

The icing’s viscosity was that inconsistent — it pumped only a little, nowhere near controllable dispensing. I hadn’t thought about possible modes of failure at the start, and it led to this one. Halfway through we made the call: cut the cookie use case and point the pump — pretty much fully developed by then — at a drink it could actually handle. Pivoting off that failure is what made the project succeed, and I’m still proud of that call.

Tuning pump compression by reprinting the housing

We went peristaltic because it can pump liquid out of any chamber — a bottle, another cup, anything. The pump is bearings rolling over silicone tubing in a 3D-printed housing; the bearing-to-tubing gap sets the compression, and getting it right was the one major point of failure — over-compress and you block flow, under-compress and you don’t make enough pressure. Printing the housing made each change cheap — adjust the spacing in CAD and reprint — and it took five printed housings to land in the window that produced reliable flow.

The demo: two cups on one G-code run

The test was the demo: line up the cups and run the G-code — raw G-code, written by hand for the cup layout and run on an Arduino — moving the axes and switching the pump.

Axis bring-up: first motion from the hand-written G-code on the Arduino — the same setup that later carried the pump head between cups.

The G-code ran and both cups were properly filled — a pass/fail result; flow rate, fill accuracy, repeatability, and our out-of-pocket spend all went unrecorded.

Requirement Target Achieved Verified by
2.5-DOF Cartesian system — X, Y, plus on/off only 2.5 DOF, no Z travel as specified final demo
Fill multiple lined-up cups at the locations written into the G-code no numeric target stated 2 cups properly filled running the G-code, pass/fail

What I’d change is the team structure: hands-on-everything was good for gaining technical knowledge at that stage, but today I’d give each person a distinct subsystem to own and become expert in, then integrate.

The build