Plant doctor

Ins The Inspiration: Green Thumbs and Global Data

Our team was drawn to the theme of Environmental Sustainability and bridging the gap between advanced AI and everyday utility. We realized that for many people, especially those new to urban gardening, plant sickness is the number one reason they give up. Diagnosing a leaf spot can feel like a guessing game, and by the time you figure it out, it's often too late. The "AI Plant Doctor" was born from a simple mission: democratize plant pathology. We wanted to create a tool where a user could take a picture of a yellowing leaf, and within seconds, get a highly confident diagnosis and an organic, actionable treatment plan. This not only empowers home gardeners but also promotes sustainable, pesticide-free urban farming, addressing a real-world need with cutting-edge technology. 📚 What We Learned: Beyond the Basics of ML The 48-hour sprint was an intense learning experience, especially in bridging the gap between a trained model and a deployed web application.

The Power of Transfer Learning The single most crucial technical lesson was the effective use of Transfer Learning. Training a high-accuracy, deep Convolutional Neural Network (CNN) from scratch takes days, which we didn't have. Instead, we used a pre-trained model (specifically ResNet-50), which had already learned vast feature hierarchies from millions of general images. We effectively "borrowed" this knowledge and only trained the final classification layers on our specific plant disease images. This allowed us to achieve impressive accuracy in just two hours of training.
Full-Stack Deployment and API Design We mastered creating a lightweight Python/Flask backend to expose our heavy ML model. The key challenge was designing an API endpoint that could reliably receive a Base64-encoded image payload from the frontend, process it, and return a structured JSON response containing the diagnosis and confidence score. This taught us how critical the deployment infrastructure is for an AI service.
Image Processing is Key The success of the model depended heavily on Image Normalization. Every image uploaded by a user had to be resized to the exact dimensions the model expected (e.g., 224 \times 224 pixels) and normalized to a specific range (pixel values scaled to [0, 1]). Failure to apply this consistent preprocessing resulted in completely random predictions. The classification loss function we aimed to minimize was the Categorical Cross-Entropy Loss (\mathcal{L}_{CCE}), defined as: Where N is the number of samples, C is the number of classes, y is the true label (one-hot encoded), and \hat{y} is the predicted probability from the model. 🛠️ How We Built It: From Pixels to Prescription Our build process was streamlined to ensure we had a working MVP by the final pitch:
Data Curation: We utilized the publicly available PlantVillage Dataset, but we aggressively filtered it down to the most common five plants (Tomato, Pepper, Potato) and their ten most prevalent diseases to keep the training set manageable and focused for the time limit.
Model Training: Using TensorFlow/Keras, we loaded ResNet-50, froze the base layers, and added a custom head (dense layers) tailored for our 15 disease/health classes.
Backend API Development (Flask): We set up a simple Flask server. The /predict route was configured to: a. Decode the incoming Base64 image data. b. Apply the necessary preprocessing (resize, normalization). c. Run the processed image through the trained ResNet-50 model. d. Look up the resulting class ID in a local JSON file (our "knowledge base") to retrieve the plain English diagnosis and the recommended organic treatment. e. Return the result as a structured JSON object.
Frontend Interface (HTML/JS/Tailwind): The interface was built as a single-page, mobile-friendly application. We used Tailwind CSS for rapid, responsive styling. The core JavaScript handled the user file selection, displayed a preview of the uploaded image, sent the image data to the Flask API via an asynchronous fetch call, and dynamically updated the DOM with the diagnosis. 🚧 Challenges and Triumphs Challenge 1: Dataset Bias and Scarcity The training data was collected in very controlled environments. Our model struggled with images taken under poor light or with distracting backgrounds (e.g., a hand holding the leaf). We couldn't solve this entirely, but we mitigated it by adding aggressive contrast adjustments to the image preprocessing pipeline, which gave us a small bump in real-world performance. Challenge 2: API Latency Running a deep learning model on a single-core backend server can be slow. The prediction time was approximately \tau \approx 2 seconds, which felt long for a real-time app. We optimized the Flask server by loading the model into memory only once at startup, which shaved off precious time, resulting in a prediction time of \tau' \approx 0.8 seconds. Triumph: The MVP Presentation Despite the hurdles, we successfully built and demonstrated a working MVP. We were able to upload a test image of a sick tomato leaf and receive the correct diagnosis of "Tomato Blight" with an organic treatment suggestion. The judges were impressed by the clear societal value and the robust implementation of a deep learning model within the tight time constraint. Where N is the number of samples, C is the number of classes, y is the true label (one-hot encoded), and \hat{y} is the predicted probability from the model. 🛠️ How We Built It: From Pixels to Prescription Our build process was streamlined to ensure we had a working MVP by the final pitch:
Data Curation: We utilized the publicly available PlantVillage Dataset, but we aggressively filtered it down to the most common five plants (Tomato, Pepper, Potato) and their ten most prevalent diseases to keep the training set manageable and focused for the time limit.
Model Training: Using TensorFlow/Keras, we loaded ResNet-50, froze the base layers, and added a custom head (dense layers) tailored for our 15 disease/health classes.
Backend API Development (Flask): We set up a simple Flask server. The /predict route was configured to: a. Decode the incoming Base64 image data. b. Apply the necessary preprocessing (resize, normalization). c. Run the processed image through the trained ResNet-50 model. d. Look up the resulting class ID in a local JSON file (our "knowledge base") to retrieve the plain English diagnosis and the recommended organic treatment. e. Return the result as a structured JSON object.
Frontend Interface (HTML/JS/Tailwind): The interface was built as a single-page, mobile-friendly application. We used Tailwind CSS for rapid, responsive styling. The core JavaScript handled the user file selection, displayed a preview of the uploaded image, sent the image data to the Flask API via an asynchronous fetch call, and dynamically updated the DOM with the diagnosis. 🚧 Challenges and Triumphs Challenge 1: Dataset Bias and Scarcity The training data was collected in very controlled environments. Our model struggled with images taken under poor light or with distracting backgrounds (e.g., a hand holding the leaf). We couldn't solve this entirely, but we mitigated it by adding aggressive contrast adjustments to the image preprocessing pipeline, which gave us a small bump in real-world performance. Challenge 2: API Latency Running a deep learning model on a single-core backend server can be slow. The prediction time was approximately \tau \approx 2 seconds, which felt long for a real-time app. We optimized the Flask server by loading the model into memory only once at startup, which shaved off precious time, resulting in a prediction time of \tau' \approx 0.8 seconds. Triumph: The MVP Presentation Despite the hurdles, we successfully built and demonstrated a working MVP. We were able to upload a test image of a sick tomato leaf and receive the correct diagnosis of "Tomato Blight" with an organic treatment suggestion. The judges were impressed by the clear societal value and the robust implementation of a deep learning model within the tight time constraint.