Skip to content

Mandi Price Forecasting & Selling Advisor for Karnataka Farmers (Python ML + React/Node/MySQL)

  • 13 slides
  • 16 viva questions
  • 5 modules
  • Code included

@mandi-price-forecast-selling-advisorUpdated Oct 2026

7–14-day tomato, onion and ragi price forecasts for Karnataka APMCs, plus which mandi pays best after transport

B.Tech / B.E., Computer Science & Engineering · Sem 7 · Advanced · 16 weeks · Team of 4

More info
Level
Advanced · 16 weeks · Team of 4
Relevant for
Karnataka
Common at
Visvesvaraya Technological University, Anna University, JNTU Hyderabad
Syllabus
VTU 2022 Scheme (OBE/CBCS) · BCS786 Major Project Phase-II · Semester 7
Tech stack
  • Python
  • pandas
  • scikit-learn
  • statsmodels
  • React
  • Node.js
  • Express
  • MySQL
  • Docker
For educational purposes only

Unlock this project

Full PPT + speaker notes, source code and setup steps, READMEFIRST, instructions and all 16 viva answers.

One-time. No subscription, no auto-renew, no drama.

Project packs

Credits never expire and work on any project. Use one here, save the rest for your friend who “will pay you back”.

  1. Pinned

    1 min

    Overview

    Mandi Price Forecasting & Selling Advisor (MPFSA) is a decision-support web application for small farmers in Karnataka who have to decide when and where to sell perishable and semi-perishable produce. It focuses on three commodities with very different price behaviour — tomato (highly volatile, perishable), onion (seasonal spikes, storable for weeks) and ragi (stable, MSP-linked) — across a handful of APMC markets such as Kolar, Chintamani, Bengaluru, Hubballi, Chitradurga, Tumakuru and Mandya.

    The system ingests Agmarknet-style daily records (arrivals in quintals and minimum, maximum and modal prices), cleans them, and produces 7- and 14-day modal-price forecasts per commodity per market. Baselines (seasonal naive and ARIMA) are compared honestly against gradient boosting and random forest regressors built in scikit-learn with lag, rolling-window, arrival and calendar features; an LSTM is kept as an optional experiment. A selling advisor then combines the forecast with the farmer's quantity, village location, transport cost per quintal-km and market charges to rank nearby mandis by expected net realisation.

    The front end is a React dashboard served by a Node.js/Express API over MySQL; the Python pipeline runs as a scheduled batch job. The UI is designed to be Kannada-friendly with a short SMS-style summary. Docker and statsmodels are industry-standard extras beyond the VTU syllabus.

    Syllabus alignment

    VTU · 2022 Scheme (OBE/CBCS)

    BCS786 · Major Project Phase-II · Semester 7 · 6 credits · CIE 100 + SEE 100

    Subjects this project applies
    • BCS602 Machine Learning
    • BCSL606 Machine Learning Lab (scikit-learn / Python)
    • BCS403 Database Management Systems (MySQL)
    • BCSL504 Web Technology Lab
    • BCSL657B React
    • BCSL657D DevOps (Git/Docker)
    How it is evaluated

    Team: individual or group ≤ 4

    report : presentation : Q&A = 50 : 25 : 25; report marks identical for all batch-mates; SEE by two university examiners

    Also fits: Anna University Regulation 2021, JNTUH R22.

    1 min read · 16 viva questions

  2. 2 min

    Synopsis

    Abstract

    Farmers in Karnataka typically sell at the nearest APMC on the day of harvest, with little idea whether prices will rise or fall in the coming week or whether a mandi 40 km away is paying more. This project builds a forecasting and advisory system that predicts 7–14-day modal prices for tomato, onion and ragi across selected APMC markets and recommends the market that maximises expected net income after transport cost and market charges. It combines a Python machine-learning pipeline (scikit-learn, statsmodels) with a React + Node.js/Express + MySQL web application.

    Introduction

    Agricultural price data in India is public — Agmarknet and the data.gov.in open-data portal publish daily arrivals and prices for thousands of markets — but it reaches farmers as raw tables, not decisions. Tomato prices in Kolar can halve within a week when arrivals spike; onion prices in Hubballi react to Maharashtra's crop; ragi prices move slowly. A farmer with 20 quintals needs a simple answer: sell now or hold, and where?

    Existing System

    • Farmers rely on commission agents, word of mouth and yesterday's price read out on radio or messaging groups.
    • Government portals show historical prices market-by-market but no forecast and no comparison adjusted for distance.
    • Private apps, where available, show current prices only and are rarely in Kannada.
    • Gap: no tool combines short-term forecasts with a transport-cost-aware market recommendation for a specific farmer.

    Proposed System

    • Automated ingestion and cleaning of daily arrival/price CSVs for three commodities and 6–8 markets.
    • Benchmark of seasonal naive, ARIMA, random forest and gradient boosting (optional LSTM) using rolling-origin backtesting with MAE and MAPE.
    • A selling advisor that ranks mandis by forecast price × quantity − transport − charges − spoilage allowance.
    • A React dashboard with price charts, forecast bands, a recommendation card and a Kannada/English toggle; an SMS-length text summary.

    Feasibility

    • Technical: all libraries are open-source; data is public; the ML job runs on a laptop in minutes.
    • Economic: zero licence cost; a small cloud VM or free tier is enough for a demo.
    • Operational: the farmer enters only commodity, quantity and village; FPO staff or KVK volunteers can use it on a phone.
  3. 1 min

    Problem statement

    Small and marginal farmers in Karnataka lose a significant share of potential income because they decide when and where to sell without any view of future prices. Perishable crops like tomato show sharp day-to-day swings driven by arrivals, and farmers often sell at the nearest APMC on a glut day even when a market within reach is paying more, or when prices are likely to recover within days. Public price data exists but is presented as raw historical tables, market by market, in English, with no forecast and no adjustment for transport cost.

    There is a need for a system that (1) collects and cleans daily mandi arrival and price data, (2) produces reliable short-horizon (7–14 day) price forecasts per commodity and market, benchmarked against simple baselines, and (3) turns those forecasts into a clear, Kannada-friendly recommendation — which mandi to sell in and whether to hold — after accounting for the farmer's quantity, distance, transport cost and market charges.

  4. 1 min

    Objectives & scope

    1. 01Build a repeatable ingestion and cleaning pipeline for Agmarknet-style daily arrival and modal-price data for tomato, onion and ragi across 6–8 Karnataka APMC markets.
    2. 02Engineer lag, rolling-mean, arrival and calendar/festival features and store the cleaned series in MySQL.
    3. 03Benchmark seasonal naive and ARIMA baselines against random forest and gradient boosting regressors using rolling-origin backtesting with MAE and MAPE at 7- and 14-day horizons.
    4. 04Implement a selling advisor that ranks nearby mandis by expected net realisation after transport cost, market charges and a spoilage allowance.
    5. 05Expose forecasts and recommendations through a documented Node.js/Express REST API with input validation.
    6. 06Build a responsive React dashboard with forecast charts, uncertainty bands, a recommendation card, a Kannada/English toggle and an SMS-length summary.
    7. 07Test every layer (unit, API integration, model backtests, usability with at least five farmers or FPO staff) and document individual contributions of all four members.

    Scope

    In scope

    • Three commodities (tomato, onion, ragi) and 6–8 APMC markets in Karnataka, using historical public data files downloaded from the government portal.
    • Daily cleaning, feature building, model training and 7/14-day forecasts in a scheduled Python batch job.
    • Selling advisor with configurable transport rate (₹ per quintal per km), market charges and spoilage allowance per commodity.
    • Web dashboard (English + Kannada labels) and REST API; admin screen to upload new CSVs and trigger a retrain.
    • Evaluation report comparing all models on the same backtest windows.

    Out of scope

    • Live scraping of any website (data is loaded from downloaded files or the official open-data API only).
    • Actual SMS gateway integration (the SMS text is generated and shown; sending is future work).
    • Weather or satellite features, trading, payments or farmer login with personal identifiers.
  5. 1 min

    Methodology

    We follow an Incremental model with CRISP-DM for the ML part: business understanding → data understanding → preparation → modelling → evaluation → deployment, wrapped in two-week increments so a working slice exists at every VTU review.

    PhaseWeeksActivitiesDeliverable
    Phase-I recap & data understanding1–2Re-read Phase-I literature survey, download 3–5 years of data, profile gaps and outliersData audit notebook
    Data preparation3–4Cleaning rules, resampling to daily, feature engineering, MySQL schemaClean tables + ETL script
    Baselines5Seasonal naive, ARIMA per seriesBaseline backtest table
    ML models6–8Random forest, gradient boosting, hyper-parameter search with time-series CV; optional LSTMModel comparison table
    Advisor + API7–10Net-realisation logic, distance table, Express endpoints, validationAPI with tests
    Dashboard9–12React pages, charts, Kannada toggle, SMS summaryWorking UI
    Testing & field check13–14Unit/integration tests, usability sessions with FPO staffTest report
    Report, paper & viva prep15–16Final report, PPT, optional conference paperPhase-II submission

    Evaluation protocol. Rolling-origin backtesting: train on data up to day t, forecast t+1 … t+14, move t forward by 7 days, repeat over the last 12 months. Report MAE (₹/quintal) and MAPE per commodity, market and horizon, and the percentage of weeks in which the advisor's recommended market actually delivered the highest net price in hindsight. Results are recorded in a table we fill from our own runs; no numbers are assumed in advance. Target: ML model MAE at least 10% lower than seasonal naive for tomato and onion.

  6. 2 min

    Architecture & tech stack

    • Python
    • pandas
    • scikit-learn
    • statsmodels
    • React
    • Node.js
    • Express
    • MySQL
    • Docker

    The system has four layers: a Python data/ML batch pipeline, a MySQL database, a Node.js/Express REST API, and a React single-page dashboard.

    1. Ingestion & ML pipeline (Python) — reads downloaded CSV files (or the official open-data API), normalises market and commodity names, removes duplicates and impossible values, resamples to a daily series (forward-filling market holidays with a flag), builds features, trains models and writes forecasts back to MySQL. It runs nightly via cron or a Docker scheduled container.
    2. Database (MySQL 8) — normalised tables for markets, commodities, daily prices, forecasts, model runs and a market-distance matrix.
    3. API (Node.js + Express) — read-only endpoints for prices and forecasts, a POST endpoint for advice, and an admin endpoint to upload a CSV and queue a retrain. Inputs are validated with a schema library; rate-limited.
    4. Dashboard (React + Vite) — charts of history and forecast bands, advice form, recommendation card, Kannada/English toggle, SMS text preview.
    flowchart TD
      A["Agmarknet-style CSV / open-data API"] --> B["Python ETL: clean and resample"]
      B --> C["Feature builder: lags, rolling means, arrivals, calendar"]
      C --> D["Model training and backtest"]
      D --> E[("MySQL 8")]
      B --> E
      E --> F["Node.js + Express REST API"]
      F --> G["Selling advisor: net realisation ranking"]
      G --> F
      F --> H["React dashboard (Kannada / English)"]
      H --> I["SMS-length summary text"]

    ER diagram

    erDiagram
      MARKET ||--o{ DAILY_PRICE : records
      COMMODITY ||--o{ DAILY_PRICE : "is priced in"
      MARKET ||--o{ FORECAST : "has"
      COMMODITY ||--o{ FORECAST : "has"
      MODEL_RUN ||--o{ FORECAST : produces
      MARKET ||--o{ DISTANCE : "from or to"
      COMMODITY ||--o{ ADVICE_LOG : "asked about"
      MARKET {
        int id PK
        string name
        string district
        float latitude
        float longitude
      }
      COMMODITY {
        int id PK
        string name
        string name_kn
        float spoilage_pct_per_day
      }
      DAILY_PRICE {
        int id PK
        int market_id FK
        int commodity_id FK
        date price_date
        float arrivals_qtl
        float min_price
        float max_price
        float modal_price
        boolean imputed
      }
      MODEL_RUN {
        int id PK
        string algorithm
        datetime trained_at
        float backtest_mae
        float backtest_mape
      }
      FORECAST {
        int id PK
        int run_id FK
        int market_id FK
        int commodity_id FK
        date target_date
        float predicted_price
        float lower_band
        float upper_band
      }
      DISTANCE {
        int id PK
        string village_code
        int market_id FK
        float road_km
      }
      ADVICE_LOG {
        int id PK
        int commodity_id FK
        float quantity_qtl
        string village_code
        int recommended_market FK
        datetime created_at
      }

    Advisor logic

    For each candidate market m and sell day d within the horizon: net(m, d) = P̂(m, d) × Q × (1 − s × days_held) − r × km(m) × Q − c(m) × Q, where P̂ is the forecast modal price per quintal, s the spoilage fraction per day, r the transport rate and c the per-quintal charges (hamali, commission, cess — configurable because they differ by market). The advisor returns the top three (market, day) pairs with the forecast band, and flags low confidence when the band is wider than 20% of the price.

  7. 5 modules

    Modules

    • Module 1 — Data Ingestion & Cleaning (Member 1)

      Member 1 owns the ETL: CSV/API loader, name normalisation (e.g. 'Kolar' vs 'KOLAR APMC'), duplicate and outlier rules (modal price outside min–max, zero arrivals with non-zero price), daily resampling with an imputed flag, and the MySQL loading scripts. Deliverables: data audit notebook, ETL tests and the data dictionary chapter of the report.

    • Module 2 — Forecasting Models & Backtesting (Member 2)

      Member 2 owns feature engineering (lags 1–14, 7/28-day rolling means, arrival ratios, day-of-week, month, festival flags for Ugadi, Dasara and Deepavali), the seasonal naive and ARIMA baselines, random forest and gradient boosting regressors with time-series cross-validation, the optional LSTM, and the rolling-origin backtest that fills the results tables.

    • Module 3 — Selling Advisor & REST API (Member 3)

      Member 3 owns the Node.js/Express API, the MySQL query layer, the net-realisation ranking, the market-distance matrix (road km per village cluster) and configurable charges per market. Includes request validation, rate limiting, API documentation and Jest/Supertest integration tests.

    • Module 4 — React Dashboard, Kannada UI & Usability Testing (Member 4)

      Member 4 owns the React front end: market/commodity selector, history and forecast charts with bands, the advice form and recommendation card, the Kannada/English label toggle, the SMS-length summary generator, accessibility checks, and the usability study with five or more farmers or FPO staff.

    • Shared — Admin, Deployment & Documentation

      All four members share the admin upload screen, Docker Compose setup, GitHub workflow, report integration and PPT. Each member writes the chapter for their own module so individual contribution is visible to the VTU examiners.

  8. Locked

    Presentation

    13 slides with speaker notes. The outline below is free; the bullets, notes and the generated .pptx unlock with the project.

    1. Mandi Price Forecasting & Selling Advisor
    2. Motivation
    3. Problem Statement
    4. Literature Survey & Gap
    5. Objectives
    6. System Architecture
    7. Data & Features
    8. Models & Backtest Protocol
    9. Results
    10. Selling Advisor
    11. Dashboard Demo
    12. Testing
    13. Conclusion & Future Work

    Bullets, speaker notes and the .pptx download unlock with the project.

    Presentation is locked: 13 slides, Speaker notes, .pptx download.

  9. 1 min

    Future scope

    • SMS/IVR delivery through a DLT-registered SMS gateway and a Kannada voice call for farmers without smartphones.
    • Weather and arrivals-upstream features (rainfall from IMD bulletins, arrivals in neighbouring states) to capture supply shocks.
    • Probabilistic forecasts with quantile gradient boosting for better risk bands.
    • More commodities and states, and integration with e-NAM market listings.
    • Storage advice — whether cold storage rent is worth paying for onion given the forecast.
    • FPO dashboard to plan collective transport to the best market.
  10. 10 sources

    References

    1. AGMARKNET — Agricultural Marketing Information Network, Directorate of Marketing & Inspection, Government of India
    2. Open Government Data Platform India (data.gov.in)
    3. e-NAM — National Agriculture Market
    4. Rob J. Hyndman & George Athanasopoulos, Forecasting: Principles and Practice, 3rd ed., OTexts
    5. scikit-learn User Guide
    6. statsmodels Documentation — Time Series Analysis
    7. React Documentation
    8. Express.js Documentation
    9. MySQL 8.0 Reference Manual
    10. Aurélien Géron, Hands-On Machine Learning with Scikit-Learn, Keras and TensorFlow, 3rd ed., O'Reilly

    Cite this bundle

    OnlyProjects. (2026). Mandi Price Forecasting & Selling Advisor for Karnataka Farmers (Python ML + React/Node/MySQL): B.Tech / B.E. Computer Science & Engineering project bundle [Educational resource]. https://onlyprojects.online/projects/btech-cse-mandi-price-forecast-selling-advisor

Slides, diagrams & files

13 slides. Titles are free; bullets, speaker notes and the .pptx unlock with the project.

  1. SLIDE 1

    Mandi Price Forecasting & Selling Advisor

  2. SLIDE 2

    Motivation

  3. SLIDE 3

    Problem Statement

  4. SLIDE 4

    Literature Survey & Gap

  5. SLIDE 5

    Objectives

  6. SLIDE 6

    System Architecture

  7. SLIDE 7

    Data & Features

  8. SLIDE 8

    Models & Backtest Protocol

  9. SLIDE 9

    Results

  10. SLIDE 10

    Selling Advisor

  11. SLIDE 11

    Dashboard Demo

  12. SLIDE 12

    Testing

  13. SLIDE 13

    Conclusion & Future Work

Architecture diagrams · 2

1
flowchart TD
  A["Agmarknet-style CSV / open-data API"] --> B["Python ETL: clean and resample"]
  B --> C["Feature builder: lags, rolling means, arrivals, calendar"]
  C --> D["Model training and backtest"]
  D --> E[("MySQL 8")]
  B --> E
  E --> F["Node.js + Express REST API"]
  F --> G["Selling advisor: net realisation ranking"]
  G --> F
  F --> H["React dashboard (Kannada / English)"]
  H --> I["SMS-length summary text"]
2
erDiagram
  MARKET ||--o{ DAILY_PRICE : records
  COMMODITY ||--o{ DAILY_PRICE : "is priced in"
  MARKET ||--o{ FORECAST : "has"
  COMMODITY ||--o{ FORECAST : "has"
  MODEL_RUN ||--o{ FORECAST : produces
  MARKET ||--o{ DISTANCE : "from or to"
  COMMODITY ||--o{ ADVICE_LOG : "asked about"
  MARKET {
    int id PK
    string name
    string district
    float latitude
    float longitude
  }
  COMMODITY {
    int id PK
    string name
    string name_kn
    float spoilage_pct_per_day
  }
  DAILY_PRICE {
    int id PK
    int market_id FK
    int commodity_id FK
    date price_date
    float arrivals_qtl
    float min_price
    float max_price
    float modal_price
    boolean imputed
  }
  MODEL_RUN {
    int id PK
    string algorithm
    datetime trained_at
    float backtest_mae
    float backtest_mape
  }
  FORECAST {
    int id PK
    int run_id FK
    int market_id FK
    int commodity_id FK
    date target_date
    float predicted_price
    float lower_band
    float upper_band
  }
  DISTANCE {
    int id PK
    string village_code
    int market_id FK
    float road_km
  }
  ADVICE_LOG {
    int id PK
    int commodity_id FK
    float quantity_qtl
    string village_code
    int recommended_market FK
    datetime created_at
  }

Files

Viva questions & answers

3 of 16 questions free. Explain each answer in your own words before you move on.

  1. General

    What is the novelty of your project compared to existing price apps?

    Existing portals and apps show historical or current prices market by market. Our novelty is combining short-horizon forecasts with a transport-cost and spoilage-aware ranking of markets and sell days, delivered in a Kannada-friendly form, and benchmarking every model honestly against seasonal naive.

  2. General

    What was each member's individual contribution?

    Member 1 built the ingestion and cleaning pipeline and data dictionary; Member 2 built features, baselines, ML models and backtests; Member 3 built the Express API, MySQL layer and advisor logic; Member 4 built the React dashboard, Kannada toggle and ran usability tests. Each wrote the report chapter for their module.

  3. General

    What did you submit in Phase-I and what is new in Phase-II?

    Phase-I (BCS685) had the problem statement, literature survey, data-source study, proposed architecture and plan with a profiling notebook. Phase-II (BCS786) adds the complete ETL, trained models, backtest results, advisor, API, dashboard, testing and the final report and demo.

+13 more questions

They and the answers unlock with the project. Try answering the ones above yourself first. Your examiner will.

For educational purposes only. Use this bundle to understand how the project works, then build and write your own. Submitting it verbatim is between you, your conscience and your external examiner.