WP1: Sensors

Week Progress Update Actions/Analysis
1 Initial meeting with team to outline the scope of the project Background reading and potential goals were being decided.
2 Outlined the data that needs to be measured Came to the conclusion that the most important values are nitrogen and temperature due to monsoon, drought and over ferritization.
3 Started research for sensors required Collected information on various relevant sensors including their prices, what metrics they would measure, how durable they would be use, their ease of use and more.
4 Comparison of sensor options The aims of the project’s sensor were properly defined and sensors were selected to meet the aims. Two sensor types were selected NPK and temperature/humidity sensor. The research for best price and fast delivery time for these devices has started now. Research was also done to find the additional components that would be needed. For the NPK sensor a converter module and power adapter would also need to be purchased.
5 Started hardware simulations on TinkerCad Used TinkerCad to create a hardware simulation of some sensors. The model used a temperature sensor (very similar to the temperature/humidity sensor being used) and a soil moisture sensor. The other soil relevant sensors were not available on the application for modelling.
6 Finalised research and ordered parts. Order an NPK sensor which measures the nitrogen, phosphorus and potassium levels of soil. Collected the temperature sensor and created a circuit similar to the hardware simulation to test sensor. Generated the code and put it in functions to increase readability for WP2.
7 Research on how NPK sensor data is retrieved Research on how sensors are used and where it is located in memory. Looked at different ways NPK sensors were used and the differences between NPK sensor models.
8 Research on calibration and validation testing for sensors Generated Ideas on how to test the recorded values and how to change the N,P or/and K values of an environment for the sake of measurement.
9 NPK sensor has arrived The sensor arrived on Friday. In order to use the sensor an adapter still needed to be purchased.
10 Test NPK code has been uploaded to GitHub The adapter arrived and development of code began. The NPK sensor was paired with a humidity and temperature sensor. Several different levels scripts were generated: the most recent one uses a switch to start the measurements similar to the how the RF signal would be received.
11 Developing code Debugging and optimisation of code was done. Experimented with the options of running multiple measurements and then taking averages. Performed tests to see how many tests would have to be run to get a stable average value. Also compared the run time with the quality of the average to see if the process was worth it.
12-14 Testing of Sensor Tested the sensor in various fruit e.g. oranges and bananas. To test the accuracy of the NPK sensor the sensor was placed in both fruits and try soil. Due to limitation there was no method to accurately test the nitrogen, phosphorus or potassium in the soil. Testing of DHT11 was done by adjust a room’s thermostat and using a damp cloth and kettle.

WP1: RF Communication

Week Progress Update Actions/Analysis
1 Meeting with supervisor who introduced the project Background reading on project
2 General discussion on group’s interest areas and skills All team members to consider work package ideas and areas of focus
3 Presented ideas for work packages. Idea for sensor and central hub work packages presented, with data sent via RF communication from sensors spread out across the farm to a central hub Focus on expanding ideas and presenting them in project brief and video
4 Completed project brief and video Start researching how to implement RF communication
5 Researched different options for RF communication and modules, as well as microcontrollers Continue research and complete BOM, check compatibility of all components
6 Finalised research and placed an order for the components Download software and libraries
7 Downloaded required software and libraries for RF module Wait for parts to arrive and then test and integrate
8 Parts arrived, soldered RF module and tested parts individually. Unable to make RF module send and receive data Double check all wiring and check datasheets
9 RF module still not sending or receiving data as expected Continue to look into the what might be causing the problem
10 RF module is now sending and receiving data Next step is to integrate RF communication, display and sensor readings and test, as well as to design a PCB board for the sensor and the central hub
11-14 RF communication is fully integrated into the central hub, see the central hub for continued details about use of RF. See details for WP2: Central Hub.

WP2: Central Hub

Week Progress Update Actions/Analysis
1 N/A N/A
2 Group’s interests and skills discussed. Electronic skills are available in embedded software, PCB design, sensors, and GUI design. By finding out where the skills and interests of the group were, then we could decide which areas might want to be included in the project. Experience in embedded software, electronics, PCB design meant that we had the skills to design an electronics product.
3 The initial idea for a “Central Hub”. An idea generated by Rhys, this device would solve many of the problems caused by the lack of infrastructures such as no service or phone. It would be able to send and receive sensor data and implement data processing to provide decisions to the farmer. We needed to find a way for the device to be accessible to everyone. Modern solutions require phones, internet etc. but these are not available in developing countries. Therefore the central hub would cover those missing areas and allow the system to work independently of the infrastructure.
4 Expanded the idea, started drawing out the required parts, and researched feasible components. Layout out a sketch and plan for the Central hub and worked towards finishing the video and report. The central hub needs to be small, low-power, lightweight, and cheap. Therefore a micro-controller is the only option. It needs some sort of display to show information to the user and some form of input for the user to be able to request data and perform other actions.
5 Thoroughly researched many options for microcontrollers and displays. There are many different microcontroller options. The central hub required one that is small, has low power, enough flash, and has high processing speed to be able to handle machine learning models. Most of the popular options like Arduinos aren’t suitable. The ESP32 is a far suitable option at just £8 and is very powerful as well as has WiFi capabilities.
6 Finalised research and ordered parts. For the display there are many options, the criteria are it being cheap, touch screen, and containing its only driver chips. The final choice was a £20 ILI9341, which was suitable and compatible with the ESP32 boards.
7 Downloaded libraries and wrote some test code for when the parts arrived. While waiting for parts, all the required libraries and IDE tools were set up. Some example code was prepared and ready for testing the parts when they arrive and also starting to design the GUI software for the central hub.
8 Bread-boarded the LCD and microcontroller. Fixed all the wiring and started testing the example code. Fixed example code and successfully got the LCD to Stage 1 of the electronics milestone. The design process for electronics was split into 3 sections to streamline that all contributors were working towards the same goal. The first step was ensuring that all the electronics functioned correctly. The microcontroller and LCD were breadboarded together, testing some example code and getting the touch screen working as intended. Also the first version of the GUI software was verified as well, allowing the user to see sensor data on the LCD.
9 Starting designing LCD GUI software. Displaying output reading and using the touch screen to take in commands. The GUI software was then continually improved adding more and more features. Touch screen buttons where the user can click to request data from sensors and a data processing button where the data can be processed.
10 Got LCD and RF working together. After the RF modules were working by themselves, the RF module and LCD needed to be combined onto a single microcontroller and be able to work together, which is a challenge because they require the same SPI line. By the end of the term, they were working together and when you click the request data button, the RF module sends a wireless request for data and another module will send a reply.
11 Figured out how to implement MATLAB generated machine learning code onto the microcontroller. Fixed problems with the RF modules. Re-wrote some example generated MATLAB code, and uploaded it to the microcontroller in order to perform machine learning in real time. Fixed some issues with the RF modules not working as intended. Updated the transmitter and receiver code, to allow the central hub to communicate with one sensor indiviually.
12 Added the functionality for the central hub to work with multiple sensors. The central hub can connect with a sensor by emitting a search signal and a button being held on the sensor that wants to be connected. Created software for the hub and sensor to send sensor data when requested. Tested WiFi code to enable gathering weather and time data on the microcontroller. Created software for the central hub to be able to search for sensors, and if not already connected, a button can be held down on the sensor that will allow it to be connected. Once connected the central hub now knows it unique ID and can request data from that sensor individually. Significantly improved the GUI software to allow for complete control.
13-14 Continued developing software functionality for the central hub, adding more features such as more detailed GUI application details. The GUI now is more robust, it allows for all the sensor data to be shown individually, stating which sensors where successfully communicated with, using colour desciption to represent updated/out of date data.

WP3: Machine Learning

Week Progress Update Analysis and Actions
1 Discussed the scope of the project and the ideas for a smart agricultural system. Gathered ideas of machine learning work packages such as computer vision, neural networks and image classification. Research more into different machine learning models that are used for agricultural applications. Gather ideas for the next meeting. This first week was to understand the aims and objectives of the project.
2 Focused on the group project topic of a low-cost smart agricultural sensing system for small holder farms in India, therefore, the research was tailored to this application. Computer vision is higher cost, so machine learning models used for data classification were researched. Understand how different machine learning models can be used for data classification. This week achieved a milestone of setting the project objectives and work packages, where the third work package focuses on machine learning.
3 Focused on producing the first project submission - project brief and video, therefore no separate work was done for this work package. We wrote up the project brief and brainstormed ideas for the marketing video. This week the project aims and objectives were finalised, and aims for the work packages were set. This means that the entire team was informed of the project scope and the requirements needed for a successful project.
4 Expanded on machine learning model ideas and brainstormed the types of decisions it could make, for example, predicting crop yields. These ideas were elaborated on in the project brief and we finalised that machine learning will be used in the GUI with the Central Hub of our system.
5 Started identifying the types of machine learning models that can be trained for our dataset, for example an artificial neural network (ANNs), regression model or decision tree algorithm. Research was done by looking at similar applications in research papers, most used ANNs and decision trees, therefore, these models were looked into more.
6 Tested different machine learning models on a trial dataset that specified temperature, rainfall and nitrogen values in the soil. Started researching how to create generated C code. A trail dataset was made in Excel to test the machine learning models in MATLAB. ANNs and decision trees had the highest accuracies, which verifies the research we completed.
7 Identified the machine learning model that would be accurate but required the least processing power which was a decision tree model. This was tested on the trial dataset and tried to generate C code for this. The decision tree model produced promising results and when tested, it gave an accurate prediction of a ‘good’ or ‘bad’ crop yield based on new data. Converting this code to C was researched.
8 Successfully generated C code for the trial dataset and considered using Bagged Decision Tree models. Bagged decision trees were suggested by a member of the group, so more research was done to check if there was a higher accuracy, but there was little difference between the two. Therefore, we stuck to a decision tree model, where the C code was generated using the MATLAB Coder app.
9 Successfully uploaded the trial generated C code onto the microcontroller. The generated code was uploaded to the microcontroller successfully after a few problems with the files, but the code managed to upload when exported as a package instead of individual files. This shows that on the final training dataset, the decision tree algorithm should work.
10 Generated ideas and validated data for our final training dataset, and discussed the outputs of this model. We then discussed that two training datasets will be made, one to advise on soil health/fertiliser amounts and one to advise on irrigation of crops. This will then be combined in a sentence to output a decision for the farmer.
11-14 Conducted further research into specific threshold values to use in the training dataset. Found optimum values for temperature, humidity and NPK for rice crop growth, and these values will be implemented into the creation of the training dataset for the decision tree algorithm.