Final Work: PlantCare

In this blogpost I will cover the different tools I have used during the development process of this project. General The tool below is used in all implementations. Github This free hosting website was used for version control. It uses the git open-source VCS (Version Controll System) enabling a combination of both local and centralized version control. This allows for easy and efficient management of progress in development. AIDE Implementation AIDE or the AI Diagnosis Engine includes the pre-trained AI model. This model allows the diagnosis engine from the previous section to calculate the disease prediction rankings. It also handles the image pre-processing of incoming requests. The following components are involved in this process. Anaconda Distribution This tool is a python package manager and provides the ability to easily manage, test and deploy development environments. Pycharm This IDE made by the software company JetBrains, is used for Python...

To start with the AI implementation of this project, I researched some similar exisiting projects until I found an open-source project on GitHub  from Marko Arsenovic, that was comparing different results achieved by AI models using a plant disease dataset. This was an ideal starting point for my own project. A chart was also provided to clarify the results achieved by his project. I noticied that AlexNet achieved good results while not taking a lot of time to train as you can see in the chart below provided by Marko Arsenovic. This project used an open-source dataset provided by the R&D unit of Penn State University called PlantVillage, to train the neural networks in plant disease identification. This dataset includes 38 classifications each represented by more than 1000 pictures and spread over 14 plant types. In order to verify that our AI model is performing correctly it is important to keep some data for validation. Thus, 80% of plant disease images was used fo...

Starting from this blog on I will switch to English as this makes my writing process much more efficiënt. In this blogpost I will describe one of the most import components of my project, the AI Diagnosis Engine. In the previous post, I wrote a short paragraph about the high level functionality this major component offers and what factor it depends on. Today I will talk about all the sub-components and relations/interactions between them.  Plant Deficiëntie Dataset The first sub-component of AIDE that I will cover is also the most critical part. The PDD (Plant deficiency dataset) is a dataset with labelled images representing different disease-plant combinations. The quality of the PDD is heavily reliant on the quality and quantity of labelled pictures it contains. This dataset is eventually used to train the AI model that will be used in the following sub-component to process analysis requests from the end-user. Actor Model This sub-component represents the e...

In het vorige deel heb ik de actoren overlopen van de oplossingsarchitectuur van mijn project en kort getoetst op het systeem. In dit deel ga ik alle onderdelen van het systeem kort overlopen en ga ik in een andere blogpost een aantal onderdelen verder uitdiepen. Ik voeg uit gemak ook het schema toe dat ik in de vorige blogpost heb getoond zodat de overzicht behouden wordt.  Figuur 1: De Oplossingsarchitectuur Knowledge Base De eerste functionele component van het systeem dat ik overloop is de "Knowledge Base". Dit component is in principe een woordenboek dat alle plant ziektes bevat dat het systeem ondersteunt, en hun remediërings advies. Dit woordenboek wordt gebruikt om het systeem te voorzien van relevante data, zodat het systeem deze data op zijn beurt kan presenteren aan de eind gebruiker in het geval dat de gebruiker die specifieke informatie nodig heeft. Ook word dit woordenboek samengesteld door betrouwbare kennis bronnen, (zie blogpost deel 1) Dit functione...

We zijn weer al een eindje verder in de ontwikkeling van mijn thesis. Om nog een overzicht te krijgen van de werking van het huidige systeem en wat er in de laatste maanden is behaald, wil ik dit in deze blogpost even overlopen. Om het probleem op te lossen dat ik in eerdere blogposts heb aangekaart en het doel van mijn thesis is, ben ik begonnen met het visualiseren van een architectuur die de functionaliteit kan voorzien, de "solution architecture". Dit visueel model dient als gids in de ontwikkeling en research proces voor mijn thesis. Deze werd meerdere keren aangepast wanneer er een fout was ontdekt in het model of een meer efficiënte oplossing werd gevonden. Figuur 1:  Solution Architecture Zoals je in de afbeelding hierboven kan zien, bestaat de solution architecture uit 2 hoofd onderdelen. Namelijk, de "actors" en het "systeem". Hierdonder zal deze 2 onderdelen verder toelichten. Actors De actors zijn externe entiteiten die c...

Before going into the specific solution implementations, the domain objects involved and how they interact were visualized in a domain model. These domain objects are the necessary elements involved in tackling the problem. They consist of users, plants, plant types, diseases, logs, classifications. Figure 14 below shows the visualization of these elements and the interactions between them as a domain model. However, this model was altered throughout the project and does not represent the final version. 7 Figure 12 : Sketch of problem domain model Domain Model It is the base for the data structure and design of the implementation. Since this model has such an important role, it is necessary to think this model through. Making a change in this step of software development can cost a lot of time as the whole system is built on top of it. This means that most of the time a redesign of this model influences many function...

Voor het starten met de ontwikkeling van de PlantCare App ben ik begonnen met het schetsen van 2 belangrijke initiële schema's het schema hierboven duid de originele simpele versie van het schermen diagram en de mogelijke flows van de gebruiker hierdoor. Er ontbreken hier nog een aantal pijlen namelijk hoe de gebruiker kan terug gaan van een huidig scherm en zijn er een aantal schermen/sub-schermen bijgekomen. Maar dit schema heeft als gids gediend voor dit project bij het ontwikkelen en het bedenken van verdere stappen in de ontwikkeling. Het schema hieronder wordt ook wel een domein model genoemd. Deze dient om een beeld te krijgen van de soorten informatie dat voor dit product een rol speelt en de relaties hiertussen. Het schema hieronder is opzettelijk niet te specifiek omdat dit erg afhangt van de implementatie en wat er mogelijk is met de technologie. Aangezien ik veel met nieuwe technologie en platformen werk was het beter om dit zo te laten tot een latere fase van ...