Like most websites, 30MHz uses cookies to remember you so that we can deliver an optimised browsing experience. Select ‘Accept all’ if you’re okay with accepting cookies from UserEngage (webchat and lead generation), Hotjar (website improvement) and LinkedIn (tailored ads). When you select ‘Accept only necessary’, we will place cookies that let you use our website properly by remembering your preferences and for anonymous statistics. For more information, please see our cookie policy and privacy notice.

Accept all
Accept only necessary

How we made our way into the Autonomous Greenhouse Challenge 

December 16, 2019

“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 competition consisted of growing cucumbers in a greenhouse, remotely, for four months, using artificial intelligence. Microsoft won and was even better than the control team of experienced growers who did it the classical way. This was a big confirmation of what machine learning can bring to this field.

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

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.

Daily light profiles 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!!!


How can we help you digitise your cultivation process?
Analyse all kinds of information from different data sources such as climate computers, sensors and manual input in a central platform. Improve the production process of your crops, plants, seeds or bulbs together with advisors, distributors and researchers. We are happy to talk to you about which service model is most suitable for your company.

30MHz is typing… Our extended support team is ready to chat!

At 30MHz we think it’s important that our users can use our platform in an optimal way. At times you may have questions and you would like some help from our support team. Email and our support page filled with helpful articles were your go to’s. But we thought it was time for something extra… ...
Read more

New 30MHz connect casing: How we protect your tech

To make sure your dataflow is fully protected, 30MHz introduces a new connect casing: waterproof, dust proof and even resistant to hits. This special shield will last longer and ensure a reliable dataflow from the connected sensor. What does that full protection mean? That’s what we will explain in this article. Watertight: resistant to wetness ...
Read more

Digital Twin at QING

For the innovation project Digital Twin from NXTGEN Hightech, several 30MHz colleagues came together with QING to exchange ideas about digital twins within the Agrifood sector of the future. Want to know more? Check out the (Dutch) video:
Read more