MangoGuard — Edge AI That Detects Mango Diseases in the Field

Submission for the GitHub Finish-Up-A-Thon Challenge

Mango farming is a lifeline for millions of smallholder farmers in Ethiopia.
A single fungal outbreak can silently destroy 20–30% of a harvest before a
farmer even recognises it. Existing solutions require a lab, a specialist,
or reliable internet. None of those exist where the problem is worst.

MangoGuard runs AI directly on a microcontroller smaller than a credit card
— no cloud, no Wi-Fi, no lab.

An Arduino Nano 33 BLE Sense runs a quantized MobileNetV1 model that
classifies mango leaf disease in under 2 seconds at 86.45% accuracy on real
Ethiopian farm data. The Nano also reads live temperature and humidity via a
DHT22 sensor and sends everything — disease result, temp, and humidity — to a
Raspberry Pi 4 gateway, which evaluates environmental disease risk against
agronomic thresholds, runs a 24-hour AI forecast model, and generates
plain-language recommendations pushed directly to farmers based on current
conditions.

Everything streams to a React dashboard in real time via WebSocket.

From the dashboard you can:

• Monitor live environmental readings and disease risk
• Run a cloud scan from your phone — upload any leaf photo for instant AI classification, no hardware required
• View a 5-day disease risk forecast calendar
• Browse your full scan history in the logs section

The dashboard is fully bilingual — English and Amharic (አማርኛ) — because
agronomists advising Ethiopian farmers shouldn't have to work in a language
that isn't theirs.

Under the hood, every scan is saved to a PostgreSQL database. The admin
dashboard exposes this data as a labeled dataset that can be used to
retrain and improve the model over time as more field data comes in.

🌐 Live Demo: https://mango-guard.vercel.app/
📂 GitHub: https://github.com/SCIFI-Shinobi/Intelligent-Mango-Health-Monitoring

The Comeback Story

The hackathon prototype worked — but only on my machine, with undocumented
secrets, and no way for anyone else to run it. Here's what I shipped to fix that:

• Rewrote the README from scratch — setup guide, env variable reference, troubleshooting for the 7 most common failures
• Added ARCHITECTURE.md, DEPLOYMENT.md, and CONTRIBUTING.md
• Fixed .gitignore which was blocking .env.example files from being committed
• Documented all 10 required environment variables (previously scattered in source code)
• Added MIT LICENSE — the repo had no legal clarity before
• Fixed a real production bug — I had set scan intervals to 20 seconds and forecast to trigger after 3 readings for demo convenience. The forecast model was actually trained on a 24-reading window (one per hour). In the field it was producing numbers that looked valid but weren't. Fixed: scanIntervalMs = 3600000UL, forecast threshold ≥ 24.

A stranger can now fork, configure, and deploy this in under 20 minutes.

Copilot Experience

Copilot saved the most time on the backend — main.py grew past 3,000 lines
and it was excellent at continuing repetitive patterns: email templates,
database migration helpers, route structure. Once I wrote the first, it nailed
the second.

During the polish phase, asking Copilot to review the README flagged that I
had no troubleshooting section and no env variable docs — exactly what a
first-time contributor needs. It also helped clean up firmware comments after
I fixed the production bug.

The honest limitation: it continues patterns well but won't proactively tell
you what's missing. You have to ask the right question first.

Built to bridge the gap between AI and smallholder agriculture in Ethiopia. 🌱