Lessons Learned
Deviations from the plan
Change in User’s Position Algorithm
Major deviations from the original design plans were witnessed due to the non-conformance of the trilateration algorithm. A brief of the trilateration algorithm and its required testing is shown below. The primary aim of the trilateration algorithm was to locate the user’s position based on the RSS from multiple Wifi-receivers. However due to the nature of heuristics involved the algorithm continuously diverged except for few test cases. The reason for the divergence was attributed to the nature of approximations needed for the inputs to the algorithm. Due to an inaccurate input model of reality (i.e. approximations of the RSS values, and the planimetric locations of the routers) the algorithm could not converge to a closed solution. Significant efforts and consultations were made in order to rectify the issue, however after consulting with an expert in the field (A professor in the ESSE faculty at Lassonde School of Engineering) it was decided that due to the probabilistic nature of the input variable (RSSI) to the algorithm a convergent solution was unlikely.
A new approach based on gridding the RSSI signature was adapted. This approach, known a finger printing, required preliminary Wifi RSSI data at regular grids mapped onto the desired floorplan. The gridded RSSI data was then stored in the database of the phone, and the live RSSI feed was then matched with the closest candidate in the database. The location of the user was then determined by accessing the 2D local coordinates of the respective RSSI grid to which live RSSI feed was the closest match.
Fingerprinting Interface
Source: [1] Chen, Lina. "An Improved Algorithm to Generate a Wi-Fi Fingerprint Database for Indoor Positioning." MPDI. Sensors, 21 Aug. 2013. Web. 5 Apr. 2017.
Change of Site
The initial design of the project was based in the Bergeron Centre of Excellence. An imperative part of the project was the building floorplan designs that accurately outlined the Wifi router positions. However due to the unavailability of the building floor plans the group had to switch sites to the Peatrie Science building, where the floor plans were easily accessible. Due to this the scope of the project had to be changed and slight alterations had to be made to the algorithm in order for it to properly function in the new environment.
Change in Voice Recognition
One of the components of the indoor navigation system was the Voice recognition system. However due to time constraints this particular feature could not be realized within the design of the application. However, the team is continuing efforts to achieve a functional Voice Recognition system that will aid the application and make it more accessible for the visually impaired community. At the present, different open source software packages are being examined, however the primary issue is in integrating them with the rest of the custom designed application. Although the Voice recognition system is not an integral component in overall functionality of the application, it yields a useful extension that makes it usable for a more universal audience, including the visually impaired. Hence the group is determined to integrate a Voice recognition system with the application before the demonstration at the open house.
Non-Conformance: Trilateration Algorithm
The testing of the trilateration algorithm was required to satisfy a functional algorithm with an initial planimetric accuracy of 5 meters. Furthermore, different geometric configuration of the trilateration network, due to the varying locations of the user with respect to the Wi-Fi routers, needed to be tested. The algorithm relied on a non-linear parametric least squares solution, which required initial approximations of the user’s positon (an estimate of the 2D planimetric coordinates of the current position of the use). Depending on the accuracy of initial approximations the algorithm had a very high tendency to diverge; hence testing with regards to the convergence of the Least squares algorithm in different trilateration configuration and with different accuracy levels of the initial approximations of the user’s planimetric position also needed to be performed. However, this could not be achieved due to the probabilistic nature of the inputs to the algorithm. The table below highlights the required tests and minimum threshold results that had to be met in order to realize a functional algorithm.
The testing requirements listed above were derived from the defined functionality of the application in the requirements table. Some of the appropriate requirements with regards to this particular subsystem have been reiterated below.
-
REQ-S-PERF-0020-1: App shall track the users position using Wi-Fi
-
Verifying that the app identifies the user position within the building with certain accuracy requirements.
-
-
REQ-S-PERF-0030: App shall be able to navigate the user to the desired location using Wi-Fi
-
Checking if the app can locate user’s position in real time in different locations within the building.
-
The initial test case (Test LS_1) was the primary criteria in the initial quality assurance of the algorithm. Functional testing was required particularly for test case LS_1. LS_1 test case employed a small subset of the input parameters to determine the correctness of the algorithm. The general conformity of LS algorithm was determined through the convergence of the LS solution under ideal conditions:
-
Initial approximations that are the exact location of the user.
-
Ideal trilateration network, where all the formed triangles are nearly equilateral.
This test was imperative for determining the correctness of the algorithm before proceeding to testing with specific test cases (i.e. LS2 and LS_3). However due to the probabilistic nature of the input arguments, the test failed. The table below captures the state of the algorithm over different iterations.
Lessons Learned
Several lessons were learned in developing this project. Since the nature of this project was research based, very little literature was available. Due to this the team had to innovate, at times, to come up with a solution. Although the team did come up with a theoretically functional algorithm (Trilateration Algorithm), more time was required to mature the algorithm. The designed algorithm was very probabilistic in nature and due to this had a high tendency to diverge. However the team did not realize this at a much later stage when actual testing was performed. This particular issue could have possibly been avoided if before coding the algorithm multiple variants of the pseudocode were designed as discrepancies might come to light from one of the variants. Additionally it was also agreed upon that since the project was heavily research based, a supervisor with knowledge in the respective field, would have provided the necessary insight to project us in the right direction.
One of the key reasons why the potential non-conformance of the Trilateration algorithm was not realized sooner was because of the delayed testing. The algorithm could have undergone Test_LS1 without having real life input variables. That is the team could have designed a pseudo testing environment to test the algorithm and hence become aware of its probabilistic nature at an earlier stage. This was one of the key issues that prevented an earlier detection of the Trilateration algorithm failure.
Another key issues that was faced was due to the multiple programming environments that were being used. Since the application was based on the Android Studio platform, it was coded in Java. However due to the run-time efficient concerns the Trilateration algorithm had to be designed in C++. Since the two environments were different the group had to design a server that would run the trilateration algorithm and take inputs from the cellular device. Although a functional design, unnecessary redundancies were introduced by just having the trilateration algorithm run in a different environment for, what now seems, insignificant run time improvements. Hence, it was learned, that some compromises are worth making because in the real world not all variables can be optimized.