AutoRejection

Industrial low-fill can rejection with hardware, software, and brewery-line constraints.

AutoRejection combined load-cell measurement, custom PCB work, Raspberry Pi control, Node-RED automation, AWS IoT, and a Wi-Fi dashboard to reject underfilled cans at production-line speed.

What it solves

Breweries need to detect and reject low-fill cans without slowing the canning line or forcing operators to watch every pass by hand.

AutoRejection measured can weight in motion, tracked historical data, exposed calibration and production views over Wi-Fi, and triggered pneumatic rejection hardware when cans fell outside the accepted range.

AutoRejection front render Front cabinet and product path
AutoRejection top render Top view of conveyor and reject area
AutoRejection back render Back view of service access
AutoRejection load cell PCB Custom load-cell PCB

Who this is for

  • Breweries running automated canning lines
  • Equipment partners integrating with existing machinery
  • Operators who need calibration, monitoring, and exports
  • Engineers building real-world hardware/software products

What it does

AutoRejection was a side project that became a business concept under MAP Equipment. I worked on it for most of a year with a business partner, Wild Goose Filling, and local breweries in the Bozeman area.

The machine weighed cans as they crossed the scale, rejected underfilled cans with pneumatic hardware, showed live and historical weights in a custom dashboard, exported CSV data, and used AWS IoT for updates and remote data storage. It ran on a Raspberry Pi with encrypted storage, a ZYMKEY real-time clock, separate 5V and 24V supplies, and a UL-listed stainless cabinet.

Workflow covered

  1. Measure and classify - read load-cell values in motion, stabilize the signal, and compare each can against calibrated thresholds.
  2. Reject and monitor - trigger the pneumatic reject mechanism, show live weights, and give operators a clear dashboard for current line state.
  3. Calibrate and report - tune the scale, review historical graphs, export CSV data, and support OTA updates through the connected system.

Technical highlights / stack

Control
Node-RED Node.js JavaScript Raspberry Pi
Hardware
Load cell Custom PCB Arduino Pneumatics
Interface
UIBuilder Wi-Fi dashboard CSV export
Operations
AWS IoT AWS RDS ZYMKEY UL cabinet

Why it matters

This project forced software decisions to survive physical timing, wet environments, manufacturability, partner schedules, support needs, and operator workflows. Code was only one part of the product.

Technical notes

Signal quality The scale had to read fast enough for production speed while still filtering vibration and product motion.
Line integration Wild Goose integration required separate mechanical variants and repeated prototyping around can flow.
Operator UI The dashboard needed live state, calibration, historical graphs, and CSV export without requiring wired access.
Security tradeoffs Encryption and remote update support were valuable, but too much security early slowed hardware iteration.

Hard parts

  • Reliable weight measurement and rejection at 50+ cans per minute.
  • Designing for moisture, temperature changes, vibration, and brewery use.
  • Coordinating machine variants with Wild Goose Filling and brewery staff.
  • Balancing AWS connectivity, encryption, cost, manufacturability, and support.
  • Developing custom load-cell hardware with local engineering and PCB partners.

Engineering takeaways

  • Rapid hardware iteration matters more than architectural completeness.
  • A simpler ESP32-style design may have served the product better than a Pi plus AWS stack.
  • Industrial products need documentation, support planning, and contracts, not only working code.
  • Partner and customer alignment determines whether good prototypes become sustainable products.

Current scope

Built

  • Standalone machine variant
  • Wild Goose line variant
  • Dashboard and calibration flow
  • CSV data export

Hardware

  • Load-cell PCB
  • Raspberry Pi control
  • Pneumatic rejector
  • 5V / 24V cabinet power

Business result

  • 10 total units sold
  • 5 purchased by Wild Goose
  • Most work remained prototype-heavy
  • Strong lessons for future hardware products

Related work

MicrophoneController Small hardware interface with HID firmware constraints. QMK Nexus Hardware-adjacent workflow tooling for firmware builders. DBFirstDataGrid Operational data UI driven by backend metadata. PersonalSite The case-study system that documents the machine work.

What to do next

Open the dashboard demo or watch the prototype clip if you want to see the operator workflow and physical rejection path behind the write-up.