Simulated Smart Greenhouse Control System
A software-simulated smart greenhouse system designed to reduce the physical and cognitive load of greenhouse management for elderly farmers. Entirely a simulation — no physical hardware or ROS installation involved — built as a cost-effective proof-of-concept before any physical implementation.
Voice-first greenhouse dashboard: 7 sensors, 8 actuators, zone-effect decay logic, RX200 arm sim — runs live in your browser.
Run the greenhouse — sensors, actuators, robot, voice.
A live, fully client-side reconstruction of the original Flask + ROS-simulated system — same sensor ranges, actuator logic, zone-effect decay timing, and voice interface, running entirely in your browser with no server.
Try: "move to zone C", "water zone B", "toggle day night", "turn on grow lights".
Zone effects hold at full strength for 30s, then decay 5% every 5s until baseline.
Greenhouse work is physical and cognitive load.
Traditional greenhouse management demands physical strain — watering, fertilizing, ventilation — plus constant monitoring of multiple environmental parameters, and the cognitive load of interpreting optimal ranges.
As the average age of farmers rises globally, that combination becomes a growing barrier. This project asks whether a simulation-first, voice-friendly control layer can meaningfully reduce it before any hardware is built.
Simulate the whole system first.
Everything — sensors, actuators, and the RX200 robotic arm — is virtual. No physical hardware, no ROS installation. The goal is a cost-effective proof-of-concept for the interaction model and the control logic before committing to a physical build.
A browser-native voice interface layered on a plain HTML/CSS/JS dashboard keeps the operator surface familiar and install-free.
Four layers, one source of truth.
The Flask backend is a thin RESTful facade over a single GreenhouseController singleton. All state, zone-effect tracking, and dispatch to the simulated arm live there — no decision logic on the actuators, no state on the frontend. Actuators change state only on an explicit request (a UI click or a parsed voice command) — there's no autonomous sensor-threshold control loop yet.
How each piece behaves.
Each sensor exposes a read_*() method that nudges a running value by a small random increment and hard-clamps it to the active day/night range — a bounded random walk, not a static number. Only irrigation is actually wired back into a sensor: while it's on, soil moisture is forced into its 40–60% optimal band.
Actuators are dumb on/off state machines with no logic of their own. Every transition is driven by an explicit toggle_actuator() call from the API layer — a UI click or a parsed voice command — not an autonomous threshold-based control loop.
Four responsibilities: state management (day/night mode, zone-effect ledger), composition/facade over every sensor, actuator, and the robot, task orchestration for the robotic arm, and zone-effect decay. Actuators respond only to explicit commands — no autonomous threshold-based climate control (yet).
Performs zone-specific watering, manuring, and fertilizing across 4 greenhouse zones (A–D). Positioned and stateful within the simulation; dispatched by GreenhouseController.
Browser-native Web Speech API — Speech-to-Text parses spoken commands (e.g. “water zone C”) into the correct API request; Text-to-Speech reads back confirmation. Fully client-side, no backend speech processing.
Plain HTML/CSS/JS UI that polls the backend, renders live sensor and actuator state, and provides a voice-command entry point alongside standard controls.
Endpoints exposed by the Flask backend.
A software simulation, framed honestly.
This is a pure software simulation — sensors, actuators, and the robotic arm are virtual. The target crop is configured for tomato cultivation.
Voice functionality depends on browser support for the Web Speech API and is best-effort where the API is unavailable.
- →Closed-loop climate control — auto-toggling actuators from sensor thresholds. Today every actuator change is driven by an explicit command, UI click or voice, not a control loop.
- →Physical hardware prototyping — sensors, actuators, and a real arm behind the same controller API.
- →Predictive ML-based control on top of the closed loop above — anticipating setpoint drift rather than reacting to it.
- →Computer-vision plant monitoring via the robotic arm.
- →Multi-crop profile support beyond the current tomato preset.