Today irrigation does often not keep into account possible water leaks from watering pipes. This superficial management is leading to a huge waste of water, which is one of main causes of drought.
Our proposed solution consists of an interface through which it is possible to monitor the irrigation system. The user can know if a leakage is detected and where it is located, as well as the flow of water at the source site. Another available information is the past water usage schedule, with the relative periodical measurements of water flows.
Our system allows to do the following tasks:
- Leakages detection, quantification and localization
- Water usage monitoring
We have created three subtopic, you can see all this work in Design and Evaluation in the relative GitHub page:
Prototype:
- build the physical prototype, solving the technical problems
- create different algorithms to synchronize the nodes
- connect prototype and AWS with MQTT
- take data to choose the best algorithm
- take data to set a correct threshold
Simulation in IoT-Lab:
- build the infrastructure of the simulation, solving the technical problems
- send data between nodes with lora-semtech
- create a sample generator function to simulate water flow rates and leakages
- take data of the energy consumption
Connection of IoT-Lab and AWS:
- create a node that send data to TTN using the sample generator function
- integrate TTN and AWS
- create the rules, the dynamoDB and the lambda functions to work with the data
- create the website page with Amplify
There are also some video on YouTube that explain the project:
DESIGNArchitectureWe propose a tree architecture with a MCU at source site connected to a water flow sensor, a LED and a buzzer. A fork is defined as a site where a single pipe divides itself in two or more output pipes. We place a water flow sensor for each of these diramations, all connected to a single MCU. So. a MCU at each fork site, which can be at different depth levels, is needed. Furthermore, we place a MCU for each pipeline branch, more precisely in correspondence of each irrigation valve, where we place a single water flow sensor connected to the MCU. Our architecture is scalable, so it can be used to control water leakages within a small field with the same crop or to control leakages from pipes irrigating different types of crop in the same field.
Our system is composed of 3 different pieces:
- MCU near the water source (connected through a power cord) called CHIEF
- MCU near the pipeline fork (using a battery) called FORK
- MCU connected to a water flow sensor at valve site (using a battery) called BRANCH
In our architecture we preferred to focus our attention on things, with computation performed at nodes rather than in the cloud. So, all the operations are done in the nodes.
PrototypeWe constructed a real prototype to demonstrate the working principle of the system. It is made up of a linear pipe and two MCUs located at its endopoints, with a water flow sensor for each one, together with a water source and an intermediate valve used to simulate a leakage.
Unfortunately, we found some problems working with LoRa with our chosen ESP32, even if it should be officially supported by RIOT. So, in order to overcome this issue, we decided to switch to WiFi technology only for demonstating purposes, using MQTT Protocol.
AlgorithmsWe have tried 3 different algorithms for allow a correct and synchronized test between two diffent nodes. The three algorthms are:
- Ack
This is the first algorithm that we have implemented and it does not work well. Firstly there is a bug in the code, in fact with this code the Son has an higher flow that the Source, and this is not physically possible (if you find the problem, please tell us where is it), Secondly with the data obtained, we have seen that the water flow arriving to the Source (before our architecture) is not stable and the code was not robust against this problem.
In particular the Source controls if there is a water flow, if yes it does the test and sends the value to the Son; the Son obtains the value, sends an "answr" to the Source (used to control the Son is not broken) and starts the test; after that it does the difference between the two values and see if there is a leakage or not, if yes it sends the value of the leakage in L/min to AWS.
- Handshake
This is the second algorithm that we have implemented and it works well.
In particular the Source controls if there is a water flow, if yes it sends an "heloy" to the Son, the Son sends an "answr" to the Source, Source sends the message "start" and starts the test; when the Son obtains the "start" it also starts the test; the Source sends to the Son the result of the test and, when the Son has both the values, sees if there is a leakage, if yes it sends the value of the leakage in L/min to AWS.
This system works well but it is uselessly complex and it is less efficient than the next one.
- SyncAck
This is the third algorithm that we have implemented and it is the one that will be used in the real scenario.
In particular the Source controls if there is a water flow, if yes it sends an "heloy" to the Son, the Son sends an "answr" to the Source and it also starts the test, Source receives the message "answr" and starts the test; Source sends to the Son the result of the test; when the Son has both the values, sees if there is a leakage, if yes it sends the value of the leakage in L/min to AWS.
This system works well and uses one less message.
SimulationWe built a simulation infrastructure on IoT-LAB, to provide a large-scale irrigation water leakage system and to test distributed interaction between MCUs. The communication between nodes is implemented using LoRaMAC, while LoRaWAN and TheThingsNetwork are used to send data to the cloud. Also, we will use this simulation to makes some experiments on energy consumpion using the IoT-LAB monitoring tool.
The simulation aims to detect leakages in a scalable distributed infrastructure, while the prototype focus on detecting leakages for a single pipe. For this reason, in the simulation we have made some assumptions:
- A code function simulates samples to avoid delays in message propagation, false positives, and all the problems discussed in the prototype. Instead, we will use a logic time to simulate the sampling at the same time.
- Forks on a pipe will divide the water flow into equal parts.
- Since we are simulating samples, we can set the threshold for leakages to 0.
The AWS architecture above shows our cloud design. In detail, data are generated both from the prototype and the simulation, but sent to AWS through a MQTT-Bridge for the prototype and TTN for the simulation. Data are sent to AWS IoT Core, using also AWS CloudFormation in the case of TTN. With two proper AWS Lambda functions data are stored in two NoSQL DBs, one for the water flow at the source and one for water leakages. With a separate unique Lambda function, data are retrieved form DBs and associated to an API deployed with AWS API Gateway. The website frontend, taken data dynamically from API endpoint, has been deployed with AWS Amplify.
WebsiteHere it is a demonstration of website content:
From the website user can monitor water flow at the source looking at last 10 measurements displayed in the upper graph and checking some statistics about average water flow. A proper alert is shown in case of leakage, with leakages displayed in the lower graph with correct location and quantity. Also here, some statistics can be retrieved.
EVALUATIONAlgorithms PerformancesThe three algorithms proposed in the design phase have been tested.
Algorithmic errorThe test of the Ack algorithm has shown that there is a problem in the code (intially we thought it is caused by the use of threads in the program, after we understood is linked to the water flow sensor) and that the water flow before our system (that we consider always present) is not stable and this issue has to be solved by the synchronization algorithm.
After several tests, and using the considerations done before, we have found that one water flow sensor has some problems and detect less impulses.
Not having other sensors, we have decided to put the best sensor in the Source and the worst in the Son, so we will have an higher Source in a NO leakage situation.
We have done some analysis to set a correct threshold in our algorithms to limit the presence of false positives and false negatives.
We have chosen the syncAck as the final algorithm because it uses one message less. We have analysed the time of the SyncAck algorithm to understand the error that can be created and to use this values for the calucus of the energy consumption. We have analysed that the standard deviation is high and this means that there is a large distribution of the data, in particular this means that the time taken by the messages and the code is fluctuating. Looking at the scheme, it is possible to understand the time of the messages and also the quality of the synchronization of the algorithms.
Here the messages take 0.462 s while the latency of the two samplings is 0.552 s (time in the Son between the end of the test and the arrival of the value of the Source). This means that the Source has ended the test 0.090 s before the Son. So Son and Source have an error of synchronization of 0.090 s.
To find the error of the algorithm we have to decide the time of testing: now is 3s but if we increase it, the influence of the error derived by the synchronization problem is less.The proportion is 0.090s : (TimeSampling) = x : 100. The FlowMax is 30 l/min.
We have analysed three times of testing.
- TimeSampling of 3s: 3% of influence, 0.90 L/min difference of water
- TimeSampling of 5s: 1.8% of influence 0.54 L/min difference of water
- TimeSampling of 10s: 0.9% of influence 0.27 L/min difference of water
So we take 10s of sampling time to limit the possible error. We do not increase more the sampling time because there will be a trade off with the energy.
Now it is important to discuss this values. The 0.27 L/min is the possible difference of L/min between the Source and the Son. This is the worst case scenario but it is important to analyse the algoritmic error in the worst case.
Turbine errorAnother significant error of the architecture is the instrumental error of the water flow sensor. Because of we have not another turbine with the correct value of the water flow or other instruments, we have run the system for several tests and we have analysed the difference between the values of Source and Son. It is important to observ that this error is influenced by the algorithmic error too.
After a lot of tests, we have analysed these data to fix a threshold for the detection of the leakages, and we have done the mean of (flowSource-flowSon)x100/flowSource%:
- 3s -> 4, 29%
- 5s -> 6, 34%
- 10s -> 4, 30%
The dynamic threshold is more efficient because it is more accurate in the lower water flow rate. We have done some sperimental test but the system was proned to false positives. So below there are our conclusions.
Conclusions on the thresholdFinally, for the threshold, we will give this observation:
- We did some tests and considering the average, we observed that in a No leakage situation there is a 5% difference between Source and Son, due to the error of a turbine (instrumental error).
- We then observed that, based on the changes in the flow before the source (therefore on the stability of the flow rate of the pipeline), there may be an average possible error of 0.9%, due to the algorithmic error.
- We have observed that in the handshake this algorithmic error is teoretical less, but for time constraints we have not focus on it.
- We have tried to apply the 5% threshold but experimentally we found too many false positives. We tried 7% and 10%. We have judged that 10% is acceptable.
- Finally considering that the turbines in a NO leakage situation have an unexpected 5% error; assuming that there is not the same problem for the future system, we will have a threshold of 5%.
- Why did it happen? First of all we have done many approximations. The standard deviation is high and we have understood it as an unreliability of the mean. Finally, the conduct of the test affects the result: the position of the cell phone and the turbines varies the times of the messages (and therefore the algorithmic error). The stability of water flow rate before the Source has been probably good during the training of the threshold and bad in the test.
Our requirement is not to tolerate a water loss of more than one day, so we wish to detect a leakage within 24 hours. Now, since the leakage is an unpredictable event, we cannot define a precise strategy apriori, but we want to indentify the best one in order to minimize power consumption. We compute this strategy analitically. In the first following analysis, we do not make any assumption about synchronization of nodes. Firstly, for simplicity, we focus on a simple father-child pair, since the same reasoning holds for every adjacent pair of nodes of the tree topology. Now, we define x as the send rate (msg/day) of the father, so the number of messages sent per day, and y as the total listen interval of the child (in hours/day). After some calculus, which you can find on GitHub, we have:
Etot = 42.61Wh
But the consumption is too huge because the time of listening is too high. So we propose another approach.
Drift rate clockWe use another approach with node synchronization. The listening time is reduced, in particular we have to synchronize the nodes in pairs and for each node there will be a situation in which it will be the passive one (waiting in listening) and another situation in which it will be active (send the message for starting the test). As before, we consider the worst case, in which a node is both passive and active. We use Deep sleep mode. The drift rate for ESP32 heltec is 1.7 sec per day. Assuming a resynchronization for each day, we need to set a listening time per day such that the drift rate over the day is not a problem. An acceptable solution is 10 seconds/day. So, for a year:
Etot ≈ 36Wh
In this situation, we would use a 5000mAh battery (for example, a phone battery), replacing it every 6 months
So, we noticed that the energy consumption bottleneck is given by the energy consumed during sleep time. However, in the official documentation of ESP32 Series, we found another value for the Deep sleep mode, which give us for the same calculus:
Etot = 7.58Wh
Now, with a battery of 2500 mAh, we can power the device for at least one year, that is our user requirement.
Comments