Den magiska spegeln som personanpassar innehållet. Tekniken i spegeln

Transkript

1 Den magiska spegeln som personanpassar innehållet Novatrox konsult Joakim Olsson arbetar som Lead developer och Lösningsarkitekt och för tillfället är han på uppdrag på SEB. Han har ett stort intresse för AI och IoT och har vid sidan av uppdraget skapat en spegel som klarar av att personanpassa innehållet som visas på skärmen, dvs vem som faktiskt står framför den styr det som visas på skärmen. Spegeln består av en glasskiva i 3mm med spegelfilm från baksidan. Spegelfilmen släpper igenom ljus om ljuset bakom är 15% ljusare än det som är framför. Bakom spegelfilmen sitter en svart vinyl för att säkerställa att det verkligen inte lyser igenom något, så att man inte ska kunna se konstruktionen. I vinylen är det utskuret för en webbkamera samt en skärm i stående format. Ramen är byggd så att spegeldelen är infräst i ramen och i ramen/spegeln sitter sedan all teknik. Tekniken i spegeln Spegeln innehåller en Raspberry 3 model B, Microsoft LifeCam HD-3000 webbkamera, 24 Dell skärm samt ett Luxorpart relä. Inne i spegeln sitter det en kopplingsdosa för elen med fast installation av elkabel, Raspberryn är kopplad med USB mot en 2.4A laddare som sitter direktkopplad mot kopplingsdosan. Skärmens nolla sitter kopplad direkt in i kopplingsdosan och fasen går mot reläet som slås på/av via att någon faktiskt står framför spegeln. Raspberryn har Windows 10 IOT som operativssytem och i den ligger en UWP programvara speciellt skriven för spegeln. I denna programvara ligger kod för att hantera rörelsedetektion, kontroll om det finns ett ansikte i bild (inte igenkänning på vem det är), slå på/av reläet samt kommunikation mot ett API i molnet (Azure). 1

2 Skärmen är kopplad mot reläet på NC, vilket betyder att om ingen Low signal finns mot reläet från Raspberryn så är strömmen till skärmen normalt avstängd. Anledningen till detta är dels för att spara ström/värme som skärmen genererar men även för att spegeln bara ska se ut som en spegel om ingen faktiskt står framför. Procedur / process När det rör sig framför spegeln försöker den, via webbkameran, avgöra om det är ett ansikte i bild, och om det är det så slås reläet på vilket leder till att skärmen startas. En bild tas från webbkameran, konverteras till en byte array och skickas till en tjänst från Microsoft som heter Cognitive Services och som finns i deras Azure tjänst. Det som tjänsten returnerar är en identifierare i form av en Guid. Tjänsten vet inte vem personen är, men om samma person ställer sig framför igen, så får den personen oftast samma identifierare tack vare att beräkningen/identifieringen är matematisk. De gånger tjänsten returnerar olika identifierare beror till största del på belysningen i rummet och ljussättningen i ansiktet samt om man står snett mot kameran. Identitiferaren från tjänsten skickas sedan till ett rest api som hostas i Azure, som har koppling mot en SQL databas (också i Azure) som innehåller en lista på alla personer som någon gång stått framför spegeln. Listan innehåller både oidentifierade och identifierade personer. När anropet görs från spegeln mot tjänsten och personen inte finns med i databasen så skapas automatiskt ett nytt entry i databasen med identifieraren och den faktiska bilden som togs. Därefter skickar tjänsten ut en signal via SignalR (websockets) till alla som lyssnar. Dessutom skickas ett meddelande in i en ServiceBus kö, även denna i Azure. I Azure finns sedan en Logic App skriven som lyssnar på ServiceBus kön och plockar ut meddelandet direkt när det kommer och skickar iväg ett mail till utvald mottagare med att det står en ny person framför spegeln som aldrig tidigare stått där förut och man vet då att denna person behöver identifieras. Tjänsten returnerar sedan tillbaka till spegeln antingen att personen är identifierad och isåfall vem det är, alternativt att personen inte känns igen. Spegeln visar därefter namnet på personen i spegeln eller att den tyvärr inte känner igen personen. För att identifiera personer som är oidentifierade så kan man antingen välja att använda en UWP applikation skriven för Windows Phone alternativt en websida skriven i Angular. I båda dessa applikationer så kan man välja att lista alla oidentifierade personer och då få upp en bild, den som togs av spegeln vid identifieringstillfället, för att avgöra vem det är. När man känner igen vem det är så kan man lägga in Förnamn, Efternamn, Mailadress samt en Biografi som sedan skickas tillbaka till tjänsten och lagras i databasen. När en person identifieras i 2

3 applikationerna, så plockas bilden som togs vid första identifieringstillfället bort, för att inte ligga och ta utrymme i databasen samt öka prestanda. Programvaror och teknikval UWP för IOT, Hololens samt Windows Phone. För Raspberryn, Hololens samt Windows Phone så är det en gemensamt skriven applikation framtagen. Denna applikation är kodad i C# med anpassningar för respektive platforms möjligheter. Applikationen är, vid tillfället, kodad i den senaste versionen av UWP och.net Standard 2.0. Valet på.net Standard 2.0 används för att skapa gemensamma bibliotek som kan användas av potentiellt flera applikationer som delar kod. MVVM tänket används att hantera modeller, vymodeller och vyer. Styrkorna som används i MVVM i denna applikation är att använda samma vymodell för olika vyer baserat på vilken platform applikationen används på. Applikationen är skriven med stöd att använda repektive platforms tekniska möjligheter och begränsningar. Så för till exempel spegeln så används endast komponenten för se personer, medan telefonversionen har möjligheter dels att se men även lista identifierade och oidentifierade personer och hantera oidentifierade person, dvs lägga in namn, mail och biografi. I spegeln finns inte möjlighet till tangentbord eller mus, så här föll valet att identifiera personer bort. Därför används spegeln endast till att ta bild samt att visa information anpassad för personen som står framför. Hololens applikationen har möjligheten att se personer samt skriva ut namnet och biografin. Hololens applikationen har även inbyggd head tracking för att kunna visa namnet på personen i direkt relation till vart ansiktet faktiskt befinner sig i bilden. Så när personen rör sig i bild så följer namnet efter. API Grundplattan i hela systemet baseras på en.net Core 2.0 tjänst som hostas i Azure. De allra senaste teknikvalen är gjorda för api:et med både EF Core 2.0, SignalR Core (Alpha version) samt gemensamma bilbiotek skrivna för.net Standard 2.0. Strukturen för API:et består av sex olika lager. 1. API 2. Businesslogik 3. Modeller 4. Repository 5. SignalR 6. ServiceBus/integration Alla lager av API:et behöver inte användas för att systemet ska fungera. Så SignalR och ServiceBus lagret är konfigurerbart i appsettingsfilen om de ska användas eller ej. 3

4 Angular Angular applikationen är skriven med hjälp av Angular CLI och, vid tillfället, används den senaste versionen 5.0 för att generera applikationen, transpilera samt publicera färdig applikation till js filer. Angular applikationen är likt API:et uppdelat i olika lager, där modeller framförallt är fördelade i ett eget bibliotek för att plockas in via npm. Angular applikationen är väldigt lik Windows Phone applikationen, och används just nu endast för att identifiera oidentifiera person och lägga till namn, mail samt biografi. Valet att skriva en Angular applikation föll för att inte vara beroende av Windows Phone platformen för att identifiera personer. Denna applikation är platformsoberoende och kan kommas åt via en telefon, platta eller något annat som kan koppla upp sig mot nätet via en webbläsare. Databas Hela databasen för systemet ligger i ett eget databasprojekt i Visual Studio, och all förändring av databasen görs i detta projekt för att kunna hålla spårbarheten på förändringar som görs/gjorts. Projektet kan publiceras direkt från Visual Studio för att snabbt få upp en ny instans av databasen för att testa. Dessutom kan en dacpac fil genereras som kan användas för att jämföras mot en befintligt instans och utföra uppdateringar. Databasen för detta projekt ligger som en instans i Azure, som en Microsoft Azure Sql Database V12. Databasprojektet har både pre och postdeployment script som kan köras vid publicering av nya databaser, men dessa används även av Releasepipelinen i TFS:en för att få till DevOps tänket för databasen. När incheckning görs i databasprojekt så kickar TFS:en igång en bygge som genererar en Dacpac fil. Denna dacpac fil innehåller en representation för hur databasen schematiskt ser ut, men även pre och post deployment scripten finns med. Efter att bygget har gått igenom så tar Releasehanteraren vid och gör en jämförelse på den genererade dacpac filen mot instansen som finns i Azure. Finns ett pre script så körs detta första, sen uppdateras databasen med förändringar och sen om ett post script finns så körs detta. Pre och post scripten används framförallt vid förändringar som påverkar foreign keys och constraints som ligger. Om exempelvis en tabell har en relation till en annan och den första behöver göra förändringar som inte går på grund av begränsningar i constraint, så plockas constraintet bort i pre scriptet och läggs sedan tillbaka i post scriptet. Unit tester Enhetstester används till största delen av API projektet och dess olika lager och körs i Visual Studio som Live Unit tests parallelt med att utvecklingen görs för att kontrollera att inga breaking changes 4

5 görs, alternativt att om breaking changes behövs så uppmärksammar failade enhetstester att det behövs göras nya på de nya förändringarna av koden. Nästan alla enhetertester är skrivna mot businesslogik lagret samt repository lagret för att verifiera att det går att lagra/hämta från databas enligt de modeller/entiteter som är skriva samt att eventuell logik gör det den ska. Vissa enhetstester är skrivna som integrationstester för att proxy lagret, som används av UWP klienterna ska kunna kontakta tjänsten och att den svarar med samma struktur på responsen som UWP klienterna förväntar sig. TFS / DevOps Microsofts tjänst VSTS används för att hålla reda på koden samt bygga och releasea nya versioner. Git används som källkodshanterare och allt som checkas in måste göras en pull request på för att få komma in i master branchen samt att code review måste göras för att säkerställa kodkvalitet men även för att sprida kunskap om koden. Efter att kod checkats in så drar ett bygge automatiskt igång via att det för respektive projekt finns en byggdefinition med en trigger inlagd. I huvudsak så används tre stycken byggdefinitioner. UWP klienterna, API samt databas. För UWP klienterna, så byggs samma solution med tre olika konfigurationer. En för IOT (spegeln), en för Hololens samt en för Windows Phone. IOT och Windows Phone byggs för ARM processor medan Hololens just nu byggs som x86. Antalet steg för UWP klienterna är relativt få. Man pekar ut solutionfilen och så sköts hela bygget med samma funktionalitet som används som om man skulle bygga själv i Visual Studio. API bygget skiljer sig lite, på grund av att det är baserat på.net Core. Så där används dotnet.exe för att göra en restore av eventuella nuget paket, bygga samt publicera till TFS:ens ArtifactStagingDirectory. Databasprojektet byggs också genom att man pekar ut solutionsfilen, som då bygger hela projektet och genererar en dacpac fil. Release / Distribuering API:et deployas automatiskt till Azure som en Azure App Service via release steget i TFS efter att ett grönt bygge har gått igenom och det en utvald person har godkänt releasen. Databasen deployas automatiskt efter varje godkänt bygge via ett steg i releasen som heter Execute Azure SQL: DacpacTask. Steget innehåller en referens mot en publiceringsprofil som innehåller vilka förhållningsregler som dacpac körning måste ta hänsyn till. Till exempel så tillåts ingen data loss. Inga förändringar får göras som gör att data förloras. T.ex att en kolumn plockas bort felaktigt. Om detta ska göras så måste det göras vi ett manuellt steg i pre scriptet alternativt att man byter publiceringsprofil temporärt. I detta steg så är det konfigurerat mot vilken databas den ska jämföra mot och sen uppdatera. I detta fall mot den databas som används i Azure. 5

6 UWP klienterna distribueras med hjälp av Microsofts tjänster HockeyApp samt Mobile Center som just nu är i preview läge. I Mobile Center kan man bygga applikationer men även distribuera till utvalda personer/grupper. Denna tjänst används nu för att skicka information om att nya versioner finns av UWP klienterna men framöver tänkt att användas för att möjliggöra automatiska uppdateringar av respektive klient på de olika platformarna. Summering av teknik och tjänster som används:.net Core.NET Standard Angular Azure App Service Azure Cognitive Services Azure Logic App Azure ServiceBus Azure SQL databas EF Core HockeyApp Hololens IOT Mobile Center Office365 Raspberry Pi Sass SignalR Core TypeScript UWP Windows 10 IOT Windows Phone VSTS 6