Automatisk varmeregulering

Transkript

1 1 Automatisk varmeregulering Temperaturmåling vha. Arduino Informationsteknologi B Programmering C Eksamen 2010 I forbindelse med fagene Informationsteknologi B og Programmering C, er et eksamensprojekt med valgfrit emne blevet udstedt. I denne forbindelse har vi dannet en gruppe bestående af Nikki Mitchell og Jacob Thuesen. Vi har valgt at fokusere på unødigt energiforbrug forsaget af manuelt regulerbare varmeapparater, såsom radiatorer. Som løsning på dette problem har vi designet en løsning bestående af et system, som automatisk kan regulere varmen. Vi har brugt Arduino til at design prototypen af vores løsning. Vi har I løbet af dette projekt fået dokumenteret processen frem til vores produkt. Produktet endte efter nogle komplikationer med at indeholde en temperatursensor og et LCD-display, der viser målingerne. Derudover fik vi, for at gøre projektet mere fyldestgørende, redegjort for hvorledes systemet kunne udvide med en stepmotor og en RFIDlæser, for at tilføje elementer af automatisering, samtidig med et strejf af brugerstyring. Vi mener at have opfyldt de stillede krav, og fundet en løsning med et tilfredsstillende resultat. Det endelige resultat blev desuden vurderet i forhold til brugbarhed og fundet særdeles brugbart på baggrund af den store automatisering, som produktet vil indeholde. Som grundlag for produktet ligger en række grundige overvejelser og analyser der omhandler generelt problem, målgruppe, resurseplanlægning, budget mm. Jacob Thuesen & Nikki H. Mitchell Klasse 3.3i Roskilde Tekniske Gymnasium Lærer: Karl G. Bjarnason 20. Maj 2010

2 2 Indhold Indledning... 4 Problemanalyse... 5 Definition af problemstilling... 5 Målgruppeanalyse... 6 Problemformulering... 7 Krav... 8 Generelle krav... 8 Målgruppedefinerede krav... 8 Løsningsfase... 9 Løsningsforslag... 9 Sammenligning og valg af løsning Specifikation af løsning Uddybende forklaring Case-diagram User interface Valg af værktøjer Resurseplan Budget Teori Arduino Dataopsamling Produktfase Første prototype Krav- og testspecifikation Design Implementering Kalibrering Test Anden prototype Krav- og testspecifikation Design Implementering... 22

3 3 Test Prototype Krav- og testspecifikation Design Implementering Test Fjerde prototype Krav- og testspecifikation Design Implementering Test Visualisering af temperatur Samlet beskrivelse af den endelige prototype Konklusion Evaluering Kildeliste Bilag Bilag 2 Uformel spørgeundersøgelse Bilag 3 - Kildekode til endelig prototype... 38

4 4 Indledning I forbindelse med fagene Informationsteknologi B og Programmering C, er et eksamensprojekt med valgfrit emne blevet udstedt. I denne forbindelse har vi dannet en gruppe bestående af Nikki Mitchell og Jacob Thuesen. Vi har valgt at fokusere på unødigt energiforbrug forsaget af manuelt regulerbare varmeapparater, såsom radiatorer. Som løsning på dette problem har vi designet en løsning bestående af et system, som automatisk kan regulere varmen. Vi har brugt Arduino til at design prototypen af vores løsning.

5 5 Problemanalyse Definition af problemstilling Der findes uendeligt mange problemer i verden i dag, og der er næsten ingen grænser for, hvad der kan forbedres på. Der er imidlertid nogle problematikker, som er mere aktuelle end andre. En af disse problematikker er energi. Energiforbruget er generelt for højt, og dette er problematisk i flere henseender. Dels kommer meget af energien i dag fra fossile brændstoffer, og et højt energiforbrug betyder derfor både, at vi forbruger vores resurser hurtigere, men også at vi forurener i højere grad. Et andet aspekt er, at prisen på energi bliver højere og højere, og et højt energiforbrug betyder derfor større udgifter. Vi har altså et overordnet problem, nemlig at vi bruger for meget energi. Løsningen på dette er i og for sig ganske simpel: skær ned på energiforbruget. Dette er imidlertid ikke så nemt, da en nedskæring i vores energiforbrug ofte vil betyde, at vi skal leve på en anden og mindre vestlig-luksuriøs måde. Det vil derfor være at foretrække, hvis en reduktion af energiforbruget kunne ske på en sådan måde, at vi ikke behøver at lægge vores livsstil om. Vi skal derfor kigge på den del af energiforbruget, der ikke er en nødvendighed for at vi kan leve som vi gør. Vi skal kigge på det unødige energiforbrug, og derved på energispild. Et sted hvor der bruges unødig energi er i vores huse. I en artikel 1 publiceret 18/12-08 på ing.dk (ingeniøren), kan man læse følgende: 40 procent af landet energiforbrug siver nemlig ud fra de danske bygninger. Det forventes, at 80 procent af dette energitab kan spares ved hjælp af nye teknologier inden for de nærmeste 40 år. Dette bekræftes af en artikel 2 på bygger.dk. Vi har altså et reelt problem vedrørende vores boliger, og her er der plads og mulighed for forbedring. Kigger vi på opvarmningen af vores huse ser vi, at det ofte er radiatorer og gulvvarme der står for denne. Disse er ofte indrettet således, at man manuelt skal indstille varmeintensiteten. Det vil da ikke være unormalt, at man sætter radiatoren/gulvvarmen til et bestemt niveau, og lader den stå der (Dette bekræftede vi igennem en uformel spørgeundersøgelse, se bilag 2). Bliver det så for varmt, kan man jo blot åbne vinduet og lukke varmen ud. Denne metode er bestemt ikke optimal, når man ønsker at spare på energien. Vi har da et eksempel på unødig energiforbrug. Vi har altså et konkret problem vedr. opvarmning af boliger. Det konkrete problem vi har valgt at arbejde med kan således indsnævres til at omhandle unødigt energiforbrug forsaget af manuelt regulerbare varmeapparater

6 6 Målgruppeanalyse Meget overordnet set, må vores målgruppe være alle boligejere, hvis bolig opvarmes af manuelt regulerbare varmeapparater. Dette er dog for bredt, så vi vil indsnævre målgruppen. Dels giver dette mulighed for, at udforme målgruppespecificerede krav til løsningen, dels ville de give mulighed for mere målrettet markedsføring af løsningen, hvis dette skulle distribueres. Vi indsnævrer målgruppen herunder. Udgangspunkter er, at løsningen er et produkt, en anordning, et indgreb etc. som vil mindske unødigt energiforbrug skabt af manuelt regulerbare varmeapparater: Vores målgruppe skal være boligejere, som er interesserede i at begrænse deres energiforbrug. Dette kan være fordi de ønsker at være gode ved miljøet, eller blot fordi de ønsker at spare penge. Da ønsket om at spare penge ved at nedbringe unødigt forbrug ikke just kan kaldes en målgruppeindsnævrende faktor, vælger vi at se bort fra denne. Vi fokuserer i stedet på det idealistiske initiativ, der kan ligge bag ønsket om at spare på energien. Individerne i vores målgruppe er således mennesker med omtanke for miljøet. Selvom vores løsning kan hjælpe folk til at spare penge, koster den stadig noget at anskaffe. Vores målgruppe skal derfor have et vist økonomisk overskud til denne investering. Målgruppens individer er altså mennesker med en vis kapital. Vores løsning vil være en investering, som vil spare forbrugeren penge løbende, og er således en investering i fremtiden. Dette betyder, at vores målgruppe vil være mennesker, der sidder i en bolig som de har planer om at sidde i lang tid endnu. På baggrund af overstående definerer vi vores målgruppe som boligejere i alderen år, der er i et parforhold og har fået de børn de nu engang ønsker at få. Den familiære status kommer i kølvandet på den del af indsnævringen, der dikterer at målgruppens individer skal være mennesker, der har planer om at blive i deres bolig mange år frem i tiden. Både det at finde en partner eller at få flere børn kan udløse et boligskift. Vi indsnævrer yderligere ved brug af Minerva modellen 3, hvori vi placere vores målgruppe i det grønne segment. Dette gøres på baggrund af, at vi definerede individerne som miljøengagerede mennesker, der også rådede og en vis kapital. Vi skal altså rette vores produktudvikling mod boligejere år fra det grønne segment, som er i et fast parforhold, hvor der ikke kommer flere born til. 3

7 7 Problemformulering Opvarmning af boliger sker ofte ved brug af manuelt regulerbare instanser (radiatorer, gulvvarme mm.). Dette betyder, at hvis mængden af energi brugt på at opvarme et givent rum til en given temperatur skulle være minimal, så ville man være nødt til at regulere på varmeapparaterne hele tiden. Dette er en urealistisk tanke (at man manuelt skal regulere hele tiden, hvilket vores undersøgelse bekræftede), og resultatet er et unødigt overforbrug af energi.

8 8 Krav Herunder definerer vi nogle krav til vores løsning. Disse krav er opdelt i generelle krav, og målgruppedefinerede krav (user stories). Generelle krav De generelle krav er helt essentielle for løsningen. Opfyldes disse ikke, er løsningen ikke brugbar. Løsningen skal reducere eller helt fjerne det energispild, som i dag forsages af manuelt regulerbare varmeapparater Produktion samt distribution af løsningen må ikke koste mere energi, end løsningen kan spare igennem dens levetid (der skal være en positiv balance i løsningens miljøbelastningsprofil) Målgruppedefinerede krav De målgruppedefinerede krav er baseret på user stories. Disse er ikke essentielle for løsningen, så alle kravene skal ikke nødvendigvis være opfyldt. Det er dog fordelagtigt at opfylde så mange af dem som muligt, da de har betydning for hvor godt løsningen rammer målgruppens ønsker. Løsningen fungerer uden brugerens regelmæssige indblanding. Brugeren har mulighed for at tilpasse løsningen specifikt efter egne behov. Implementeringensprocessen af løsningen er ikke for ekstrem for brugeren. Brugeren kan anskaffe sig løsningen for en pengesum, der er indtjent igen igennem løsningens energibesparende (og derved pengebesparende) effekt indenfor for en rimelig tidshorisont.

9 9 Løsningsfase Løsningsforslag Vi har nu et konkret problem, en målgruppe samt en række krav. Det næste skridt er, at finde en løsning på problemet, som både passer til målgruppen og overholder kravene. Vi opstiller nu en række løsningsforlag: Mere isolering i ydervæggene En forøgelse af isoleringsmængden i en boligs ydermur. Anordning, der brænder affald af, og opvarmer huset derigennem. Brændbart, ikke genanvendeligt affald afbrændes, og varmen herfra brugs som et supplement til opvarmning af huset. System der automatisk kan regulere varmen Et system, der kan måle temperaturen, og ud fra denne tilpasse intensiteten af varmeapparater. System der opsamler data om varmeforbruget. Et dataopsamlingssystem, som kan indsamle informationer om varmeforbruget i de forskellige rum, og derved give brugeren guidelines til at formindske overforbruget. System, der kan informeres om, hvornår man ikke er hjemme. Et system, som brugeren kan aktivere når der ingen hjemme er. Således kan systemet slukke for al varme når huset står tomt. Brugeren kan ligeledes informere systemet om, hvornår der kommer folk i huset igen, således at systemet kan opvarme huset til første beboers hjemkomst.

10 10 Sammenligning og valg af løsning Herunder sammenligner vi løsningsforlagene, og vælger det bedste. Mere isolering i ydervæggene Anordning, der brænder affald af, og opvarmer huset derigennem. System der automatisk kan regulere varmen System der opsamler data om varmeforbruget. System, der kan informeres om, hvornår man ikke er hjemme. + mindsker energiforbruget der skal til at opvarme huset + kræver ingen interaktion fra brugerens side når løsningen først er implementeret - Meget dyr at implementere (hele ydervæggen skal ændres) - Meget besværlig at implementere - Ikke innovativ løsning + Udnytter affald - Afbrænding forurener - Gør formentlig ikke så stor energimæssig forskel - Ville kræve en del implementeringsarbejde + Kræver meget lidt interaktion fra brugerens side + Effektiv løsning på det reelle problem + Åbner god mulighed for videreudvikling (regulere andre ting end blot varme) + Forholdsvis simpel at implementere - Kan koste en del + Forholdsvis billigt + Forholdsvis simpel implementering - Kræver stor interaktion fra brugerens side - Formentlig ikke den mest effektive løsning + Simpelt system, let anvendeligt + Forholdsvis simpel implementering + Forholdsvist billigt - Kræver moderat interaktion fra brugerens side - Formentlig ikke den mest effektive løsning På baggrund af positive kontra negative sider, tager vi udgangspunkt i System der automatisk kan regulere varmen som vores primære løsningsforslag. Vi krydstjekker dog først med kravene, inden vi vælger løsningen endeligt: Krav Løsningen skal reducere eller helt fjerne det energispild, som i dag forsages af manuelt regulerbare varmeapparater Produktion samt distribution af løsningen må ikke koste mere energi, end løsningen kan spare igennem dens levetid (der skal være en positiv balance i løsningens miljøbelastningsprofil) Opfyldelsesgrad Opfyldt Opfyldt Da løsningen er implementeret fast, vil den spare penge hvert år. Til sidst vil dette nødvendigvis betyde, at den vil opfylde kravet.

11 11 Løsningen fungerer uden brugerens regelmæssige indblanding. Brugeren har mulighed for at tilpasse løsningen specifikt efter egne behov. Implementeringensprocessen af løsningen er ikke for ekstrem for brugeren. Brugeren kan anskaffe sig løsningen for en pengesum, der er indtjent igen igennem løsningens energibesparende (og derved pengebesparende) effekt indenfor for en rimelig tidshorisont. Opfyldt Kan Opfyldes Kan nemt implementeres som et ekstra aspekt Opfyldt (Opfyldt) Dette afhænger i høj grad af brugerens tidligere forbrug. Vi vurderer dog, at der er god mulighed for at dette krav kunne opfyldes. Vi vurderer, at denne løsning opfylder kravene med glimrende tilstrækkelighed, og vælger da den som vores løsning. Specifikation af løsning Uddybende forklaring Vores opstilling kan skitseres som følger: Apparatet justerer, på baggrund af en række inputs eller setpoints, temperaturen/styrken på varmekilden. Dette kan foregå eller i hvert fald vises ved hjælp af en stepmotor, som bevæger sig med et antal steps der vil få varmekilden til at sænke temperaturen til det ønskede. Apparatet kan i forvejen være indstillet til at holde temperaturen indenfor to setpoints. Når en beboer/bruger ønsker at ændre denne temperatur kan denne holde sit genkendelsesudstyr op foran sensoren, der herefter vil bede apparatet ændre temperaturen til den der er indkodet i genkendelsesudstyret.

12 12 Case-diagram Vi har udarbejdet følgende case-diagram over produktet: User interface Selvom vores løsning er baseret på automatisk regulering, så er det stadig nødvendigt for brugeren manuelt at kunne regulere på systemet. Ligeledes skal det være mulig for en reparatør at kunne komme til at undersøge den programmæssige del af løsningen. Userinterfacet kunne eventuelt være et lille panel med tilhørende skærm, som sidder på væggen i bryggerset, eller blot en virtuel indgang igennem en computer. Interfacet skal være simpelt, og skal som minimum have følgende funktioner: mulighed for at registrere bruger ID Mulighed for at knytte informationer til et givent bruger ID Mulighed for at reparere et eventuelt defekt system Interfacet skal selvfølgelig have et brugervenligt, og man ville med fordelagtighed kunne tage udgangspunkt i nogle af Bruce Tognazzinis 4 principper vedrørende design af user interface. Valg af værktøjer Til at lave vores løsning vælger vi at bruge med Arduinoplatformen, da denne uden de store komplikationer kan løse vores problem, samtidig med at vi i forvejen har kendskab til systemet. Derudover har vi næsten alle komponenterne til rådighed og skal derfor ikke anskaffe nye. Arduino giver en bred vifte af muligheder for at løse problemet. Genkendelsesudstyret og sensoren kan bestå af RFID chips og en læser der kan sende besked videre til Arduinoboardet. 4 Kilde:

13 13 Resurseplan Vi har lavet en tids-/resurseplan ved brug af programmet WinPlanner 5. Denne ses herunder: Budget Da det meste Arduinoudstyr allerede er tilgængeligt, vil det kun være nødvendigt at anskaffe en RFID-læser der kan kobles til Arduinoboardet. Denne vil anslået have en pris på omtrent kr. inkl. forsendelse. 5 Fra SourceForge

14 14 Teori I teoriafsnittet herunder vil teoretisk viden relevant for projektet blive beskrevet. Dette indebærer en beskrivelse af specifik teori vedrørende Arduinosystemet samt teori vedrørende dataopsamling (som er vores arbejdsmetode med Arduino) generelt. Arduino Arduino dækker over to ting, nemlig Arduinoplatformen (som kan ses ovenfor), samt Arduino softwaren. Platformen skal købes, men softwaren (Arduino IDE) er open-source (frit tilgængelig). Arduino kan, ved hjælp af forskellige former for sensorer, bruges til at opsamle fysiske data, som kan overføres til for eksempel en PC via softwaren. Man kan ligeledes skrive kommandoer i Arduino IDE en, som kan definere hvordan Arduinoplatformen skal agere. Arduionosystemet kan også bruges sammen med programmer som Processing, via hvilket man eksempelvis kan skabe et virtuelt visuelt output. Arduino viser tydeligt hvorledes rå hardware og software kan interagere med hinanden, og giver brugerne mulighed for at bestemme hvordan og hvorledes denne interaktion skal foregå, og hvad resultatet af den skal være. I forbindelse med vores Arduinoorienterede arbejde, bruger vi transducere og aktuatorer til at hjælpe os med dataopsamlingsprocessen. Transducere Transducere er komponenter der kan omdanne én form for information til en anden. Vi bruger transducere i forbindelse med dataopsamlingsprocessen, eksempelvis en temperatursensor, der kan omdanne værdien for temperaturen til et elektrisk signal, som så kan føres ind i computeren. Aktuatorer Aktuatorer er komponenter der modtager et signal, og på baggrund af dette udfører en mekanisk handling. Transduceren opsamler altså data, og hvis disse data har en eller flere givne værdier (defineret igennem softwaren af brugeren), vil aktuatoren reagere. Eksempelvis en blæser der aktiveres, hvis temperaturen bliver for høj.

15 15 Dataopsamling Herunder vil der være beskrivelser af begreber, som er relevante for dataopsamling generelt. Da dataopsamling er en væsentlig del af vores løsning (dataopsamling ved brug af Arduino), da er nedenstående begreber relevante for projektet. Begrebet dataopsamling dækker, som det hentydes af begrebets navn, over det at opsamle data. Det vil dog ofte være tilfældet, at man bruger begrebet til at henvise til hele dataopsamlingsprocessen, hvilket kan indebærer opsamlingen af data, lagring af data, bearbejdning af data, visualisering af data, ændring af eventuelle parametre på baggrund af data, etc. Signal Et signal er, i dette tilfælde, overførelsen af data fra ét sted (en sensor) til et andet. Signaler er altså data transporteret via en elektrisk strøm, en elektrisk spænding eller et elektromagnetisk felt. Støj Støj er en eller flere parametre der kan sløre det opsamlede data. Støj skaber således en (ofte) lille usikkerhed i det data man opfanger. A/D konvertering (ADC) A/D konvertering er konverteringen af analoge signaler, således at de bliver til digitale signaler. Et eksempel er konverteringen fra strøm eller spænding (analogt) til digitale værdier, som er proportionale med strømmen eller spændingens værdi. Successive approximation Dette dækker over, at man estimerer en ukendt værdi ved gentagne gange at sammenligne den med en række af kendte værdier, som kan indikere værdien af den ukendte parameter. Man kan således med stor nøjagtighed nærme sig den korrekte værdi. Sampling rate Definerer hvor ofte data bliver målt, altså hvor ofte der bliver aflæst en værdi af måleren. Resolution Dette definerer det opsamlede datas nøjagtighed. I vores prototyper er resolution lig 10 bit, altså kan værdierne der opsamles ligge mellem 0 og 1024.

16 16 Kalibrering Kalibrering handler om at omregne og omskrive dataværdierne, som transduceren opfanger, til en brugbar enhed. Det rå data en transducer på Arduinoplatformen opfanger, kan være en værdi imellem 0 og Hvis man måler temperatur, er en sådan værdi ikke videre brugbar. Man skal således finde ud af hvad en given værdi imellem 0 og 1024 svarer til i grader celsius. Dette gøres ved at få transduceren til at måle en værdi for temperaturen et sted, hvor man allerede kender temperaturen i grader celsius. Gøres dette flere gange med forskellige værdier, kan man til sidst finde sammenhængen imellem grader celsius og 10-bit værdier. Denne sammenhæng bør helst være lineær, da det gør omregningsprocessen simplest. Shannon og Weavers kommunikationsmodel Denne model er blevet kaldt the mother of all models, altså alle modellernes moder. Modellen kan hjælpe med at legemliggøre koncepterne bag ikke altid lige håndgribelige begreber, som ofte optræder i forbindelse med IT-orienteret kommunikation. Overstående er et eksempel på Shannon og Weavers kommunikationsmodel. Dette eksempel viser en korrespondance imellem to instanser. Dette kan både være imellem to mennesker, men det kan også være en legemliggørelse af interaktionen imellem to instanser i et system, eksempelvis et Arduinosystem.

17 17 Produktfase Første prototype Krav- og testspecifikation Ved vores første prototype ønsker vi, at: Temperatursensoren giver et output. Dette output kalibreres således at vi får værdierne givet i grader celsius (dette gøres i overensstemmelse med den tidligere forklaring af begrebet kalibrering). Dette vil give os en god start på projektet. Vi tester prototypens output ved, at benytte et termometer, og sammenligne dets værdi med Arduinoens, i en given situation. Design Vi benytter os af Arduinoboardet, Atmega328, og et tilhørende electronic brick chasis, med brick elementer. Herunder ses temperatursensoren: Denne er tilkoblet en analog indgang, da dens værdier er kontinuerligt variende - i modsætning til digitale, som oftest baseres på et til/fra princip. Implementering For at udarbejde prototypen har vi naturligvis benyttet Arduinoplatformen, og skrevet følgende kode: int Temp = 1; void setup() { pinmode(temp, INPUT); Serial.begin(9600); void loop() { int analogvalue = analogread(temp); Serial.println(analogValue, DEC); delay(1000); Først defineres hvor sensoren er placeret, i vores tilfælde ved indgang 1. Int (integer) er den primære datatype når man når man behandler tal.

18 18 void setup() køres én gang efter programstart, hvor void definerer datatypen (funktion). Under denne funktion definerer vi en række informationer, som bruges af programmet: pinmode() definerer hvorvidt indgangene fungerer som output eller input. Serial.begin() benyttes til kommunikation mellem Arduino og computeren. Værdien definerer hvilken hastighed datastrømmen skal ske ved (i bits/sekund (forkortet baud)). void loop() gentager en række hændelser, hvis disse er kodet ind i programmet. Giver altså løbende resultater af vores målinger. I dette loop gør vi følgende: Vi benytter igen integer til at definere en variabel, som aflæser den værdi temperatursensoren giver. analogread benyttes altså til at fremskaffe denne værdi fra sensoren. Serial.printIn() definerer hvad der skal vises på computer, i Arduinoplatformens Serial Monitor (her er det værdien fra sensoren der vises). delay() definerer med hvilken hastighed at ovenstående skal gentages. Værdien angives i millisekunder. Ved denne opstilling og kode får vi følgende resultat: Vi får altså et output, som viser en næsten konstant værdi, men dog er denne meget høj, hvilket naturligvis fortæller os at den ikke er i grader celsius. Vi må derfor selv foretage en kalibrering. Kalibrering Vi bliver derfor nødt til at finde en række sammenligningspunkter, hvorefter vi kan tjekke om forholdende er proportionale mellem den reelle temperatur og de værdier systemet giver os. For at finde disse punkter måler vi temperaturen med et termometer og noterer den tilsvarende værdi på temperaturmåleren. Vi fik følgende resultater: Målt med termometer ( o C) Målt med Arduino 25, , , , ,9 602

19 19 Med disse kan vi opstille en graf for at se om punkterne er tilnærmelsesvis lineære: R-værdien på over 0,99 viser os at linjen er godkendt, og derved kan vi opstille vores ligning som bliver følgende: Implementering fortsat Vi kan nu udfra vores kalibrering ændre vores kode, således at outputtet gives i grader celsius. Koden bliver således: int Temp = 1; Her har vi tilføjet en funktion, der ud fra vores kalibrering omregner værdien fra sensoren til grader celsius. Vi har benyttet følgende for at lave denne: double - en datatype der tillader decimaler. I Arduino fungerer den identisk med float. Vi har desuden ændret outputtet, så vi kun får én decimal på resultatet (jævnfør Serial.println). I Serial Monitoren ser vi resultatet: void setup() { pinmode(temp, INPUT); Serial.begin(9600); void loop() { int analogvalue = analogread(temp); double tempc = ((analogvalue-293,82)/7,9777); Serial.println(tempC, 1); delay(1000);

20 20 Her ses det at vi igen får ens værdier, hvilket fortæller os at måleren umiddelbart virker efter hensigten. Test Vi afprøver og vurderer vores prototype i overensstemmelse med testspecifikationen, hvilket betyder at vi benytter et termometer til at tjekke om Arduino-værdierne er inden for et acceptabelt område. Vi får følgende resultat: Sammenlignes det med ovenstående værdier fra Arduinoen, må vi konkludere at de er acceptable, og dermed at den lille forskel ikke er relevant. Vi fortsætter derfor med udviklingen af vores produkt.

21 21 Anden prototype Krav- og testspecifikation Ved vores anden prototype ønsker vi, at: Kunden skal have mulighed for at få informationer om den aktuelle temperatur. Vi har allerede konkluderet at Arduinomåleren giver resultater der er inden for en acceptabel grænse af virkeligheden. Derfor tester vi denne gang kun ved at sikre os at den information brugeren/kunden får stemmer overens med den værdi, som vises i Serial Monitoren. Design For at opfylde ovenstående krav vælger vi at udvide Arduinoen med et LCD-display. Dette muliggør at vi kan fremvise værdierne, på en lille skærm, som er tilgængelig for kunden. Displayet ser således ud: Denne er tilkoblet en BUS-port, da den behøver mere end én signallinje.

22 22 Implementering For at udarbejde prototypen har vi arbejde videre på vores tidligere kode og er nu kommet frem til følgende: #include <LiquidCrystal.h> int Temp = 4; LiquidCrystal lcd(10, 11, 12, 13, 14, 15, 16); void setup() { pinmode(temp, INPUT); Serial.begin(9600); void loop() { int analogvalue = analogread(temp); double tempc = ((analogvalue )/7.9777); Serial.println(tempC, 1); lcd.clear(); lcd.print(tempc, 1); delay(1000); Vi har tilføjet en række funktioner i den eksisterende kode, således at det output, som fås fra temperatursensoren - omregnet til grader celsius - bliver vist på LCD-displayet: Vi benytter os af #include til at tilføje LiquidCrystal-biblioteket, der indeholder en række kommandoer, som kan benyttes. Vi definerer hvilke indgange enheden skal sidde i. Da denne som sagt benytter en BUS-port, så optager den en lang række indgange. lcd.clear() bruges til at rydde displayet for indhold, således den er klar til et nyt input. lcd.print() definerer hvad der skal vises på displayet. Her har vi valgt temperaturen i grader celsius - med én decimal. Ud fra ovenstående har vi formået at få følgende resultat:

23 23 Dette viser os umiddelbart at det viste tal er korrekt, da værdien stemmer godt overens med stuetemperaturen i skrivende stund. Test Vi afprøver og vurderer vores prototype i overensstemmelse med testspecifikationen, hvilket betyder at vi sammenligner temperaturen som vises på LCD-displayet og i Serial Monitoren. Der ses følgende: Det ses (hvis man kigger godt efter) at de to værdier er identiske, og derfor har vi ingen modstridende faktorer, der skulle forhindre videre udvikling af produktet.

24 24 Prototype 3 Krav- og testspecifikation Ved vores tredje prototype ønsker vi, at: Rummets temperatur skal justeres automatisk imod en forudbestemt værdi. Herved vil vi opfylde den ene user-story: "Løsningen kan fungere uden brugerens regelmæssige indblanding." For at teste at kravet er opfyldt vil vi udsætte systemet for en række prøvelser, der skal vise om temperaturen justeres effektivt på baggrund af temperaturændringer i rummet. Design Vi mener at ovenstående krav kan opfylde vha. en stepmotor. En stepmotor er en elektromotor, som bevæger sig i små vinkeltrin. Størrelsen af den mindst mulige vinkel afhænger af motorens type. Denne step-funktion gør den til et præcisionsværktøj, som er ideelt til at gøre manuelle justeringer automatiske - fx en radiator, som skal skrues ned, når temperaturen i stuen bliver for høj. En sådan stepmotor kan se således ud: Vi skal altså udvikle en kode der får stepmotoren til langsomt, at justere på varmetilførslen vha. en stepmotor der regulerer radiator/gulvvarme. Det er dog umiddelbart ikke til, at sige hvor meget radiatoren skulle reguleres for at justere temperaturen. Men antager man at rummets størrelse er konstant, samt at der ikke sker en varmeveksling mellem rummene eller en udluftning, mens man opvarmer rummet, så må det være muligt at opstille et eksperiment der illustrerer idéen. Den største udfordring umiddelbart er, at størstedelen af disse motorer bruger mere en 5V, og da dette er Arduinoboardets grænse, så må man lave en justering af spændingen. Dette kan gøres ved en spændingsforsyning eller et batteri (dog er batteriløsningen ikke anbefalelsesværdig).

25 25 Implementering Det har efter lang tids prøven vist sig at vi ikke har de nødvendige resurser eller evner til at opstille det elektriske kredsløb, der benyttes når en stepmotor skal tilsluttes Arduinoen. Vi vil dog hurtigt gennemgå de overordnede aspekter i hvordan stepmotoren tilsluttes. Den følgende opstilling er lavet af en af hovedudviklerne af Arduinoplatformen, Tom Igoe, og viser hvorledes motoren skal sættes op: 6 Her benyttes en L293D dual H-bridge komponent. Denne muliggør at to motorer er tilsluttet samtidig. Der findes en række standard funktioner, som man benytter når man opsætter en step motor: Stepper(steps, pin1, pin2) Stepper(steps, pin1, pin2, pin3, pin4) Disse bruges når man definerer stepmotoren. Steps henviser her til hvor mange vinkeltrin der går på en hel cirkulær omgang. pin1 og pin2 er de to indgange, som med sikkerhed benyttes. pin3 og 4 benyttes hvis motoren har 4 ledninger der skal tilsluttes (flere ledninger kan forekomme). setspeed(rpm) Denne funktion bestemmer den fart motoren roterer med. Dette måles i enheden rounds per minute. Illustration Da vi fandt ud af, at vi ikke kunne udføre prototypen med stepmotoren prøvede vi at tilslutte en almindelig DC- motor i stedet. Dette forsøg mislykkedes dog også, selvom vi denne gang trods alt fik gang i motoren. Vi arbejdede ud fra følgende opstilling: 6 20/ Kilde:

26 26 og med denne fik vi altså liv i motoren, men kunne ikke kontrollere den vha. Arduino (retning, hastighed osv.). Test Oprindeligt ville vi selvfølgelig have afprøvet og vurderet produktet i overensstemmelse med testspecifikationen, men da vi ikke har lavet prototypen - kun redegjort for den - kan vi ikke udføre testene. Vores idé var dog at ændre temperaturen, så systemet registrerede en ændring. Så kunne vi overvåge motoren, og se hvorvidt den opførte sig efter hensigten. Selvom vores tredje prototype ikke blev en succes, så vælger vi at fortsætte forløbet og starte på næste prototype.

27 27 Fjerde prototype Krav- og testspecifikation Ved vores fjerde prototype ønsker vi, at: Kunden(brugerne) skal have mulighed for at ændre temperaturen efter individuelle behov. Herved vil vi opfylde den ene user-story: Brugeren har mulighed for at tilpasse løsningen specifikt efter egne behov For at teste at kravet er opfyldt vil vi udsætte systemet for en række prøvelser, der skal vise om temperaturen justeres til den ønskede værdi, når de personlige oplysninger indtastes. Design Uden stepmotoren har dette personlige temperatursystem ingen reel effekt, da vi ikke kan ændre temperaturen, men hvis vi antager at man med de rette resurser kunne færdiggøre prototype 3, så kan man også forestille sig at denne udvidelse vil have en brugbar effekt. Vi forestiller os, at et RFID (Radio Frequency Identification) system vil fungere og tilfredsstille vores behov, i forhold til det krav det skal opfylde. Metoden anvender radiobølger til at genkende objekter. Ovenstående skitserer groft forløbet i et RFID-system. Et personligt tag bliver genkendt af læseren, når tagget kommer inden for en bestemt rækkevidde. De ønskede informationer blev herefter indlæst på pc'en. Ønsket til vores system er som beskrevet, at hver beboer i huset får et RFID-tag. Dette åbner op for en livlig diskussion beboerne imellem om hvem der skal bestemme temperaturen, men man må antage at det ikke er en væsentlig faktor, og derfor kan vores system kun give et positivt udkast. Implementering Vi har endnu engang ikke været i stand til at udarbejde prototypen, fordi vi var i mangel på tid og resurser. Men vi har, med udgangspunkt i et eksempel på Arduinos hjemmeside, prøvet at redegøre for hvorledes et sådan system kunne udføres. Benytter man en Parallax RFID Reader, kan opstillingen se således ud:

28 28 RFID-kortet er tilsluttet på følgende måde: Arduino serial RX til Parallax TX Arduino GND til Parallax GND Arduino digital pin (fx #2) til Parallax /ENABLE Arduino +5V til Parallax Vcc Online findes der en række vejledninger til hvordan denne RFID læser kan programmeres, bl.a. på Arduinos egen hjemmeside 7. Derudover findes der på dette link en ganske veludført beskrivelse af en Parallax RFID læser opstilling: Test En RFID-læser og tilhørende tags kunne testes sammen med systemet ved at kode tagsene til en ønsket temperatur, som er forskellige fra stuetemperatur. Registrerer vi tagget burde systemet nu forsøge at ændre temperaturen (illustreret ved en stepmotor). 7 Kilde:

29 29 Visualisering af temperatur Vi kan vha. programmet processing visualisere temperaturændringerne i en graf. Kildekoden ser således ud: import processing.serial.*; Serial myport; int xpos = 1; void setup () { size(400, 300); println(serial.list()); myport = new Serial(this, Serial.list()[2], 9600); myport.bufferuntil('\n'); background(0); void draw () { void serialevent (Serial myport) { String instring = myport.readstringuntil('\n'); if (instring!= null) { instring = trim(instring); float inbyte = float(instring); inbyte = map(inbyte, 0, 1023, 0, height); stroke(127,34,255); line(xpos, height, xpos, height - inbyte); if (xpos >= width) { xpos = 0; background(0); else { xpos++;

30 30 Når vi benytter denne får vi følgende resultat: Det ses at grafen registrerer vores temperaturændringer. Det ses dog også at når man stopper opvarmningen, så skal sensoren have tid til at justere sig den omgivende temperatur igen. Det tager væsentligt længere tid for den at køle ned til stuetemperatur, end det tager at opvarme den med fingrene.

31 31 Samlet beskrivelse af den endelige prototype Vores endelige prototype indeholder nu faktisk kun temperaturmåler og et LCD-display: I modsætning til vores ønskede produkt, som ydermere vil indeholde RFID læser og stepmotor. Da vores nuværende prototype ikke løser problemet, hverken på klima eller økonomisk plan, så vælger vi at beskrive det ønskede produkt i stedet. Vi har udarbejdet et flowchart, der viser hvorledes programmet fungerer: Kort forklaret beskriver ovenstående flowchart hvorledes systemet vi reagere når brugeren indlæser sit personlige RFID-tag. Ønsket der er registreret til dette tag, vil blive sammenlignet med en måling fra Arduino. Er de to værdier ikke ens vil motoren starte, og regulere temperaturen på varmekilden. Igen vil temperaturen blive sammenlignet med den ønskede, og indtil de to er ens vil rutinen gentage sig. Skal man evaluere på systemets brugbarhed må man opstille og diskutere følgende betingelser for et brugbart system:

32 32 Er systemet let at lære I vores system er det i teorien ikke nødvendigt at lære noget. Næsten alt fungerer nemlig automatisk! Det eneste brugeren selv skal lære er at benytte vores user-interface, hvori man kan definere den ønskede temperatur der hører til RFID tagget. Sikrer man at user-interfacet er brugervenligt, så sikrer det altså også at systemet er nemt at bruge og det er let at lære. Er systemet effektivt Vi har ikke kunne teste det samlede system, så derfor ved vi ikke præcist hvor effektivt, men på rent teoretisk basis mener vi, at det er et effektivt system der opfylder de krav der er stillet. Er systemet nemt at huske Ligesom, at vi er overbeviste om at systemet er nemt at lære, så mener vi også at det er nemt at huske. Dette begrundes ved at automatiseringen overlader et minimum af ansvar i brugerens egne hænder. Forhindres brugeren i at lave fejl Igen må der henvises til det automatiske system, som sikrer at brugeren ikke behøver interagere med systemet. Tekniske fejl kan rettes af en tekniker. Er systemet tilfredsstillende På baggrund af ovenstående punkter tror vi på at systemet vil give en tilfredsstillende og behagelig oplevelse for brugeren, der kan benytte systemet i sin hverdag. I henhold til disse punkter der omhandler brugbarheden af vores produkt, konkluderer vi at det ønskede produkt kan få stor succes inden for brugbarhed.

33 33 Konklusion Vi har I løbet af dette projekt fået dokumenteret processen frem til vores produkt. Produktet endte efter nogle komplikationer med at indeholde en temperatursensor og et LCD-display, der viser målingerne. Derudover fik vi, for at gøre projektet mere fyldestgørende, redegjort for hvorledes systemet kunne udvide med en stepmotor og en RFID-læser, for at tilføje elementer af automatisering, samtidig med et strejf af brugerstyring. Vi mener at have opfyldt de stillede krav, og fundet en løsning med et tilfredsstillende resultat. Det endelige resultat blev desuden vurderet i forhold til brugbarhed og fundet særdeles brugbart på baggrund af den store automatisering, som produktet vil indeholde. Som grundlag for produktet ligger en række grundige overvejelser og analyser der omhandler generelt problem, målgruppe, resurseplanlægning, budget mm. Evaluering Arbejdet med projektet er forløbet fint. Vi har haft nogenlunde styr på, hvad næste skridt var under hele forløbet, og vi mener at dette har været med til at give rapporten en god rød tråd. Af mindre heldige ting, må vi erkende at vi kom i tidspres med hensyn til udvikling af produktet. Dette kombineret med generelle besværlighed fra produktionens side gjorde, at produktet dette ikke blev så omfattende som vi kunne have ønsket. Alt i alt synes vi dog, at vi har lavet et helstøbt projekt, hvor mangel væsentlige aspekter er inkluderet.

34 34 Kildeliste Overordnede kilder: - Arduinoplatformens officielle hjemmeside. Anses derfor for at være den mest troværdige kilde, når det omhandler arduino. - Officiel hjemmeside til programmet processing. Meget troværdig kilde. - Seeedstudio udvikler komponenter til Arduino og hjemmesiden indeholder hovedsageligt beskrivelser af deres egne produkter meget troværdig. Getting Started with Arduino af Massimo Banzi Specifikke kilder: -Hjemmeside for Arduino. Producent af komponenter til vores endelige prototype. Meget troværdig. - Hjemmeside for Seed Studio. Producent af komponenter til vores endelige prototype. Meget troværdig. - Hjemmeside for Arduino. Producent af komponenter til vores endelige prototype. Meget troværdig. - Hjemmeside for Seed Studio. Producent af komponenter til vores endelige prototype. Meget troværdig. -Hjemmeside, hvor artikler relevante for ingeniører offentliggøres. Troværdig. -Byggeside, bekræfter overstående kilde. Troværdig. -Hjemmeside, hvor Minerva modellen er taget fra. Denne model kender vi i forvejen. - Hjemmeside for Arduino. Producent af komponenter til vores endelige prototype. Meget troværdig Hjemmeside for medudvikler af Arduino. Meget troværdig. -Bruce Tognazzinis hjemmeside. Meget troværdig.

35 35 Bilag - Bilag 1 Projektbeskrivelsen - Bilag 2 Uformel spørgeundersøgelse - Bilag 3 Kildekode til endelig prototype - Bilag 4 Kildekide til porcessing

36 36

37 37 Bilag 2 Uformel spørgeundersøgelse Vi stillede os foran den lokale købmand i Vindinge og stillede folk spørgsmål om, hvor ofte de regulerede på deres radiatorers/gulvvarmes termostater. Resultatet af undersøgelsen var som følger: Antal adspurgte: 82

38 38 Bilag 3 - Kildekode til endelig prototype #include <LiquidCrystal.h> int Temp = 4; LiquidCrystal lcd(10, 11, 12, 13, 14, 15, 16); void setup() { pinmode(temp, INPUT); Serial.begin(9600); void loop() { int analogvalue = analogread(temp); double tempc = ((analogvalue )/7.9777); Serial.println(tempC, 1); lcd.clear(); lcd.print(tempc, 1); delay(1000);

39 39 Bilag 4 - Kildekode til processing import processing.serial.*; Serial myport; int xpos = 1; void setup () { size(400, 300); println(serial.list()); myport = new Serial(this, Serial.list()[2], 9600); myport.bufferuntil('\n'); background(0); void draw () { void serialevent (Serial myport) { String instring = myport.readstringuntil('\n'); if (instring!= null) { instring = trim(instring); float inbyte = float(instring); inbyte = map(inbyte, 0, 1023, 0, height); stroke(127,34,255); line(xpos, height, xpos, height - inbyte); if (xpos >= width) { xpos = 0; background(0); else { xpos++;