Context
The brief for this machine-design assignment was open-ended: build a machine that combined mechanism, actuation, and automation as a team, and document both the group build and each member's individual contribution. The team chose a vending machine because it forced CAD, CNC fabrication, electronics, programming, and mobile/wireless work to interlock rather than operate in isolation.
That interlocking is what made it a genuine systems project rather than five separate assignments stapled together: a fabrication delay on the enclosure would stall electronics integration, and a firmware bug in the barcode parsing would stall the mobile-payment testing, so the team had no choice but to coordinate the workstreams closely from the start.
02Solving for a real local pain point
Beyond the mechanical challenge of six independent dispensing units, the team wanted to solve a genuine local pain point: cash-based vending is awkward in Pakistan. Customers often lack exact change, shopkeepers struggle to make change, and queues can become long in high-traffic settings like university cafeterias where a simple chocolate purchase should not take minutes.
The machine needed a cashless purchase path without depending on card payment infrastructure unavailable in those settings — which ruled out the obvious card-reader solution and pushed the team toward something built around infrastructure that was actually already in every customer's pocket: a mobile phone and a prepaid SIM.
03What was built
Work was split five ways: CAD modeling, CNC milling, electronics, programming, and the wireless/mobile application layer. The body went through two fabrication passes. First, a laser-cut 4mm cardboard prototype validated the CAD joints and press-fits. Then the final body was milled in 16mm laminated MDF on a ShopBot, with the front panel cut separately in acrylic.
Six 360° continuous servos — hand-converted from standard 180° servos because true continuous-rotation servos were not available in the lab — powered six dispensing slots. Product selection ran through a 16x2 LCD and an HC-05 Bluetooth module bridging into the mobile payment side of the system. Each product had its own vinyl-cut barcode. A customer used a phone app called Scan to Arduino to scan the item they wanted; the app sent the code to the machine over Bluetooth, which then dispensed the matching item and displayed confirmation and thank-you messages on the LCD.
Payment rode on a telecom-issued SIM-based prepaid credit flow through Jazz: users preloaded credit, each purchase deducted the item price, and confirmation arrived by SMS, eliminating the need for cash, card readers, or POS integration.
04System thinking
Control board
An Arduino Leonardo read incoming barcode-derived product codes over serial and drove the matching servo, LCD update, and dispensing sequence.
Product logic
The firmware mapped a small set of numeric codes to specific SKUs and triggered that slot's servo for a fixed duration before resetting and returning to an idle scrolling display.
Wireless bridge
The HC-05 module received the scanned barcode value from the phone and passed it into the Leonardo's serial buffer, where it was parsed and matched against the product table.
Mechanical execution
Each servo sat behind a dispensing slot, allowing one product to be released at a time while the machine remained compact and modular enough to iterate rapidly.
Results and lessons
The finished prototype dispensed products correctly against scanned barcodes and displayed live purchase confirmations, validating the core idea: a phone-scan-to-dispense flow riding on prepaid mobile credit, with no cash or card hardware required. The two-stage fabrication approach — cardboard proof followed by MDF/acrylic final — caught fit issues early and meant the CNC pass came out clean on the first attempt.
The project also reinforced the practical reality that constraints drive design. Converting hobby servos to continuous rotation, rather than sourcing different hardware, kept the six-slot design working within the lab's parts inventory. The team also noted real limits in the prototype: capacity was small, payment security was minimal, and large-scale deployment would require direct telecom cooperation. Those were realistic trade-offs for a concept prototype rather than a production rollout.