Project Logs

Collapse

• Real Video

  Himanshu Dada • 29 minutes ago • 0 comments

• About Project

  Himanshu Dada • 32 minutes ago • 0 comments

  We don’t do flashy branding here. The client’s gym logo appears on the e-paper display during idle mode. Our logo—a simple circuit trace forming a “D”—is etched into the PCB silkscreen and embossed on the steel enclosure door. That’s it. If the machine works, people don’t care about logos.

  How It Actually Works 

  The ESP32 runs three main FreeRTOS tasks:

  1. Sensor polling task – Reads all 24 load cells via two HX711 multiplexers (we used 74HC4051 analog muxes to save GPIOs). Polls DS18B20s every 5 seconds. Updates e-paper display every 60 seconds (e-paper is slow, but it draws zero power otherwise).

  2. Payment and dispense task – Listens for NFC tap or QR scan. Sends member ID to cloud via MQTT. Cloud returns available balance and recommended items. ESP32 lights up the corresponding slot’s RGB LED green. User presses physical button to confirm. Stepper motor rotates dispensing wheel 180 degrees. Product drops. Load cell confirms weight change. If no change detected (jammed), retries twice then marks slot as faulted.

  3. Cloud sync task – Publishes inventory levels, temperature, and fault status every 60 seconds. Listens for OTA update commands, pricing changes, and remote lock commands. Runs on a 30-second watchdog timer—if it misses a heartbeat, the machine goes into safe mode (no dispensing, only reads).

  The PCB we designed in KiCad has screw terminals for every sensor and motor connection. No JST connectors that can vibrate loose. We learned that lesson on an earlier project.

  The One Thing That Almost Broke Us

  Load cell calibration. Twenty-four load cells, each with a different zero offset and sensitivity. We tried auto-calibration with known weights—too slow. We tried factory calibration values—too inaccurate.

  Solution: We wrote a calibration routine that runs during manufacturing. Place a 100g reference weight on each slot, press a button, firmware stores the offset and gain in NVS (non-volatile storage) on the ESP32. Takes 3 minutes per machine. Accuracy is ±2g. Good enough to detect a missing 50g protein bar.

  Conclusion

  This wasn’t a moonshot. It was a straightforward ESP32 project with careful attention to mechanical reliability and power management. The client got working machines in 12 weeks. Members get snacks they actually want. The gym chain is planning to deploy 50 more units across their locations.

  The full design files—KiCad schematics, Fusion 360 models, firmware source, and PCB Gerbers—are available on our GitHub. If you’re building something similar, start with the load cell calibration routine. That’s where the pain lives.

  Want the Gerber files? Email us. We’ll send them over. No NDAs, no sales pitch. Just a zip file and a note saying “good luck.”

  If you're considering a personalized vending machines deployment, start with the user profile system. The hardware is straightforward. The firmware is manageable. But the personalization logic — that's what drives adoption.

  We shipped fully assembled prototypes to the client within 8 weeks of kickoff. PCB, enclosure (3D printed in PETG for the first run), firmware, and cloud backend. If you need a vending machine for gym that actually sells product, the recipe is simple: ESP32, MQTT, and a recommendation engine that learns from real behavior.

View all 2 project logs