AI-Powered Hydroponics Robot

A semester-long engineering project: an autonomous plant-monitoring robot for a small hydroponic rig. The robot hangs on a four-cable lift inside the rig with a separate pan axis, finds each plant by its ArUco marker, drops to a close-up height, captures a photo, and runs it through a vision-language model. Structured plant-health output streams to a live dashboard and a phone app.

I led and designed the project and built its brain: the AI, the electronics, the robot, and the software stack, with a team of students working alongside me on the physical hydroponic structure. What started as a rough motion-control prototype grew into a full system covering firmware, server, vision pipeline, dashboard, and scheduler.

The whole project is built around one goal: a product anyone can bring into their home and use to grow their own crops and food sustainably. The people who stand to gain the most from growing their own food are often the ones who know the least about how to do it, so the system has to carry that knowledge for them.

That ties directly to two of the UN Sustainable Development Goals: Zero Hunger (Goal 2) and Responsible Consumption and Production (Goal 12). The larger ambition is to chip away at a global problem by giving people a cheap, low-effort way to farm food at home, and making the whole process as approachable as possible. Controlled-environment agriculture is already becoming more relevant in Thailand as land and climate pressures push small-scale farming toward technology, and a self-running home rig is one way to meet that.

The aim is a smart hydroponic system run almost entirely by AI. As much of the grow as possible is handed to the model: monitoring each plant, reading its health, and deciding what needs attention, so human intervention is kept to a minimum.

That is the entire point. Someone who knows nothing about plants or the growing process should still be able to grow food for themselves and keep it alive, because the system is doing the watching and the thinking on their behalf.

I built a web app that runs on any device, my own iPhone included, from anywhere in the world. Users open it to check on their plants and get a live update without ever having to stand in front of the rig or monitor anything themselves.

The same interface drives the wall dashboard and the phone in your pocket: ambient temperature, humidity, and light, plus a per-plant health read alongside the latest close-up the robot captured.

I led and designed the project end to end, and I owned the parts that make it intelligent: the AI, the electronics, and the hardware. That meant integrating the different sensors, building the robot itself, and writing the algorithm that moves it around the rig to scan each plant in turn.

The students working with me focused mainly on the physical hydroponic structure. Splitting it that way forced clean interfaces between subsystems instead of letting things bleed into each other.

The control side uses a VEX EXP brain talking to a host Mac over USB serial. The brain runs the motion firmware in C++. The host runs everything else: vision, server, dashboard, and the scan scheduler.

To train and test the vision model, we used paper cutouts of plants printed at different health stages, from thriving down to clearly struggling. It let us rehearse the full scan-and-diagnose loop without waiting on real grow cycles.

The results came back strongly positive. The model read the health stages well, and it was even sharp enough to flag that a plant was a fake paper cutout rather than a real one, exactly the kind of edge case you want it catching.

Most development time went into control stability. A naive first attempt sending the same velocity to all four cable motors caused wobble-induced sign-flip oscillation: tiny tension imbalances would cause one motor to overshoot, the controller would reverse it, the cable would slack, then snap back. The whole rig would shake.

I solved it by latching each motor independently the moment it hit tolerance, backed by brain-side software limits and a watchdog. That gave lockstep motion without needing a full PID loop, and it survives the asymmetric loading you get whenever the camera platform isn't perfectly centered.

VEX is a closed ecosystem. I used it for budget reasons, but its byte-level USB command scheme is not designed for general-purpose use. I reverse-engineered the USB interface and replaced its protocol with a tagged compact-line scheme of my own: structured, versioned, and debuggable, so I could trace exactly what the host was sending and what the brain was doing.

VEX firmware in C++. A Python FastAPI server on the host with HTMX, Tailwind, and Server-Sent Events for the dashboard. SQLite for storage with tiered photo retention so old captures get downsampled rather than deleted. APScheduler runs the autonomous scan loop. OpenCV handles capture, ArUco detection, and pre-processing before frames go to the VLM in LM Studio.

There's also a mock mode that swaps the brain, camera, and VLM for in-process fakes so the whole system runs with no hardware attached. That made it possible to develop the dashboard and scheduler on a plane, on a lunch break, or anywhere I wasn't standing next to the rig.

Two-Mac setup with a git-hook deploy. Push to the repo, the host Mac pulls and restarts. LLM-assisted coding tools were used throughout, but I kept full ownership of architecture and behavior. Every interface and every state machine was a decision I made and could explain.