Monthly Archives: November 2016

Gruppe 10 Smartpostkasse

3D rendering av PCB kort. Siden dette er prototypkort har vi montert to forskjellige kommunikasjons muligheter, dette for enklere å kunne velge den som fungerer best.

Korte har

IC til styringen av solcellepanel lading av batteri
Boost IC til Lås mekanismen, 3.7V til 12V
Xbee pro eller Particle Electron til kommunikasjon
IC til batteri nivå
Buzzer
MCU
Load amplifier til loadcell
Status LED

15056344_586837068184330_2002514455275847252_n

Gruppe 10 Smartpostkasse

30/8

Gruppen består av Thomas Huse, Tor Øverberg, Ole Christian og Martin Rishovd

Vi skal lage en smart postkasse. Postkassen skal gi beskjed til bruker om levert post og være låsbar. Systemet skal benytte seg av en microcontroller innebygdt i postkassen koblet til lås, vekt, sensor på lokket, 433mhz trådløs kommunikasjon og NFC/bluetooth mot en Raspberry pi koblet til wifi innendørs.

Postkassen vil registrere når lokket åpnes, vekten vil registrere om noe ble lagt i postkassen eller tatt ut. Hvis vekten på innholdet blir lavere uten at låsen har blitt åpnet vil man kunne anta at noe har blitt tatt ut ulovlig.

Det skal laget en applikasjon til Android som virker med NFC/bluetooth alle med korrekt tilgangsnøkkel i appen vil kunne åpne postkassen.

Fra denne appen skal det også være mulig å gi andre tilgang, eten åpne den over internett eller gi tilgang i et spesifikt tidspunkt

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.

Test av to steppermotorer (med video)

Sist uke fikk tak i to nye steppermotorer og drivere fra skolen. Les mer her . I dag har vi testet motorene sammen med en Aurduino. Bildet under er hentet fra en utfyllende tutorial med kode. Link til den.

example4_bb

Vi koblet opp steppermotorene etter dette skjemaet – vær obs på å koble kretsene på steppermotor riktig – se forrige post.  Som strømforsyning til steppermotoren bruker vi en 12v batterieliminator som gir 1500mA. Den er kraftig nok til å drive begge motorene samtidig. Vi bruker Arduino biblioteket AccelStepper – det har støtte for både flere motorer og akselerasjon.

På videoen over kjører vi øvre motoren på 1/8 step og den nedre på 1/2 step. Koden er lik. Den øvre motoren beveger seg 4 ganger så langt på samme tid. Eneste forskjellen i oppsettet er at vi på driveren har valgt 1/8 step og 1/2 step. Motorene kan kjøres fram eller tilbake. De blir styrt av kommandoer fra Serial Monitor.

Nå er det bare å få montert motorene i speilskapet og få vår MagicMirror til å styre skuffene på en smart måte.

Skyveskap montert!

Det er motiverende å se at produktet begynner å ta form. Enda mer motiverende er det at målene stemmer så godt overens med slik vi har designet det i 3D. Det er ikke alltid dette er tilfelle, da spesielt når en kutter og skjærer materialene for hånd.  4Helse, miljø og sikkerhet er et svært aspekt av arbeidslivet. Derfor følte vi det også er viktig å ta hensyn til dette mens vi jobber med vårt produkt. 6Nedenfor ser dere et bilde av hvordan vi har tenkt at skyveskapet skal fungere. Det ledige rommet nederst benyttes til plassering av motor, mens de nødvendige kablene trekkes mellom skinnene. 1

Dere lurer muligens på hva det store tomrommet øverst skal benyttes til, og det finnes det et enkelt svar på:

De elektroniske komponentene samt kablene til Raspberry Pi, skjermen(e), kameraet og steppermotorene samles her og ledes videre til strømkilden.

3

 

 

Hei bloggen!

 

Vi har testet to forskjellige batteripakker til boksen vi viste i forrige bloggpost. Den ene er på 9V og den andre har 4 AA batterier på 1.5V. Vi velger å bruke batteriet på 9V, med hensyn på plassen i boksen. De 4 AA batteriene vil ha noe lengre levetid, men vil ta mye mer plass, noe som er viktig for systemet.

batteripakker-min

Vi har også testet hvilken motor vi skal bruke. Det stod mellom en servo motor og en step motor. Step motoren jobber på en spenning fra minimum 6 V og max 12 V, dette er ganske mye sammenlignet med step motoren som jobber på en spenning på 4.8 V. I det lange løp vil dette har mye og si. og med tanke på batteripakken vi kom frem til og plassen vi har i boksen kommer vi til å gå for servomotoren. Den er også mye letter som vi kan se fra databladet under.

step-motor-min   micro-servo

Vi har nå testet hvilken sensor vi skal benytte i “banke” funksjonen til systemet. Det ble en piezo sensor. Vi kan sammenligne denne sensoren med en høyttaler. En høyttaler får signaler og begynner så og vibrere, fra denne vibrasjonen kommer det lyd. denne sensoren funker på samme måte, bare at denne kjenner om det er vibrasjon for og så sende det signalet videre til systemet. Enkelt forklart er dette en innput som sender signaler etter vibrasjon, mens en høyttaler blir en output som sender ut lyd med hjelp av vibrasjon.

piezo-sensor-min

Teknologidagene

#include"Servo.h"

const int servoPin = 6;
const int escPin = 7;
const int trig = 10; // attach pin 3 to Trig
const int echo = 9; //attach pin 4 to Echo
Servo steeringServo;
Servo esc;

void drive(int speed) {
speed = max(speed, 0);
speed = min(speed, 100);
speed = map(speed, 0, 100, 91, 0);
esc.write(speed);
}

void start() {
drive(5);
}

void stop() {
drive(0);
}

int avstand() {
long duration, cm;
digitalWrite(trig, LOW);
delayMicroseconds(2);
digitalWrite(trig, HIGH);
delayMicroseconds(5);
digitalWrite(trig, LOW);
duration = pulseIn(echo, HIGH);
cm = microsecondsToCentimeters(duration);
Serial.print(cm);
Serial.print("cm");
Serial.println();
delay(100);
return cm;
}

long microsecondsToCentimeters(long microseconds)
{
return microseconds / 29 / 2;
}

void setup() {
pinMode(servoPin, OUTPUT);
pinMode(escPin, OUTPUT);
pinMode(trig, OUTPUT);
pinMode(echo, INPUT);
steeringServo.attach(servoPin);
steeringServo.write(90);
esc.attach(escPin);
delay(2000);

Serial.begin(9600);
}

void loop(){
//her skal dere skrive kode

}

Hvor er vi nå?

«Vinnere er ikke de som aldri feiler. Det er de som aldri gir opp» sier sitatet så fint. Og vi har enda ikke gitt oss. Vi er ca to måneder inn i prosjektet og det nærmer seg dead line. Hvis vi spoler tilbake til start. Til friskt mot og høytflyvende ideer… Hva ønsket vi å oppnå? Som vi skrev i det første innlegget er målene våre: ansiktsgjenkjenning, automatisk innmating (og utmating) av kapsler, registrering/gjenkjenning av kaffekopp og en app med informasjon om kaffepreferanse. Og hvor er vi nå?

Ansiktsgjenkjenningen har bydd på flere utfordringer. Blant annet har lyssetting vært et stort problem. Bildene av personene som openCV bruker til ansiktsgjenkjennings-delen burde bli tatt i samme rom/lys som kaffemaskinen skal stå i. Takket være et par scripts vil det ikke ta lange tiden å få lagret nye personer i databasen, og vi kan dermed få testet flere omgivelser og lyssettinger fortløpende. I tillegg har ansiktsgjenkjenningen hatt for lav nøyaktighet og pålitelighet. Vi har fått den til å fungere når den tar for seg en person, men å sjekke flere personer har vært problematisk. I det siste har dette blitt mye bedre, og Raspberry Pi B har blitt byttet til Raspberry Pi3, noe som gir positivt utslag i forhold til deteksjonen.

Når det gjelder kapselstativet, altså innmating/utmating av kapsler, jobbes det med å få det til å snurre rundt som ønsket og med å holde kapslene på plass. Vi har kjøpt inn PVC-rør som skal brukes som aksling og et hjullager som skal inn på PVC-røret, disse skal rotere ved hjelp av en motor, som igjen beveger kapselstativet vårt. I tillegg skal det brukes fjærer i konstruksjonen, en fjær er et maskinelt element som kan ta opp store elastiske formforandringer. Fjærene, som er i karbonstål med sinkbelegg, skal føre en maskindel tilbake til en bestemt stilling og holde den der, slik at kapslene ikke detter ut når kaffemaskinen ikke er i bruk. For å finne egenskapene til fjærene har vi brukt en nettside som beregner alle parameteren knyttet til en kompresjonsfjær, fra enkel geometri og material data. Nettsiden heter www.efunda.com.

fjaer

Bilde 1: Viser hvor man skal måle

karbonstal

Bilde2: Karbonstål har en tetthet på 7850 kg/m3, Poisson ratio 0,27-0,3 og elastisk modulus 190-210 GPa

resultat-fjaer

Bilde 3: Resultater til 5×20 fjær fra nettsiden Efunda

 

Etter at delene til kapselholderen ble printet ser vi at fjæra er litt større i diameter enn hullene de skal inn i. Vi hadde kjøpt fjærer på biltema med målene 5×20, men i virkeligheten er de altså 5,39×20. Dette må vi finne en løsning på; feks. Bruke en annen fjær eller korrigere den vi har slik at den passer. Vi har også fått motorene vi har ventet på. For å være sikre på at de kan fungere i prosjektet har vi gjort en undersøkelse av disse, hvor vi sjekket omtrentlig hastighet og kraft (da spesifikasjoner på et ark ikke alltid overbeviser oss). Det er tre motorer som henholdsvis skal brukes til å bevege kapselstativet, mate ut kapsel fra stativ og til å åpne en luke på kaffemaskinen slik at kapslene faller uhindret inn i maskinen. Sistnevnte har vi ikke helt klart for oss hvordan vi skal løse enda, men vi kommer til å jobbe med dette fremover. I tillegg har vi skaffet sensorer som er tenkt å bruke i sammenheng med motor, for å vite hvilken posisjon motoren har. Dette vil vi styre med en Arduino, vi er i gang med testing av dette nå. Det er også laget til ett tannhjul som skal brukes i kraftoverføring fra motor til kapselholder.

Nå er vi i gang med koppdeteksjonen! Vi bruker openCV og tester deteksjonen med kamera. Den første haar- cascade filen fungerte ikke som ønsket. Det kan henge sammen med hvordan bildene av koppen ble tatt eller at det var for få negative bilder. Vi fortsetter å jobbe med saken. Målet fremover er å få til godt over tredve nye bilder, beskjære dem og lage en ny haar- cascade fil. Vi krysser fingrene for at den vil fungere som ønsket.

Og nest sist, men ikke minst… APP-en. Her har vi kommet godt på vei. Det er satt opp en innloggingsside, og en registreringsside hvor man må oppgi brukernavn og passord. Neste på planen var å opprette en database for å holde på informasjonen. Dessverre fungerte den ikke som den skulle. Vi foretok feilsøk i Android Studio prosjektet og i PHP- filene for registering og innloggingsfunksjonene. PHP- filen skal være feilfri, men likevel får vi ikke lagret i databasen. Dette skaper helt klart forvirring! Vi har derfor sett endel på hvordan menyen skal se ut etter innlogging, det reduserer annet arbeid når problemet med databasen er fikset. Og her går det fremover. Hovedmenyen for APP-en nærmer seg ferdig. Inntil videre har vi gjort det slik at man kan komme videre fra innloggingssiden uten brukernavn og passord, så får vi testet hvordan det ser ut på mobilen. La oss håpe at fremtiden inneholder langt mindre databasetrøbbel.

Til slutt vil vi nevne at vi har demontert to kaffemaskiner som er donert til oss. Dessverre fant vi ingen deler vi kunne bruke, vi donerte derfor to plastposer med deler videre til HSN.

demontering

Bilde 4: Deler fra demonterte kaffemaskiner

 

Vi har også utført strekktest av 3D-printet materiale!

extensometer

Bilde 5: Extensometer

strekktest

Bilde 6: En av strekktestene som er utført

 

Ses snart igjen!