
A few months ago, a gym chain in the UK came to us with a problem. Their members were losing keys and forgetting locker combinations. They wanted something better — a locker that opened with facial recognition, tracked inventory, and integrated with their membership system.
We said yes. Here's how we built it.
We started with a Raspberry Pi 4 as the main controller. Why not an ESP32 or nRF52? We needed USB camera support, decent local AI processing, and the ability to run Python-based inference models. The Pi gave us that without needing a separate compute module.
For the locking mechanism, we used 12V solenoid locks with a relay board controlled via GPIO. Each locker bay got its own solenoid, with a current sensor on the 12V rail to detect if a lock was jammed or forced open.
The camera module was a standard USB 1080p webcam mounted above the locker bank. We run face detection locally using OpenCV with a lightweight LBPH (Local Binary Patterns Histograms) model. No cloud calls for recognition — everything stays on-device.
The enclosure? We designed a custom 3D-printed bezel in Fusion 360 to hold the Pi, relay board, and a 5-inch TFT display. Our mechanical team printed it on a Prusa MK4 using PETG. Took three iterations to get the camera angle right.
We wrote the main control loop in Python, running on Raspberry Pi OS Lite (no desktop overhead). The flow is straightforward:
For the vending machine for gym use case, we added a weight sensor (load cell with HX711 ADC) under each locker bay. When a member places an item inside, the system logs it: what bay, what time, what item (based on weight signature). If the weight changes unexpectedly, we flag it for staff review.
We also built a simple REST API using Flask. The gym's existing membership system pings this API to enroll new users, revoke access, or pull usage logs. The API runs on a separate thread, so the locker control loop isn't blocked by HTTP requests.
The "AI" here isn't flashy — it's practical. We trained the face recognition model on about 50 images per user, taken under different lighting conditions. The gym has fluorescent overheads and some natural light from windows. We captured images at 6 AM, noon, and 8 PM to cover the range.
Recognition accuracy hit 97% in testing. False positives happen when two members look very similar (siblings, for example). We handle this by requiring a secondary PIN entry on the TFT display after face match. It adds two seconds to the unlock process but kills false opens.
For the vending machine for gym scenario, we added a simple inventory prediction model. It tracks which items (towels, supplements, etc.) get taken at what times of day. After two weeks of data, it predicts restock needs with about 85% accuracy. The gym manager gets a daily email: "Restock protein bars in Bay 4 — predicted depletion at 3 PM tomorrow."
The Pi draws about 3W idle, 6W under load. Solenoids pull 1A each during activation. With 12 bays, simultaneous unlock could spike to 15A. We added a 20A PSU and a capacitor bank on the 12V rail to handle transients. Each solenoid's relay is driven by a ULN2003 Darlington array — cheap, reliable, and handles inductive kickback without extra flyback diodes.
Thermal management matters. The Pi's CPU hits 75°C under continuous camera inference. We added a small heatsink and a 40mm fan running at 5V. Without it, throttling kicked in after 20 minutes and recognition latency went from 300ms to 1.2 seconds.
USB camera latency is real. The webcam introduces about 100ms of buffer delay. We switched to a camera with hardware JPEG encoding (Logitech C920) and dropped the resolution to 640x480. That cut latency to 40ms.
Weight sensors drift. The HX711 modules we bought from Amazon had inconsistent reference voltages. We calibrated each one manually using known weights and wrote a calibration routine that runs every 100 unlocks. Drift stays under 2 grams.
Every smart locker vendor we've seen pushes cloud-based face recognition. That means sending face embeddings to AWS or Azure, waiting for a response, and hoping the internet doesn't go down. For a gym locker, that's unacceptable. Members expect instant access, not "please wait... connecting to the server."
Running inference locally on the Pi means zero latency, zero cloud costs, and zero privacy concerns. The gym owns all the data. We encrypt the face model files with AES-256 and store them on an encrypted SD card. If someone steals the Pi, they get a brick.
We ship prototype hardware and firmware in 4-6 weeks. If you're looking for an Arduino coder for hire or a full embedded systems team, we do that too. Our engineers have shipped products using nRF52, ESP32, STM32, and Raspberry Pi. We handle PCB design in KiCad, 3D design in Fusion 360, and firmware in C, Python, or Zephyr RTOS.
The smart locker we described is now deployed in three gyms. It's been running for six months without a single failure. The gym chain is planning to roll it out to all 12 locations.
If you have a project that needs hardware that actually works, drop us a line. We'll tell you if it's feasible, what it'll cost, and how long it'll take. No fluff, just engineering.
The decision to keep face recognition on-device instead of relying on cloud inference stood out to me.
For something people expect to work instantly, reducing dependency on network connectivity feels like a product decision as much as an engineering one.