# Team zeven

gantt
    title Planning
    dateFormat  DD/MM
    axisFormat  %d/%m
    
    section WebRTC
    M1: webRTC1, 11/10, 14d
    
    section webRTC-b
    Code Review + M1: webRTC2, 28/10, 11d
    
    section QR Code
    M1: QR1, 11/10, 14d
    
    section QR-b
    Code Review + M1: 28/10, 11d
    
    section Sensors
    M1/M2: 11/10, 16d
    M3/M4 + report: 08/11, 14d
    
    section Sensors-b
    Code Review + M1: 28/10, 11d
    
    Section REST API
    M1: REST API, 11/10, 14d
    M2: REST API, 25/10, 2d
    M2 + M3: REST API, 11/11, 12d
    
    Section REST API-b
    M1 + Code Review: 28/10, 14d

## Web-RTC
* M1:
- Alles hiervan is geimplementeerd *(begin week 4)*.
- De timeout kan op ∞ gezet worden zonder dat dit problemen geeft voor het antwoorden op de lokale call van peer connection 1.
- Alle details van de RTC connectie worden beschreven in de console.

## Web-RTC-b
* 30 oktober:
* Inleiding op feature en interpreteren van voorbeeldcode

* 3-4 november:
* Analyseren van de code van pair 1 en het schrijven van de code review

* 6 november:
* Start van implementatie van M1

* 8 november:
* Afwerking implementatie M1/ begin implementatie M2

## QR code detection
* 11 Oktober:
* Oriëntatie, research, resources lezen
* 16 Oktober:
* Voorbeeldcode begrijpen, uitvoeren en debuggen
* 18/19 Oktober:
* image-info.ts output omgezet naar binary grey-scale array.
* Begonnen met finder pattern detectie algoritme en research.
* 22 Oktober
* Eerste versie finder pattern detectie algoritme + debugging
* 24 Oktober
* Verfijning finder pattern detectie algoritme
* Markering van finder patterns + image output
* Debugging
* 25 Oktober
* Debugging
* Voor pair wisseling:
* Finder patterns worden gedecteerd zetten, maar toevallige patronen van zwart wit pixels met 1:1:3:1:1 verhouding worden ook gedetecteerd (zie afbeelding)
* Dit kan opgelost worden door zowel verticaal als horizontaal te checken voor de 1:1:3:1:1 verhouding (momenteel gebeurt dit alleen horizontaal). Zie: https://www.mdpi.com/2076-3417/10/21/7814/pdf pagina 6
* Bronnenlijst:


## REST-api
* Week van 11 oktober:
- Server werkt via http en https (via hotspot, wegens beveiliging KU leuven netwerk).
Dit doormiddel van een script dat een port van de virtuele machine forward naar onze fysieke.

- Lijst van alle gebruikers opvragen met behulp van een get-request.

- Methode toegevoegd waarmee notes kunnen worden opgevraagd via een url waar een key en password worden meegegeven.

- In memory database aangemaakt in de vorm van 2 arrays (1 voor secret notes en 1 voor public notes).

* Week van 18 oktober:
- Database aangepast naar een aparte JSON file. Achteraf geen goed idee, later weer veranderd (behoorlijk wat verloren werk).

- Methode toegevoegd waarmee een nieuw key-password paar kan worden aangemaakt of waarmee een note aan een bestaand
key-password paar kan worden toegevoegd.

- Methode toegevoegd waarmee een specifieke note verwijderd wordt, gegeven key, password en note.

* Week van 25 oktober:
- Database opnieuw aangepast naar 2 arrays en alle andere code aanpassen om hiermee te kunnen werken.

- Methodes voor het toevoegen, verwijderen en toegang vragen tot publieke notes.

- Aanpassen van javascript naar typescript.

- Toevoegen van testfiles.
* Week van 8 november:
- creëren van een html pagina, waarop users gemakkelijk requests naar de server kunnen sturen.

- errors uit de testfiles halen

- requests server-end polishen

* Week van 15 november:
- Mounten van de html pagina op de correcte end-point

- andere endpoints van de server-requests aanpassen naar /REST.M2/api/v1/notes(/public)

- tests volledig afwerken

* Bronnenlijst:
- Koa: https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=&cad=rja&uact=8&ved=2ahUKEwi7lfvdzOrzAhWNqaQKHbhxDz0QFnoECAIQAQ&url=https%3A%2F%2Fkoajs.com%2F&usg=AOvVaw2MO-wbFyhk2Ew8TfzJRSrp
- REST-api: https://www.redhat.com/en/topics/api/what-is-a-rest-api
- REST-api in js tutorial: https://www.youtube.com/watch?v=pKd0Rpw7O48&list=WL&index=39
- Requests via html: https://stackabuse.com/building-a-rest-api-with-node-and-express/
- mocha: https://mochajs.org/

## Sensors
* Sensors.M1:
- Bevat een pagina met een div elements die bewogen kan worden met touch/click events of met de accelerometer.
- Bij de eerste touch/click worden permissions gevraagd om de accelerometer te gebruiken en wordt de accelerometer event listener aangezet.
- Voor het geval dat een accelerometer niet gebruikt kant worden, zijn er event listeners om de div met touch/click te kunnen verplaatsen.

* Sensors.M2:
- Bevat een pagina die accelerometer gegevens verzamelt, verwerkt op een bepaalde data-format (zoals beschreven in https://github.com/p-en-o-cw-2021-2022/course-notes/blob/main/data-format.md) en als een file download ter beschikking stelt.
- Analoog met M1, wordt de accelerometer handler aangezet met de eerste touch (hiervoor is geen click handler). Vervolgens wordt accelerometer data verzameld en bewaard in het geheugen.
- Bij het drukken van het download knopje wordt er aan de gebruiker gevraagd om de omschrijving van de test, end-point van de beweging, de hardware model van de toetsel en de OS model in te geven.
- Daarna de inhoud van de dataFile object als een json file gedownload op de toetsel.

* Scripts M3 : recover-line.ts
- Gebruikt een .json file als invoer om daaruit de end-point te berekenen door middel van integreren (toepassing van een kinematica formule).
- De input file moet in de format zijn zoals beschreven in https://github.com/p-en-o-cw-2021-2022/course-notes/blob/main/data-format.md
- De output file bevat de end point die berekend is en de relatieve afstand to end point bij elk interval van integratie.
- Neemt een input file path, output file path en alignment flags als arguments (zie "Runnen" voor voorbeelden).

* Scripts M3 : filter.ts
- Neemt dezelfde input als recover-line.ts en gebruikt dezelfde methode om de end point te bereken. Daarna wordt er een running average filter op de bekomen resultaten toegepast om ruis weg te filteren.
- De output file de coordinaten van de tussenresultaten bij elk interval van integreren.
- Neemt een input file path, output file path en window size (voor de running average filter) als arguments (zie "Runnen" voor voorbeelden).

* Scripts M4 : recover-n-compare.ts
- Neemt dezelfde input als recover-line.ts en gebruikt dezelfde methode om de end point te bereken. Daarna wordt de berekende end point met de daadwerkelijke end point vergeleken.
- De output file is een web pagina met daadwerkelijke end point, de berekende end point en de relatieve nauwkerigheid daarvan.
- Neemt een input file path, output file path als arguments (zie "Runnen" voor voorbeelden).

* Nauwekeurigheid van de accelerometer data
* Door de aard van de sensor, is rauwe accelerometer data op zichzelf niet nauwekeurig (zie https://www.youtube.com/watch?v=C7JQ7Rpwn2k). Hoewel, de accelerometer data die wij gebruiken is uit een fusion sensor gehaald(zie https://w3c.github.io/deviceorientation/#devicemotion) en is dus al een combinatie van de metingen van meerdere sensoren. De nauwkeurigheid daarvan is enorm veel beter dan de rauwe accelerometer data, en dient dus als een veel betere hulpmiddel bij het bereken van afstanden.

* Runnen:
- Certificaten zijn aangemaakt met *mkcert* in de cert1 folder:
- ```npm install -g mkcert ``` om te installeren
- ```mkcert create-ca``` om certificaten aan te maken
- Modules update met ```npm ci```
- Typescript transpilen met ```npm run tsc-web```
- Een kopie van HTML en CSS files maken met ```npm run copy-files-web```
- Node server runnen in https met ```npx http-server -S -C cert1/cert.crt -K cert1/cert.key -c-1 dist/webroot```
- Ngrok wordt gebruikt om localhost te forwarden.
- Gedownload van ngrok.com
- Authentication token toevoegen met ```ngrok authtoken [tokenHash]``` (Een Ngrok account is hiervoor nodig)
- Forwarding met ```ngrok http https://localhost:8080```
- Voor recover-line.ts zijn de mogelijke flags: none, x, y, z, xy, …, of auto. Eem voorbeeld commando: ```npx ts-node src/scripts/recover-line.ts ../shared-data/sensor-test-data/team-07/test1.json ../shared-data/sensor-test-data/team-07/outPutTest.txt x```.
- Voor de filter.ts is het derde argument de window size (een natuurlijk getal) voorbeeld commando: ```npx ts-node src/scripts/filter.ts ../shared-data/sensor-test-data/team-07/test1.json ../shared-data/sensor-test-data/team-07/outPutFilterTest.txt 20```
- recover-n-compare.ts voorbeeld commando: ```npx ts-node src/scripts/recover-n-compare.ts ../shared-data/sensor-test-data/team-07/test1.json src/scripts/results/results.html``` N.B. De input en output paths zijn relatief aan de directory waar de terminal geopend is. In de voorbeelden hierboven is de terminal open in de root directory van de repo (waar de package.json zich bevindt en is de shared-data repo op hetzelfde niveau als de team repo.).

## Sensors-b
* 31 Oktober: Code review + Code vorige pair bekijken
* 2 November: Idee voor implementatie + Begin M1
* 7 November: M1 volledig afgewerkt

## Applicatie 1(REST API + Sensoren)
**Functionaliteit:**
Ik denk dat we inderdaad net iets te hard hebben geprobeerd om letterlijk de 2 features te integreren. Eén van de proffen liet
ons ook weten dat het behoorlijk moeilijk kan worden om gelijkaardige bewegingen te vergelijken, zeker bij iets zo nauwkeurig als een wachtwoord. Vandaar dat we toch een nieuw idee bedacht hebben.

Het is gebaseerd op 'high-striker'. Dit spel komt voor op de kermis, waarbij iemand zo hard mogelijk met een hamer op een platform slaat en dan een score krijgt op basis van hoe hard ze slaan. We willen iets maken waarbij iemand een slagbeweging maakt met zijn gsm in de hand, eventueel op een fysiek kussentje of iets dergelijks. Op basis van de acceleratie data van de beweging krijgt de gebruiker dan een score (hoe harder de slag, hoe hoger de score). Op de webpagina zal dan een 'leaderboard' bijgehouden worden met de beste scores van alle gebruikers en eventueel een soort animatie van hoe het spel er in het echt uitziet, of iets dergelijks.

Dit maakt dat de beweging niet zeer nauwkeurig moet gemeten worden, aangezien we enkel de norm van de versnellingsvector nodig hebben. Het geeft ons ook meteen wat meer werk, aangezien er een volledig nieuwe REST api moet worden gemaakt en die van de notes dus niet kan worden hergebruikt. Laat zeker weten als u hier nog feedback of kritiek op heeft.

## Applicatie 2 (WebRTC + QR-scanner)

**Functionaliteit:**
Eén persoon laat een QR code zien in een p2p connectie(opgezet door webRTC), de andere beller drukt dan op een knop om deze te scannen. Op basis van de QR-code wordt ofwel een spel (bv. schaken) gestart tussen speler 1 en speler 2 dat kan worden gespeeld op de p2p connectie ofwel de site van de QR geopend.

**To do:**
* Integreren WebRTC en QR branches
* Knop maken die schermopname neemt van video
* Afbeelding doorgeven aan QR script
* Uitvoer QR script teruggeven
* Handlen van QR uitvoer (spel/site opstarten)
* Functionaliteiten spel implementeren (werking, stoppen, etc...)
* Eventuele uitbreiding naar andere functionaliteit geactiveerd door QR.

**Testen:**