Vend-A-Shoe

System Overview

How the system fits together

A Next.js dashboard drops bin dispense commands into Supabase. A Raspberry Pi worker claims each row, drives MG996R servos off a soldered protoboard that also feeds eight LEDs and a cooling fan, then writes completed or failed. The harness was the product as much as the queue was; enclosure, power, and dozens of connections were in the loop from the start.

01

Enclosure & mounts

Onshape assembly with printed mounts, wire covers, and a laser-cut rear panel you can actually open again.

02

Power & protoboard

Wall AC to DC / USB-C PD into a soldered protoboard with common ground; one outlet path feeds servos, eight LEDs, the fan, and the Pi.

03

Harness

Forty-plus wires for motors, LED runs, fan, and control; lengths and service loops were design constraints, not cleanup.

04

Pi worker

Python process claims pending commands, maps bin to GPIO, runs PWM sweeps, persists status.

05

Command queue

Supabase device_commands with pending to running to completed or failed; the Pi never needs a public port.

06

Dashboard

Existing frontend kept in place; the new backend had to meet its API shape and show queue state clearly.

Data flow

UI insert; Supabase queue; Pi claim; GPIO and PWM; servos plus eight LEDs plus fan; status write-back.

Control flow

Only the worker owns actuation. The browser never talks to GPIO; claiming by status update keeps two polls from firing the same dispense.

Control path

Dashboard to queue to Pi to protoboard to servos, LEDs, and fan.

At a Glance

Timeline

1. June 11–17

   Pi bring-up, GPIO/PWM learning, first motor experiments, breadboard and bench-supply basics.

   What slowed it: New platform, unknown whether the motors were even good, no EE mentor in the room.

2. June 18–25

   Early end-to-end path that became fullvideoinitialdemo.mp4: one-motor / two-LED app demo, then more motors as replacements came online.

   What slowed it: Several motors were already dead. I kept rebuilding the circuit before a swap test proved the hardware was the problem.

3. June 23–30

   All four motors working with the app on breadboard; fan in the loop; started moving toward protoboard and wire-length planning.

   What slowed it: No protoboard in stock at first. Soldering tools were rough: dull iron, paste instead of wire, no fume extraction.

4. July 1–7

   Most wiring soldered and labeled; protoboard mounted; diagnosed SSH loss after a Wi-Fi reset changed the Pi's DHCP address; isolated a bad fan joint by substitution.

   What slowed it: Dynamic IP, borrowed-monitor dependency, dense harness rework.

5. July 8–15

   Wire bundling, CAD rear cover, wire covers, mounting, Pi screw-terminal connector, packaging for transport and service.

   What slowed it: I had already cut wire lengths before the layout fully froze, so the enclosure had to adapt to the harness.

6. July 18–25

   Only travel week. While I was away, a 24 V connection likely damaged motors. The team chased faults, including a failed alligator clip; replacements arrived.

   What slowed it: That overvoltage mistake was mine. Recovery was slower because there was almost no power-review process or spare-qualified actuators ready.

7. July 27–28

   Finalized USB-C PD / wall power, corrected LED color mismatch, cleaned up soldering and wire management, got all four motors / eight LEDs / fan running for the client demo.

   What slowed it: Too much of the last validation still sat at the deadline.

Engineering Breakdown

01Mechanical

Mechanical

Goal

Fit the dispense mechanism, Pi, protoboard, fan, and a dense harness in a compact box that still opens for service.

Design

Custom Onshape enclosure; printed mounts and extenders; laser-cut rear panel. Clearances and harness paths for motors, eight LEDs, and the fan drove the layout more than the outer silhouette did.

Challenges

• Four servo positions plus LED runs and a fan left almost no slack once the harness existed.
• Eight LEDs needed unique lengths; four per side at different heights.
• Wire lengths got cut before the mounting layout froze, so service access and cover clearance became a fight with a forty-plus-wire bundle.

Iterations

• CAD packing against real component envelopes, including fan clearance.
• Print, fit, remount cycles on brackets, covers, and extenders.
• Rear panel cut so cables and rework did not mean a full teardown.

Final implementation

Integrated mounts, organized routing, removable rear panel. It shipped as one assembly, not a pile of boards in a shell.

Full enclosure CAD

Packaging built around servos, LEDs, fan, Pi, and harness; not a generic box.

Printed extenders

Printed parts that made the dispense geometry and mounts fit the real box.

02Electrical

Electrical

Goal

Take a normal AC wall outlet, convert it to usable DC, and power the protoboard, 4 MG996R servos, 8 LEDs, the fan, and the Raspberry Pi from that one path without brownouts or sketchy grounds.

Design

Bench supply for bring-up; multimeter checks on rails and grounds before trusting a channel. Then a wall AC to DC / USB-C PD path into a soldered protoboard with common ground so the whole unit can leave the bench. This was one of the clearest electrical lessons from the internship: wall power is not just plugging something in; it is conversion, distribution, and load budgeting. Actuator and accessory current stay off the Pi GPIO path; GPIO only signals.

Challenges

• We planned for four motors; a few were already fried and just sat dead. Later I connected the system to 24 V during a power mix-up and likely damaged more. Sorting wiring versus software versus dead hardware became its own debug loop.
• Eight LEDs and a fan added continuous load on top of the servo harness; the wall converter and protoboard had to feed all of that plus the Pi.
• Shared Pi power sagged under multi-servo moves; breadboard contacts lied; forty-plus wires made routing a design problem, not a cleanup task.
• No experienced EE mentor, dull soldering iron, solder paste instead of proper wire, and no fume extraction. I was also teaching a teammate basic circuits while trying to bring the board up.

Iterations

• Bench PSU for controlled bring-up; multimeter on voltage drop, continuity, and common ground before rewriting PWM code.
• Swap-test motors and channels; watch LED and fan rails while servos move.
• Soldered protoboard for permanence; wall AC to DC path so the packaged unit runs from a basic outlet.

Final implementation

One wall outlet path into DC distribution on the protoboard. That rail powers the motors, eight LEDs, the fan, and the Raspberry Pi in the shipped assembly.

Wall AC to DC

AC wall outlet into DC for the protoboard. Same path feeds the motors, 8 LEDs, fan, and Pi.

Protoboard front

Soldered permanence after the breadboard stopped being trustworthy.

03Embedded

Embedded

Goal

Turn a queued cloud command into one clean dispense motion and a status you can trust.

Design

Raspberry Pi 4; Python worker; RPi.GPIO PWM. Parses dispense_bin_n, applies per-bin target duty, returns home. systemd keeps the worker up across reboot.

Challenges

• A silent motor looks identical to a bad pin map until you meter the rail, swap hardware, and prove which layer failed.
• SSH disappeared after a Wi-Fi restart because DHCP handed out a new IP. It looked like a deeper OS failure until the address changed.
• One shared motion profile over-rotated Bin 3.
• Crashes mid-run left ambiguous state until running existed.

Iterations

• Standalone scripts on the bench; channel swap tests before blaming software.
• Polling worker with a single dispense action.
• Four-bin map, duty overrides, systemd unit.

Final implementation

Claim-by-status worker with bin to GPIO mapping and calibration hooks. The unit wakes into a working loop without a laptop attached.

First working motor

Known-good channel proof before scaling to four lanes.

Pi motor bring-up

GPIO and PWM on the Pi once the channel and the motor were both known-good.

04Cloud & Integration

Cloud & Integration

Goal

Remote dispense without exposing the Pi, while keeping the frontend that already existed.

Design

Supabase queue as the boundary. New backend bent to the existing Next.js UI instead of rewriting the client.

Challenges

• API shape had to match an independently built frontend.
• Polling delay versus double-fire under concurrent claims.
• Cross-stack failures only showed up end to end.

Iterations

• Local-only GPIO scripts.
• Cloud-connected single action.
• Multi-bin queue plus UI status badges.

Final implementation

Browser click to durable row to physical dispense; completed and failed show up where you already look. The cloud path is software and queueing; wall AC to DC power lives in the electrical section.

Key Design Decisions

When It Broke

Evolution

What Took Time

Version 2

1. 1

   Freeze the requirements

   Actuator count, LED behavior, fan, wall input, connector locations, service access, software interface, acceptance tests. One-page diagram and a power budget before cutting wire.

2. 2

   Qualify every actuator first

   Bench-test every servo, LED pair, fan, and converter. Label PASS/FAIL. Keep one golden channel.

3. 3

   Prove one complete lane

   Protected bench supply with current limit. One servo + LED + queue + status write-back for dozens of cycles before scaling to four bins.

4. 4

   Freeze power, then build the board

   Rails, fusing, ground, connectors, gauges. Power review before energizing everything. Prefer a KiCad distribution PCB once the map is stable.

5. 5

   Harness, package, validate

   Cut list, labels both ends, continuity as you go, then mounts and covers. Written test matrix: each bin, reboot, Wi-Fi reconnect, tug test, thermal check.

What This Built

Reflection