The Autonomous
Grow Box
Sustainability
What do we provide?
The smart farm is for those who want to grow their own vegetables and herbs. It's for those of you who want to live more sustainable and reduce your carbon footprint. It’s for those of you who want to always have completely fresh vegetables at your hand. And yes It’s also for those of you who don't have any skills with plants. It enables the user to grow herbs and vegetables easily and efficiently with an hydroponic system. The only effort it requires from the user is inserting seeds in a grid, filling a water tank and connecting a box to an app. The the Smart Farm will do all the hard work. It doesn't get any easier! Green Goblins Smart Farm is for everybody.
APP ALPHA VERSION
FINAL BLOGPOST
Introduction
As a result of overpopulation and consumerism we have created a food industry where mass production and making money has become the main focus. This comes at a great cost for/to our planet. Everyday more rainforest and other natural habitats are destroyed. Food is transported thousands of kilometers in CO2 emitting vehicles. Pesticides are infecting our groundwater and it is wasted by ineffective watering of crops.
Therefore, there is a need for better and more sustainable ways to produce food. This is the goal of Green Goblins Smart Farm, developed in the course 41029 Design of Mechatronic systems. A product that makes indoor farming easy and accessible for everybody.
Product Description
Final concept
Green Goblin's Smart Farm allows the user to grow vegetables and herbs at home without any prior knowledge of plants. It is designed to be easy, effortless and time efficient. It is the perfect option if you want to limit your carbon footprint or have fresh vegetables all year round.
The farm is a modular system that makes it possible to stack grow boxes vertically. This makes it suitable for the user who wants to be self-sustainable as well as the user who just wants to always have access to fresh herbs. The modularity makes it suitable for any home, whether it be small or big.
To make it easy and effortless for the user, the smart farm does all the hard work. It has built in LED lights, an automatic watering system, temperature measuring, and an app to keep you updated. All this ensures perfect conditions for the plants and is therefore much more effective, both regarding water and time, than outdoor farming. It does not even require the user to fiddle with dirty soil in their kitchen because the farm works with a refined method of hydroponics also used by vertical farming companies like Nordic Harvest. Seeds surrounded by a fertilizing gel are placed in a specially designed plastic grid. From there the roots start to grow and soon after reaches the water underneath, in which they live for the rest of their growth period.
Use case
The vertically stacked grow-boxes are run by a mother box placed at the bottom. The mother box communicates with the grow boxes on top of it through an MQQT-broker. It works as the water supplier for its grow boxes. When a grow box needs water it sends a message to the mother tank that it's time to pump water up to the specific box. You can have one grow box on top of a mother box or as many as your ceiling allows. The boxes are easy to connect; they just click together via an "aqua lock" and an ATX-cable. This allows both water and electricity to flow between the boxes in a controlled way.
After attaching the boxes you connect each grow box to the mother box through an app. Here you also choose which type of plant the box contains and it will display information from that specific grow box. Fill the tank in the mother box with water, insert your gel-seeds in the plastic grid and place it in the grow box. Now your plants are ready to grow for approximately one month. When they are ready to be harvested the app will let you know.
The Prototype
Description
The prototype is built from solid materials, like acrylic and plywood. The prototype has been developed through multiple iterations, and has ended up as a functional alpha version. The prototype includes almost all of the features intended for the concept. They all work in cohesion, and show how the app interacts with the electronics, and thereby how software and hardware work together. The model is built on a 1:1 scale. By creating the prototype in the real scale we can see how it plays and works within its intended surroundings.
The prototype consists of a master box, a slave box and a tank for each one. Both boxes come with electronics built into the box. By having multiple slaves, we can showcase how the modularity works from box to box. This is our key defining feature, and what makes our product special. Therefore, it is especially important for us that this could be showcased when having the interplay of multiple systems.
Evaluation
The evaluation of the prototype has its basis in our expectations of the project and how we want it to look as a finished product: Ready for a sales pitch. These evaluations are either what we learnt or what we want to look further into.
First and foremost, we found a problem in a component that is essential for the modularity of our modules. The principle we call \textit{the ketchup principle} uses the tip of a regular ketchup bottle. In the beginning, this concept seemed very useful for us, as it was easy and accessible. This turned out to have a habit of leaking, and we thereby found out that we can’t use this for any future or final product.
The cleaning button will always have to be pressed in, and we found that this actually pushes our shelves a bit. A lighter button or a different solution will be in place for any future prototype.
Every shelf moves on a track, but these tracks are not nearly as smooth as they should be. The harshness of the tracks made the sliding of the shelves a bit difficult. We know that we will need a way to secure the shelves, so we have thought in different directions; new tracks or alternative guides, e.g. triangular guides in the sides.
The current system takes into account occasional responses and updates from the system, but from our way of data logging, we know that we will need more signals than we’re currently receiving under a bigger system. We have found that there is a limit to the speed of receiving and sending data, and the system can be clogged up. To avoid this, we will have to make a better system for receiving the data for the Arduino. Furthermore, our system and database should be able to manage, hold and secure user information, so we can provide the service for many users.
In multiple parts of the system there have been implemented features to ensure that user errors can’t occur. This is seen when trying to create a box, with a name already used, or limiting the ways of having the user control the specifics of the sending signals. There are multiple securities which could be implemented throughout the system. Currently when creating a name, it becomes locked up in a queue, and therefore multiple names can be sent at one time confusing the system, and ending up in flooding of the MQTT. The deletion of names, which also does not have any security, as one can delete a box from NodeRED, but still have the name as active on the Arduino and box. This could be solved by sending back to the Arduino deleting if it’s characterized under that name.
The Process
To control and keep an overview throughout the entirety of the project and product, we made use of the tool(s): Protomap and Prototype planners. This overview enables us to more easily have control over the iterations which we have run through, and what has worked for us throughout the prototypes. This was especially useful in a bigger group, where everyone couldn’t work on the same systems/prototypes. The Protomap was logically divided into separate modules, their wanted functions, and modularity. These headlines would ensure a fully fleshed and thought through prototype, where we have left no stone unturned. The functions were made in cohesion with our design brief.
Sprint 1 - Iteration on functions
During the first sprint we focused heavily on the individual functions of the sub-system. Since we had three main sub-systems to our system it made sense to split up into smaller groups and then later in the process create cohesion with the other functions. At this point we focused on iterative prototyping in the early stages to find the best track to continue on with the different sub-systems.
Sprint 2 - Connecting the different functions
With all of the functions coming together nicely, we started on implementing them in cohesion, by having them work on each other's signals. Due to limited resources and multiple setbacks we had difficulties especially in the mechanical department, as we didn’t have the tools of rapid prototyping. However, the code went very well, as we didn’t need the same tools to achieve the desired results.
Sprint 3 - Wrapping up our work
In these later stages we became too eager to finish, and started to forget about the protomap. This made it harder to work together, and keep tabs on where we were in the different phases/systems of the final prototype. This whole sprint became a bit rushed wherein the stress of a deadline lowered our energy and overview, making it easier to just force through it without keeping the structural overview of the protomap.
Future improvements
To improve upon what did not work optimally or at all in our prototype, we will look into other concepts for a more consistent and secure result. This could e.g. be interchanging the ketchup principle for an "aqua lock" mechanism, for a more elaborate setup.
For further work, we have considered different things that could make our product either meet our scope better, or improve upon the concept itself. The first concern is that one might have see the limitations to our modularity, as we’re only able to stack vertically. To make the modularity work horizontally, it will take more experimenting to make new fittings work, but this would allow a single master box able to carry a much bigger system. At this same time, an improvement like this will likely require the product to upgrade some hardware, e.g. the pump, as no pump can deliver an indefinite amount of water. To complete the vision of modularity, we can make the service chain circular, and thereby deliver upgraded components as a part of a membership-like service.
To make the water and fertilization even more seamless than it is now - using an older concept of pre-fertilized gel - a fertilization of the water supply will be in place. A sensor and supplier, e.g. a pump, will be able to give this result. Though this will open up to new problems like how we manage the fertilization in each box without backflow to other boxes.
Different types of plants require different kinds of light and intensity of luminance. So the system will have to be adjustable for the optimal growing conditions even more, and open up the possibility for difficult-to-grow plants. LED grow lamps are already seen as pretty universal, so a simple luminance adjustment will possibly be sufficient. This begs the need for a different factor, that we’ve slightly neglected in the project - a bigger database for different plants. As it stands, filling out this database is unnecessary, as it doesn’t change the functionality of the product, though it gives a much better user experience.
Conclusion
The project was successful, as it showcased that all of the set functions worked in cohesion. The key feature that makes our concept shine through is the modularity aspect that has been implemented both in the physical model, and in the code and IoT. There were some issues with our prototype, as expected, and the prototype will need futher work to be optimal. Our model lives up to our set goals for functionality, and additionally has an excellent form design. In the end, we believe that the prototype solves the stated issue at hand and our set goals.
