A control decision you cannot explain is a crop you cannot diagnose, and a grow room has no undo.

At a glance

  • Role — Data Scientist, named in the funded proposal as the only person listed for the project's AI and machine-learning work: "AI development and machine-learning processes", "algorithm development and deep-learning processes". Volunteer, alongside full-time employment elsewhere.
  • Company — Interno, a security-technology company. Interfarm is its closed vertical-farming research-and-development venture, launched at Ankara University Teknopark.
  • Funding — funded under TÜBİTAK's 1501 industrial research-and-development programme, Digital Agriculture call. TÜBİTAK is Türkiye's national scientific research council, the counterpart of UK Research and Innovation; 1501 is its competitive, peer-reviewed industrial programme. Funding is confirmed in a companion filing held by the company.
  • Selection — the company reports the proposal ranked first among roughly 300 applications in its call. That figure is company-reported; I did not see the assessment and cannot verify it independently.
  • What I built — the fuzzy-logic control layer that decides the module's climate, nutrient and lighting behaviour, and the browser-based operator application, end to end.
  • The unit — a sealed growing module farmed hydroponically and fogponically, with one Raspberry Pi automation unit per module, adjustable-spectrum LEDs, ultrasonic micro-spray nozzles, HVAC and CO₂ injection, sensing temperature, humidity, CO₂, pH, electrical conductivity, dissolved oxygen and reservoir level.
  • Transport and platform — CANBUS inside the unit, MQTT off it, into a Linux server running SQL Server, Python and Node-RED.
  • The stakes — the proposal's committed targets: 95% less water than traditional agriculture, eight times the output of conventional growing, 90% less fertiliser, zero pesticide, and a 25% energy saving attributed to the AI control layer — with its business model built against 11 of the 17 UN Sustainable Development Goals.
  • Period on site — October 2022 to December 2024.

No source documents, drawings, filings or code from the project are published here, and the figures below are limited to what the funded proposal states plus what I did myself.

The product problem

A field supplies light, air movement, temperature swing and root-zone chemistry for free, and badly. A closed vertical farm supplies all of them deliberately, which is the entire argument for building one — and it means every variable that was previously weather becomes a set point somebody has to choose, and then keep choosing, several times an hour, for the length of a growing cycle.

The difficulty is not any single set point. It is that they move each other. Raise light intensity and the plants transpire more, which raises humidity, which the HVAC pulls back, which changes how quickly the nutrient reservoir concentrates, which moves electrical conductivity, which changes what the plants can take up under that same light. Control each variable with an independent threshold rule and you get one of two failures: actuators that fight each other and oscillate, or a rule table so conservative that the farm never operates near the conditions that justified sealing it in the first place.

The second difficulty is that a new venture has no history. There was no logged dataset of this module, growing this crop, under this lighting, because the module was the thing being built. The first crop is the first data. That constraint decided most of what follows.

The stakes, as the funded proposal argues them

The module is small; the argument the funded proposal makes for it is not. Agriculture takes roughly seventy percent of the world's fresh water — the proposal cites the UN Environment Programme's assessment — and the UN projects a population near nine billion by 2050, most of it in cities, eating food grown ever further from where it is eaten. A sealed, AI-controlled module attacks several ends of that at once, and the proposal commits to targets rather than adjectives: 95% less water than traditional agriculture through closed-loop hydroponic and fogponic feeding, eight times the output of conventional growing from the same footprint, 90% less fertiliser, zero pesticide, and a 25% energy saving attributed specifically to the AI control layer this page describes. Its business model is written against 11 of the 17 UN Sustainable Development Goals by name — Zero Hunger, Clean Water and Sanitation, Affordable and Clean Energy and Climate Action among them.

From the funded proposal's design work: seven tiers, one sealed climate, crops at staggered stages

From the funded proposal's design work: seven tiers, one sealed climate, crops at staggered stages

Two externally anchored details situate the work. The call it was written for — TÜBİTAK 1501's Digital Agriculture priority area — required a formal European Green Deal alignment section, and the proposal carries one: sustainable agriculture, reduced chemical-fertiliser use, carbon-reduction practice. And its state-of-the-art review measures the module against the field's best-funded ventures — including Plenty of San Francisco, whose SoftBank-led round was, as the proposal notes, the largest agricultural-technology investment made to that point — alongside a review of the US and European patent landscape. The same problem the American market was pricing in billions, taken on by a five-person team in Ankara, under a consultancy agreement with Ankara University's agricultural-machinery department, in a national programme where the proposal — by the company's report — ranked first of roughly 300.

None of that makes my controller more measured than the limitations below say it is. The targets are the proposal's commitments, not observed outcomes, and the page keeps them in that register. What the section establishes is why the work was judged worth funding — and why I gave it two years of evenings.

What I owned, and what I did not

What I owned

  • The control layer. Fuzzy logic implemented in Python, with the membership functions modelled in MATLAB before they were written into the running system. It takes sensor state and decides climate, nutrient and lighting behaviour rather than switching each actuator on its own threshold.
  • The operator application. A browser-based HTML5 application, built end to end, usable from a PC, tablet or phone as well as from the touchscreen mounted on the unit itself (the proposal's interface work package names me against it, alongside the project manager).
  • The design of the plant-health monitoring layer — AI-assisted computer vision over Full-HD and thermal cameras plus a spectrometer, specified in the proposal. It was designed, not delivered, in the period I was on site, and I say so again in the limitations.

What I did not own

  • Mechanical and structural design, HVAC and computational fluid dynamics. The physical module, its airflow and its thermal behaviour belonged to the founder-led engineering team.
  • Agronomy. Crop selection, growing recipes and what a healthy plant is supposed to look like came from people who know that subject. I built the machinery that holds a target; I did not choose the target.
  • Hardware and electronics. Sensor and actuator selection, wiring, and the bus itself were somebody else's work. I consumed what they produced.
  • Company and project leadership. This was Interno's venture and Interno's proposal.
  • A full-time seat. I contributed as a volunteer alongside a full-time role at another company. That is a real constraint on the depth of anything I claim here, and it is why the boundaries above are drawn as widely as they are.

System view

The unit as a unit: one sealed module, one Raspberry Pi automation unit, one CANBUS loop, one MQTT connection out. Modules are meant to be added rather than enlarged.

The shape of the system follows from the module being sealed. Inside, a Raspberry Pi automation unit sits on a CANBUS loop with the sensors and actuators for its own module: temperature, humidity, CO₂, pH, electrical conductivity, dissolved oxygen and level on the sensing side; adjustable-spectrum LEDs, ultrasonic micro-spray nozzles, HVAC and CO₂ injection on the acting side. The control layer runs against that local state, so a module keeps deciding whether the network is there or not.

Off the module, MQTT carries telemetry and commands to a Linux server running SQL Server for history, Python for the control and analysis work, and Node-RED for the integration wiring between them. The operator application is a browser client against that server: the same interface on a laptop in an office, on a phone in a corridor, and on the touchscreen bolted to the unit.

In the room

A working session with the frame of a growing module in the room. Most of what is being argued about at that whiteboard is mechanical — the half of the project I did not own.

A project meeting. Both photographs are here because a research venture is mostly this: a small team, a table, and a long argument about what the module is supposed to do before anybody writes a control loop. The people in these photographs are colleagues from Interno; the work described on this page is only my part of theirs.

Decisions that shaped it

Fuzzy logic rather than a trained model

The obvious modern answer to "control this environment well" is to learn a policy from data. There was no data. Building the first module, growing the first crop and learning a controller from the result is a sequence with the learning step at the end, and the module still has to be operated from the day it is powered on.

Fuzzy logic fits the shape of that constraint. The knowledge that existed was the agronomists' — slightly warm and quite humid means back the misting off — expressed in exactly the graded, overlapping terms that membership functions are for. It encodes a rule base without a training set, it degrades gently across the boundaries between rules instead of snapping between states the way thresholds do, and every action it takes can be traced back to the rules that fired and the degrees to which they fired.

That last property is what settled it. When a tray of lettuce goes wrong, the question is why the environment moved, and a controller that can be read is the difference between diagnosing a growing cycle and repeating it. The trade-off is real: a fuzzy controller cannot discover a policy nobody thought of, and its ceiling is the quality of the rules it was given. It is the right choice with no data and a domain expert in the room, and the wrong one once several seasons of logged history exist — at which point the logged behaviour of this controller is what a learned one would be trained against.

Modelling the membership functions in MATLAB before writing the Python

The membership functions and the rule base were modelled and swept in MATLAB before any of it was implemented in the running system. This is slower than writing the Python first and tuning against the module.

It is also the only version where a wrong rule is cheap. Tuning a controller against real hardware means every experiment costs a piece of a growing cycle, on a rig that other people need for their own work, and a mistake is a plant. Doing the modelling first meant the implementation was a transcription of something already argued about rather than the place the argument happened.

The cost is a second representation to keep honest. Two descriptions of the same controller drift unless somebody makes sure they do not, and that is a maintenance obligation I would want to state clearly to anyone inheriting it.

A browser application, not a panel application

The unit has a touchscreen, which is an invitation to write embedded panel software for it. I built an HTML5 browser application instead and pointed the panel at it.

The people who need this interface are not all standing at the module. Somebody checks a reservoir reading from an office, somebody looks at a chart on a phone on the way in, somebody adjusts a light schedule from the corridor, and somebody is in front of the unit with wet hands. One application serving all of them means one behaviour to learn, one place a change lands, and no second implementation quietly falling behind the first — which is what a separate panel build becomes within a few months on a small team.

The trade-off is that a browser client is only as available as its server and its network. A panel application would keep working when both are gone. The mitigation is architectural rather than in the interface: control lives on the module's own automation unit, so losing the server costs visibility and supervisory changes, not the growing environment.

CANBUS inside the module, MQTT outside it

Two transports rather than one is a thing to justify. They are answering different questions.

Inside the module the traffic is short, frequent, and between devices sharing a physical bus in an electrically noisy enclosure full of pumps, fans and LED drivers. CANBUS is built for that: differential signalling, hardware error handling, no server involved.

Off the module the traffic is telemetry going to a database, dashboards going to people, and commands coming back — over a normal network, to consumers that come and go. MQTT is built for that instead: publish and subscribe, so adding the operator application, a logger or an analysis job does not mean touching the automation unit.

The seam between them is the automation unit, and putting the seam there is what makes the module the unit of scale. A second module is a second Pi and a second CANBUS loop publishing to the same broker, not a rewiring of the first.

What is verified, and what is not

Being precise about this matters more here than on any other page on this site, because this is the project where the strongest-sounding claim is the one I can verify least.

  • Funded, competitively. Interfarm was funded under TÜBİTAK's 1501 industrial research-and-development programme, Digital Agriculture call. TÜBİTAK is Türkiye's national scientific research council and 1501 is peer-reviewed and competitive; funding is confirmed in a companion filing held by the company. What that establishes is that independent reviewers judged the proposal fundable — not that any figure on this page is independently audited.
  • My role is documented. I am named in the funded proposal as the project's Data Scientist, and I am the only person named against the AI and machine-learning work in it. That is a document, not a self-assessment.
  • Both halves are in the document. The proposal's personnel-duty table assigns "AI development and machine-learning processes" to me alone, under the title Data Scientist; its technology table names me, alongside the project manager, against the HTML5 interface development. The intelligence and the interface — both halves of what I describe building — are the two halves the document put my name on.
  • What I built is still my own claim. The fuzzy-logic control layer and the browser application were mine end to end. That is a personal claim about private work — but it is a claim the document's work-package assignments are consistent with, which is more than this page could previously say, and I remain willing to be asked detailed questions about it.
  • The ranking is company-reported. The company reports the proposal ranked first among roughly 300 applications in its call. I did not see the scoring, and I present it as the company's statement rather than as a measurement of mine. If that qualifier makes the claim weaker, that is the correct outcome.
  • There are no production figures here. No yield, no uptime, no energy numbers, no crop comparisons. I did not measure them, they are not mine to publish, and a research module's early figures would not mean what a reader would reasonably assume they meant.

Public record

The venture leaves fewer public traces than a startup with a press page, and it is worth being exact about what can and cannot be checked from outside.

  • The system has a public front door. interfarm.com.tr serves the Interfarm Server login — the running operator platform's entrance. That a system exists and is live is externally checkable; what stands behind the login today, and who has built what since my period ended in December 2024, is not mine to claim.
  • The company's public face is its security business. interno.com.tr presents Interno's eighteen-year camera-systems practice and its public-sector references; it does not describe the farm. The R&D venture lives in filings and at the Teknopark, not on the company website — which is exactly why this page leans on the funded proposal rather than on links.
  • The programme is public even where the project is not. TÜBİTAK's 1501 programme — Türkiye's national industrial R&D support scheme — is documented by the council itself, including its peer-review process. The proposal, its ranking and its contents remain private to the company.

Limitations, and what I would change

  • This is research-stage work, not a shipped product. The scope described here is what the funded proposal specified and what was built against it while I was on site. It is not a commercial deployment and I would not want it read as one.
  • The computer-vision layer was designed, not delivered. The plant-health monitoring described in the proposal — Full-HD and thermal imaging with a spectrometer, feeding an AI-assisted assessment of plant condition — did not reach a working state in my period. It is the part of the project I most wanted to build, and listing it as an achievement would be the easiest dishonest sentence on this site to write.
  • I have no measured evaluation of the controller. There was no held-out dataset to score it against and no instrumented comparison against a threshold baseline, because building the baseline would have cost growing capacity the project did not have to spare. I believe the controller behaved well; I cannot show you that it did, and those are different sentences.
  • Volunteer capacity set the ceiling. Evenings and weekends around a full-time job is enough to build a control layer and an application, and not enough to own an operational system. Some of the boundaries in this page are principled and some of them are simply about hours.
  • Two representations of one controller. MATLAB models and a Python implementation are a good development sequence and a standing drift risk. If I were continuing, the first thing I would add is a test harness that replays recorded sensor traces through both and fails when they disagree — which is also the point at which the recorded traces start being the training set for the model that replaces it.
  • The controller you can read — why fuzzy logic beat a learned model here, why traceability was the deciding property, and the condition under which that choice expires.
  • 95% less water is a control problem — where vertical farming's sustainability targets actually live: in the software layer holding the set points.