Introduction

Smart Irrigation v2 is a continuation of the smart irrigation v1 project that was done as a proof of concept for automated irrigation through the use of sensors and pivots. Documents from smart irrigation v1 have been linked throughout this document. Although this solution is intended for use by Alberta farmers as part of the project with Farming Smarter and RDAR, this could be easily replicable for a different geography as well.

Problem Statement / Opportunity

By enabling hands-free irrigation, this project is an opportunity to add efficiency and intelligence to a key aspect in Alberta agriculture.

Solution

Hands-free irrigation is made possible by automatically detecting when watering is needed and remotely turning on the irrigation system, without requiring any manual input. This is achieved through a combination of sensors and a pivot-based irrigation system that can be controlled through Litefarm, a web application.

Ideal customer group

• This solution is meant for farm owners or managers who have one or more center pivots and one or more sensors installed on their farms. Typically, these are farms that are at least 180 acres.

• Solution is suitable in geographies where access to natural sources of irrigation like rainfall or proximity to waterbodies is less and dependence on an irrigation system is more prevalent.

Implementation

The MVP1 does not include Crop ET curves, elevation data and the calculation of the water deficit model.

The solution will be implemented in the following components and sub-components. The division and sub-division is done from a user perspective:

Module -1 Sensors

As a farmer and Litefarm user, I want to be able to add, view and manage sensors in my farm on the app. For this MVP, we will be supporting only sensors by the manufacturer Ensemble Scientific.

1. Study & Refactor existing sensor architecture

Research must be done on previous implementation for relevance and soundness of code. Adding notes from previous document:

• Review architecture and refactor as needed

• Make queries against time series data more performant

• Automated migration of data out of Postgres after a certain amount of time?

2. Add / Create sensors on map view –

• Flow to add multiple sensors through the UI: A single point on the map can have an array of sensors, all with same location, but different depths. Sensors can be added only on already created farms. An array of sensors can be represented by a single point.

• User flow to upload an array or batch of sensors

• Create sensor attributes in the DB

3. View, edit & delete sensors

• See essential sensor details by clicking on a sensor point on the map: Shows if sensor is active / inactive, soil water potential, label and depths of sensors

• Flow to edit the location, label and depths of a sensor array. It’s not possible to move just one sensor from an array of sensors. Can possibly make use of the create sensor flow and allow editable fields.

• Flow to retire/delete a single or array of sensors.

4. Capture sensor readings

Capture sensor readings in database via webhook. Archive / delete readings older than 6 months.

 Module -2 Center Pivots

A pivot is an farm machinery or equipment used for irrigation in large scale farms. As a farm manager/technician and Litefarm user, I want to be able to add, view and manage pivots in my farm on the app. Some field notes on pivots from previous implementation.

Assumptions:

• A farm can have only one pivot. It is assumed that a particular area of the farm is never irrigated by more than one pivot. As a rare scenario, for very large farms, there can be multiple pivots. In such cases, each pivot irrigated area becomes a separate “field” or “farm” and must be created as such in the Litefarm.

• A pivot-irrigated farm for MVP1 will have one homogenous crop throughout.

• Farm must be created first and then only a pivot can be added

1. Add / Create pivots on map –

• Add pivot: Create a pivot on the map, on an existing farm.

• Create pivot attributes in the DB

2. View, edit & retire pivots

• See essential pivot details by clicking on the pivot on the map: Shows if pivot is active / inactive, last irrigation prescription link (if available), else CTA to create one.

• Edit & retire pivots - to verify if this is a necessary user action and plan to scope after talking to Lewis

3. Initiation / Generate Irrigation prescriptions

Generate prescription to have an additional visibility in the app, apart from the pivot on the map.

• To generate this, there must be atleast one pivot, one active sensor and one crop plan added.

• Irrigation prescription or a .vri file is a modified json that is understood by pivots. This will be created by Litefarm either when a user requests it, or when the sensor triggers the need for one.

• This will also form the basis for the irrigated zones view on the map, described in next module.

• The structure of the json could vary depending on the pivot manufacturer.

4. Irrigation prescriptions - Push & History

h) A newly generated irrigation prescription could show up in the notifications with CTA to confirm or ignore. Push prescription to pivot on confirmation. Delete prescriptions older than 24hours, notifications can remain without CTA

i) Store irrigation prescription files in the app, possibly in a tab in the documents section.

j) View an irrigation plan with zones - An irrigation plan shows the irrigated zones of the field for a single pivot. More detail in the next module.

Module - 3 Layers & Integrations

Layers are visual representations of data on the same map, usually simultaneously. An example would be satellite view / default / terrain view in Google maps.

In addition to showing farms and structures on the map, we will be showing soil types and irrigated zones in the fields in two-dimensional map (not supporting elevations and depths), one at a time.

Currently we show farm location, boundaries and structures in the map. This can be expanded to the following:

View soil layers on map

The map would give the user an idea of the type of soil that is present in their farm(s). A user can look at the map of the farm and see a visual representation of zones / areas categorized by type of soil.

SoilGrids API gives the data on type of soil and other soil data when a lat long is passed. To begin with, this will be system generated and we won’t accept user uploaded maps or zones.

View irrigation zones on map

The irrigation prescription typically is not readable by common apps and is not easily consummable. So the last executed irrigation prescription is made available on the map as irrigated zones so it gives users a user-friendly way of understanding how their area was irrigated.

This will be system generated and not user generated. Please refer to this document on how these zones can be generated. An example of how that would look like:

Open Questions

1. Can/should users be able to edit an irrigation prescription?

2. How much of an area is represented by a sensor? - answered in irrigation zones in module-3 layers

3. How do a sensor and a pivot understand a field mapping? Is it configured at the beginning? - also answered in irrigation zones in module-3 layers

4. How exactly do we integrate with a pivot?

5. Possible error scenarios to be thought through in this entire journey.

6. How to show soil types for multiple depths in layers? How much of this information is relevant to the user?

7. We could recommend min and max values for the 10 crops and give a guidance around that for a user to choose? Or this common knowledge. Check 6,7 with Michelle

8. Are the user settings / rules we defined fine enough to prevent over and under watering? Double check!

9. What if we don’t store the sensor readings at all ? What if we get the sensor data on demand? Things to consider: Is data required for research? How far back does a user want to go?

10. The database structuring depends on whether other sensors are push or pull based?