Evaluation (Assessment Criteria)

1. Assessment of the responsiveness of the application in the context of the task / environment.

Whilst the responsiveness of the system in its practical application will be much slower due to the duration of sunrise and sunset, our system's responsiveness was tested in an environment with a dimmer switch. The system responded accurately and quickly in relation to the rise and falling of the ambient light controlled by the dimmer switch. A demonstration of this can be witnessed in our final demonstration video on the home page of our GitHub.

2. Overall latency permitted between physical event and output (control output or display of data).

No visual latency is witnessed between decrease in ambient light and increase in LED array brightness. The only latency experienced in the system is in the communication between the application and server if the WiFi connection to the RPi3 is poor.

3. What is the sampling rate?

For demonstration purposes, the default sampling rate of the RPi3 was implemented alongside added wait functions. This resulted in a sampling rate of around 10kHz, which allowed the system to adequately show its capabilities. In normal circumstances a slower sampling rate would also be suitable.

4. What bus protocol should be used (I2C, SPI, ...) and why?

The I2C bus protocol is utilised to communicate with the OPT3001 ambient light sensor. This was due to the ADC on the ambient light sensor requiring I2C communication as detailed in the data sheet.

This was a similar case to the Max7219 LED driver, which required the SPI bus protocol for communication. The SPI specifications were provided from the data sheet.

5. How many channels?

Two input channels are required. One for the ambient light sensor data stream and another for android application listening.

One output channel is then required to send instructions to the Max7219 driver chip.

6. Low level implementation: kernel or userspace and why?

Only userspace low level implementation was required. No adjustments to the RPi3's kernel were necessary.

7. Data flow from hardware to GUI to output with data formats, latencies, processing and conversions.

A detailed illustration can be found in our data flow diagram. The TCP connection allows a string of information to be sent from the mobile application to the server on the RaspberryPi. This is then analysed based on the index of the string to decrypt what event message was sent.

The sensor values are received in the range of 0 - 65545 which is then converted to lux using the formula stated in the data sheet. The OPT3001 can measure from 0.01 lux to 83k lux.

8. Buffering of data: how many samples?

No buffering of data is implemented in this project. Ambient light data is processed sample by sample due to high signal to noise ratio from sensor.

9. How does the buffering impact on the realtime performance and how much latency is introduced?

No data buffering is implemented in this project.

10. Postprocessing of data and how that introduces latencies / processor load?

No postprocessing required as the light sensor has an appropriate signal-to-noise ratio. This doesn't impact the PID control.

11. How many threads are needed and/or how can the load be distributed to allow a responsive application?

The GroPro requires the use of two threads, one for sensor data acquisition, PID control and light intensity control and the second for server connection and port listening. There is also shared parameters across threads which have been secured using thread-safe techniques when writing to memory as seen from our code.

12. How to implement the GUI? Permitted refresh rate and latency resulted from it.

The GUI was created using QT Creator and built for an Android application using the Android SDK and JDK. The application is launched from the Android/IOS device. An APK can be downloaded from this Git repo and easily installed on an Android device. The standard refresh rate of the GUI is 24-60FPS set by the Android/IOS device.

13. Structure of the software in classes, associated unit tests to turn it into reliable software

The key elements of the software's functionality have been encapsulated into classes for ease in implementation in source code. A class UML diagram can be found in the software section of our wiki page. Each class can be found in the software folder as:

• OPT Class
• Max7221Driver Class
• GroProServer Class
• PIDControl Class
• Pwm Class

Unit tests were implemented for each class to ensure correct functionality. The tests can be found in the directory for each class.

14. Team structure: which roles in a team of 3 and how equal contributions are guaranteed?

• Andrew Fyfe - Software development, mobile application development, networking.
• Alasdair Robertson - Software development, sensor data acquisition, PID control.
• Oliver Warner - Circuit design, PCB design, assembly and hardware testing.

15. How much time is allocated to hard, software and debugging and how is this interleaved?

Software was conceptualised whilst hardware test boards were in development. Most of conceptualisation and planning took place in January. Software algorithms and hardware interfacing were worked on once test boards were completed in February. The Mobile application was developed in parallel with other tasks and tested on a Samsung S7 edge and RaspberryPi connected to local network. Final boards were completed a month before due date to allow the remaining time to debug and bring together individual software elements to produce the final working system. The project was complete by the beginning of April 2018.

16. Which version control software is used? How are releases / milestones done and numbered?

Git was used to control versions and commit changes to the online repository. Releases were constrained to the "Master" branch with other developments contained on the development branch. When developments were completed they were merged to the Master branch. Informative comments were also given for each commit to explain the changes.

17. What is the release strategy / publication / publicity? How is that measured and deemed to be successful?

Social media platforms (Twitter, Instagram and Youtube) were used to provide updates and information on the product development whilst showing the personalities behind the project and providing engaging content to appeal to our audience. This can be deemed successful due to the number of likes on social media posts and the number of followers on our pages.

A YouTube video was then created and published after project completion, showing full demonstration of the GroPro's functionality.

18. Measurement of success of the application in the context of the problem given and evaluation of it.

The application is evaluated on the ability to adjust its brightness to changes in ambient light. This is shown in the video demonstration, with the GroPro appropriately dimming when light levels increase, and brightening when light levels decrease. This sustains a consistent overall light intensity for the plant. The mobile application directly adjusts brightness levels and colour temperature to the user's preference and responds efficiently when a good quality internet connection is established.