1 of 30

Smart

PLANT system

CS460 G1T4 Jian Lin, Gadman, Kok Wee, Yi Xin

2 of 30

01

02

04

05

PROBLEM

FUTURE WORKS

LESSONS LEARNT

SOLUTION

TABLE OF CONTENTS

03

PROTOTYPE

Improvements

Live till old,

Learn till old

WHY

HOW

SEE

3 of 30

Problem

4 of 30

PROBLEM

Singaporeans love growing plants but many do not have the time or physical capacity to care for them properly.

5 of 30

SOLUTION

A cyber-physical system that monitors and water/fertilise plants to reduce the effort required to care for plants while increasing care quality.

6 of 30

PrototypE

7 of 30

OUR PROTOTYPE

Smart Plant System

8 of 30

System features

MONITORing

AUTOMATED

The plant environment such as the soil moisture and sunlight level is actively monitored

Pump systems that automatically dispense a set volume of water/fertiliser

9 of 30

System features

INTERFACE

portability

A web application present users with system information and configurations

A reservoir system that stores water and alerts user of water levels

10 of 30

OUR ProtoTYPE as a CPS

Sensing

Computation

Networking

Control

Moisture
Light
Water Level

Raspberry PI
ADC
Python

GPIOs
WiFi

Relay Module
Watering Pump
Fertilising Pump

11 of 30

CIRCUIT DIAGRAM

12 of 30

PROTOTYPE COMPONENTS

TYPE	name	details
Sensor	1x Soil Moisture Sensor	3.3-5V, Analog
Sensor	1x Light Sensor	3.3-5V, Analog
Sensor	1x Water Level Sensor	3.3-5V, Analog
Sensor	1x Temp & Humidity Sensor	3.5-5.5V, Digital
Actuator	2x Water Pump	6V, 30ml/s
Actuator	1x Relay Module	3.3-5V, 4-Channel
Microcontroller	1x Analog-To-Digital Converter	3.3-6V, PCF8591T Chip
Microcontroller	1x Raspberry PI 4B	-
Power Source	1x Battery	9V
Storage	1x Micro SD-Card	32GB

Not necessary since I will be covering the components in the demo anyway

13 of 30

FEATURE 1

MONITORING

14 of 30

What?

why?

how?

Soil moisture and sunlight sensors to take measurements of plant environment. Soil moisture measurement is processed by backend system to carry out watering action, based on set moisture threshold.

By taking in soil moisture data and watering the plant based on this measurement, it creates a closed-loop system that ensures automated watering capabilities. Sunlight data is collected for plant owners to understand the amount of sunlight their plants are getting so that they can adjust the plants location to get the best sunlight.

We connected the analog sensors to an ADC which feeds 8-bit data to the microcontroller (Raspberry Pi). This data is processed by a flask-based server that controls the system and which settings are configurable via the web app.

The first feature we have is monitoring. As the moisture and light sensors of our system takes in measurements from the environment surrounding the plant, these measurements are then processed by our system to perform watering actions based on a predefined threshold. As the watering is only triggered after computation has been made, this makes our system a closed-loop system.

Moreover, as light data is being tracked by our system, plant owners are able to identify how much sunlight their plants are getting. In the event that they feel that their plants are not getting enough sunlight, owners can move their plants to a location with more direct sunlight, which is easy since our system is small and portable.

To achieve this, we have connected the analogs sensors to an ADC which feeds in 8-bit data to our Raspberry Pi. The backend computation is served by a flask-based server that controls the system and can be adjusted through our web application.

15 of 30

FEATURE 2

automated

16 of 30

What?

why?

how?

While the fertiliser dispense system runs based on a configurable time-interval, the water dispense system is part of an automated closed-loop system together with the soil moisture sensor.

This two dispense systems allow the prototype to automatically care for the plants without the plant owner’s intervention, fulfilling the core functions of our solution.

The water pump runs based on the configured soil moisture threshold data from the backend server. Meanwhile, the fertiliser pump runs based on the time-interval data. The frequency of instructions is in tandem with the logging of the sensor data, which is every 1 minute.

17 of 30

FEATURE 3

interface

18 of 30

What?

why?

how?

A web application is created to allows the presentation of system data in a visualised manner and allows the configuration of system settings.

This makes it easy for the user to understand data collected. At the same time, it is simple to configure the system parameters based on the user’s preferences.

The web application is built with the React framework that utilised API data sent from the Flask backend server. This application contains data calibration and formatting functions, and is integrated with several lightweight libraries such as ChartJS to create a user-friendly interface.

19 of 30

FEATURE 4

PORTABILITY

20 of 30

What?

why?

how?

A reservoir system is integrated into the prototype which allows it to be portable and easy to set-up. This system is also set up with automated notification via SMS to alert plant owner’s that water level is low.

As a prototype, it is important for the hardware to be portable so that testing can be performed efficiently. Additionally, when deployed for application, this portability feature will allow the plant owner’s to adjust the plant location easily and reduce the cost needed to connect a fixed water source.

A water level sensor is used to collect reservoir levels. The data received is sent to the backend server for processing. Twilio API is used to send notifications to the plant owner whenever the reservoir level is below the customised threshold.

Our last feature portability. As our systems works with any containers that is capable of holding water, plant owners can easily find such products lying around their homes to set up with our Smart Plant Systems. Furthermore, with the integration of automated alerts via SMS from our system, plant owners will be quick to know if the water level in their reservoir is running low. This removes the need from them to have constant supervision over the reservoir system.

We believe that being portable is very important as the testing and deployment of our systems can be performed efficiently. Similarly, being portable also means that plant owners can easily move our system around to fit the needs of their plants, and that a fixed water outlet is not required to make our system work - unlike traditional watering systems. This also means that plant owners in apartments can also utilise our watering systems even if they keep their plant indoors, for example along the corridors or inside their house.

To achieve our water alerts, a water level sensor is to be fitted in the reservoir. Data is then sent to our Flask backend server for processing. If the water level is computed to be low, the Twilio API is then called to send an SMS to the plant owner that the water level is below their defined threshold.

21 of 30

Demonstration

22 of 30

23 of 30

Future

Works

24 of 30

FUTURE WORKS

autonomy

MONITORING

scalability

A variety of high-quality sensors can be added to the system to enhance the capabilities of the system, such as nutrients and PH sensor.

Connect the water pump to a water pipe to make the system fully automatic. However, will trade off portability.

Although the circuits are relatively independent, more can be done to improve the software to allow more sensors and actuators to be added onto the system.

First and foremost, complete automation. Complete autonomy is something that we thought would be a great and logical extension to our current set-up. Currently, one of our key features is portability. If say a user wants a completely automated system, we want to be able to enable that by allowing our system to run completely autonomously through connecting the pump to a water source. This removes the need for any human interaction with the system at all.

Next, with our current implementation, monitoring could also be optimised. Currently all of our sensors run through a single BUS. The implication of this is that we potentially are not able to increase the fine-grainedness of our logging of data due to the limitations of the single bus on some of our sensor outputs. We intend to improve this monitoring situation simply by increasing the number of buses that we interface with.

That said, we also see a potential in adding other high quality sensors to more effectively observe and capture the different states of data with our system.

Lastly, scalability is also another important factor that we would like to consider (can talk about how singapore is heavily invested into smart farms and this project can lead to that). With our current setup, circuits are already relatively independent. However, we see potential room for improvements where we can further modularise our system to enhance performance in the areas of assembly, portability and functionality.

25 of 30

Lessons learnt

26 of 30

Learning Phases

Research

Planning

Application

Troubleshooting

Improvement

Learn about the problem

Study potential solutions and approaches

Learn to build

Identify issues and learn from mistakes

Apply knowledge

27 of 30

Lesson 1: RESEARCH

Challenges

Digital Raspberry Pi pins vs Analog sensors

Learning Point

Research on the parts to determine compatibility and availability

The lesson we’ve learnt from this project was to do our research thoroughly. As we embarked on our project, we initially thought that the sensors we’ve bought was a plug-and-play system. To our dismay, we’ve only found out that the Raspberry PI’s pin are digital while the Sensor’s pins are analog. We had to make a second trip down to Sim Lim tower to purchase an Analog Digital Converter to correctly read the inputs from our sensors. The learning we have taken away from this is to first research on the specifications of the sensors we are intending to use to determine it’s compatibility and availability. Likewise, to prevent hiccups like parts failures, we could also get extra quantities of the components in case of inadequacy or part failures.

Now I will be touching on the various lessons we have learnt
Firstly, we learnt the importance of research.
We did not know that the raspberry pi pins are digital while our sensors are analog thus we needed to buy the ADC on a separate occasion which is time-draining
We feel that it would be more ideal if we placed more emphasis on the parts research which includes the compatibility and availability before committing to the components so that we can prevent wasted time in procuring components

28 of 30

Lesson 2: CALIBRATION

Challenges

Inaccurate and inconsistent results

Learning Point

Systematically calibrate the operational ranges of sensors
Account for invalid readings

The second learning point we can take away from this project is the practice of calibration. As we tested and developed our prototype at home, our dashboard was developed with the readings we received from the readings we received from our sensors in our home setting. However, after we hooked up our prototype in school, we realised that our readings was far off and uninterpretable. After playing around, we came to an understanding that we have to recalibrate our system every time we set it up in a new environment so that we can get accurate readings from components like our moisture sensor. Another possible remedy is to set a wider range of allowed readings to provide buffers for different environments so that we can reduce the number of calibrations required.

Secondly, we learnt to calibrate our data.
We were met with inaccurate and inconsistent results during our prototype development journey which confused us initially and slowed us down.
From this challenge, we learnt to calibrate the sensor data in a systematic manner by create max and min boundary variables for the sensor data which we can update everytime we boot up the prototype.
We also learnt to account for invalid readings. There are times where the readings from the ADC are invalid, such as having duplicate readings and min/max readings. Thus, we needed to add to conditional code to filter out these.

29 of 30

Lesson 3: PROBLEM SOLVING

Challenges

Troubleshooting in a multi-faceted system

Learning Point

Tracing through data flow
Tape and do some cable management for the wire connections for better durability.
Label the wires for more clarity and easier troubleshooting

The lesson we can take away from the project is the challenge of hardware and wire management. As the wirings of each components is small, short and fragile, any major movements may results in the various components disconnecting from one another easily. Moreover, as these components are meant to be reused in future projects, the idea of soldering these components together is not feasible. We recognise that it is important for us to layout the components and how they should be connected to one another before building our prototype. We believe that doing so will make both the management and troubleshooting of components easier for us in our developing process. Furthermore, to allow for a greater reliability in the connection of the components, we could have utilized stronger tapes like black tape to join the wirings together.

Last but not least, we learnt how to problem solve.
It was our first time working with a multifaceted system, which includes backend, frontend and hardware. Thus, when it comes to troubleshooting, it was challenging to identify faults in the system because problems could be due to the hardware wiring, sensors fault or due to some backend servers not running properly or some commented out code in the frontend web application.
Through this project, we learnt the importance of tracing the data flow of the system from the sensors to the backend server and then to the frontend code. We also learnt to secure the hardware by taping and doing cable management for connections so that chances of loose connections are lowered. We also learnt to label the connections to make troubleshooting of the hardware easier

30 of 30

THANK YOU

Let’s make Singapore technologically GREEN!