Sprint 2 Challenges - rokanas/terminarium GitHub Wiki

Web application

The primary concern at the start of Sprint 2 [internal] was: how would the team be able to create a website for the project - without any significant prior knowledge. In essence, this resulted in the Sprint being divided into two distinct phases, comprised of:

1. Learning the Required Concepts

After having split into two sub-teams, the Front-End group started by discussing and defining what steps were necessary in order to be able to execute the process of developing the Terminarium website application. It was quickly realised, that to sufficiently familiarise themselves with the required concepts, they would have to use the first half of the two-week Sprint to setup a plan for a crash-course in web-development, which included:

as part of the Front-End-dev-roadmap. This document was used to keep track of and communicate the sub-group's plans and any changes made to them - both internally, as well as with the rest of the team's members.

The main challenge during this first learning period was the amount of information that the team had to process and understand, especially with the knowledge that any delays would result in less time dedicated to the actual development - whilst already being pressed for time from the beginning of the sprint.

2. Putting the Knowledge Into Practice

Coming into the second phase of Sprint 2, the team was well-prepared, albeit a little behind schedule - due to the vast amount of learning necessary in the previous phase - but work picked up swiftly once the team got started. The rigorous planning in how to approach the website's design, which meant breaking the website up into stand-alone components (SFC's), proved effective.

However, the process was not without obstacles:

  • CSS proved to be a difficult concept to grasp; being a very feature-rich language with the drawback of having a steep learning-curve due to its complexity. Understanding the cascading nature was made even more confusing due to styling being applied within the individual Vue-component files as well as in a separate style-sheet, which was part of the initial Vue-project setup and interfered with the styling of new components that were being created - until it was deleted. Creating responsive designs that adapt to the screen they are being displayed on was also very challenging for beginners.

  • Certain aspects of the Vue framework proved difficult to implement, namely, external props. These are properties of a (child) Vue-component, that needs to be provided by its parent-component in order for it to function as intended. Debugging syntax-related errors between two different components when working with a new framework, and only half-a-week/one-week's worth of experience was hard, but eventually manageable.

  • Time - again, this was the main challenge during Sprint 2: creating a website using a new framework can be difficult; creating a website for the first time can be even more difficult; creating a website for the first time, in under two weeks, is very difficult. Although the website was not fully functional by the end of the Sprint, the team had made good progress and were very proud of their results. With the vertical slicing approach most of the necessary components had been created and the team had an MVP for the Sprint 2 demo & presentation.

Wio Terminal

Sprint 2 [internal] provided numerous challenges, primarily stemming from the technical limitations of the Wio Terminal together with the use of external libraries. Together, these factors did not limit our potential to implement our desired features, but did severely impact the complexity of the task.

Program responsiveness - overall & especially of the vibration sensor

Use of the delay() function to control the loop was causing the program overall to be less responsive. Due to the nature of the vibration sensor readings, using delay() was causing many vibration inputs not to be registered. While it didn't impact the rest of the sensors as drastically, it left the vibration sensor (which needed to show whether it is vibrating second-by-second) virtually useless. The first step to fixing this was replacing the uses of delay() with a custom function that would allow the program to run, but would track elapsed milliseconds and restrict certain functions (like printing and publishing sensor data) to running only after a defined interval. Thus, the vibration inputs are now being read at an extremely fast rate, but are only processed at a manageable interval.

However, this didn't fully fix the problem, due to:

Temperature & Humidity sensor library

The official Seeed temp&humi sensor library, used for parsing the sensor data into readable celcius and relative humidity readings, was also causing delays in the program that were severely affecting the responsiveness of the vibration sensor readings. After peering into the library files, we discovered that the library made frequent use of delay() functions. Rather than tinkering with it ourselves, we found a different external library (DHT Non Blocking) that offered precisely the solution--the same temp&humi sensor data parsing without the use of program-stopping delays. Using this, we finally improved the responsiveness of the program and made it lightning fast.

Hardware memory issues: WiFi library & screen buffer

Prior to the addition of the MQTT connectivity feature to the Wio Terminal, the way we drew to the LCD screen was using a screen buffer, a practical and fast implementation. However, it was soon discovered that the simultaneous use of the screen buffer with the use of the rpcWiFi library to establish wifi connection was impossible due to both taking up an enormous part of the Wio Terminal's available memory. After much research, we could not find an alternative wifi library that was both functional and also more memory efficient. Obviously, MQTT was a non-negotiable feature, so compromise had to be struck with the LCD screen display. We were forced to draw our UI features into the Wio Terminal's screen RAM directly, without the use of a buffer. While this worked, it created a new set of challenges:

Drawing directly to the Wio Terminal screen

Having to draw directly on the LCD screen instead of using a buffer posed an enormous complication when displaying a dynamic UI. This is because unless you clear the entire screen by overwriting, new elements will just be drawn on top of existing ones. Overwriting in turn would lead to a very noticeable screen flicker/stutter.

The solution to the flicker was to write code logic that would overwrite only the specific sections of the UI that had elements that would update (like sensor readings). This, however, brought its own set of problems, including instances where elements should update but didn't.

The general difficulty of dealing with this method of drawing continued to complicate every aspect of every other feature designed for the LCD screen, so much so that the code eventually became inelegant and hard to read. While functionality is now perfect (through many hardships), the code is difficult to understand and for now there is no time but to move on to other more pressing project issues.