Automatisk Vandingssystem. Rettelser. 1 af 32

Transkript

1 Rettelser 1 af 32

2 Automatisk Vandingssystem Projektrapporten Aarhus Universitet Gruppe 6-3. Semester - F15 vejleder: Michael Alrøe dato: Lærke Isabella Nørregård Hansen IKT Kasper Sejer Kristensen IKT Kalle Rønlev Møller IKT Jakob Alexander Szalontai Kristensen IKT Kenn Hedegaard Eskildsen E Karsten Schou Nielsen E Thomas Vase EP

3 Resumé Dansk AVS (Automatisk VandingsSystem) har til formål at automatisere vanding og gødning af planter i gartnerier. Et automatiseret system medfører at der skal bruges færre arbejdstimer og at arbejdet udføres ens hver gang. Dette resulterer i bedre afgrøder til billigere penge. Systemet er udarbejdet således, at det fungerer til små såvel som store gartnerier. Hele systemet kan styres fra en central computer. Hertil kobles et kar som indeholder vand med den rigtige mængde gødning. Hertil kobles en ø som opsamler data fra plantejorden. Kommunikation imellem de 3 resulterer i et fuldt funktionelt og automatiseret system. Til at udvikle systemet er der brugt en let version af Scrum. Iterationerne er kørt i 2-4 ugers intervaller og der har i flere af iterationerne været daglige møder. Alt dette har resulteret i en funktionel prototype med få mangler. For at færdiggøre prototypen skal dosering af gødning og intelligent håndtering af opsamlede data i forhold til vanding implementeres. Den udviklede prototype har givet anledning til flere forbedringer til et bedre produkt; hovedsagligt at samle HW-delene på færre print, implementere en bedre kabelføring og tilføje error-handling i SW. English The purpose of AVS (Automatic WateringSystem) is to automate watering and fertilizing of plants in a horticulture. Implementing an automated system results in fewer man-hours and a more identical execution of the desired task. This results in better crops for less money. The system is developed so it scales with small aswell as large horticultures. The entire system can be controlled by a central computer. Connected to this is a reservoir which contains water with the correct amount of fertilizer. Connected to this is a so-called Sensor Island which collects data from the soil. Communication between these three systems results in a fully functionel and automated system. A light version of Scrum have been used to manage the project. The iterations have been divided into 2-4 week intervals. Several of the intervals had daily meetings. All this have resulted in a functional prototype with few deficiencies. To complete the prototype the dosage of fertilizer and intelligent handling of collected data relative to watering must be implemented. The prototype has sparked ideas for improvements to better the system; mainly assembling all the HW-parts on fewer PCBs, implementing better cable management and adding error-handling to the software. 1 af 32

4 Indhold 1 Resumé 1 2 Indledning 4 3 Opgaveformulering 5 4 Systembeskrivelse 6 5 Projektafgrænsning 8 6 Krav 9 7 Projektbeskrivelse Projektgennemførelse Metoder Scrum ASE modellen SysML Specifikation og Analyse Systemarkitektur Blokbeskrivelser af AVS Allokerings diagram af AVS Design og Implementering Software GUI Database FlexPMS Kar SensorØ Fieldsensor AVSLibrary RS Design og Implementering af Hardware RSConverter Ventil-/pumpestyring Flowsensor Jordfugtsensor ph-probe PSU Shields til Raspberry og PSoC Resultater og Diskussion Støjproblemer i prototype-setup Udviklingsværktøjer Fælles HW SW Opnåede Erfaringer Jakob af 32

5 7.9.2 Kalle Karsten Kasper Kenn Lærke Thomas Fremtidigt Arbejde HW PSU Ventil/Pumpestyring Flowsensor ph-sensor Jordfugtsensor SW Automatisk vanding Manuel vanding Fælles Konklusion 29 Litteratur 30 Ordliste 32 3 af 32

6 Indledning I dette 3. semesters projekt vil vi beskæftige os med et automatisk vandingssystem til et gartneri. Ideen kommer fra en af gruppemedlemmerne, hvis veninde er gartner. I projektet vil vi bruge vores opnåede viden fra undervisningen. Her er der tale om fagende Indlejret Software Udvikling, Hardware Abstraktioner, Mixed Signal Electronic, Grænseflader til den fysiske verden, og Elektro Fysik. Endvidre er der blevet tilegnet viden på områder der ikke ligger inden for undervisningen. Her er der tale om databaser, PHP, HTML, Kemi mm. Projektet vil blive udført således der ved aflevering vil stå en prototype til rådighed, her er ikke tale om et færdigt produkt, men der vil være mulighed for senere at gå videre med produktet hvis interessen opstår. Da det er et semester projekt og ikke et produkt som skal sælges, vil der ikke blive købt enheder til systemet som har en stor omkostning. Vi vil ligge vægt på systemets virkemåde og for så vidt holde udgifterne på så lavt niveau som muligt. Prototypen til vandingssystemet vil derfor ikke kunne kobles direkte til et gartneri, den vil blot illustrere vores idéer og kan derfor ikke tåle at blive udsat for vind og vejr. 4 af 32

7 Opgaveformulering For at en gartner kan få det optimale udbytte af sine afgrøder, dvs. både mængde og kvalitet, kræver det, at gartneren er i stand til at give planterne de mest optimale vilkår. Det indebærer bl.a. vanding i tilpas mængder med tilpas mængder gødning tilsat. For et større gartneri kan det være et enormt arbejde at skulle overvåge jordens fugtighed, blande gødning samt at gå rundt og vande alle planterne. Man kan spare gartneren for hele dette arbejde ved at automatisere processen. I dette projekt skal der laves et system, som automatisk kan gøde og vande planter. Dette medfører at systemet skal kunne: Blande gødning i et vandkar. Dosere tilpas mængder vand fra karret til planterne. Opretholde en tilpas ph-værdi af vandet i karret. En sensor måler fugtigheden i jorden og dosere vand herudfra, så jorden altid har en tilpas fugtighed. Der skal implementeres en grafisk brugergrænseflade i systemet, så også folk uden sans for IT kan benytte det. I brugergrænsefladen skal brugeren kunne indstille mængden af nogle forskellige slags gødninger, ph-værdi og jordfugtighed. Brugeren skal også have mulighed for at oprette og genbruge planer for, hvor meget gødning planterne skal have på bestemte tidspunkter i deres vækststadier. I det færdige produkt er der fokus på at der er en præcis dosering af vand og gødning til planterne, der muliggør optimale livsvilkår for planter. Dertil skal brugervenligheden være i top, i form af et let anvendeligt grafisk interface. 5 af 32

8 Systembeskrivelse Som før nævnt er systemet et automatisk vandingssystem. På figur 4.1 ses et rigebillede af systemet. Systemet tilgås af et grafisk brugerinterface som vil være en webside der logges ind på via en PC. Her gives der mulighed for at se ph-værdi i karet, se hvor meget vand der er i karet, samt jordfugtigheden i gromedie. Der vil også være mulighed for at indstille disse værdier således systemet selv opretholder dem. Systemet er bestående af en Raspberry-Pi som kører Raspbian, hvilket er en distribution af linux. Systemet kan måle fugtigheden i gromediet via en jordfugt-måler der kommunikerer via I2C. Hvis fugtigheden når ned under et bestemt niveau tændes der for vandingen. I vandkaret er der iblandet gødning og en korrekt ph-værdi vil opretholdes af systemet. Systemet kan måle phværdien via en ph-probe som sidder fastmonteret i vandkaret. Figur 4.1: Rigebillede af AVS Når systemet startes op vil vandkaret være tomt. For at fylde karet med vand, tændes der for indløbsventilen der sidder direkte i forlængelse af en vandhane. Hermed vil der løbe vand ned i karet og mængden måles vha.. flowsensor. Når der er løbet den ønskede mængde vand i karet, vil ventilen lukke og der vil automatisk blive doseret gødning indtil til en forudbestemt ph-værdi er nået. Skulle det ske, under opfyldning af det ikke lykkedes at lukke indløbsventilen vil der blive åbnet for afløbsventilen for at bibeholde et ønsket vandniveau. Der er to aktører som kan tilgå systemet. Den ene er Brugeren, som tildaglig benytter systemet. Den anden er Teknikeren som tilgår systemet ved oprettelse, vedligeholdelse, samt nedlæggelse af systemet. Systemetoprettelse sker i forhold til use casen "Opret kar", se Projektdokumenationen, afsnit 1.2. Herefter kan oprettes et ønsket antal sensorø er, her benyttes "Opret SensorØ-usecasen. Når karet er oprettet skal ph-proben kalibreres via use casen "Kalibrer ph-probe", dette skal, som minimun gøres en gang hver måned for at kunne sikre en korrekt måling, dog gøres det også ved hver systemstartup. Styringen til vandkaret er implementeret på et "karprint"her er ph-proben ligeledes koblet til. På 6 af 32

9 printet, vil der være en rød LED som lyser når ph-proben skal kalibreres. Ved kalibrering sættes proben ned i en buffer-væske som har ph-værdien 7 og der trykkes på en knap på karprintet. KarControl vil herefter indlæse værdien og den røde LED skifter til en grøn. Karet kan også fyldes manuelt via use casen "Fyld kar". Her gives der mulighed for at åbne indløbsventilen, og lukke den når den ønskede mængde vand er løbet til. I use cas en "Indtast ph-værdi"gives der mulighed for at indtaste en ph-værdi som systemet skal opretholde. Det samme gives der mulighed for i "Indtast volumen". I use cas en "Aflæs målinger"går Brugeren ind og aflæser værdierne fra sensorerne hvis det ønskes at se hvad status er. Use cas en "Manuel vanding"giver mulighed for at vande manuelt. Dette kan være ønskeligt hvis systemet har fejl ved sensorene. Use cas en "Tøm kar"bruges til at tømme karet og "Slet kar"er for at nedlægge et oprettet kar. 7 af 32

10 Projektafgrænsning Til dette projekt har vi fra start af haft nogle hardwarespecifikke krav, der siger, at vi skulle bruge sensorer/aktuatorer, systemet skulle have en grafisk brugergrænseflade og systemet skulle indeholde en indlejret Linux platform og en PSoC platform. Ud fra disse krav lavede vi en opgaveformulering som vi følte dækkede kravene. I denne formulering skulle systemet være autonomt og selv være i stand til at vande, doserer gødning i vandet, for at give optimale vækst forhold, og opsamle data hvorfra systemet kunne tage sine beslutninger. Der skulle også være en høj grad af automation i forhold til sensorer og deres tilkobling til systemet. Disse skulle kunne autodetekteres således, at brugerne ikke skulle skænke det en tanke under operation. Systemet skulle også kunne understøtte flere kar og sensor ø er. Vi valgte dog ikke at fokusere på alt automatikken, da der var andre udfordringer der kom på banen, i form af bl.a. store afstande mellem delsystemerne, muligheden for konstruktion af egne sensorer, herunder disses kommunikation, og PSoC-platformens mulighed for modulopdeling igennem specialfremstillede komponenter. Derfor valgte vi at fokusere på et system med basal funktionalitet med mulighed for senere udvidelse såfremt tiden tillod det. Dog var afstandene i systemet ikke noget vi ønskede at gå på kompromis med. Den basale funktionalitet kommer til udtryk i, at systemet kan vande og opsamle målte data fra sensorer. Der er ligeledes implementeret en brugergrænseflade, som er nem at udvide med flere kar. Kommunikationen er også lavet efter muligheden for udvidelser. 8 af 32

11 Krav I dette afsnit beskrives de opstillede krav for AVS. På 6.1 ses det færdige Use case diagram over systemet, der ligger til grund for de funktionelle krav. Figur 6.1: AVS Use case diagram Herunder findes en kort beskrivelse af de enkelte use cases. For yderlige detaljer henvises til Projektdokumentationens afsnit 1.2 "Use Cases". 9 af 32

12 Use Case 1 - Kalibrer ph-probe Denne use case har til formål at lade Tekniker kalibrere den ph-probe der er tilsluttet et givent kar. Denne use case skal køres hver gang systemet startes op. Use Case 2 - Opret kar Denne use case har til formål at lade Tekniker oprette et nyt Kar til systemet, dette udføres fra Gui en i brugerens webbrowser. Use Case 3 - Opret Sensor Ø Denne use case har til formål at lade Tekniker oprette en ny SensorØ til systemet, dette udføres fra Gui en i brugerens web-browser. Use Case 4 - Fyld kar Denne use case har til formål at lade Bruger åbne for indløbsventilen og fylde karet med vand. Use Case 5 - Indtast ph-værdi Denne use case har til formål at lade Bruger indtaste en ønsket ph-værdi via Gui en. Herefter justerer systemet Gødning/vand indtil den indtastede ph-værdi er opnået. Use Case 6 - Indtast volumen Denne use case har til formål at lade Bruger indtaste en ønsket volumen via Gui en. Herefter justerer systemet ind- og afløbsventiler indtil den indtastede volumen er opnået. Use Case 7 - Aflæs målinger Denne use case har til formål at lade Bruger tilgå de tilkoblede kar via Gui en og aflæse ønskede data. Use Case 8 - Manuel vanding Denne use case har til formål at lade Bruger, manuelt tilføre vand til gromediet. Use Case 9 - Tøm kar Denne use case har til formål at lade Bruger åbne for afløbsventilen, tænde pumpen og tømme karet for vand. Use Case 10 - Slet kar Denne use case har til formål at lade Tekniker, via Gui en slette et givent kar fra systemet. Derudover er følgende use cases tilføjet systemet, dog på ikke-fullydressed basis. For yderlige detaljer om de enkelte use cases refereres til Projektdokumentationens afsnit 1.3 "Ikke fully dressed Use Cases" Use Case 11 - Doser ph-væske Denne use case har til formål at Bruger får mulighed for, manuelt at dosere ph-væske via en doseringspumpe indtil den ønskede ph-værdi er opnået. Use Case 12 - Automatisk vanding Denne use case har til formål at lade vandingen ske automatisk, baseret på den målte jordfugtighed. Use Case 13 - Alarm Denne use case har til formål at lade Systemet afgive en alarm hvis de brugerdefinerede grænseværdier (jordfugtighed, ph-værdi og volumen) overskrides. Use Case 14 - Ugeplan Denne use case giver Bruger mulighed for at indtaste en ugeplan for styring af dosering af phvæske og vand til gromediet. Use Case 15 - Udprint log Denne use case giver Bruger mulighed for at få udprintet en log over de hændelser der er forekom- 10 af 32

13 met i systemet, herunder optaget sensordata samt dosering af vand. For at sikre kvaliteten af det færdige produkt, er der opstillet en række ikke funktionelle krav. Disse beskrives kort herunder, for yderligere detaljer henvises til Projektdokumentationens afsnit 1.4 "Ikke funktionelle krav" De ikke-funktionelle krav er inddelt i 3 undergrupper: Brugervenlighed Systembetingelser Ydelse Kravene under brugervenlighed baserer sig på at systemet skal kunne kører på en "standard"pc og kunne tilgås igennem normal webbrowser. Derudover skal systemet både kunne tilgås over lokalt netværk samt over www. Under Systembetingelser opsættes de miljømæssige omstændigheder under hvilke hvor systemet skal kunne opererer. Ydelse opsætter de tider og grænseværdier for fyldning og tømning af systemet, samt for dosering af gødning og vand til gromediet. 11 af 32

14 Projektbeskrivelse 7.1 Projektgennemførelse Projektet startede med at vi skulle finde på en idé. Efter et par brainstormings fandt vi ud af, at det skulle være det automatiske vandingssystem. Herefter gik arbejdet ud på at finde ud af hvad det specifik skulle kunne. Da dette var besluttet blev der tegnet SysML diagrammer herunder oprettelse af vores usecases, BDD er og IBD er. Herefter uddelte vi nogle teknologiundersøgelser som gik ud på at finde ud af hvad der var den optimale løsning til den bedste pris. Undervejs holdte vi ugentlige møder hvor vi diskuterede vores opdagelser, samt kordinerede det med hvad der var muligt at realisere. Da vi havde fundet de enkelte dele fik vi dem bestilt og vi delte os op i hardware og software. Under hardwaren var det mest individuelt arbejde som blev lavet. Her var der tegnet SysML diagrammer og signaltabellerne blev lavet for at kunne specificere hvad der skulle modtages fra softwaresiden. Softwaren var mere handson, hvor der blev brugt viden fra faget ISU og det var derfor svært at gøre noget rigtigt første gang, da der hele tiden blev fundet en bedre måde at klare problemstillingen på. Da dette var meget tidskrævende blev der desværre ikke tid til at automatisere processerne. Derfor blev der kun implementeret manuel styring. Da undervisningen sluttede besluttede vi os for at samle vores enheder. Her fik vi på få dage samlet systemerne til et stort og efter en gennenført acceptest gik vi i gang med selve dokomentatione og rapportskrivningen. 7.2 Metoder Scrum Til styring af arbejdsprocessen i dette projekt har vi forsøgt at bruge Scrum. Det har vi forsøgt at udføre igennem iterationer af projektet samt fjorten dages sprint hvor der så vidt som muligt har været holdt daglige møder. Dog har vi ikke igennem hele projekt perioden brugt Scrum der har været perioder hvor det ikke har været hensigtsmæssigt som i krav specifikation og system arkitektur fasen af projektet. I vores brug af Scrum har der heller ikke været en "produkt owner", da det har været gruppen der har skulle styre backloggen og sprintbackloggen. Der har heller ikke været en decideret Scrum master. Det er altså arbejdsgangen vi har benyttet blandt andet igennem brug af Scrum board via waffle.io som integrerer med vores projekt på Github ASE modellen Til at udforme dokumentationen er ASE modellen blevet benyttet, det vil sige at projektet er delt op i nogle faser hvor hver enkelt fase producere et dokument. Der har været lidt udfordring i forhold til at få dette til at køre sammen med Scrum derfor har design fasen som nævnt ikke kørt efter Scrum SysML Til udformning af krav specifikation og system arkitektur er der brugt SysML både til at udforme use cases som beskriver de funktionelle krav for systemet og senere blok definitions diagrammer (BDD) og interne blok diagrammer (IDB) der er brugt til at give et indblik i hardware opbygningen. Til den overordnede beskrivelse af systemet er der brugt en domæne model diagram som også er blevet brugt til at udforme en applikations model som forsøger at beskriver hvordan software hænger sammen og her er der også brugt system sekvens diagrammer. 12 af 32

15 7.3 Specifikation og Analyse I vores overvejelser omkring systemet har vi lagt vægt på, at det skal kunne virke over lange afstande og at brugeren sjældent skal have behov for at tilgå hardware ved kar og sensor ø. Det skulle således kun ske når der skal tilføjes nye sensorer eller nye sensor-øer. Desuden skulle brugergrænsefladen være nem at tilgå. Det gik også op for os at det var en god ide at have systemet inddelt således at brugergrænsefladen stod for sig selv, da systemet så kan udvides med flere kar. Samme argumentation gælder for sensor-øen da et kar kan stå for at vande mange planter og det giver god mening at kunne opsamle data flere steder fra. Det giver også mulighed for bedre at styre vandmængden til forskellige områder af planteområdet. Figur 7.1: Domæne model for AVS På modelen herover7.1 ses et udlæg af systemet. Her er det lidt svært at se at systemet er meget opdelt, men modellen illustrer data vejen i systemet og hvordan systemet samler data op som det skal bruge til at logging og automatisk vanding. På baggrund af disse tanker har vi valgt at bruge en bus med differentielt signal til at opnå afstandene i systemet, desuden har vi valgt selv at designe vores sensorer. 7.4 Systemarkitektur Under systemarkitektur beskrives den overordnede systemarkitektur som er dokumenteret i projektdokumentationen. Systemarkitekturen fungerer som udviklingsramme for videre design og implementering. Det er her at systemets funktionalitet, der er beskrevet i systembeskrivelsen og kravspecifikationen, nedbrydes til overordnede moduler. Systemet kan illustreres i et BDD bestående af flere moduler. 13 af 32

16 Figur 7.2: Block Definition Diagram af AVS Blokbeskrivelser af AVS Systemmet består af en CentralControl, ud fra den er der en RSConverteren som konverterer mellem RS485 og UART 232, der er blevet anvendt fordi den giver mulighed for at have en længere afstand mellem systemmet. Gennem GUI kan brugeren tilgå systemet. Databasen skal indeholde alle sensor data samt de indtastede værdier fra brugeren. Softwaren som er bindeleddet mellem GUI og de andre delsystemer kaldes FlexPMS. FlexPMS afvikles konstant på CentralControl, og håndterer at sende kommandoer til og opsamle data fra KarControl. Der kan være en til flere KarControler, som har til arbejde at styr og håndterer al datakommunikation og kommandoer relateret til ét kar. Ud fra KarControl kan der være en til flere Sensor Øer der giver mulighed for at måle (f.eks. jordfugtighed) over et større areal ved, at Sensor Ø erne spredes over området, hvor planterne gror, og har hver især tilsluttet sensorer Allokerings diagram af AVS I AVS er der en række blokke der har en logisk funktionalitet, som er allokeret på en række fysiske enheder. Nedenstående diagram viser hvor de logiske blokke er allokeret. 14 af 32

17 Figur 7.3: Allokerings diagram af AVS Det ses på diagrammet at KarControl og SensorØ er allokeret på hver deres microkontroller/psoc. I dette projekt er det besluttet at microcontrolleren skal være af typen PSoC4. Databasen, GUI og Flex er allokeret på Embedded Linux. 7.5 Design og Implementering Software Da der skulle laves software blev der taget udgangs punkt i domænemodellen og den gav anledning til følgende opdeling således at systemet består af følgende software blokke: GUI Database FlexPMS Kar SensorØ Fieldsensor AVSLibrary GUI GUI er den brugergrænseflade, som brugeren kan tilgå systemet gennem. Som udgangspunkt til at lave GUI en er der blevet implementeret en webside hvor der er anvendt PHP. Til HTML filerne er der anvendt Bootstrap3, som er beregnet til at gøre webudvikling lettere, da den består af HTMLog CSS- baserede design skabeloner. Ydermere er der anvendt nogle jquery AJAX metoder, som kan bruges til at udveksle data med en server og opdatere dele af en webside uden at genindlæse hele siden. 15 af 32

18 7.5.2 Database Databasen er blevet anvendt til at opbevare indtastede data omkring kar og Sensor Øerne med deres ventil og vandingsstatus, samt aflæste værdier fra de forskellige sensorer, hvor denne database kan tilgås via GUI en. MySQL er databaseformatet der er valgt, og valget bunder i at denne har alle de kvaliteter systembeskrivelsen og kravspecifikationen foreskriver. Desuden er softwaren til etablering af en sådan server gratis, veldokumenteret og nem at gå til FlexPMS Programmet FlexPMS er designet til at være bindeled mellem brugergrænsefladen og kar/sensorø styringerne, der til får programmet nogle opgaver der hedder sig at programmet skal op sample data og gemme dette i databasen, samt holde en log af det opsamlede data. Programmet skal også facilitere kommunikationen fra brugergrænsefladen til kar/sensorø når der for eksempel bliver bedt om at starte en vanding i brugergrænsefladen eller det ønskes at styre ventiler. FlexPMS kunne også udvides således at programmet selv kan bestemme hvornår der skal vandes baseret på de målinger der er fortaget Kar Kar Controlleren (se 7.4) er tilkoblet et enkelt Kar, hvor den har en række sensorer og ventiler tilkoblet. Dens funktion er at styre ventilerne baseret på beskeder fra FlexPMS, indsamle data fra dens sensorer tilkoblet karret, indsamle måledata fra Sensor Ø en og forwarde beskeder videre til SensorØ en fra FlexPMS. Der er forsøgt at lave automatisk adressering af Sensor Ø er fra Karret, men da der ingen error detection er på RS485, ligger dette et stykke ude i fremtiden. Sensor Ø er kan allerede dynamisk oprettes fra FlexPMS. Figur 7.4: Kar i PSoC creator Det kan ses på figut 7.4 at vi har nydt godt af custom komponenterne fra AVSLibrary, da projektet hurtigt ville have været uoverskuelig og mere errorprone, hvis det hele skulle ha ligget i et enkelt projekt. Nu får man et let overblik over hvad karret reelt indeholder, samt bliver loggikken i projektet lettere at overskue. Den største downside er at man skal være varsom med timings issue som nye komponenter kan introducere SensorØ Sensor Ø en placeret ude i marken med en række Fieldsensorer og en ventil. Her bliver den brugt til at opsamle data fra dens tilkoblede Fieldsensorer, samt styre ventilen. Mens den afventer beskeder fra Karret, indsamler den data fra Fieldsensoren, derved har den altid de opdaterede tal, når der kommer en forespørgsel fra Karret. Når Sensor Ø en tændes, scanner den SensorBussen for Fieldsensorer og begynder at polle dem. Der er start implementering på automatisk addresering af Fieldsensorer. 16 af 32

19 7.5.6 Fieldsensor Fieldsensoren er en skabelon til alle typer af Fieldsensorer. Den er bygget til at det er let at udvikle nye sensor typer baseret på skabelonen. Det eneste der skal tilføjes fra udviklerens side er et nyt typeid, samt sørge for at måledata bliver sendt ind via en af skabelonens LoadValue funktioner. Dette gør det lettere at fx skifte kommunikationsinterface, hvis dette skulle være ønsket, da selve sensor udvikleren på intet tidspunkt har skullet rode med den del af koden. Der er lagt start funktioner til automatisk tildeling af I2C adresser, men dette nåede ikke at blive færdigudviklet AVSLibrary AVSLibrary er et bibliotek af custom components 7.5 til PSoC Creator. Dette er lavet da mange af komponenterne bliver brugt af de forskellige enheder PSoC enheder. Derved sikres det at ændringer bliver rullet ud på tværs af enhederne. En positiv bivirkning er at koden på de andre PSoC enheder bliver lettere at læse, da meget af komponent koden er pakket væk. Der er også implementeret en Debug feature de fleste komponenter og enheder bruger, der giver mulighed for at manuelt gå ind og aflæse og manipulere med data. Figur 7.5: AVSLibrary i PSoC creator Der er også lavet en række stub projekter til hjælp af udvikling af biblioteket og til at man kan teste interfacing. Dette har gjort det muligt at teste en Fieldsensor uden at have en Sensor Ø klar, og vide at den vil virke med Sensor Ø en, inden den blev færdigudviklet RS485 Da vi havde valgt at bruge RS485 som det fysiske lag for vores bus blev vi også nød til selv at lave en protokol til denne. Det gjorde vi ret simpelt ved at definere hvordan en besked ser ud, det blev til at vi valgte at alle på bussen skulle have en adresse således at vi kunne vælge hvem der skulle skrives til. For at kunne skelne mellem en adresse og en data byte har vi valgt at bruge paritetsbit en i en UART data frame til at indikere adressen. Vi kører med det der hedder mark/space paritet hvor mark betyder at der står 1 i paritetsbit en og ved space står der 0, i vores løsning betyder mark paritet at det er en adresse der er sendt og space betyder at det er data. En dybere beskrivelse af kommandoer og dataformat kan læses i systemarkitekturen. 7.6 Design og Implementering af Hardware Systemet består af følgende hardware blokke: RSConverter Ventil-/pumpestyring Flowsensor 17 af 32

20 Jordfugtsensor ph-probe Power Supply Unit (PSU) Shields til Raspberry og PSoC RSConverter Figur 7.6: RS485 converter Bussystemet som er valgt til at kommunikere på er RS485-standarden. Denne beskriver kun de hardwaremæssige krav og det er op til udvikleren selv at lave en protokol. RS485 udmærker sig ved at være en differentiel bus som giver mulighed for at kommunikere over længere afstande (op til 1200m). Der er forbundet arbejde med selv at udvikle en protokol, men det giver også mulighed for at skrue protokollen sådan, at den passer bedst til systemets behov. PSoC4 og Raspberry Pi understøtter dog ikke RS485-kommunikation. De kan begge kommunikere via. RS232/UART. Derfor er der udformet et simpelt RSConverter kredsløb som kan konvertere imellem RS232 og RS485. Kredsløbet benytter sig af MAX3082-kredsen. De eneste eksterne komponenter der er krævet er en pull-down modstand til at trække T X enable lav når den ikke er aktiveret fra PSoC4/Raspberry Pi. Til at terminere buslinjerne kræves en modstand som har samme modstand som det anvendte kabel. Dette gøres for at formindske reflektionen og dermed give det størst mulige signal i modtager-enden Ventil-/pumpestyring Til at styring af ind- og afløbsventiler, samt vandpumpe benyttes en række MOSFET-styringskredsløb. MOSFET erne er specifik valgt pga. af deres logic-level-kompatibilitet. Dette betyder at transistorens GATE kan kobles direkte til output-pin en på PSoC en, da dens grænseværdier følger CMOS-standarden. på fig.refscreenshot:ventilstyringskreds, s.19 ses eksempel på ventilstyringskreds. 18 af 32

21 Figur 7.7: Ventilstyringskredsløb Både ventilerne, og pumpens belastning af styringskredsen har spolekarakter, da de indeholder et relæ som skal trækkes. Ved denne form for styring er det vigtigt at være opmærksom på, at når MOSFET en går off, og spændingen fra spolen fjernes, hvorved strømmen ikke længere har en løbebane, vil spolen selv inducere en en modsatrettet spænding. Denne spænding kan blive utrolig høj, og i værste fald beskadige nærliggende komponenter så kredsløbet ikke længere er funktionelt. Til at modvirke dette benyttes en flyback diode. Denne implementeres således at strømmen har en løbebane og herved kan spolen aflastes. Derudover benyttes der en pull-down modstand til at trække gat en lav når den ikke er aktiveret af PSoC4 en Flowsensor Når karret skal fyldes med vand er det vigtigt at vide, hvor meget vand der i realiteten er fyldt i karret. Det blev derfor valgt at benytte en flowsensor til formålet. Jo mere vand som løber igennem sensoren jo højere en PWM-frekvens vil den sende ud på udgangen. Dette kræver dog, i praksis at der, over hele den tid hvor indløbsventilen er åben konstant skal holdes øje med det signal den leverer. Dette kræver alt opmærksomhed fra PSoC4 en, og i den konfiguration som vi benytter den, er dette ikke en mulighed. I stedet sætte karcontrol-programmet op til at modtage interrupts som triggeres af pulserne fra flowsensoren. Dette vil dog stadig kræve utrolig meget opmærksomhed fra karcontrol. For at imødekomme dennee problemstilling, er der udarbejdet et eksternt hardware counter-kredsløb. Dette kredsløb tæller pulserne fra flowsensoren, og når der er talt 10 pulser op, går en output-pin høj, og interrupt et trækkes. Hermed minimeres antallet af interrupts og giver større frihed til karcontrol-programmet. På fig.7.8, s.19 ses schematics af det eksterne counter-kredsløb Figur 7.8: Counter-kredsløb 19 af 32

22 Kredsløbet er opbygget omkring en 4-bit counter (74HC393). Dertil er koblet en AND-gate som gør, at når counter en rammer 10 giver den interrupt-signalet til PSoC4 en. Det allerførste der sker i ISR-rutinen er at tælleren nulstilles. Dette gøres for at undgå at der fejlagtigt gen-trigges når begge inputs til AND-gaten går høj 4 clockcycles senere når counter rammer 14 counts Jordfugtsensor Selve jordfugt sensoren skal måle jordfugten i jorden således systemet kan vide hvornår en plante skal have vand. Da vi ønsker at sensoren skal kommunikere over I2C igennem vores egen protokol, ønsker vi samtidig at levere en speciallavet jordfugt sensor med til systemet. Dette kræver at vi selv designer den. Den første ide til at måle jordfugten gik ud på at måle den kapacitivt. Alt afhængig af jorfugtigheden må jordens ledeevne ɛr ændre sig. Dette kan måles ved hjælp af to elektriske ledende plader med jorden som dielektrikum. Der blev ud af noget printplade opbygget en pladekondensator. Til den hjemmebyggede pladekondensator blev der også opbygget en oscillator som varierede sin udgangsfrekvens afhængig af kondensatorens kapacitet. Dette kredsløb blev bygget med en LM555. Desværre var det umuligt af få oscillator-frekvensen til at være stabil og idéen blev derfor opgivet Anden idé var at lave en resistiv måling af jorden. Her stikkes et tobenet spyd ned i jorden og ved at sætte en spænding over det, vil strømmen ændres afhængig af fugtigheden. Dette viste sig også at være en dårlig metode, da der forekommer elektrolyse når der går en strøm i spyddet. For at undgå at slide mere end nødvendigt bruges der derfor en MOSFET til at lede strømmen i det øjeblik der måles. Der blev tørret noget jord i en oven således fugtigheden var 0%. Efterfølgende blev der tilsat vand i målte mænger, således der kunne tegnes en kurve over strøm afhængig af fugtighed. Ved hjælp af disse data kunne der laves en funktion i en mikroprocessor til at måle og udregne fugtigheden i procent. På figur 7.9 ses et diagram over jordspyddet. Projektbeskrivelse/DesignOgImplementeringAfHW/Jordfugt_billede Figur 7.9: Diagram over jordspyddet Den valgte mikroprocessor blev en PSoC 4. I figur 7.10 ses topdesignet over designet. Figur 7.10: Topdesign i PSoC creator Da programmet var skrevet og testet blev der fremkaldt et print hvor selve mikroprocessoren skulle loddes på. Dette viste sig at volde nogle problemer da der ikke kunne komme nogen funktion ud af mikroprocessoren. Det var dog muligt at programmere den og det var derfor svært at finde ud 20 af 32

23 af hvad der gik galt. I stedet blev der bygget et shield til PSoC 4 Pioneer kittet som blev brugt som prototype ved accepttesten ph-probe Planterne kræver ikke kun denne rette mændge vand, men også at vandet har den rette ph-værdi. ph-værdien i karret skal derfor måles samtidig med at der doseres gødning i karret. Til denne opgave blev valgt en glasprobe. Det viste sig at at være en meget godt metode at bruge da den både er billig og hurtig. Selve proben generere en spænding afhængig af ph-værdien. Det viste sig at proben har en udgangsimpedans på 9,5MΩog det tog noget tid at finde ud af hvorfor der ikke kunne måles noget med et oscilloskop. Problemet var at oscilloskopets indgangsimpedans var 1MΩog signalet blev derfor dæmpet betydeligt. For at løse problemet blev der koblet en buffer på udgangen af proben. Herefter var det hurtigt at omregne spændingen til ph-værdi i en PSoC 4. Fordi at proben vil drifte med tiden kræver det at den kalibreres ca hver måned. Til dette laves der en kalibreringsfunktion på PSoc en som indlæser værdierne når der trykkes på en knap. På figur 7.11 ses diagrammet. Figur 7.11: Diagram over ph-proben På figur 7.12 ses topdesignet i PSoC creator. Figur 7.12: Topdesign i PSoC creator 21 af 32

24 Der er foretaget en støjanalyse af proben ud fra den indhentede viden fra E/EP faget MSE (Mixed Signal Elektronik). Analysen viste at det største støjbidrag kom fra støjstrømmen i bufferen. Ved at lave en støjmåling af proben viste det sig at de forventede værdier var ca. en faktor 10 større. Ved høje impedanser blive strømstøjen meget dominerende. Det er derfor meget vigtigt at tage med i sin tanker/beregninger når det endelig kredsløb skal udformes PSU For at forsyne systemet med de rigtige spændingerne og strømme er der udformet en strømforsyning. Den skal tilkobles 230VAC og forsyne systemet med 5V- og 12VDC. Dette kræver en transformering fra 230VAC til 12VAC og 2 reguleringskredsløb. Reguleringskredsløbet til 5V-forsyningen kan ses på figur Forskellen til 12V-forsyningen er D 5 og R 4. Figur 7.13: 5V strømforsynings diagram Spændingen transformeres ned til 12VAC. Spændingen dobbeltensrettes og lades op på nogle store elektrolytter. D 5 skaber en reference spænding som fejlforstærkeren kan regulere ud fra. Spændingsdeleren R 2 og R 4 er udregnet således, at når spændingen på udgangen når over det ønskede punkt, vil fejlforstærkeren lukke for strømgennemløbet i MOSFET en Q 1. For at undgå reguleringsstøj på udgangen er der koblet 2 kondensatorer og 1 elektrolyt på. Samtidig med er forstærkningen i fejlforstærkren gjort frekvens-afhængig hvilket ogsåundertrykker støjens indvirkning på reguleringen. Da der ved fuld belastning afsættes en forholdsvis stor effekt i de 2 regulerings-mosfets, er de placeret på en køleplade. 5V-forsyningen trækker en konstant strøm for at forsyne Raspberry Pi, PSoC4 mm. 12V-forsyningen belastes kun når der bruges pumper eller ventiler Shields til Raspberry og PSoC Systemet består af mange små kredsløb, og mange af dem skal kobles til kar-psoc en. En almindelig løs kobling giver anledning til en del støj, og det er derfor er det valgt at placere alle disse kredsløb på såkaldte shields. Der skal laves 3 forskellige: PiShield 22 af 32

25 Kar-shield Ø-shield Ved at samle kredsløbene på disse shields opnår man langt færre "løse"ledninger imellem de forskellige blokke, da alle koblinger enten ligger i printlayout et, eller er forbundet med pin-headers til kar-psoc en, som disse shields passer sammen med. Dette reducerer samtidig med mulighed for støjindlejring fra omverdenen. At udlægge prints og teste disse er en forholdsvis stor opgave i forhold til at lave en prototype. Det giver dog et meget bedre overblik over systemet og reducerer muligheden for fejl. Der forekommer også leveringstid på udlagte print og det skaber et endnu større tidspres. Det er dog altid en god idé at designe print sideløbende med at kredsløbene tager form, så det er muligt i f.eks. næste iteration at skabe et fuldt funktionelt system som vil være tæt på det endelige. 7.7 Resultater og Diskussion I bund og grund opnåede vi meget af det vi ville i forhold til en første iteration/prototype. Der blev lavet en grafisk brugergrænseflade, der kører godt, som kan det den skal i forhold til de krav der er sat. FlexPMS kører godt og har den basale funktionalitet, men her er plads udvidelser, blandt andet i forhold til automatisering. Der var en del besvær i forhold til kommunikationen mellem FlexPMS og Kar. RS485-bussen blev udvidet med en selvudviklet protokol, der indeholdte addresering. I denne sammenhæng var adresseringen et problem, da vi brugte paritetsbit en i UART data-frames til at indikere adresser. Dog var der ingen understøttelse for dette på Linux-platformen. Her kunne protokollen forbedres og implementeringen kan sagtens optimeres. Kar- og Ø-styringerne har også den basale funktionalitet på plads. Ø en kan skanne og finde fieldsensorer, så her er opnået lidt af den automatisering, der skulle implementeres. I forhold til hardwaren er der blevet lavet nogle gode udlæg til print for jordfugtsensoreren. Der var desværre en fejl i de udlagte print men prototypen virkede efter hensigten. Ventilstyringen fungere også ganske godt, dog var der lidt problemer i forhold til støj fra pumpestyringen. Strømforsyningen virker ganske godt og kan levere det, som den skal. Flowsensoren virkede også, men der var dog en udfordring i forhold til at kunne måle rate of flow, da PSoC en ikke har et begreb omkring tid. Der er også blevet designet print til alle PSoCs samt Raspberry pi. Vi har dog ikke nået at implementere dem til denne rapports aflevering Støjproblemer i prototype-setup Ved realisering af system-prototypen til styring af indløb- og afløbsventiler samt doseringspumpe blev styringskredsløb til disse implementeret på samme veroboard. Dette gav nogle uforudsete støjproblemer, idet pumpen (når denne kørte på 100% effekt, og trak 2.2A) støjede så meget at der lå nok spænding over styringen af ventilerne til at få dem til at gå "on"og "off". Problemet synes at kunne komme flere steder fra: Dels at designet er implementeret på veroboard og afstanden imellem de fortrykte copperbaner kan give anledning til støjoverlejring Dels at Kar- PSoC en ved teststillingen var en "fuglerede"af tilslutninger. Dels var ventilerne "kun"er afkoblede med 100nF caps, og dette sikre dem desværre ikke imod denne type støj. Der blev prøvet flere løsninger til dette problemet: Fysisk blev printet med doseringspumpestyringen adskilt adskilt fra ventilstyringerne, så muligheden for overlejring her blev elimineret. Derudover blev det forsøgt at skifte PSoC ens output ben til pumpestyringen. Dette havde desværre heller ikke den ønskede effekt. Det var også på tale om støjen evt. kunne løbe tilbage igennem strømforsyningen, og dermed forstyrre hele 12V linjen. Da vi ikke fandt noget endegyldigt svar på problemet. Blev løsningen at nedjustere doseringspumpens "100%"således at den ved max. kun trækker 1,8A, dette var rigeligt til formålet, og samtidig gav det ikke problemer med nogle af de andre tilkoblede kredsløb. 23 af 32

26 7.8 Udviklingsværktøjer Til udvikling af projektet er der benyttet en række programmer/ værktøjer. Disse har været en vigtig del for at komme fra idé til produkt. Værktøjerne er inddelt i 3 kategorier: Fælles, HW, SW Fælles GitHub - Revisionsstyring og backend til Waffle.io Latex - Dokumentation og Rapport ShareLatex - CI af Dokumentationen og Rapporten Travis-CI - CI af Dokumentationen og Rapporten Waffle.io - Scrum Board Dropbox - Diverse fildeling og møder PSoC Creator - Udvikling af software til PSoC Waveforms - Måling af signaler TeamViewer - Skærmdeling under møder mm. MS Office Pakke - Mødereferater, Sysml Diagrammer HW MathCad 15 - Beregninger af hardware MatLab - Beregninger af hardware Maple - Beregninger af hardware MultiSim - Simulering af hardware Eagle Light - Udlægning af printboards DesignSpark - Udlægning af printboards SW phpmyadmin - GUI til MySql database GCC Raspberry Pi Toolchain & Make - Cross compilering af FlexPMS 7.9 Opnåede Erfaringer I opnåede erfaringer vil vi hver især reflektere på projektets forløb og hvad vi kan tage med derfra. De opnåede erfaringer i projektet vurderes individuelt, da hver projektdeltager har oplevet det på sin egen måde. Der kan forekomme ens opnåede erfaringer, men hvor lærerigt det har været kan være forskelligt fra projektdeltager til projektdeltager Jakob Jeg har udviklet en stor del af FlexPMS, og har i den forbindelse benyttet mig af mange af de metoder, som vi har lært i ISU. Jeg har haft specielt fokus på, at få implementeret de metoder vi har lært omkring eventbaseret tråd-kommunikation, da det var oplagt til produktet, og har desuden suppleret det med egne undersøgelser af TCP/IP socket-forbindelser og MySQL-forbindelse i C++. I sidstnævnte forbindelse har jeg opnået en god erfaring med kompilering og linking af 3. parts biblioteker i C++. Da FlexPMS er et relativt stort program (i forhold til vores tid og tidligere erfaringer) var det også en udfordring at få designet programmet, så boundaryklasser, domæneklasser og controllers var pænt adskilt men alligevel kunne interagere med hinanden på fornuftig vis. Her har især sekvensdiagrammer været en stor hjælp. I løbet af projektet har jeg desuden fået god indsigt i, hvordan Git fungerer, en disciplin som 24 af 32

27 jeg kun havde svag erfaring med før vi startede, men som jeg ikke er i tvivl om er en rigtig god kompetence at besidde. Mit arbejde på FlexPMS har foregået i tæt samarbejde med Kasper, som lavede alt kommunikation ud til de fysiske busser. Det har været et godt forløb, hvor vi har suppleret hinanden løbende, og delt de erfaringer vi har opnået gennem især ISU øvelserne Kalle I dette projekt har jeg arbejdet mest med udvikling af PSoC enhederne Kar, SensorØ og Fieldsensor. Desuden har jeg stået for en del af de bagvedlæggende systemer til vores "udviklingsmiljø"så som github, waffle.io, sharelatex og travis. Jeg har brugt en del viden fra GFV og nogle design patterns fra ISU. Den mest udfordrende del kommer helt sikkert fra AVSLibraryet, da vi ikke har fået undervisning i custom komponenter, samt PSoC Creator har store forskelle mellem de forskellige versioner. Det har dog været ret tilfredsstillende at bagefter kunne lave drag n drop med ens egne komponenter, da det har giver meget større overskuelighed på de enkelte enheder, samt været utrolig let at rette fejl. Ved at stå for de bagvedlæggende systemer har jeg fået meget erfaring i at koble systemerne sammen, og derved letne arbejdsbyrden, jeg nåede ikke at få mig sat ind i Doxygen til dokumentation, og dette er helt sikkert en fejl i forhold til tid der er blevet brugt på dokumentation af kode. Der har desuden også været lidt mangler i styring af projektet Karsten I min del af projektet er der blevet arbejdet med ph-proben og jordfugtmåleren. I arbejdet er der blevet inkluderet viden fra fagene EFYS, GFV og MSE. Det har været spændende at inkludere viden fra sideløbende undervisning og det har på den måde fremmet forståelsen for fagene. Undervejs har det været en udfordring at vide hvad der skete på softwaresiden, da systemerne hele tiden blev lavet om og meget af det der er blevet lavet er uden for mit vidensområde. Af opnåede erfaringer kan nævnes udlægning af print som har været helt nyt. Her har der været nye programmer der skulle læres at kende og det har givet et godt grundlag for efterfølgende semesterprojekter, da dette vil lette arbejdet med prototyperne. Endvidere er projektet blevet lavet via et revisionsstyringssystem samt rapporten er blevet skrevet i LaTeX. Dette har vist sig at være særdeles nyttigt Kasper Til at starte med har jeg undervurderet hvor hurtigt dette projekt forløb kom til at gå, der har været fuld fart på fra start af. Når et forløb går så stærkt er det vigtigt at have en leder der har det store overblik, vi har kørt det mere løst hvor der ikke var en der stod for at samle os og følge op på arbejde, det er noget jeg vil tage med videre. Dog føler jeg at det er svært at når projekt arbejdet kører sideløbende med undervisningen i andre fag. Min egen rolle i dette projekt har været software udvikling og her har jeg lært at en god plan kan gøre meget for at lette arbejdet. Hvis der ikke er en aftalt plan så giver det problemer hen af vejen. Det har været sjovt at kæde de forskellige 3. semesters fag ind i projektet det har også givet anledning til ændringer undervejs når man lige lærte et nyt design pattern i ISU, eller fandt ud af at PSoC platformen kunne noget mere i GFV. Alt i alt har det været et udfordrende og læringsrigt projekt som har givet meget i forhold til hvad der skal til for at styre et projekt, også i forhold til hvis der kører agile metoder. Det er vigtigt at have en leder om det så er i form af en Scrum Master eller andet er mindre vigtig. det har også givet meget i forhold til at bruge det jeg har lært i undervisningen. Det har også været lækkert at udvide min kendskab til værktøj som git og LaTeX Kenn I dette projekt har jeg primært arbejdet med på hardware-siden, med design og implementering af styringskredsløb til ventiler og pumpe, samt counter-kredsløb til flowsensoren. Derudover har jeg udviklet første iteration af software, samt tests til ventil- og pumpestyring. Tilsidst har jeg stået for at designe og udlægge prints til de 3 shields, hvilken grundet tidspres og leverngsdatoer ikke nåede at komme 100% med i dokumentationen, men disse forventes at være klar til præsentation til fremlæggelsen. I mit arbejde har jeg trukket på den erfaring jeg har fået, primært i E3MSE, E3FYS 25 af 32

28 samt GFV. MSE og GFV primært til udarbejdelse af styringskredsløb, og EFYS i forbindelse med udlægning af print til forståelse af støjoverlejringer. Af opnåede erfaring har det været helt nyt for mig at arbejde med Eagle og udlægning af print med alt hvad det indebar. Dette er helt sikkert en fordel at ha lært, både til senere samesterprojekter, samt til brug udenfor skolen. Derudover er der i projektet blevet benyttet LaTeX til fremstilling af dokumenter, samt git til versioncontrol, begge disse 2 værktøjer har krævet en del tid at lærer at administrere. Til sidst har det, i dette projekt, til forskel fra de tidligere semestre været meget mere adskilt SW/HW. Derfor har det været utrolig lærerrigt at læse softwarearkitekturen som "udefrakommende", og forstå denne Lærke I arbejdet med projektet har jeg opnået en lang række faglige erfaringer. Jeg arbejdede med GUI en og derfor kom jeg ind på både php, html, databaser, jquery, mm., hvilket har været uden for mit pensum og til trods for at skulle arbejde med et nyt sprog som f.eks. php, kunne jeg stadig bruge mine erfaringer med objekt-orienteret programmering. Men selvom der forekom problemer med at arbejde med noget uden for pensum, viste det sig at være nogle værktøjer, der løste mange af problematikkerne i kravspecifikationen. Da projektet er delt op i flere moduler, men også delt op i hardware og software var der en del overvejelser der skulle gennemtænkes. Dette demonstrerede hvor vigtigt det er at have en god kommunikation i gruppen, som også har vist, at det er en god ide at bruge de scrum inspirerede metoder til projekt gennemførelsen, da det altid var vigtigt at holde status på processen, men også kommunikationen mellem moduler Thomas I 3. semesterprojektet har jeg udover projektdokumentation arbejdet med PSU og RSConverter. I mit arbejde med hardware udvikling har jeg inddraget viden fra fagene EFYS, EEV, MSE og GFV. Strømforsyningen har været den største men bestemt også den mest interessante opgave jeg har arbejdet med. Jeg har haft mulighed for at udforske emner på egen hånd, som f.eks. regulering. Reguleringskredsløb er bygget op del for del, hvilket har medført mange ændringer undervejs, men også en god forståelse for hvad de forskellige fænomener skyldes. Projektet vi har valgt har været rigtig spændende. Forløbet fra idéen frem til prototypen har været meget lærerig. Den allervigtigste erfaring jeg tager med mig fra projektet er, hvor vigtigt det er med kommunikation imellem projektdeltagerne. En god kommunikation forhindrer misforståelser som senere hen kan skabe små såvel som store problemer Fremtidigt Arbejde Projektforløbet er endt ud i en funktionel prototype. Prototypen gennemførte accepttesten og var et godt proof-of-concept. I det følgende afsnit vil det fremtidige arbejde og videreudvikling af systemet blive diskuteret. I forlængelse af projektet er der nemlig flere muligheder for, hvordan produktet kan videreudvikles. Mange af ideerne, fremlagt i projektformuleringen, er stadig en realistisk del af et endeligt produkt. Disse ideer vil blive delt op i 3 punkter HW PSU Strømforsyningsprototypen opfyldte dens funktion med små fejl og mangler. Spændingsreguleringen var opsat således, at spænding baserede sig på flere komponent som alle kommer med en tolerance. Dette gør at spænding vil variere fra produkt til produkt, og i værste tilfælde ikke være i stand til at opfylde dens funktion. Derudover var der ved hård belastning (ca. 50% af den maksimale effekt), en tendens til at der opstod en 100Hz rippel på spændingen. Der er foreslået 2 ændringer til at løse disse problemer: Indføre flere elektrolytter på udgangen for at stabilisere spændingen ved hårde belastninger. 26 af 32