@adlrocha - Lego Farming Blocks: Letting AIs Grow our Food
From fragile supply chains to AI-driven home farming: Designing the hardware for food independence.
If you are a regular reader of this newsletter, you already read, or at least are aware, of the first post of my Critical Infrastructures of our Society series dedicated to the food supply chain. After doing the research and writing that post, I’ve been thinking a lot about how people living in cities and highly-populated areas without a lot of space to grow food could become more resilient to the fragility of the food supply chain.
The same way households install solar panels to become more independent from their country’s power grid and be resilient to potential outages, would it be possible to install some device at home that help households become more independent from the global food supply chain? We could think of urban farms as a potential solution, but unfortunately, I don’t think that scales. We need something as decentralised as a solar panel, and that people can purchase and plug-and-play themselves without any farming knowledge, like a TV. This is how I came up with the idea of the Lego-like modular home farming modules.
As I was thinking about this idea, I came across this tweet describing the project that Martin DeVido is doing with Sol, his AI-grown tomato plant. This pushed me to explore my lego idea further, and that’s how I ended up writing this post.
Background
As mentioned above, the first thing that came to mind when thinking about food resilience in cities was urban farming. We could convert warehouses and rooftops into massive vertical farms. Unfortunately, this would require some kind of central coordination among the community. While I could see this working in a small village, or even a small city, where there is some level of trust and acquaintance among the population, this would be a governance nightmare in a big city. Even more, I think a system like this based on shared vertical gardens would be really hard to scale efficiently.
But as we learnt from distributed systems and from electricity self-consumption: true resilience requires some level of decentralisation. What if everyone could grow some basic nutrients at home without any knowledge of farming just by plug-and-playing a device? Enter the lego farming modules (I should definitely find a better name for this, but let’s not overthink it for now).
The concept is simple: A modular, stackable system that treats plants to grow vegetables, fruits and other herbs like software packages. Imagine a base station, or independent modules that are plugged and can grow a specific food independently. You want to grow tomatoes? You buy a “tomato block” and snap it to the base or install it independently. You want basil? You snap a basic block on top of the tomato one. You want avocados? You know the drill.
The core technical architecture of the module is agnostic to what it grows, and each block contains all that is needed to grow the specific food. Each block contains the specific LED spectrum, the seed pod, and the sensors required for that specific species. The user experience should be as simple as unboxing a new computer and plugging it to the power (OK, this is the aspiration, but it may end up being between that and assembling IKEA furniture).
I had all this idea sketched out when I came across Martin Devido’s project. For this initial idea I wasn’t even considering the use of AI, and I was focused on figuring out the feasibility of the technical architecture for the module. But seeing how Martin was using an AI agent to control the tomato plant’s water and light to keep him alive was an incredible “aha! moment” for me. He not only showed the feasibility of the project, but he even conceptualised it better than me by including AI to the mix to make it more scalable.
By leveraging AI we could really optimise the growth better than a human could (especially a human without any farming skills and who is horrible with plants like me). I got really excited about this. I felt like the idea had the potential of becoming a full-fledged product that people would actually buy (you tell me if this is true and you would actually buy something like this).
The Architecture
I wanted to come up with a design that can be scalable to manufacture and easy to install for users. While not a strict requirement, I would love it if it is also beautiful. Aesthetics are important, and more so when you may need to install one of these in your living room.
My idea for the initial design is based on three layers. Disclaimer, this is still a paper design closer to a thought experiment than a real design, as it will be described later.
The Physical Layer (i.e. the bricks)
This is where the plants will be grown. Its job is threefold: It must bear the weight of the water and plants without bending or leaking (I am targeting a maximum of 4-5 kg. here). It creates a dark, humid chamber for the roots, protecting them from light (which causes algae) and pests. And it physically aligns the electrical and water connections so the user doesn’t have to fiddle with wires or tubes. We can’t use soil because it’s heavy, messy, and introduces pests.
After some research, the obvious solution to avoid soil is to use hydroponics (water) or aeroponics (mist). Aeroponics is ideal for a modular system because it uses 95% less water and requires no heavy reservoirs in the upper blocks, but they require high-pressure pumps.
Each block is essentially a hollow shell with a nozzle. For the prototype we can use 3D printing, but for mass production we need to leverage Injection Molding using food-safe PP (Polypropylene) or HDPE.
For the watering and nutrient distribution mechanism, the simplest system I found was to use a modified “flood-and-drain system” because it relies on gravity instead of pressure. This would work as follows:
The pump fills the top block. The water level rises until it hits a calibrated overflow tube (approximately 20mm diameter to prevent air-lock), then drains down to the next block.
The pump in the base turns on for 15 minutes. It pushes water up a single internal pipe to the top block. The top bock fills up like a bathtub until the water level hits the overflow tube (set at 5cm height).
Once the water hits that tube, it spills down into the block below, filling that one up, and so on, until it drains back into the base reservoir.
It oxygenates the water naturally as it falls (the “waterfall effect”), and because there are no tiny nozzles to clog, it is almost impossible to break.
To prevent roots from clogging the drain, each drain tube is covered by a removable mesh basket (3D printed or stainless steel) that the user can rinse out between harvests. More on the why for these pogo pins below.
To ensure the pogo pins always align despite the heavy water weight, the blocks feature interlocking dovetail rails. They don’t just stack, they slide and lock into place physically.
I considered alternative mechanisms for this like high-pressure pump spray, something called Nutrient Film Technique, and Deep Water Culture. Describing in detail all these alternatives would make this post too long and boring, so as always, if you are interested in this let me know and I’ll share my research notes.
The Transport Layer (i.e. the bus)
This is probably the hardest engineering challenge of the design (and it is the one with the highest-probability of breaking my design in the prototype stage). We need to pass resources through the tower without cables. The connection points must transfer power (for the LEDs), data (for the sensors), and water. Blocks must be completely independent (you can add/remove them instantly). The system must act as one single unit, passing high-current electricity, data signals, and water from the bottom to the top without interruption.
We want to eliminate all external cables. The connection should happen automatically when two blocks click together. To achieve this, we use 5-pin spring-loaded connectors (the aforementioned pogo pins) embedded in the frame. When you stack a block, strong magnets pull the pins into alignment with contact pads on the block below. This creates a solid electrical link instantly.
We use 12V power instead of the standard 5V (coming up with this part actually took me a huge amount of back-and-forth with different LLMs, using an LLM-as-a-judge to come up with the best design and prevent hallucinations).
Higher voltage pushes through the resistance of the connections much better, ensuring the lights at the top are just as bright as the lights at the bottom. We use WS2815 Addressable LEDs. Unlike standard strips, these run natively on 12V. This means we can power the pump and the lights from the same rail without massive amperage spikes or dimming at the top of the tower. WS2815s also have a backup data line. If one LED dies, the rest of the tower keeps working.
To distribute commands to all the modules we use one single data pin running through the whole tower. The Base Station shouts a command to block 1, which passes it to block 2, and so on.
The Logic Layer (i.e. the brain)
This layer is the one responsible for orchestrating the commands for each block and triggering the actuators. It translates complex biological requirements (e.g., “needs 14 DLI of photosynthetically active radiation”) into simple electrical commands (e.g., “Set LED PWM to 80% Blue”).
For the brain, we use the same architecture used by Martin with Sol. There is a cloud AI (or local LLM in a desktop or beefier machine) that interacts with the edge nodes (a microcontroller in the blocks responsible for executing the commands from the brain).
The edge device itself is robust and simple. It downloads a “recipe file” (i,.e. a JSON config) and executes it locally. If Wi-Fi cuts out, your plants don’t die; the ESP32 keeps running the last known good schedule. For this we can use a ESP32 microcontroller.
The AI orchestrator has knowledge of all the blocks that have been connected and registered and it updates the recipes for each of the modules. The AI can generate a dynamic timeline and adapt according to the state of each block. For instance:
Week 1 (Germination): The AI tells the ESP32 to keep lights dim and blue (6500K) to prevent stretching.
Week 4 (Vegetative): It ramps up intensity to max.
Week 8 (Flowering): It shifts the spectrum to Deep Red (660nm) to trigger blooming.
This design has a really interesting second-order consequence. Users can opt-in to share their plants data with a centralised service that could collect information about all the collected bricks and their state in order to optimise the recipes and improve the designs. It would be like monitoring your cloud infrastructure but you have plants instead of servers :)
Drafting the MVP
The best way to validate the design is to build a small prototype. This is my attempt to come up with a BOM (bill of materials) for the prototype and an estimated cost.
There are a few more things we would need for the prototype like a 3D printer for the base, and an LLM provider (or just Claude API key like in the Sol project) if we want to test the end-to-end. A few notes to bear in mind for the prototype if you chose to build this yourself, and that came up from my research and LLM interactions:
When soldering the pogo pins, bridge two pins together for the positive line and two for the ground line. This doubles the current capacity to safely handle the 4-5 Amps required by the lights.
3D prints are micro-porous. Coat the inside of your reservoir and the floor of every block with a thin layer of food-grade epoxy. This prevents “phantom leaks” and bacteria buildup.
I was also trying to think what was the best plant to use for the prototype. Apparently, Genovese Basil is the “hello world” of hydroponics. It roots aggressively, grows visibly every day (high gratification), and is chemically resilient to pH fluctuations. This is what is needed to grow hydroponic basil (included in the estimated cost of the prototype from above)
The Business Model and Next Steps
Just building a prototype of this would be a success. Anyone with some basic technical skill could start building their own local farming module. However, for this to scale into my dream of home-grown food, it would have to become a full-fledged business. And this is something that I’ve also been thinking about in my spare time.
I feel the way to make a business like this sustainable involves a model similar to that of Nespresso:
The company would manufacture and sell the lego blocks for each of the plants. Every year new blocks for new plants would be released.
On top of this hardware, the core of the business would be the consumables. Just as Nespresso sells coffee pods, this company would sell “seed squares” with all nutrients and all that is needed to grow new batches of plants. Every month (or whatever planting period required for that specific block), the user would receive the consumables required to grow their plants. I know this would make us dependent on an external company and a supply chain again, killing the original purpose. However, the same way that you can buy a computer and use Linux and open source software instead of buying a Windows (or any other software) license, if I were to build this company I would also post DIY tutorials to buy and grow the plants yourself leveraging your block.
I have a full page on my notebook with a sketch of how a company like this could be built. But as you could imagine, I don’t have the time or the mental space to focus on this right now (making structured data and data analytics available for everyone with Baselight is what occupies all my time these days).
However, this is something that I would love to see built, so if you are interested in learning more about the idea, you want to build a prototype, or you just want to chat and brainstorm, drop me a line.
I hope you enjoyed this one, please give me your feedback, and see you next week!
Turns out someone built a lego-farming module over a rack: https://sa.lj.am/rack-mount-hydroponics/