Portfolio aflevering 2
Hardware og Robotteknologi
Vejledere:
Bente Charlotte Weigelin & Jacob Nielsen
Gruppe:
Eva K. Nøhr Larsen, Jens H. Jakobsen, Nickolai Petersen.

Introduktion

De hjemme automations problemstillinger vi har valgt:

Illustration 1 – Smarthome


I Portefølje-2 opgaven skulle der findes problemstillinger, som kunne løses ved hjælp af automation. Gruppen var særlig opmærksom på ordet “problemstillinger”. Det betød at systemet som skulle laves kunne løse en række problemer, der tilsammen har en central hændelse og dermed binder dem sammen. 


Gruppen blev enige om at skabe et system, som kunne hjælpe en bruger igennem en dagligdag med minimal indflydelse. Ud fra denne idé skabte vi “J.A.R.V.I.S”.

“J.A.R.V.I.S” eller “Just A Rather Very Intelligent System ” er en simulering af et komplet intelligent hjem med fire fokusområder, taget ud fra ovenstående samtale i gruppen. De fire fokusområder blev fundet ved at kigge på hvilke punkter alle i gruppen havde til fælles, i en dagligdag, fra morgen til aften. Den første problemstilling var styringen af gardiner, ud fra hvornår solen står op og går ned. Her kom vi frem til automatiske gardiner som selv ruller op/ned alt efter om det er mørkt/lyst udenfor. Derudover blev automatisk styring af temperatur sat på som endnu et system, som især er et problem om sommeren. En blæser skulle derfor skulle kunne starte hvis der er mere end 22C i huset. En bevægelsessensor som tænder lyset ved bevægelse. Dette ville fjerne problemet i at skulle lede efter en kontakt, hvis man eksempelvis kom sent hjem. En lås som åbnes med nøglebrik, som automatisk låser døren hvis man glemmer dette og som har ekstra feature ved at kunne låses med en remotecontrol og lave den kendte “bip-bip” lyd, som man kender fra sin  bil, når man slår centrallåsen til med sin fjernbetjente bilnøgle.

Disse features blev delt op i følgende problemstillinger samt de elementer, som skal bruges til at bygge dem:

Dagslys og Gardiner
Gardinerne er bliver styret af en DC motor som kan åben og lukke gardinet. Dette system bruger en photoresister, som vil registrere lysindfaldet på huset der simulerer dagens gang.

Blæser
Der er monteret en temperatursensor som vil registrere hvorvidt om en bestemt temperatur er overstreget og hvis dette er tilfældet, starte en DC motor med en monteret blæser. 

Bevægelsessensorer og lys
Der vil være monteret bevægelsessensorer i form af en PIR sensor på alle tre etager af huset som vil sikre at der altid er lys hvor der er bevægelse.

Dør/briklås
Døren kan kun låses op med en nøglebrik både indvendig og udvendig derudover er der monteret en afstandssensorer som vil registrere hvorvidt om du har låst døren når du går ind i huset og vil låse døren automatisk. Låsen selv vil blive styret af en Servo motor. 

Main Control Center
Hvor inputs skal kunne ses af brugerne via en LCD skærm, samt mulighed for at man skal kunne styre systemet manuelt med en fjernbetjening. 

Step By Step Guide til Projektet

Tjekliste over ting som skal bruges.

Liste over de elementer du skal bruge fra det komplette arduino starter kit :

  • 1 x arduino Controller Board
  • 1x Servo motor
  • 1x RFID Modul
  • 1x Passive Buzzer
  • 1x Ultrasonic Sensor
  • 1x PIR Motion Sensor
  • 4x White LED
  • 1x Temperature and Humidity module
  • 1x 3-6 DC motor
  • 1x L293D h-bro
  • 1x Photo Resistor
  • 1x LCD modul
  • 1x IR Receiver
  • 1x Remote

Udover tilkøb til projektet

  • 1x arduino Controller Board
  • 2x PIR Motion Sensor
  • 1x 3-6 DC motor

Planen

Lav en plan over sammenkoblinger

Lav en overordnet plan over hvad der skal styres, hvad der er input og output. Sæt gerne det hele i skema så der kan dannes et overblik. Tegn gerne det hele ind i TinkerCad eller Fritzling. På denne måde får man styr på sine prioteter, rækkefølge og inputsmuligheder på arduinoerne. Vi tegnede i begge programmer men efter at udvide Fritzing med Elegoo- pakken, er det de tegninger som er mest komplette. 

Illustration 2 – Opdelingsskema af Input/Output

Illustration 3 – Kredsløb kort

En eller to arduinoer -og hvordan?

Til dette projekt har vi lavet et “Master/Slave”forhold mellem de to arduino boards. Hvilket  betyder at den ene af de to arduinoer som sender alle beslutningerne er “Master” og den anden tager imod alle beslutningerne er “Slave”. Se illustration som viser hvordan man forbinder de to arduinoer nedenfor.

Illustration 4 -Master/Slave

Udover at systemet kører et master/slave forhold opdelte vi de to arduinoer op mellem input og output, på denne måde stod masteren for alle input. Dette giver god mening da “Master” modtager inputs og laver en vurdering (en logik) og sender vurdering over til “Slaven”, hvorefter “Slaven” starter/tænder/slukker output enhederne.

Illustration 5 – Første Sammenkobling

Sammenkoble alle enheder efter din plan.

“Divide and conquer” har været et gennemgående tema. Tilslutning kræver at man kan holde tungen lige i munden, men er man omhyggelig og følger sin plan til punkt og prikke lykkes det til sidst at tilslutte alle komponenter til de to arduinoer.  Man kan med fordel opdele de to arduinoer på to breadboards i form af:

Master = Input
Slave = Output.

Dette gør det nemmere at bibeholde overblikket.

Programmeringens Tre Faser

For lettere at kunne forklare hvordan programmeringen finder sted, er dette afsnit delt op i tre underemner som fortæller om masterens inputs, slavens outputs og til sidst om kommunikationen imellem de to.

Fase 1. Arduino-Master og Inputs

På denne enhed arbejder vi med med en arduino (Master) hvortil der er tilsluttet:

  • 1x RFID Modul
  • 1x Ultrasonic Sensor
  • 3x PIR Motion Sensor
  • 1x Temperature and Humidity module
  • 1x Photo Resistor
  • 1x IR Receiver + Remote

Inputs på en styreenhed er afgørende for hvor mange ting systemet “ved” og man derefter kan handle ud fra. I dette projekt arbejde vi med to input områder (sikkerhed og bekvemmelighed).

Døren – Sikkerhed 


Døren har et adgangssystem bestående af en (1x RFID Modul) også kaldet en nøglebrik som skal registrerer brugerens adgang.

Koden læser det input der fortæller hvorvidt om den rigtige nøglebrik er blevet benyttet eller ej. Er der ændringer vil state.Laas skifte værdi og Slaven sætter låsen til det der passer.

Kodeeksempel 1 – Kortlæser

Automatisk Lås. – Sikkerhed 

Når brugeren har fået adgang til huset og er gået ind sidder der er en Ultrasonic Sensor og registre at personen er nået et punkt inde i huset for så at sende besked om at døren skal låse.

Kodeeksempel 2 – Afstandsmåler

OBS. Da man blot kan sætte en funktion ind i koden som automatisk låser døren igen, når den har været åben efter 1 min ca -Samt at vi ikke har kunnet finde ud af hvor og hvordan vi skulle placere den soniske afstandssensor i pap-huset og implementeringen i koden, måler den kun en værdi og sender denne til SerialMonitor.

Lys – Sikkerhed/Bekvemmelighed 

På alle tre etager af ejendommen er der monteret 1x PIR Motion Sensor de har til opgave at registrere bevægelse af to grunde. Er bygning i tilstande ”state.Alarm == til” skal dette fungere som alarmsystem. 

Er bygning i tilstand ”state.Alarm == fra” skal det fungere som energibesparende i forhold til lyset automatisk slukker.

Kodeeksempel 3 – Pir Logik

Temperatur – Bekvemmelighed

På siden af husets er der monteret “Temperature and Humidity module” som arbejder sammen med blæseren. Hvis funktion er at køle huset ned. Koden har to stadier; tempereret og for varmt.

Kodeeksempel 4 – Temperatur

Lysindfald – Bekvemmelighed 

Huset er udstyret med en Photo Resistor som hjælper til med at fortælle systemet, om det er nat eller dag. Om dagen skal gardiner gå op og er det nat, skal de gå ned. 

Kodeeksempel 5 – Photoresistor

Remote Control – Bekvemmelighed

Stort set hele husets output system er sat op til at kunne styres manuelt med en fjernbetjening, de vil “overrule” -eller slå de automatiserede funktioner fra, så brugeren kan indstille gardin, lys og blæser efter behov.

Automatiseringen af huset sættes til igen ved tryk på “0”.

Kodeeksempel 6 – Remotecontrol

Dette er et kode udsnit der viser registrering af tryk på remotecontrol og en enkelt funktion der slår slå alarmen fra. 

Op og ned knapperne ruller gardinet op eller ned, vol + tænder blæser og vol- slukker. Derudover kan alle lys tændes og slukkes på hhv knap 1, 2 eller 3.

 Illustration 6 – Remote + IR-receiver 

Fase 2. Arduino Slave og Outputs

På denne enhed arbejder vi med med en arduino (Slave) hvortil der er tilsluttet: 

  • 1x Passive Buzzer
  • 4x White LED
  • 2x 3-6 DC motor
  • 1x L293D h-bro
  • 1x LCD modul
  • 1x Servomotor

Buzzeren/Alarmen

Den Passive Buzzer har to funktioner.

  1. Fungerere som alarm

I tilfælde af at bevægelsessensorer viser tegn på bevægelse under stadiet ”state.Laas  == til” skal Buzzeren reagere med en alarm lyd (ALARM).

  1. LÅST/ÅBEN Tilstand

Når du benytter nøglebrik eller remote control til at åbne eller låse huset, skal lyden indikere brugeren at handling er udført.

Kodeeksempel 7 – Alarmsystem

Kodeeksempel 8 – Alarm Lyd

Lys

Lysets har to funktioner i dette smarthome. Den første funktion er belysning på alle tre etager og den anden er med et sammenspil med buzzeren for at indikere at alarmen er til. 

Kodeeksempel 9 – Lys logik

Motor 1 – RulleGardin

Rullegardinets motor reagerer efter at photo resistorens indikation og rulle gardinet op eller ned efter behov, men som udgangspunkt om det er nat eller dag. For at det kan lade sig gøre skal motoren kunne køre i begge retninger og derfor har vi benyttet en H-bro løsning, som har den fordel udover at kunne styre to motorer på samme tid også kan styre hvilken retning strømmen skal komme fra og på den måde os styre om motoren køre urets retning eller mod urets retning. 

Kodeeksempel 10 – Gardin logik

Motor 2 – Blæseren/Fan

Blæseren i huset fungere som husets kølersystem. Når Temperature and Humidity module vurdere at huset er overophedet bliver der sendt en besked til Slaven om at starte motoren via H-Broen.

Kodeeksempel 11 – Gardin logik

LCD Skærmen

LCD skærmens funktion er den primære kommunikation til brugeren der skal fortælle hvilket stadie huset er i.

Kodeeksempel 12 Temperature state
Kodeeksempel 13 LCD Humidity state
Kodeeksempel 14 Day/Night time State

Dette er kort udsnit af koden som fortæller brugeren hvorvidt om det er nat eller dag.

Displayet viser tre stadier den looper igennem; temperatur, humidity og til sidst hvilken tid vi er på dagen.


Fase 3. Kommunikation imellem

Kommunikation mellem de to enheder bliver sendt som en struct og kun i det omfang at der er sket en ændring. Når der sker en ændring på en af masterens inputs enheder, som er definerede “Game Changers” bliver der sat en ny værdi på denne struct. Structen bliver derefte sendt til Slaven som aflæser og reagere.

struct State {
  float Temperature;
  float Humidity;
  AlarmState Alarm;
  bool Laas;
  bool Gardin;
  bool LysStue;
  bool LysEtage1;
  bool LysEtage2;
  bool Fan;
  bool Night;
};

På master deklareres både staten og “oldState”, de sammenlignes og når de to ikke er ens mere sendes Staten til Slaven og denne State bliver derefter til en ny “oldState” -som så sammenlignes med state og sådan køres der hele tiden i ring.

På Slave modtages State fra Master, så oprettes en lokal “newState”. Beskeden fra Master læses ind i “newState”, herefter sammenlignes de og hvis der pludselig er en “newState” som ikke er ens med state, så udføres den handling som er sat dertil. 


Rammen For Projektet

For at danne ramme for projektet valgte vi i dette tilfælde at tage brug i et dukkehus af pap. Mest fordi det er nemt at simulere et hus og det at materialet er af pap gør det nemt at skære til og omrokere sider, vinduer osv. (Ingen børn har lidt overlast ved at få ødelagt et pap-dukkehus).

Illustration 7 – Kreative materiale

Opbygning af hardware – fra TinkerCad/Fritzing

Herunder kommer beskrivelser af selve hardware opbygningen. Da den er lettere indviklet er den meget kort vist og beskrevet.

Kredsløbsdiagrammer!

I starten havde vi to tegninger -en i TinkerCad som kunne ikke kunne implementerer RFID systemet -og Fritzing der ikke kunne implementerer remoten…

Indtil vi fandt ud af at Elegoo har en pakke med deres komponenter til Fritzing -og derfra kunne vi få alle komponenter ind i en tegning! 

Kodeeksempel 8 – Schematic overview
Kodeeksempel 9 – Kredsløbs overview

Beskrive hvorfor og hvordan i har valgt at lave de enkelte løsninger.

Først tænkte vi kun på hvad vi ville lave. Vi tog ingen hensyn til om vi kunne bygge den løsning vi havde i tankerne. Det her har vi jo aldrig prøvet før, så det kan vi sikkert sagtens!

Så fandt vi ud af at der manglede porte. Derefter fandt vi ud af at nogle ting ikke kan sidde i fx. port 0 eller andre steder da nogle af Elegoo’s ting er specificeret bestemte porte.

Vi fik dobbelttjekket om porte er analoge eller digitale og om det er nødvendigt med PVM på de digitale porte. 

Vi fik dog afskrevet de fysiske knapper til kun at involvere remoten -og har dermed brugt alle porte på de 2 arduinoer.


Opbygning af program 

Kodeeksempel 10 – Flowdiagram

For generelt at beskrive hvordan systemet fungerer, kan man ud fra ovenstående billede se at vi har gjort brug af to arduinoer der er blevet delt som Master og Slave.

Master Arduino styrer logikken og har sensorerne med inputs.

Kommunikationen mellem de to arduinoer foregår sådan at Master tjekker om der er sket ændringer i “State” -er der det, sendes beskeden til Slave over I2C Wire kommunikation. 

Kodeeksempel 15 – State ændring 

Når Slave modtager en besked, laves en lokal newState State, hvor den nye state kopieres ind i. Så sammenlignes hver State og derudfra tændes/slukkes de forskellige aktuatorer ud fra hver deres givne muligheder.

Kodeeksempel 16 – Sending State Info

Funktioner

Herunder forklares funktionerne i hhv. Master og Slave, hvor det nærmere forklares hvad de to gør.

Det er stort set pseudokoden til de to Arduino programmer.

Master

Inkluder 7 biblioteker.
#definer temp/Hum, afstandssensor, PIR system, IR Remote og RFID nøglekortlæser.
Sætter og deklarerer forskellige parametre.
Enum AlarmState.
Tidsintervaller til forskellige forsinkelser. (fx. skal lyset først slukke efter 20 sek uden bevægelse)
Automatik
Struct State

Aflæser Hum & Temp hvert 3. sekund.
Aflæser Afstand hvert 0,2. sek
Hvert 1,5 sek aflæses om IR receiver har modtaget signal
	Hvis den har:
{
Power -> Lås = true.
Op ->  Gardin = false.*   		*)Ved tryk på knap med kursiv, 
Ned -> Gardin = true.			slås automatisk tilstand fra.
Vol+ -> Fan = true.
Vol- -> Fan = false.
1-3 -> Lampe 1-3 = true else false.
0 -> Slår automatisk tilstand til 
}
TranslateIR -oversætter digitale tal til fx “Power” 
Aflæser hvert sekund om RFID chippen er tæt på
	Er den det:
		{Tjek om det er den rigtige brik og giv adgang, hvis rigtig brik}
Send besked til Slave ved ændringer
Setup starter Pir, RFID, Remote og Wire.
Loop tjekker lyssensor om det er nat, 
hvis gardinet er automatisk vil det rulle ned ved nat, 
tjekker temperatur og om blæseren skal tændes. 
Måler afstand, 
tjekker PIR systemet og tænder lyset hvis der er bevægelse 
-er der bevægelse og døren låst startes alarm.
Er det automatisk tilstand, slukkes lyset efter 20 sek uden bevægelse.

Til slut i loop kaldes Remotes signaler, RFID signaler, print til SerialMonitor og Send til Slave.

Slave

Inkluder 3 bibloteker
#definer motor 1 & 2.
Enum AlarmState
Sætter og deklarerer
	lås, 
lys, 
display og 
buzzer.
Melodier
StructState

Display opdateres hvert 3. sek
Definerer de tre ikoner.

Update Display skifter hvert 3. sekund til næste “array”.

RecieveEvent modtager beskeden fra Master
hvis ændret så
{tænd/sluk lys
åben/luk lås + melodi
afspil melodi ved alarm
tænd + eller - til Gardin motor
tænd/sluk blæser.
} 
Så kopieres newState til state

Setup starter Wire kommunikation, lys, lås, LCD display samt de tre symboler til display.
Loop har det tidsinterval som gør længden af en tone, samt en gardinTimeout der stanser gardinets motor efter 0,3 sek.

Prioriteringer

Vores prioriteringer er få, men i de to følgende afsnit fortælles om de dele der har haft indflydelse på både programmets prioritering i læsning af koden, samt det at en remote skal kunne “overrule” det automatiske system.

Delay() vs. millis().  

Meget tidligt i projektet finder vi ud af at delay absolut ikke er optimalt.

Et delay pauser hele programmet i de millisekunder en parameter definerer.

Millis() på den anden side er en funktion som returnerer det antal millisekunder der er gået siden programmets start.

Dette giver en mere akkurat timing og man sikre også at loopet kan køre så tit vi vil, hvorimod man ikke ved hvor lang tid loopet vil tage, når man bruger delay.

Hvordan remote overruler det automatiske system

Der er lavet forskellige boolske automations-stadier som bruges til gardin, blæser og lys. Når der så registreres tryk på de knapper der styrer blæser, lys og gardin sættes det automatiske-stadie til falsk. Nu vil de tre dele så blive i et ikke-automatisk-stadie, da alle de automatiske funktioner kræver at det automatiske stadie er sandt.

Opbygning af den samlede fysiske prototype

Herunder beskrevet hvordan det samlede udtryk er. Der er i Links et video link til youtube hvor man kan se det samlede produkt i aktion.

Hvordan er samspillet mellem mekanik, elektronik og software?

Samspillet fungerer rigtig godt! Når alt koden er opdateret -fx de rigtige ben i virkeligheden og i koden, fungerer den fysiske prototype generelt godt. Det har for alle gruppemedlemmer været spændende og lærerigt at få det hele til at gå op i en højere enhed.


Konklusion

Hvor godt løser jeres løsning de oprindelige problemstillinger?

Denne Portefølje opgave, gik ud på at lave et automatisering af hjemmet. Dette besluttede gruppen som skulle løses ved hjælp af flere systemer, som hver skulle løse deres egen problemstilling, men som samlet skulle kunne løse scenariet, “Dagligdag”.

Photosensor og Gardinets funktion starter scenarie, ved at brugeren står op, med åbent Gardin. Som brugeren går gennem huset vil lyset tænde automatisk. Brugeren skal ikke længere tænke over at tænde/slukke lys når han/hun går gennem huset. Brugeren forlader huset og kan let åbne og låse huset med sin personlige låsenøgle og Remote. Om brugeren er hjemme eller ej, holder blæseren og temperatursensoren, temperaturen nede på et behageligt niveau. Hjemmet er sikret med et alarmsystem, som tænder for en alarmen, hvis brugeren ikke er kommet hjem og bevægelses sensor bliver aktiveret. Når brugeren kommer hjem, er det let at låse op med sin nøglebrik og deaktivere alarmen. Når mørket falder, ruller gardinerne automatisk ned igen. 

Samlet løser disse enkelte elementer det scenarie “dagligdag”. Brugeren kan komme fra seng til dør, og fra dør til seng igen, med minimum indflydelse på hverken husets sikkerhed og eller indeklima.

Med de rette indstillinger gennem ardoinoerne og deres Master/Slave system, løser J.A.R.V.I.S opgaven at holde styr på elementerne. Master/Slave systemet gjorde det mulig at kunne opdele opgaverne i yderligere 2 dele i form af inputs og outputs. Dette gjorde at der var mere styr på koden, kontrol over systemet og at scripte kunne samarbejde, uanset hvilke elementer der kommunikerede.

Ideen om at løse portefølje opgaven ud fra gruppens erfaringer fra dagligdagen, gjorde ikke bare at gruppen kunne finde mange forskellige scenarier, som kunne løse opgaven, men også løse den med relevante problemformuleringer og løsninger, som gruppens egne medlemmer oplevede i deres daglig.

Perspektivering

Hvad kan man gøre for at gøre den bedre?

En videreudvikling af projektet kunne være at flere elementer havde kontrol over lyset. Lyset i sin nuværende tilstand kan kun tænde og slukke ud fra PIR og Remote input. LED lysene i etagerne kunne derfor også blive influeret af alarmsystemet eksempelvis. Dette ville give en ekstra sikkerhed, da hele huset vil blive et stort larmende og lysende kaos, i tilfælde af indbrud. Når huset bliver låst af, kunne lysende også lyse op, ud fra lyden fra buzzeren. Dette ville skabe et sjov scenarie, men også give en klar besked til brugeren uden for, huset at huset nu er låst. Ideen bygger den måde at en bil kommunikere sine tilstande til en bruger. 

Afstandssensoren kunne optimeres ved at få den til at kommunikere med låsesystemet. I dens nuværende tilstand har afstandssensoren ikke andre funktioner end at måle en afstand og sende den enhed til monitoren. Den originale plan og dermed også noget vi kunne have implementere bedre, ville være at bruge afstandssensoren til at opfange en værdi som indikerer at brugeren er kommer hjem. Går man længere ind i huset, uden at låse døren, vil systemet undgå at brugeren har glemt at låse og låser døren automatisk.

Der er sikkert mange flere små opdateringer som kan forbedre “J.A.R.V.IS” og netop også derfor er det blot version 0.01.


Links; 

Youtube Link til Projekt præsentationen:


Master/Slave forholdet mellem to arduinoer:
https://www.arduino.cc/en/Tutorial/LibraryExamples/MasterWriter

Omkring Struct
https://www.ibm.com/docs/en/zos/2.2.0?topic=types-structures-unions

Leave a Reply