Fruit sorter

Real-Time Fruit Quality Detection and Sorting System

A complete personal engineering project built and validated from February to May 2026. The system combines edge computer vision, embedded firmware, custom electronics, a real conveyor and a Flutter monitoring application to classify fruit quality and route accepted products to two output bins.

The physical system uses a direct Raspberry Pi-to-STM32 UART link. There is no ESP32 or MQTT layer.

Demonstrated results

The test protocol and limitations are documented in docs/evaluation.md.

System behavior

Raspberry Pi 4B and Camera Module V3 run a five-class MobileNetV2 INT8 model. A confidence-filtered multi-frame vote reduces transition errors as fruit enters and leaves the field of view. Accepted fruit type 1 and type 2 produce framed UART commands for the STM32F401CCU6. The STM32 confirms physical arrival using separate active-low sensors on PA0 and PA1, then drives servo 1 or servo 2 through TIM3 PWM. Defective fruit continues to the reject end of the conveyor.

The Pi also estimates visible defect area, uploads the result image to Cloudinary, writes the classification event to Firestore, and exposes MJPEG and JSON endpoints. The Flutter client uses Firebase Authentication and Firestore to show live status, daily metrics, images and filterable history.

See docs/architecture.md for the signal, control and power architecture.

Repository layout

apps/fruit_quality_monitor/     Flutter Android/web monitoring client
docs/                           Architecture, hardware and evaluation records
edge_ai/models/                 Deployed Edge Impulse Linux INT8 model
edge_ai/runtime/                Raspberry Pi inference and integration service
edge_ai/training_config.json    Authoritative model and dataset configuration
firebase/                       Firestore client security rules
firmware/stm32f401_sorter/      Bare-metal CMSIS firmware and PlatformIO config
hardware/kicad/                 KiCad schematic and two-layer PCB source
hardware/manufacturing/         PCB fabrication Gerbers and drill data

Hardware summary

Detailed power and bring-up guidance is in docs/hardware.md. Firmware pins, protocol and calibration values are in firmware/stm32f401_sorter/README.md.

Quick start

Raspberry Pi

cd edge_ai/runtime
sudo apt install -y python3-picamera2 python3-opencv python3-venv
python3 -m venv --system-site-packages .venv
source .venv/bin/activate
pip install -r requirements-rpi.txt
cp .env.example .env
# Edit .env locally, then:
python main_stream.py

The Cloudinary, Firestore, UART and service setup is in edge_ai/runtime/README.md. Credentials are intentionally excluded.

STM32

cd firmware/stm32f401_sorter
pio run
pio run --target upload

Flutter monitor

cd apps/fruit_quality_monitor
flutter pub get
flutter run --dart-define=FIREBASE_API_KEY=... \
  --dart-define=FIREBASE_APP_ID=... \
  --dart-define=FIREBASE_MESSAGING_SENDER_ID=... \
  --dart-define=FIREBASE_PROJECT_ID=... \
  --dart-define=PI_BASE_URL=http://raspberrypi.local:5000

See apps/fruit_quality_monitor/README.md for Firebase setup and all build arguments.

Model configuration

• Dataset: 1,105 images, five classes, object-level 80:20 split.
• Architecture: MobileNetV2 with width multiplier 0.35 and 160 × 160 RGB input.
• Training: transfer learning, 50 epochs, batch size 32, learning rate 0.001.
• Deployment: Edge Impulse Linux .eim, INT8 quantization, 721.5 KB model and 416.1 KB reported peak RAM.

Images from one physical fruit are confined to one split, although several views of that fruit may exist within that split. The dataset itself is not included, so the deployed .eim is reproducible only from the original dataset and Edge Impulse project. edge_ai/training_config.json records the authoritative parameters without claiming that the binary can be regenerated from absent data.

Security

• Keep .env, Cloudinary credentials and Firebase service-account JSON local to the Pi.
• The Flutter app receives only Firebase client configuration and requires authenticated reads.
• Firestore client writes are denied; the authenticated service account performs server-side writes.
• Rotate any credential that was previously committed, pasted or shared. Removing it from current files does not revoke it or erase it from Git history.