/ tech

The AstroPlant framework

One of the intriguing challenges of the AstroPlant project is the design of the electronic hardware and software systems underlying it. Our efforts focus on developing a truly broadly applicable and open source framework, providing a solution for easily deploying monitor and control systems. In the most general sense, the target is to develop a novel ecosystem design for managing multiple IoT devices from a central location. The devices receive instructions and configurations from a central system, perform control programs – such as plant growth recipes – and transmit their data to be collected centrally.

This framework will support the global AstroPlant citizen science program, where multiple plant growth kits are located around the world, all managed from a single website. However, due to its flexibility the framework also lends itself to other purposes, such as greenhouse farming where a central system is used to tightly monitor and control various plant growth environments, beer brewing, or home climate monitoring.

High-level framework overview

The framework is split into two parts: the kit – an IoT device – and the backend. The kit implementation forms the basis of the framework; it is a lightweight system providing an abstraction of sensor-driven applications. The main abstraction made is that of a peripheral device, which is an abstract device that can be run or can accept commands, or both. A sensor, such as a barometer, is a peripheral device that can be run and produces measurements. An actuator, such as a heating unit, is a peripheral device that can accept commands. Each kit is connected to a number of such peripheral devices.

The kit itself does not know of its purpose: instead, it communicates with a back-end for configuration and dynamically loads the required peripheral device functionality. Due to the dynamic loading of functionality, the kit is easily extendable and custom peripheral device functionality can be defined by users. The functionality required for the AstroPlant lab is provided as precisely such an extension, i.e. the AstroPlant peripheral device library – providing official AstroPlant implementations of drivers for the lab hardware required – is treated and dynamically loaded through the same mechanism as any other third-party functionality would be.

For scalability and flexibility, the back-end acts as a central orchestrator for many kits, performing kit authentication and management. It provides a programming interface (API) for configuration of kits and publishing data. As the back-end contains the data models and acts as a central repository of all kit data, it helps keep the kit implementation lightweight and agnostic. The back-end itself is kept flexible through the same peripheral device abstraction: all functionality of peripheral devices must be accompanied by a definition of that peripheral device on the back-end. The definition states the expected measurements made by the device (if any), and crucially provides information on how the kit can load the device driver. The website is built on the back-end to provide a user interface for creating and configuring kits, as well as viewing real-time and historical sensor data.

In-depth AstroPlant overview

The AstroPlant kit is built on the inexpensive Raspberry Pi zero W, which runs the framework’s kit software. The kit consists of a purpose-built AstroPlant extension board, allowing for easy connections to the sensors and actuators needed for the citizen science program. In specific, the AstroPlant kit contains the following sensors:

  • a CO2 sensor (UART);
  • a water temperature sensor (1-wire);
  • a humidity and air temperature sensor (1-wire);
  • a light sensor (I2C);
  • an EC sensor (I2C); and
  • a pH sensor (I2C).

The citizen science project has only minimal control requirements, so the the AstroPlant kit contains a relatively modest number of actuators:

  • LEDs;
  • fans;
  • a Raspberry Pi camera; and
  • an LCD screen (I2C).

An overview of the framework can be seen in the figure below.

AstroPlant Framework


Recipe controller

With the ability of kits to be applied in varying environments, with varying sensors, actuators, and goals, there is need for a powerful means of expressing a kit’s control program. Many systems capable of effectively performing specific control programs exist. However, most of them are proprietary, purpose-built and limited in scope.

In the vertical farming community there have been recent efforts in standardizing plant growth recipes, allowing one to state the parameters under which a plant should be grown. Of course, such a recipe would be unlikely to be applicable to beer brewing or home climate control. Further, it is notably difficult to develop a recipe format that is sufficient for all use-cases even in a single domain.

Clearly, these recipes are not satisfactory for a system intended to be applicable to a variety of domains.

The AstroPlant team is shifting its focus from standardizing recipes, to standardizing controllers. A standardized controller is an abstraction of a system taking sensor inputs and commanding actuators. The controller comes in the form of a domain-specific virtual machine, which can be implemented on various platforms. The virtual machine accepts a domain-specific programming language, which represents the most abstract format of control recipes. Any control recipe can be performed on any such controller, as long as the requisite sensors and actuators are available.

For normal use, more specific control recipe formats (such as a simple plant growth recipe format) can be defined. Along with a format definition, a compiler should be developed to transform growth recipes of that specific format to the domain-specific controller language. It is possible that certain recipe formats will require additional information for compilation that is not in the controller specification, such as groupings of sensors or specific information about the growth environment. As such, a format can only be used if the requirements for compilation are met.

The goal of standardizing the controller is to provide a starting point for better recipe collaboration and easier recipe development. Once the controller has been standardized, the community can shift its focus onto developing recipe format protocols on top of the controller.


The goal of the framework is to remain unopinionated, nevertheless several choices have been made to enable implementation. Firstly, the provided back-end, website and kit are implemented in Python. Secondly, the back-end and kit communicate through HTTP requests and websockets. Such a system might not suit everyone, and, in collaborative research, interoperability is of utmost importance – especially regarding data .

As such, the AstroPlant team is actively collaborating with other groups, such as the Open Agriculture project, to push forward in the standardization of data exchange of IoT-backed experiment and control systems as well as the recipe controller. The goal is to provide a data standard enabling researchers to easily collect and use data from various sources, and to define new experiments.