Future...

Recent developments in computer vision and artificial intelligence have made it possible to achieve classifications of complex patterns in images. These developments have made the successful implementation of this solution architecture achievable. My implementation does not represent a production-ready product as it is a PoC. However, it does prove that a product resulting from this solution is achievable. With this implementation it is safe to say that all technical requirements have been satisfied to an acceptable degree for this thesis.

Future

To achieve a production ready product a few improvements must be implemented.

1.   Legal Compliance in general and specifically with regards to privacy/integrity (GDPR) and       Data Storage laws must be researched and implemented.

2.  A feature must be implemented in the AI implementation that allows for live training to support continuous improvement of the AI. This live training will lead to ever increasing accuracy.

3.     The number of supported plants must be increased to be viable for more users.

4.  Automatic identification of plant type can be implemented; this functionality is already available in many Apple App Store and Google Play Store apps.

5.  The external python server can be containerized and deployed in different regions for low latency. Load balancing can then be applied to stabilize usage surges. Lastly and most importantly, accurate remedying advice must be provided from a reliable source as this is outside the scope of this thesis.

If these requirements are met, then this implementation could be considered ready for public use. After deployment many more expansions and improvements can be made to increase the user-base even further. Supporting additional interaction platforms like web, iOS, Mac, and Windows will surely enable this increase. The increasing trend of urbanization, urban farming and vertical farming will also have a positive influence in the need for this type of solution.

Due to the loosely coupled diagnosis engine implementation, it is also possible to treat it as a microservice. If a licensing system is implemented it is possible to license the use of this engine to third parties.

Multi-purpose Architecture

A diversification can also be made in Use-case as the solution architecture is made to not only support plant disease classification, but any kind of functional classification. It does this in a scalable and flexible way. A few minor modifications must be made to make this switch possible in the current implementation. However, this can be avoided by increasingly generalizing this implementation. The following steps must be taken to switch the use-case of this architecture:

 Step 1: AI

First a new AI model must be trained. Therefore, new data needs to be collected or retrieved in order to train the model for a new goal. When this is done, 20% of the collected data needs to be reserved for validation. Before training can start, an application needs to be created using TensorFlow, Pytorch or other equivalent AI frameworks. In this application the data must first be imported, the number of classifiers, the training length and hyper parameters must be set. Finally, the data must be prepped for training. When a sufficiently precise accuracy is reached, the trained model is exported as “.pt” file and imported in the diagnosis engine. If an existing service like plant disease recognition is already present in this engine, the engine is easily modified to make a distinction between the type of requests. This allows it to send requests to the relevant AI implementation for processing.

Step 2: Database

Next, the necessary related data must be added to the database. For example, in this implementation this included all the distinct problem information related to supported classifications. In the case of animal recognition, it would be animal information.

Furthermore, if the data format for analysis requests is not generalized or generalizable over all implementations, then for SQL the database schema would need to be updated. This is because a new type of request format must be added to its database schema. For NoSQL this is not required, as it has a dynamic database schema.

Step 3: Interaction platform

Lastly a new or generalized interaction platform must be created/used based on the use-case. In this implementation this represents the “PlantCare” app. This app is case specific and cannot be used for other use-cases. Thus, a new use-case requires a new platform. However, it is possible to create a generalized platform that can display all kinds of data and support multiple request and/or classification types.

Resulting impact

A conclusion cannot be made on the impact of this implementation on the case described in the introduction of this thesis, as it has not yet released for public use. Thus, the impact of the implementation cannot be researched. Neither is it possible to conclude if this solution would truly help most people to care for their indoor and/or outdoor plants. To make such conclusions, the app must be tested extensively, and the user experience must be researched over an acceptable period.