MoniGrow

MoniGrow Logo

Inspiration

We began our search for urban innovation ideas by focusing on food-based solutions in urban locations. Due to expansions in urban areas, the quantity of local land that is available for farming is diminished, making it more difficult if not impossible for those living in urban settings to obtain crops grown in their area. The alternative, purchasing crops out-of-state that need to travel by truck for hours to days, is both more unhealthy and more expensive.

This is where we came across hydroponics, a solution that enables those living in urban areas to grow their own produce. Hydroponics is a form of soil-free farming, allowing for setups to be built indoors in small confined areas. With innovations in hydroponics comes a lower barrier to entry, thus allowing more people living in cities to gain access to locally-grown produce.

However, as it still stands, the benefits of hydroponics come with a relatively high barrier to entry. For our project, we’ll be lowering this barrier by addressing two problems: The inherent volatility of some hydroponic setups and the effort needed to monitor plant development.

The first problem can be seen in setups such as ones using a Nutrient Film Technique (NFT). Though these setups are efficient, they are vulnerable to cases of pump failure and power outages, both of which could result in total crop failure if not caught in time. The second problem involves the time needed to be dedicated to system maintenance. Those with full-time jobs may not have the time to measure: the electrical conductivity and pH of the water the temperature and humidity of the air the light intensity on the plants and more on a daily basis, nor would anyone want to as it is tedious work.

What it does

Monigrow works to address the problems above by providing two utilities.

1: A monitoring system that displays the information of the monitored variables on easy-to-read graphs.

2: An early warning system which notifies the user in the case of irregularities or deficiencies in their setup. Examples can include a sudden drop in water flow or a pH level outside of the healthy range for the plant.

These two utilities are complemented by an additional feature: a database of plants containing the acceptable variable levels specific to the plant, as well as an option to add plants that are not in the database. The plants that are being grown are then chosen from this set by the user, which will enable the application to both monitor whether the environment around the plants are within acceptable levels and to report any discrepancies to the user.

How we built it

We began by splitting Monigrow into three parts:

1: A web application that transferred data to Firestore and simulated various scenarios with a hydroponic setup (More information in Challenges) We programmed this application by using two main files: index.html and main.js. index.html is used to hold the basic structure of the application as well as the Firebase SDK integration. main.js is where the main functions of the application were held. It contains functions that wrote documents into specified collections within Firestore, as well as buttons calling functions that simulated situations in the system. An example of this would be the normal case, where the application generates and uploads data that would typically be expected of a well-functioning hydroponic setup.

2: A mobile application that retrieved data from Firestore to display to the user in an organized fashion and allowed the user to specify the plants they were growing from a database and add their own. We began this part of the project by starting off on an Expo app creation template. The database and various monitored variables were organized on different pages, while the main screen held buttons that navigated the user to said pages. The ‘database’ All of this was programmed in Javascript and HTML using React and React-Native.

3: A web scraper that collected a database of plants from link and uploaded it to Firestore. For this part of the project, we wrote three main files: dataclean.py, webscrape.py, and uploadtofirestore.py. dataclean.py parsed a text file containing information from the Food and Agriculture Organization of The United Nations link. The information was parsed into common and Latin names. The common names were then input into webscrape.py, which searched for records on link and wrote down the temperature requirements into degrees.txt. The names which did not appear on the record were then removed from commonnames.txt. This left us with two files: commonnames.txt and degrees.txt, both of which we input into uploadtofirestore.py in order to convert the file data into documents on Firestore.

Challenges we ran into

1: Lack of Hardware This is by far the biggest challenge that we had to overcome. Due to the shipping time of hardware components taking much longer than the duration of the hackathon, we could not obtain any hardware components for our project. Since our application depended on the input of hardware sensors, we were unable to implement our concept ideas fully.

We solved this issue by building multiple simulation cases into the web application. These cases generated data reflecting several scenarios that could occur within a setup, which put both our monitoring and warning systems to the test.

Though it is unfortunate that we weren’t able to fully realize our idea, it provides our project with the potential to grow in the future even once the hackathon is finished.

2: Implementation Growing Pains Our project uses React, React-Native, Firebase, Expo, multiple libraries (some of which are outdated), and some more. With such a diverse number of tools, it was inevitable for us to run into problems during implementation.

One such problem can be seen in the mobile app implementation. When programming the graphs used to display variable information, we had to integrate outdated libraries with the Firebase SDK. One such library, a table library that depended on an outdated version of React-Native, could only work on mobile apps, preventing us from extending the application to the web as well.

3: Bugs. Lots of Bugs Though this is probably a common issue, it was one that ate a lot of time and productivity. Debugging our code was a large challenge since it consumed the time that we could have used to implement more features and mentally recover from the work.

An example would be when one of us accidentally included text in the mobile application that was not closed under , a constraint brought from working under React-Native. This bug was relatively easy to spot and fix, but some others less so. Like the other teams, we were able to overcome this challenge through crusty CSE 12 debugging techniques and grit.

4: A Painful Mistake I refreshed this Devpost page before saving it. I was finished. ;-;

Accomplishments that we're proud of

1: Redirecting the user to a new screen: This may sound simple, but it took a considerable amount of time to figure out and the end result is smooth and satisfying to watch like it was made by a professional.

2: Building the web application and the many simulated sensor scenarios This accomplishment required many parts. First, we learned how to transmit data to Firestore. Then we programmed buttons that could start and stop transmitting generated data and a constant rate. The end result functioned well and did its job, which we considered to be a milestone in our project since we were learning on the fly.

3: Making real-time graphs that updated along with our data Getting the graphs and tables to retrieve data from Firestore and actually displaying them in a manner that wasn't confusing took a lot of trial and error. The two libraries we used both had issues that required workarounds to make function. One of the libraries relied on an outdated version of React Native, while the other did not work on web builds. I'll admit, getting the labels to work properly on the line graphs and watching it update with data in real time was quite satisfying after toiling around with the formatting and trying to understand the rendering flow of React Native components.

4: Building the web scraper in order to collect data for a database It felt pretty cool working on a data science practice in real life and the webscraper did its job effectively.

What we learned

This project introduced us all to React and React-Native programming. We grasped a basic understanding of these two libraries as well as how to add and retrieve data from Firestore. This came with the learning experience of setting up a Firestore SDK in an application twice, once on the web app, once on the mobile app.

In addition to the technical skills that we learned, we also acquired some knowledge regarding the workings of hydroponics and its various setups, as well as the variables that need to be monitored for healthy plant growth.

We learned how to web scrape using Python as well as how to upload data to Firestore using Python.

What's next for MoniGrow

There are many ways that we can improve Monigrow in the future. Without such a strict time constraint, we can purchase and utilize sensors and a microcontroller to fully implement our project to be fit for real-life usage. We can implement new variables, such as light level, airflow, and water flow, and utilize either esp32s for small-scale monitoring or LoRa for large-scale implementations. We can also improve the mobile application by allowing users to register their own sensor devices upload their data, thus making our software more flexible and user-friendly. We can build on the early warning system and make it more complex, potentially using machine learning in order to detect discrepancies in the future. We can make some aesthetic improvements to the UI and add more information to the plant database. Finally, we can standardize a scalable system of hardware and sensors to use along with our applications, allowing Monigrow to be fit for both local and commercial use.