Blogg SmartTarget

22.08.2017

Innføring i faget

29.08.2017

Satt sammen gruppe, 2 data, 1 maskin. Diskuterte prosjekt.

Krav som ble diskutert finner du her:

05.09.2017

Funnet ut at vi skal ta i bruk Raspberry Pi 3B for bruk til bildegjenkjenning. Samlet utstyr for å kunne sette opp Raspberry Pi.

Startet med planlegging av konstruksjonen av en robot.

12.09.2017

Startet installasjon av operativsystem og programmer nødvendig for bildegjenkjenning. Problemer under installasjon, må gjøres om igjen en annen dag.

Tegnet på robot.

Første modell

19.09.2017

Installasjon av operativsystem og programmer ferdig installert. Fant ut at noe mer manglet for å benytte CV2, mer å installere.

26.09.2017

Startet å forsøke å bruke PiCamera for bildegjenkjenning. Lite til ingen dokumentasjon om hvordan vi skal gå frem, så forsøket å gjøre fremgang på egenhånd. Python er et nytt programmeringsspråk, det er uvant å bruke.

03.10.2017

Fått til å ta bilder og video med PiCamera, usikker på hvordan å gå frem ettersom at det er lite å lese seg opp på for bruk av PiCamera til å gjenkjenne laser.

10.10.2017

Fant noen som har satt opp et lignende laser gjenkjennings prosjekt. Byttet til et webcam som kunne brukes til koden som personen brukte.

Laget første video:

(måtte gjøre det om til en .gif fil)

17.10.2017

Lest gjennom koden for å få forståelse for hvordan man benytter kamera i Python.

Første modell forkastet.

Modellen ble for komplisert da akselen som laser skal monteres på blir unødvendig komplisert.

En ny modell planlegges.

Ny modell lages med opplagring i bare den ene enden. Dette frigjør plass på enden av akselen.

Antakelse:

  • Akselen blir mindre utsatt for deformasjon.
  • Akselen blir enklere å fremstille.
  • Det blir mindre krav til konsentrisitet på opplagringen av akselen.

24.10.2017

Justere på maksimal og minimum verdier for å se om det kan bedre deteksjon av rød laserdott fra en laser koblet til arduino.

Jobbet med aksel.

Det er vurdert om vi behøver en av/på bryter til laseren.

Diskutere hvordan vi kan lage en enkel mekanisme.

31.10.2017

Bestemme oss for laser type. Endte med rød ettersom at det virket mest normalt å få tak i.

07.11.2017

Hovedfokus på å få programmet til å gjenkjenne rød laser på lengre avstand.

Sendt modell til 3D print

14.11.2017

3D print ble mislykket. Har hatt problemer med:

  • Toleranser
  • Overhengende flater som behøver støttemateriale
  • 3D printen feilet, den stoppet

21.11.2017

Prøvde å koble opp Raspberry Pi til motor og driver. Problemer med driver. Raspberry Pi har for lav spenning til å kjøre driveren.

28.11.2017

Flere gruppemedlemmer har eksamener om kort tid, dagen ble satt av til videre øving i andre fag.

Ny modell sendt til 3D-print.

Beskrevet hvordan delene er tenkt printet. Se linken: Link.

05.12.2017

Gjøre klar film og presentasjon til eksamensdagen.

06.12.2017

Justeringer Turret rotation barrel. Sendt til 3D-print.

07.12.2017

Siste touch på presentasjon.

Fulgt opp deler, takker for goodwill og rask behandling hos print avd.

Dokumentasjon

  • Arbeidsbeskrivelse
  • Produksjonsbeskrivelse
  • Partslist

Kode

Laser_tracker.py

Video

Video til fremføring

Blogg

Ble noe formaterings når bloggen ble flyttet til DroneSonen.

Bilder og videoer mangler men kan finnes på orginal bloggen:

Link til blogg

Selvbalanserende Robot Uke 49

Avsluttende blogginnlegg. Denne uken har vi gjort avsluttende forberedelser til presentasjon. Kort avsluttende informasjon om produktet:

  • Systemets funksjon: I PID regulatoren setter vi en ønsket vinkel vi vil at den skal regulere, som er setpoint. Input variabelen gis ifra MPU hvor vi henter vinkelaksellerasjon og vinkel posisjon og legger disse sammen vha komplimentær filter. Input og setpoint sammenlignes hele tiden og reguleringen kan justeres vha kp ki og kd verdien.  Output sendes da til motorkontrolleren og gir en verdi i forhold til hvor mye kraft motorene skal ha.
  • Dersom vi skulle fortsatt prosjektet ville vi prøvd å få implementert encoderene til motorene. Hvor vi vha disse kan finne vinkelhastighet/fart/posisjon. Vi ville også fokusert mer på å få implementert ett kalmanfilter som kan “forutse” neste posisjon vha estimater. og til slutt implementert et styringsystem vha bluetoothkontroller.

Link til kode og presentasjon kan du finne under.

https://drive.google.com/drive/folders/1aM7obNVLto-LxInUHKWGkC-UeDH4gPzk

 

Design & brukergrensesnitt ferdig?

Design & brukergrensesnitt

Nå er det sluttinnspurt fra hele gruppen. Det  som gjenstår nå er å få til kommunikasjon mellom de forskjellige systemene, testing og finpussing av, forhåpentligvis, mindre detaljer.

Data

Brukergrensesnittet – Vi bruker Tkinter som kanskje ikke er det peneste brukergrensesnitter man har sett, men det fungerer godt og har et rent design som passer for alle brukere. Menyen som møter kunden består av en rekke check-bokser der brukeren skal kunne gi tilbakemelding om forrige kjøp og om den “ikke liker” en type godteri. Kunden skal også kunne gi en input som forteller hvor mange kr den har lyst til å bruke på godteriet.  Tilslutt vises fordelingen av godteriet den fikk i kvitteringsdelen.

Kommunikasjon mellom Raspberry pi og arduino – Da vi skulle kommunisere med arduinoen (fra raspberyy pi) oppstod det problemer. Vi hadde kanskje undervurdert dette aspektet ved prosjektet iom. at det tok flere dager med fortvilelse og frustrasjon.  Vi fikk ikke til å sende en string liste (som verken var konstant i lengde eller variabler) via serial kommunikasjon.  Vi klarte å sende signaler i form av en enkel string da vi testet tidligere i prosessen, men at en liste skulle skape så mye mer trøbbel hadde vi aldri trodd. Vi skaffet ekspert hjelp i form av lærere og super-studenter, men fant ikke en løsning på den tiden vi hadde lagt av til dette.

Ansikts gjengkjenneren fungerer i den forstand at den klarer å gjenkjenne brukere som er lagt inn i databasen og gi dem tilgang til menyen videre. Men det som gjenstår, som et siste finpuss, er at identifikasjonen til en bruker kan dukke opp når det er en “ukjent” person som stiller seg foran kameraet. Den “ukjente” personen kan riktig nok ikke logge inn fordi det ikke er høy nok gjenkjennings-score. Men det er, som sagt, en siste liten finpuss vi vil gjerne få på plass før presentasjonen.

Maskin

Hvorfor vi valgte den løsningen vi gjorde?

Gruppen utviklet noen alternativer til hvordan godteri kunne dispensens under ide myldingen tidlig i utviklings prosessen. Av disse ideene ble en med et roterende element med forskjellige kammeret valgt som den enkleste og mest effektive løsningen.

Materialvalg

Vi har valgt og 3d printe alle de sentrale delelene av systemet, dette har begrenset materialvalget noe. Prototypen består av to 3d printede deler, to stykker laser kuttede plexus glass paneler og noen hjemmelagde tre deler. De 3d printede delene er printet i PLA plast.

Prosessbeskrivelse

Vi startet med en idemyldring hvor vi diskuterte mulige løsninger til oppgaven. Vi fastslo så hvordan systemet skulle operere og hvilke funksjoner det skulle ha. Deretter begynte vi og produsere prototyper som vi kunne teste med (denne delen av prosessen ble meget forsinket, noe som har hindret produktet i å bli 100 % funksjonelt). Når man har funnet et design som virker etter hensikten setter man i gang produksjon av dette.

Operasjons beskrivelser

3D printede deler:

  1. Delen blir designet i Solidworks eller annen CAD programvare.
  2. Delen blir lagret som .stl fil og overført til printeren.
  3. Printeren blir gjort klar for printing (Last inn riktig plast, påføre festemidler)
  4. Start printen.
  5. Vent til printen er ferdig.
  6. Ta den ferdige printen av byggeplaten,
  7. Rengjør printern.

For laser kuttede deler:

  1. Lag modellen som brukes til å generere 2d tegningen det skal kuttes etter.
  2. Gjør nødvendige endringer i layout for 2d tegninger.
  3. Legg inn riktig materiale i laser kutteren (plexi).
  4. Sett startpunkt.
  5. Sett riktig høyde til materialet hvis dette ikke er satt.
  6. Start avsuget.
  7. Start kuttingen
  8. Vent til kuttingen er ferdig.
  9. Ta ut produktet og restene.
  10. Slå av avsuget og maskinen.

For tre deler:

  1. Kjøp materialer (to hobbyplater og en meter 60*60)
  2. Del en hobbyplate i to på tvers av lengde retningen.
  3. Lim sammen de to delene, men i horisontal retning.
  4. Mål opp og bor opp fire hull (64mm hullsag) til montasje av steppere.
  5. Kutt opp hobbyplate nummer to til fem stykk 18*28*1180 (B*H*L) kutt disse så i riktige lengder.
  6. Sett sammen delene med trelim og 6.5*25 treskruer.
  7. monter 3D printede deler.
  8. Monter plexi glass.

Produksjons-underlag.

 

Slutt fremlegg

Oppsummering

  • Utstyrsliste
    • 4 stepper motorer
    • 4 stepper drivere
    • Avstands sensorer
    • 1 last celle
    • 4 3D-printa rotorer
    • 2 arduioner
    • Rasberry pi 3
    • Pi 7-tommers touch skjerm

Med vårt verk ønsker vi å frembringe en ny og enklere bane innenfor godteri handling. Det skal kunne gjøre lørdags handling av smågodt både enklere og raskere, samt kunne brukes i andre situasjoner. Vi startet prosjektet med “brain-storming” og drøfting av hvordan vi skulle utforme et produkt som dekker alle våre ønsker. Etter å ha presentert forslaget vårt for foreleseren endte vi med godteri dispenser som utgangspunkt .

 

Fremgangsmåte

Vi Startet med koseptutvikling i startfasen og endte relativt raskt opp med det mekaniske designet til maskinen. Vi ble enige om hvordan vi skulle løse de forsjkellige aspektene av prosjektet som dermed ble delt  inn i tre fagfelt der alle hadde noe å jobbe med.

Samarbeid

Medlemmene fra de forsjellige fagfeltene har jobbet selvstendig med sin del samtidig som vi har hatt møter hvor vi har diskutert og løst problemer sammen.  Vi konsentrete oss om å få på plass kritiske deler for å teste at de fungerer tidligst mulig. Men med en 3D printer som røk og uforutsette problemer med kommunikasjonen mellom mikrokontrollerne ble prosjektet en del forsinket og slik at ikke alle deler fungerer optimalt.

Konklusjon

Gruppen er stort sett fornøyd med produktet vi har laget selvom vi helst skulle hatt en itterasjon til på den mekaniske biten. Vi har bygget mange nye erfaringer blandt annet at seriell kommunikasjon ikke nødvendigvis er “plug and play”. Vi har endt opp med en kul prototype som viser hvordan vi tenkte da vi designet. Vi har nok den eneste godteridispenseren med en fungerende ansiktsgjenning i verden!

Videre arbeid?

Om vi skulle jobbet videre med prosjektet ville vi sett på muligheter for å gjøre den mekaniske delen mer robust. Vi har noen ideer om hvordan konseptet kan løses på andre måter.

 

Smart Mirror – Last update from software

Link to GitHub:

https://github.com/erlendhel/smartmirror

In hindsight, the software part of the project has mostly gone according to plan, the biggest turnaround we had to do, was to change from a touch screen to speech recognition. This was mainly due to the fact that the foil we decided to use to provide the mirror effect wouldn’t support touch. This meant that we had to implement the speech recognition function, which in turn meant that we had to facilitate the smartmirror app for touchless navigation throughout. The user will be displayed a progress bar at the bottom of the screen, indicating when voice is being recorded. By saying a valid command in the timeinterval it takes the bar to go from 100% to 0%, the application will perform the chosen command.

Speech Recognition

In order to implement speech recognition, we used the python package SpeechRecognition, which has support for the Google Cloud Speech API, which is the one we ended up using. The decision of using the Google Cloud Speech API was made because the interface seemed the easiest and also since the services provided from the Google API are well tested. Since we had a limited budget ($1 soundcard and $3 microphone), we tried to limit the negative factors by choosing safe.

How we used the API

Our initial plan for the speech functionality for the mirror was to have a thread which continously listened for commands, and then returned them to the main program, which would handle the different command. While testing on Windows, the listen() function, which is a part of the SpeechRecognition worked fine, and was able to process the commands we gave it while running continously. When we started testing the code on the Raspberry Pi, the functionality was weak at best. Usually it would listen endlessly without handling the commands it got, while it worked fine one or two times. This resulted in a change of design of the original plan.

Instead of using a listener, we decided to use recordings which were timed to three seconds, for some reason, the recordings were able to process the speech. The short answer to how this works, is that the smartmirror will record three seconds of audio, send it to the Google API for processing, get a return value from the API which should be a word/command, and then use the command to navigate the smartmirror.

Database of words

As mentioned earlier, this smartmirror has been made on a tight budget. Low-cost hardware, coupled with not so perfect pronounciation gave some weird returns from the Google API. In order to be able to work around this, and provide a ‘smooth as possible’ flow for the user. We had to create our own database of keywords for the different commands used in the smartmirror. The more we tested, the more words we got. Although this might be a way of ‘cheating’ the system, the structure of the smartmirror and the set number of commands allowed us to use similar words to represent our actual commands (an example is ‘Logan’ for ‘login’).

To use the database of words which we created throughout the testing period. The smartmirror sends the value which it gets returned from the API to functions which in turn iterate through lists of ‘allowed keywords’ for a given command. When it finds a keyword representing a command, it returns the command to the main program.

Face Recognition

The way we decided to differentiate between users of the smartmirror, was to use Face Recognition. We decided to use the OpenCV library together with a RaspiCam to provide this feature. In order to be able to use the feature as we wanted in the smartmirror app, we had to do a lot of testing in terms of speed and accuracy to get to a level we felt was satisfactory.

Finding the right algorithm

The first thing we experienced when using OpenCV together with our RaspiCam, was that it was very inaccurate in it’s predictions. After testing FisherFaces, EigenFaces and LBPH (Local Binary Pattern Histograms), we opted for using the LBPH. Using this we had a very high rate of success when recognizing different users compared to the other two. Especially FisherFaces seemed to be very sensitive to light, which basically meant we had to provide new training pictures for the face recognizer every time the lighting changed. In addition, both EigenFaces and FisherFaces use the entire database of images for a given user when searching for a match, whereas the LBPH algorithm only uses one at a time, this eases the processing time.

LBPH works in the way that it produces a matrix representing the face of a user/subject. The matrix consists of binary-numbers representing different areas of the face. When setting up a profile of a given face, and when comparing to the image fed to the algorithm by the smartmirror. LBPH looks at relative difference between neighbouring tiles of the matrix in order to provide a final number representing the accuracy of the prediction.

When starting out with FisherFaces, we were happy with accuracy-numbers in the ranges of 750-900. At the end of the project with LBPH, we set the threshold for ‘accepted accuracy’ to 50 (Lower numbers indicate higher accuracy).

Connecting with the database

As the OpenCV library works, the smartmirror has to provide training data for it to work. The training data are the pictures of users of the smartmirror, which is stored locally on the Raspberry Pi. In order to be able to make a prediction when given a face, the algorithm has to have a way to sort the different faces of the database. Locally on the Raspberry, the images taken during registration (which are used in the face recognition) are stored in folders named s1, s2, s3, etc. When training, the algorithm will iterate through the folders and read the integers and at the same time process the images stored in the folders in order to bind all images in s1 to the index of 1, all images in s2 to the index of 2 and so on. This will produce two vectors which will represent a profile of a face found in a image (which will depend on the algorithm used), and also a reference to the indexing number of the folder. If during login, the face which is processed corresponds to a profile indexed to 1, the face recognition knows that the face trying to logon belongs to index number 1.

We also decided to use this index as a reference to our database’s Primary Key. If a face is recognized, the index is stored to a variable and used as a referencing variable in the database throughout the smartmirror.

Database

To store the different users and preferences we’re using a SQLite3 database which is stored locally on the Raspberry Pi. The ‘users’ table consists of a ID (Primary Key), name, path to images, three news sources, a users preferred destination and also preferred type of travel. As mentioned earlier, the referencing from the smartmirror to the database is done using the ID returned from the face recognition at login.

Other modules

In addition to the named modules, we have utilized NewsAPI, WeatherAPI, and Google API for travel. These are used as described in earlier blog posts.

User specific data

When the application is started, the user can see a startup screen with three
options: sign in, register and guest. By saying something along the lines
“sign in” or “log in”, the smartmirror will check if the face is a registered
user in the database. If a known face is found within 10 seconds, the user is
met with a welcome screen, and then redirected to the main screen.

Not user specific data

In the main screen, the user can see various personal information fetched from
the database. The navigation part of the main screen will
display the users chosen destination and travel type, and tell the user the
time it will take to get there. The news part will show the users chosen
preferred news and display the news icons. By saying the name of the source,
e.g. “BBC News”, the user will be redirected to the spoken source. Here the
user will be displayed with the 10 latest titles from the news soruce.

Regardless of which user is logged in, the main screen will always show the
date and time. The main screen will also show the current temperature in Kongsberg,
as well as a image describing the weather, e.g. sunny. By saying the word weather,
the user will be redirected to the weather screen. Here more detailed weather data
will be displayed. This contains a daily forecast, a weekly forecast, as well as a
more detailed current weather description.

Brushing your teeth

Anytime when in the main screen, the user can say the word ‘hello’ to get
handed a toothbrush with toothpaste on.

Navigating backwards

In any screen, the user can go back to the screen he/she came from by saying
something along the lines of ‘go back’, ‘return’ or ‘previous’. When in the
main screen, the user can also log out by saying for instance ‘log out’, ‘sign
out’ or ‘return’. The application will then go back to the startup screen.

Not finished modules

If we would have more time in the project, we would continue on the
registration and setting modules. The registration is one of the choices in
the startup screen, and allows for a new user sign up by spelling their name,
as well as letting the mirror take pictures of their face to use for the login.
The setting module would allow for a already registered user to adjust their preferences.
This would include changing their chosen destination and travel type, as well
as mixing up their preferred news sources.