How we made our way into the Autonomous Greenhouse Challenge 

“I thought it would be great to participate, but clearly we were not in those leagues.”

An article written by Flavia Paganelli, CTO and Co-Founder 30MHz. 

The first time I heard about the Autonomous Greenhouse Challenge a year ago I thought it would be great to participate, but clearly we were not in those leagues: Microsoft, Tencent and Intel were three of the five teams participating.

The greenhouse where the cucumbers were grown in the first Autonomous Greenhouse Challenge. Photo: wur.nl

A few months after the competition ended, our CEO had the idea of asking Delphy, a horticulture consultant who won the third place in the challenge, if they wanted to join forces and participate together in the second edition of the challenge. It was agreed to make a proof of concept to see what we were capable of. And so the day we started we hired our first data scientist and we had a day-long meeting with Delphy to understand the problem.

The goal was to generate ideal light, temperature, humidity and CO2 daily profiles for a crop, given certain conditions and rules. The conditions could be the weather forecast and the available led lights in the greenhouse. The rules could be for example “there shouldn’t be sudden changes in temperature” (since it should emulate nature), or “there should be at least 8 hours of total darkness during the night” (since tomatoes also have to sleep). Given those, we generated profiles as you can see in the animation.

Defining a daily light profile considering the weather forecast and the needs of the crop.

We were still far from the results wanted, but we proved that in a short time we could understand the problem and build an application to solve it.

So we registered for the competition, together. The first instance was a hackathon, where the initial 21 teams had 24 hours to learn the best way to grow cherry tomatoes in a greenhouse simulator applying some algorithm of their choice. The teams were ranked based on the net profit obtained, but also on the strategy that they planned to use during the actual challenge, and the composition of the teams.

It was actually amazing to see people coming from all over the world, mostly from Asian countries. 26 different countries. We thought the composition of our team was pretty diverse but some teams even had participants joining from different time zones during the hackathon.

The Automators during the hackathon

The hackathon started effectively at 1 pm, and we had until 1 pm the following day. The first hour we had the nerves of the beginning: where to start? What do we do? Everyone wanted to do something but we were not sure how to begin and how to combine efforts. A group of techies and a group of agriculture experts needed to find some sort of common ground to work together. Eventually, we agreed on some ideas and everyone started working.

The total number of input parameters that we could give to the simulator was nearing 1000, where each parameter could have different values within a certain “reasonable” range that the horticulture experts could define. If we assume each value could have around 30 different “reasonable” values, we get up to 30.000 different possibilities to test. If the simulator took 15 seconds to respond as it did: we needed 125 hours, or over 5 days to test them all. But we had only 24 hours.

These input parameters were mainly setpoints for the climate computer. Temperature, CO2, lighting, screens, irrigation. The ag experts in the team helped us determine some reasonable bounds, and based on that we had to explore and get results. We couldn’t of course test all the possibilities in the given time. Otherwise, it would have been an easy problem. And we could only make one call at a time to the simulator. Each time the simulator would give us a result: what was our net profit?

We did start brute-forcing randomly at first, but soon we wrote a better exploration algorithm, giving it a “reasonable” starting point for inputs, looking at the result and keeping the new one if it was better​. Our data scientist called this the “Monte Carlo-ish” approach.

In the meantime, we gave the experts an easy to use tool through which they could also experiment with other parameters, calling the simulator and learning from the results. They tried to answer questions like “if we give as much light as possible do we get the most production?”, or “if we give more nutrition to the plants, do we get tastier tomatoes?” and how does all this impact the net profit?.

At the end of the day, everyone was quite tired, but we managed to improve our net profit steadily and were pretty enthusiastic. We didn’t think staying the whole night would help much, as tiredness makes it very difficult to make the right judgements, so we went to sleep at around 10 pm to continue the morning after. The last decision we made before going to sleep proved the above fact because at the last moment we decided -greedily- to be more intrepid in our exploration… a small change in the code… but when we woke up we noticed that the steady improvements we had been getting all through the day had stopped. We lost the night. We learned the lesson: if it’s late and you are tired, don’t try to make big changes.

The next morning we did some more progress. It didn’t get us to the top, but we made it, and we were one of the five teams who made it to the next instance.

Some of the Automators team members 

On the 20th of December 2019 we start growing tomatoes for real, for six months. The real challenge begins. Will we be up to it? We will definitely do our best!!!