Category Archives: Hexagon Security

Siste innspurt

Dette er en oversikt over hva vi har gjort de siste ukene.

 

Uke 46

Data jobbet videre med face recognition og det fungerer endelig etter mange timer med prøving og feiling.

Elektro la til brikkeleser i arduinokoden. Arduinoen sender signal til Raspberry PI når denne blir brukt ved inngangsdøra, hvorpå Raspberry PI sender tilbake et signal om at arduinoen skal åpne døren.   

46

Maskin fikk tak i en dør og begynte å bygge den om. De designet også boksen som skal huse brikkeleseren (RFID-RC522) og printet ut denne i 3D printer. Testing av vindusåpneren montert i vinduet viste at motoren ikke var effektiv nok til å utføre jobben. Åpning av vinduet tok ufornuftig lang tid. Maskin måtte derfor lage et nytt design med en større steppermotor (mer info i blogginlegget “Maskinrelaterte valg”).

46-2

 

Uke 47

Data jobbet med integrasjon av face recognition med resten av koden. Dette kom selvfølgelig med noen bugs som de fiksa. Dette betyr at programmeringen på Raspberry Pien snart er komplett. Da gjenstår det å teste kommunikasjon med Arduinoen, hvor signal for låsing av huset og når chipen er plassert på leseren, må overføres.

Elektro laget spenningsdeler og løsning for kommunikasjon med Rasberry Pi. De begynte med kode til den andre steppermotoren som skal styre vinduet og la til buzzer i koden, slik at vi kan høre når alarmen går. Det ble valgt å kun bruke en buzzer foreløpig, for demonstrasjonens skyld. Det reelle systemet ville hatt en sirene.  De laget også en spenningsdeler slik at vi kan overføre signaler fra arduino til PI uten at vi ødelegger PI’en siden den opererer med 3.3V og arduino med 5V.

Maskin lagde exploded view av flere av komponentene i solidworks for å forklare sammenstillingen av disse. De fortsatte å bygge døra og ulike deler til denne, som blandt annet plata og boksen som dekker låsen.

pir-cam-image

 

Uke 48

Data testet kommunikasjon med Arduinoen og forskjellige scenarioer, da oppdaget vi bugs i hoved scriptet for face recognition. Etter noe omskriving og testing kjørte hovedprogrammet nesten som de hadde håpet, hvor noen tilfeller ga uforventede resultater. De gikk derfor gjennom koden systematisk for å luke ut (potensielle) feil. Det ble og lagt til en smart del, hvor vi bruker timeframe til å avgjøre om personen må bruke kort og eller ansiktsgjenkjenning. Er personen innenfor timeframe, vil han bare trenge kortet. Hvis utenfor må han bruke kortet og ansiktsgjenkjenning for å kunne entre leiligheten. Det ble også lagt til en buzzer som vil gi lyd hvis noen bryter seg  inn. Det vil si hvis maskinen vet at personen er borte, og den oppdager bevegelse i huset.

Elektro ferdigstilte koden til den andre steppermotoren som skal styre vinduet, og fikset bugs i koden. Vi testet oppkobling mot Raspberry Pi, kommunikasjonen fungerte som forventet etter litt feilsøking. Lagde nytt og oppdatert kretsskjema ettersom testingen krever noen nye tilkoblingsløsninger.

Maskin lagde ferdig døra til systemet og hovedboksen som skal huse de viktigste komponentene. De satte også sammen deler av systemet slik at det ble klart til testing. Testing viste at både vindu og dørlås fungerer som det skal, maskinellt sett.

3qiuwhr

 

Uke 49

På datafronten var det den største spenningen knyttet til hvordan systemet ville operere når alt var i en boks. Ved første test fikk vi noen uventede feil, som f.eks. at kortleseren enten leste uten at kortet var tilstedet, eller ikke i det heletatt. De trodde først det kunne være noe feil i python scriptene, men fant ut at det var på elektrosiden. Det handlet om elektronikk som var for nære hverandre. Etter det slanket de koden slik at den er mer lesbar og optimalisert for demonstrasjonen.  De redigerte også demonstrasjonsfilmen som viser hvordan systemet fungerer.

film-redigering-img

Maskin dokumenterte alle maskinrelaterte valg i et eget dokument (tilgjengelig i blogginnlegget “Maskinrelaterte valg”). Jonas satt sammen resten av systemet; lodda på pinner, trakk og kobla ledninger og skrudde på plass alle bokser og komponenter.

Elektro finjusterte koblinger, fikset flere bugs i koden og lagde koblingsskjema.

skjema

I skrivende stund fungerer alt som det skal og det er bare litt finpuss igjen, som å ta litt flere bilder til face recognition for å være sikker på at vi har bilder som dekker lysstyrken i fremførings lokalet og gå gjennom alle sekvenser flere ganger for å bekrefte at alt fungerer som det skal, slik at ingen bugs, spenningsfeil, eller andre problemer hindrer systemet i å utføre oppgaven sin korrekt.

Maskinrelaterte valg

I dette innlegget forklarer vi de ulike komponentene og valgene vi har gjort i forbindelse med dem.

 

Dørlås: 

Systemet vårt skal kunne låse opp og igjen en dør. For å få til dette valgte vi å montere akselen til en stepper motor rett på akselen til låsen, slik at døren kan låses opp og igjen ved å styre steppermotoren. Motoren dekkes av en 3D-printet boks, valget av denne forklares i et avsnitt lenger ned. Mellom boksen og døra har vi en metallplate. Den har stort areal i forhold til tykkelse. Vi valgte derfor å lage den av stål for at den skal tåle eventuelle belastninger. Den er konstruert slik at den stikker ut fra den ene siden av dørbladet og dermed dekker låsemekanismen. Dette er gjort som et bevisst valg for å forhindre muligheten til å skjære over låseboltene.

Designet på døråpneren er svært enkelt, dette har to grunner. Den ene er at vi ønsket å gjøre det så enkelt som mulig, uten mange bevegelige komponenter. Dette er fordi systemet skal stå ute, og er da svært utsatt for varierte temperaturer som kan føre til tilfrossing i små deler. Derfor er motoren koblet direkte til låsekassen med en erstattning som nøkkel (Nøkkelbolt).

Det andre valget som avgjorde et enkelt design, var at man skal kunne montere låsesystemet direkte på en eksisterende dør, uten store inngrep i dørbladet eller karmen.

Materialvalget er som nevnt ovenfor, to-delt. Dette ble gjort bevisst, da vi ønsket styrke i den overflaten som skulle beskytte låsebolten, og lavere vekt i resten av strukturen. Fasongen har mye ulike flater og grader, noe som hadde ført til høy kostnad og dårlig materialbruk om vi hadde valgt å frese den ut av et helt stykke.

En ting vi ikke fikk gjennomført, var overføringen av strøm og signaler til låsesystemet uten ledning. Dette var tenkt at skulle gjøres gjennom låsekassen og inn til dørkarmen ved hjelp av slepekontakter. Grunnen til slepekontakter og ikke batteri, er at man slipper at døren ved et uhell gå tom for strøm og dermed miste tilgang til huset.

Ved å velge denne løsningen, vil døren miste spenning når den er åpen, men dette har ingen betydning, da låsesystemet kun trenger strøm når døren er lukket.

dor-assy-img

 

Vindusåpner: 

Vi vil ha en innretning som er i stand til å åpne og lukke et vindu. Dette systemet drives av en steppermotor som styres av en arduino. Under utviklingen av vindusåpneren var det en del praktiske ting vi måtte ta hensyn til. Under beskriver vi hvorfor det ene designet er valgt fremfor det andre.

Første del av utviklingsprossesen gikk ut på å velge løsning på hvrdan vinduet skulle åpnes. Vi gikk igjennom fordeler og ulemper for de forskjellige typene. Deriblant tannstag, aktuator og et skrue-design. Vi valgte til slutt og gå for skrue-designet da denne løsninngen betyr at motoren ikke trenger å holde igjen vinduet når det er åpent. All vekten hviler da på gjengene til staget, slik at motoren ikke trenger å stå med spenning kontinuerlig.

 

Første design, vindusåpner:

Dette designet ble laget med tanke på styrke. Motoren vi først valgte var ganske svak, men det skulle i teorien gå om vi giret den om. Dette ville da føre til at den fysiske størrelsen kunne være litt mindre til sammenligning med en større motor. Vi fullførte designet og monterte hele systemet, som vist på bildet under. Designet fungere som ønsket, men en effekt vi ikke hadde tatt i beregning var at siden vi endret utveksling på motoren, hadde vi senket hastigheten så mye at vinduet brukte 10 min på å åpne seg. Dette førte til at vi måtte forkaste dette designet, selv om funksjonen var der.

 

vindusopner-assy-exploded-2d-jpeg

 

Final design, vindusåpner:

Dette designet ble valgt ut ifra erfaringene fra første design. Vi valgte her å bruke en større motor, med akselen koblet direkte på motoren med en overgang. Denne motoren (Nema 17) var kraftig nok til å ikke måtte gires ned, og har i tillegg større mulighet til å endre rotasjonshastighet. Designmessig, ble den laget for å matche de andre komponentene i systemet, for å skape en helhet.

Igjen er det valgt å 3D printe, dette på grunn av vekt og materialbruk. Denne ville også vært lite hensiktsmessig om man skulle frest det ut av en hel blokk aluminium. Bunndekselet er laget av platestål, da det både er robust, men også enkelt å jobbe med i en prototype-prosess. I neste revisjon av designet vil denne platen være aluminium, da denne er lettere.

Mottakeren i karmen er laget i vanlige vinkeljern, hvor det er boret og gjenget for gjengestangen. Dette er et midlertidig design, laget mtp å vise funksjonen. Dette skal i ettertid lages i lik stil som resten av komponentene slik at det står naturlig til resten av systemet design.

vindusapner-2-img

 

Hovedboks:

Hovedboksen er boksen som skal huse alle de viktigste komponentene, som arduino og Raspberry Pi. Vi lagde den av platestål. Dette lot oss lage en boks med stort volum samtidig som veggene kunne være tynne, slik at boksen ikke tar mer plass enn den må.

Under viser vi 2d tegningene, for bunnen, lokket og veggene. Veggene og lokket er brettet i henhold til hva som står på tegningene. Et unntak er lokket, der den ene kanten er brettet ned for å sikre mot inntrenging av ukjente legemer. Dette er den siden med hengsler, hvor mellomrommet ble større enn forventet. I neste revisjon vil dette tas hensyn til i tegninger.

Når systemet skal monteres i fullskala, er det ikke tenkt at pir og kamera skal plasseres på boksen, men på hver sin side av døren. Boksen er kun der for å forbinde de forskjellige sensorene.

hovedboks-img

vegg-hovedboks-img

bunnplate-hovedboks-img

lokk-hovedboks-img

 

Andre bokser:

Vi trengte bokser til å dekke mekanismene i dørlåsen og vindusåpneren, PIR detektor, Raspberry Pi kamera og RFID-RC522 brikkeleser. Vi valgte å 3D-printe (additiv tilvirkning) boksene til de ulike komponentene. Dette gjorde vi fordi det lot oss lage produkter med avansert geometri som ville vært vanskelig å tilvirke på noen annen måte, dermed fikk vi det designet vi ønsket. Boksene påføres heller ingen store belastninger, så de trengte ikke lages av sterkere materialer. Ved å velge 3D printing, får vi også større spillerom med tanke på designprosessen. Dette lot oss designe former, som ved tradisjonelle metoder ville kostet mye mer å tilvirke.

PIR boks 2D:pir-detektor-2d-jpeg

PIR boks exploded view:pir-image

Kombinert PIR og kamera boks 2D:kamera-pir-detektor-2d-jpeg

Kombinert PIR og kamera boks exploded view:pir-cam-image

RFID-RC522 boks 2D:rfid-rc522-box-2d-img

RFID-RC522 boks exploded view:rfid-rc522-image

 

Vindu og dør:

Vi trengte en dør og et vindu for å demonstrere systemet vårt. Det mest realistiske ville da vært å teste det i et hus og montere det på eksisterende dør og vindu, men dette ville vært veldig upraktisk i forbindelse med dette prosjektet. Vi lagde de derfor selv. Begge er laget forenklet for å gjøre det lettere for oss å frakte systemet rundt på skolen. Design og mål er ikke viktig, siden systemet vårt skal kunne monteres på eksisterende dører og vinduer.

Veien mot et smart sikkerhetssystem

Heisann!

Dette er en oversikt tilbake til starten av prosjekter vårt og frem til i dag.

 

Uke 34

Første uke av prosjektet er i gang og vi har dannet en gruppe. Vi endte opp med å bli en gruppe på 6 kjekke karer; Martin og Tony fra elektro, Håkon og Torkil fra data og Jonas og Daniel fra maskin. Så kom valget av system. Det foregikk i flere faser, da vi ikke var helt  klar over hva som inngikk i et smart system. Mye av tiden gikk med til å definere hva et smart system er. Vi avtalte til slutt at vi skulle bruke uka på å komme opp med våre forslag, for så å gå igjennom dem i slutten av uka og velge en av dem.

Da vi møttes diskuterte vi de ulike forslagene, blandt dem var minigarasje, vekkerklokke, 3D printer og sikkerhetsystem. Vi endte opp med å velge sikkerhetsystemet.

 

Uke 35

Denne uka gikk  tiden med til å finne ut hvilke oppgaver systemet vårt skal utføre og hvilke metoder vi kan bruke for få det til.

Vi kom fram til at systemet skal kunne låse opp og igjen ytterdøra samt åpne og lukke vinduer i huset automatisk og at det skal lære seg typiske klokkeslett for avreise og ankomst. Poenget er at systemet skal låse døra og lukke vinduer når huseieren drar og låse og lukke opp når han kommer hjem.

Så bestemte vi oss for at systemet skal omfatte smart vindu og dørlås, kamera med ansiktsgjenkjenning (del av dørlåsen, på den måten at den gir noen bestemte personer tilgang til huset), bevegelsessensorer og for strengere sikkerhet er brikkeleser med “nærhetsteknologi” (bluetooth, NFC eller lignende) inkludert. Utenfor vanlige ankomsttider vil vi at systemet skal kreve begge sikkerhetsmetoder for adgang. Datagutta utvekslet idéer rundt system modell.

 

Uke 36

Vi har jobbet mer med hvordan systemet skal utføre oppgavene sine og laget en midlertidig komponentliste.

Maskin så på ulike måter å integrere låsemekanismen i døra og hvordan de skal få til å åpne vinduet. Etter diskusjon med elektro virker det som steppermotorer blir en del av begge løsningene.

Elektro kom fram til at de vil bruke arduino til styring av mekanismene i både vindu og dør, fordi arduinoen er enkel å tilpasse og har et stort komponentutvalg. Som bevegelsessensor valgte de å bruke en PIR-detektor som ved hjelp av infrarød sensor kan oppdage bevegelser i huset og utenfor inngangsdøren. Det er en pålitelig og mye brukt sensor som brukes til nettopp dette, så valget var ganske enkelt.

Data fikk tak i Raspberry Pien, Pi kamera og  PIR-detektor fra skolen. Og deretter satt de i gang med å installere operativsystem på Pien, i tillegg til å installere software som trengtes for å kunne styre Pien fra en annen PC over nettet, kalt “Putty” og “Xming”. Dette gjorde de for å slippe å måtte sette opp skjerm, tastatur og mus hver gang de skulle programmere på Pien. Dette ga datastudentene muligheten til å programmere på Pien samtidig fra hver sin PC!

raspiraspi-cam-v2

 

Uke 37

Vi møttes for å diskuterte løsninger på hvordan ansiktsgjenkjenningen og kameraet skulle fungere. Først ville vi at kameraet skulle kunne bevege seg for å finne ansiktet til folk uavhengig av høyde, men bestemte til slutt at kameraet skulle være fiksert i døra siden det ikke vil utgjøre noen stor forskjell i dette prosjektet.

Elektro fikk tak i arduino mega og brødbrett av skolen, så de kan gå i gang med koding i arduino.

Data starta vi med å laste ned og installere OpenCV, som er open source programvare som trengs for å bruke ansiktsgjenkjenning med Pien. De lagde også et demo program, som kan ses i bruk på bildet under.

facerec-test-resultat

 

Uke 38

Maskin diskuterte hvordan vinduåpneren skal fungere og kom fram til at de vil ha et design som overfører kraft fra en steppermotor til et tannhjul og videre til en gjengestang som skrus ut og åpner vinduet. Det ferdige designet ble printet ut ved hjelp additisjons produksjon (3D printet). Dette var fordi formene var såpass komplekse at den måttet ha blitt delt opp om det skulle gjøres på en annen måte.

Elektro arbeidet med kretsskjema for sikkerhetssystemet. Det er greit å få en visuell oversikt over koblingen mellom de forskjellige komponentene. I utarbeiding av kretsskjema jobbet de i et program som heter Fritzing. Det var med forbehold om at ting kan endre seg ettersom vi jobber mer med prosjektet og uventede overraskelser kan gjøre at det blir andre løsninger senere, men det er en god foreløpig illustrasjon og oversikt over sikkerhetssystemet vårt.

Data planla hvordan de skulle få systemet til å oppføre seg smart. De så på ulike måter å sette opp programmet, scripts, osv.

tid-logging-brainstorming-sketch

Uke 39

Elektro startet arbeidet med hvordan åpning/låsing av dør og vindu skal fungere rent kodemessig.

De tenkte også ut måter for kommunikasjon mellom raspberry pi og arduino og hvilken mikrokontroller som skal styre hva.

Maskin lagde CAD-modell til vinduåpneren og leverte den til 3D printing. De undersøkte også hvilke deler som måtte kjøpes inn til denne. Så skaffet de materialer til selve vinduet og begynte å bygge det.

b2

Data starta å programmere scriptet for deteksjon av når en person drar og returnerer til hjemmet. Scriptet kalte de TimeLogger.

tid-logging-kode-inn-i-database

 

Uke 40

Data og Elektro hadde et kort møte hvor det ble diskutert forskjellige grensesnitt mellom Raspberry Pi og Arduino. Etter litt bestemte de seg for å bruke i2c-metoden, i stedet for firmata.

Maskin skaffet deler til vinduåpneren (gjengestang, steppermotor, vinkelledd, tanhjul, mm) og fortsatte å bygge vinduet. Deler av vinduet måttet bygges på nytt pga for dårlig håndtverk, men det ble ferdig i løpet av uka.

b3

Elektro kom fram til å bruke I2C overføring i kommunikasjonen mellom arduino og Raspberry PI. De testet hvordan slik overføring fungerer ved å jobbe med programmering av dette i arduino. Så testet de overføring og det fungerte som det skulle mellom en arduino nano og en arduino mega. Da gjenstår det å se om det fungerer like problemfritt mellom Raspberry Pi og arduino. Det ble også gjort noen endringer på kretsskjema for å akkomodere endringene i løsningene våre.

b4

Data fant også ut at vi trengte enda en PIR-detektor for scriptet som sjekket når en person drar og returnerer. Og implementerte dette i koden.

raspi-pir-sensor

 

Uke 41

Maskin fikk tak i resten av delene de trengte til vinduåpneren, satte den sammen og testet at den fungerte som den skulle.

b5

Data besteme seg for å bruke en enkel database for å lagre tidene huseieren dro og kom hjem. Valget falt på TinyDB siden den ikke trenger noen form for kommunikasjon eller SQL. Den lagrer alt i en lokal fil, er lett å bruke og godt dokumentert.

database-format-pa-info

Elektro fant ut at dei ikke trengte I2C likevel. Dei skal løse kommunikasjon mellom PI og arduino med kun 2 ledninger i stedet, siden de fant ut at det er mer hensiktsmessig i forhold til vår oppgave ettersom PIen kun skal styre om Arduinoen skal åpne døra og vinduet, og Arduinoen skal gi signal til PIen når brikkeleseren er brukt. Etter dette satte de i gang med å se på koding av steppermotorene.

 

Uke 42

Data begynte med script nummer to, som skulle hente dataen fra databasen og lage det de kalte “TimeFrame”, som deretter skulle brukes til å vite når man skulle låse vinduer og dører, ved å sende signal til Arduinoen når visse betingelser var sanne.

Maskin fortsatte å jobbe med hvordan dørlåsen skal fungere. Kom fram til at en god løsning er å montere en steppermotor rett på låseakselen. De begynte også å tegne boksen som skal skjule låsesystemet, men denne kan ikke gjøres ferdig før vi får tak i en dør og bygger en ramme til denne.

Elektro jobbet med arduinokode for åpning og låsing av vindu og dører. De lekte litt med  tanken å lage power supply og en batteribackup som kan slå inn hvis strømmen går eller blir tuklet med.

 

Uke 43

Data fant ut at når tidene er lagret i databasen må de tas ut og analyseres for å kunne lage en TimeFrame. TimeFrame er gjennomsnittet av når personen drar og kommer hjem fra jobb.

F.eks. hvis personen drar ca. 07 og kommer hjem ca 16 hver dag vil timeFrame-en være 07-16.

Vi har gjort det slik at vi bare tar med ukedagene. Helgen (lørdag og søndag) er ikke med i beregningen. Personen må også være borte mellom 5 og 10 timer for at det skal bli tatt med.

Elektro jobbet videre med arduino-koden. De gjorde endringer på hvordan åpning og låsing av både vinduer og dør skal foregå.

Maskin diskuterte hva som er beste plassering for PIR-detektorer og PI kamera. Etter konsultering med data og elektro anngående plass til ledninger og nødvendige komponenter bestemte de seg for at det beste var å plassere sensorene over døra, den med kamera og PIR på utsiden og den med bare PIR på innsiden. Denne plasseringen gjør det lettere å trekke ledninger til sensorene.

 

Uke 44

Maskin tegnet bokser til PIR-detektor og PI kamera, dokumenterte disse i 2D og leverte modell til 3D printing.

b6

b7

Data har til nå hatt to script, og er i tenkeboksen på hvordan de skal eksekvere dem og i hvilken rekkefølge. Det står mellom å starte scriptB fra scriptA, eller å kjøre de samtidig. Et annet problem er hvordan de skal dele data mellom script-ene. En løsning er å lage en lokal fil hvor det ene scriptet skriver til, og det andre leser fra, kalt “pickle”.

Elektro jobbet med steppermotorene. De støtte på et problem med steppermotoren, den fungerte bare den ene veien, dvs med klokka og ikke mot. De skal se videre på dette neste uke.

b8

 

Uke 45

Data har implementert klasser i scriptene så de kan bruke variablene og funksjonene de lagde tidligere (som var uten klasser), i et Main script som eksekverer det de trenger av funksjoner når de trenger dem. Main scriptet skal oppføre seg som en master, for å få oversikt over hva som skal gjøres når. I tillegg til kommunikasjon med Ardionoen som derfra tar seg av styring av motorene etc.

Elektro fikset problemet med steppermotoren, og ordnet slik at den gikk i “dvale” når den ikke er i bruk, så den sparer strøm. Hvis den ikke går i “dvale” er det fortsatt strøm i spolene til motoren slik at den holdes fast.

Maskin diskuterte hvordan de vil produsere deler av dørlåsen og hovedboksen. I stedet for å 3D printe er planen å tilvirke disse fra metallplater. Grunnen til dette er at noen av delene blir relativt store, men også at de vil prøve seg på noe annet enn 3D printing.