Automatisk Vandingssystem. Rettelser. 1 af 23

Transkript

1 Rettelser 1 af 23

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 23

4 Indhold 1 Resumé 1 2 Indledning 4 3 Opgaveformulering 5 4 Systembeskrivelse 6 5 Projektafgrænsning 7 6 Krav 8 7 Projektbeskrivelse Projektgennemførelse Metoder Scrum ASE modellen SysML Specifikation og Analyse Systemarkitektur Design og Implementering Software GUI Database FlexPMS Kar SensorØ Fieldsensor AVSLibrary 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 Lærke Kasper Kalle Jakob af 23

5 7.9.5 Kenn Karsten Thomas Fremtidigt Arbejde HW PSU SW Automatisk vanding Manuel vanding Fælles Konklusion 20 Litteratur 21 Ordliste 23 3 af 23

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 23

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 23

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 bruger interface 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 planterne. 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 verision af linux. Systemet kan måle fugtigheden i planterne via en jordfugt-måler der er koblet på I2C bussen. Når 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 blive opretholdt af systemet. Systemet kan måle ph-værdien via en ph-probe som sidder fastmonteret i vandkaret. Figur 4.1: Rigebillede Når systemet startes op vil vandkaret være tomt. For at fylde karet med vand, tændes der for en ventil som sidder direkte på en vandhane. Hermed vil der løbe vand ind i karet og mængden af vand vil blive målt af systemet med en flowmåler. Når der er løbet tilpas mængder vand ind i karet vil ventilen lukke og der vil automatisk blive doseret gødning indtil til en bestemt ph-værdi er nået. Skulle det ske under opfyldning af det ikke lykkedes at lukke indløbsventilen vil der blive åbnet for udløbsventilen. På figur 4.2 ses de forskellige usecases over systemet. Figur 4.2: UseCases Der er to aktører som kan tilgå systemet. Den ene er brugeren som tildaglig bruger systemet. Den anden er teknikeren som tilgår systemet ved oprettelse, vedligeholdelse og nedlæggelse af systemet. Når systemet oprettes bruges usecasen "Opret kar"her opsættes et vandkar og systemet får besked om hvilke sensore der er koblet til via usecasen "Opret Sensor Ø". En sensor Ø er et print som videreformidler dataen fra fx. jordfugtmåleren. Det vil væremuligt at koble flere typer af sensore til fx. en temperatur måler eller flere af samme type. Når karet er oprettet skal phproben kalibreres "Kalibrer ph-probe", dette skal gøres en gang hver måned for at kunne sikre en korrekt måling. På selve vandkaret er der en styring som vi kalder for "karprintet"her er ph-proben koblet til. Der vil være en rød LED som lyser på karprintet 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. Karprintet vil herefter indlæse værdien og den røde LED skifter til en grøn. usecasen "Fyld kar"bruges når karet skal fyldes manuelt. Her gives der mulighed for at åbne indløbsventilen og stoppe den når den ønskede mængde vand er løbet ind. I usecasen "Indtast ph-værdi"gives der mulighed for at indtaste en ph-værdi som systemet skal tilnærme. Det samme gives der mulighed for i "Indtast volumen". I usecasen "Aflæs målinger"går brugeren ind og aflæser værdierne fra sensorerne hvis det ønskes at se hvad statussen er. Usecasen "Manuel vanding"giver mulighed for at vande manuelt. Dette kan være ønskeligt hvis systemet har fejl ved sensorene. Usecasen "Tøm kar"bruges til at tømme karet og "Slet kar"er for at nedlægge et oprettet kar. 6 af 23

9 Projektafgrænsning Fra projektets start var det meningen at hele processen skulle ske automatisk. Dette viste sig at det blev en problem da tiden hurtigt løb fra os og vi fik derfor kun implementeret det manuelle. 7 af 23

10 Krav I dette afsnit beskrives de opstillede krav for AVS. På 6.1 ses det færdige Use Case diagram over systemet, dett et 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 Projektdokumentationen under afsnit 1.2 "Use Cases" Use Case 1 - Kalibrer ph-probe Denne use case har til formål at lade Teknikeren kalibrere den ph-probe der er tilsluttet et givent 8 af 23

11 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 Teknikeren 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 Teknikeren 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 Brugeren å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 Brugeren 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 Brugeren 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 Brugeren 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 Brugeren, manuel tilføre vand til gromediet. Use Case 9 - Tøm kar Denne use case har til formål at lade Brugeren å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 Teknikeren, 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 Projektdokumentationen under afsnit 1.3 "Ikke fully dressed Use Cases" Use Case 11 - Doser ph-væske Denne use case har til formål at Brugeren 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 brugerdefineret grænseværdier (jordfugtighed, ph-værdi og volumen) overskrides. Use Case 14 - Ugeplan Denne use case giver Brugeren mulighed for at indtaste en ugeplan for styring af dosering af ph-væske og vand til gromediet. Use Case 15 - Udprint log Denne use case giver Brugeren mulighed for at få udprintet en log over de hændelser der er forekommet i systemet, herunder optaget sensordata samt dosering af vand. For at sikre kvaliteten af det færdige produkt, er der opstillet en række krav. Disse er kort beskrevet herunder, for yderligere detaljer henvises til Projektdokumentationen under afsnit 1.4 "Ikke funktionelle krav" 9 af 23

12 Kravene 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 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. 10 af 23

13 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. 11 af 23

14 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 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 12 af 23

15 7.5.1 GUI Database FlexPMS Kar Kar Controlleren 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 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 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 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. 7.6 Design og Implementering af Hardware Systemet består af følgende hardware blokke: RSConverter Ventil-/pumpestyring Flowsensor Jordfugtsensor ph-probe Power Supply Unit (PSU) Shields til Raspberry og PSoC 13 af 23

16 7.6.1 RSConverter Figur 7.2: 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 styre den valgte pumpe og ventil benyttes et MOSFET-styringskredsløb. Figur 7.3: Styringskredsløb til pumpe og ventil Begge belastninger optræder som en spole da de indeholder et relæ som skal trækkes. Ved denne form for styring at det vigtigt at notere, at når spændingen fra spolen fjernes, vil den modsætte sig denne ændring ved at skabe en modsatrettet spænding. Denne spænding kan i værste fald beskadige nærsiddende komponenter så kredsløbet ikke længere er funktionelt. Til at modvirke dette benyttes der en såkaldt flyback diode. Derudover benyttes der en pull-down modstand til at trække gaten 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. Der er valgt en flow sensor til formålet. Jo mere vand som løber igennem sensorer jo højere en frekvens vil den sende ud på udgangen. Dette kræver dog at der over hele tiden som indløbsventilen er åben, konstant holdes øje med signalet den leverer. Dette kræver alt opmærksomhed fra PSoC4 en. I stedet kan der laves en interrupt som reagere på pulserne fra flowsensoren. Dette vil stadig kræve utrolig meget opmærksomhed fra PSoC4 en. For at fjerne dette problem er der udformet et tæller-kredsløb. Dette kredsløb tæller pulserne fra flowsensoren. Når tælleren ruller over kommer der et interrupt på PSoC4 en. Dette minimerer antallet af interrupts og giver større frihed til PSoC4 en. Figur 7.4: Counter-kredsløb Kredsløbet er opbygget omkring en 4-bit tæller (74HC393). Dertil er koblet en AND-gate som gør, at når tælleren rammer 10 giver den interrupt-signalet til PSoC4 en. Det allerførste der sker i ISR-rutinen er at tælleren nulstilles 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. 14 af 23

17 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.5 ses et diagram over jordspyddet.../projektdokumentation/hardwarearkitektur/sensore/jordfugt_bi Figur 7.5: Diagram over jordspyddet Den valgte mikroprocessor blev en PSoC 4. I figur 7.6 ses topdesignet over designet.../projektdokumentation/hardwarearkitektur/sensore/jordfugt_bi Figur 7.6: 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 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.7 ses diagrammet. 15 af 23

18 ../Projektrapporten/Projektbeskrivelse/DesignOgImplementeringA Figur 7.7: Diagram over ph-proben På figur 7.8 ses topdesignet i PSoC creator.../projektrapporten/projektbeskrivelse/designogimplementeringa Figur 7.8: Topdesign i PSoC creator 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 7.9. Forskellen til 12V-forsyningen er D 5 og R 4. Figur 7.9: 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 det er derfor valgt at placere alle disse på såkaldte shields. Der skal laves 3 forskellige: PiShield Kar-shield Ø-shield Ved at samle kredsløbene på disse shields opnår man langt færre ledninger imellem de forskellige blokke. Dette reducerer samtidig med mulighed for støjindlejring fra omverdenen. 16 af 23

19 At udlægge print 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 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". Et OSC-screenshot af støjen ses p fig.1 XX INDSÆT SCR- støj. 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 devæ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. Videre arbejde: Ved en videreudvikling af systemet kan styringen af doseringspumpe og ventilstyringen forberedes ved bedre afkobling. 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 17 af 23

20 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 invidividuelt, 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 Lærke Kasper Kalle Jakob Kenn Karsten 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 har endt ud i en funktionel prototype. Prototypen gennemførte accepttesten og var et godt proof-of-concept. Under dette afsnit vil vi diskutere det fremtidige arbejde som ville opstå i tilfælde af, at projektet skulle færdigudvikles. I forlængelse af projektet er der nemlig flere muligheder for, hvordan produktet kan videreudvikles. Mange af ideerne, fremlagt i opgaveformuleringen, er stadig en realistisk del af et endeligt produkt. Disse ideer vil blive delt op i 3 punkter. 18 af 23

21 HW PSU Strømforsyningsprototypen opfyldte deres 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. Indsætte et potentiometer i spændingsføleren som derved kunne indstille spændingen på udgangen SW Automatisk vanding Baseret på at en Bruger kan indtaste en ønsket værdi på jordfugtigheden, aflæse data fra en jordfugtsensor og vande plantere via en GUI, kunne det være en kæmpe fordel, hvis systemmet blev implementeret så vandingen skete automatisk. Her ville vandingen være baseret ske når den målte jordfugtighed er for lav i forhold til den indtastede. Manuel vanding Ved manuel vanding kunne man give brugeren mulighed for at vælge hvilke Sensor Øer der skal vandes ved i stedet for at der bliver vandet alle steder Fælles Hvis en doseringspumpe der doserer gødning/ph-væske, blev implementeret, kunne de give Brugeren mulighed for at gøde vandet til den ph-værdi der er ønsket, da Brugeren allerede har mulighed for at aflæse ph-værdien, dette kunne styres via GUI en. Hvis dette kunne lade sig gøre, kunne denne proces ske automatisk baseret på at Brugeren kan indtaste en ønskede ph-værdi, og systemmet kan styre ind- /og afløbsventil. Der kunne være en flowsensor implementeret på udgangen af karet, så det var muligt at beregne hvor meget vand karet indeholdte i stedet for kun at aflæse hvor meget vand der kommer igennem indløbsventilen. 19 af 23

22 Konklusion 20 af 23

23 Litteratur Andrew Frueh. Andrew Frueh. The Soil Moisture Sensor. URL Apache Software Foundation, Apache Software Foundation. Apache 2.0. Apache Software Foundation, URL Biltema, Biltema. Inline-Pump, URL Bootstrap, Bootstrap. Bootstrap. Bootstrap, URL Cypress, Cypress. PSoC Creator Component Author Guide. Cypress, URL Diodes Incorporated. Diodes Incorporated. 1N4007. URL Hydralectric. Hydralectric. Thread/Push-fit solenoid valves. URL International Rectifier, International Rectifier. 36MB120A, URL International Rectifier, International Rectifier. IRLZ44Z, URL Jin Moon Choi and Tae Wan Kim, Jin Moon Choi and Tae Wan Kim. Humidity Sensor Using an Air Capacitor, URL Maxim Integrated, Maxim Integrated. MAX3080 MAX3089, URL Michael Kerrisk. Michael Kerrisk. Linux man pages. URL National Semiconductor, National Semiconductor. LF356N, URL NXP Semiconductors, NXP Semiconductors. 74HC08, URL NXP Semiconductors, NXP Semiconductors. 74HC393, URL Oracle, 2015a. Oracle. Mysql Oracle, URL Oracle, b. Oracle. MySQL Connector/C++ Developer Guide. Oracle, URL Talema, Talema. Ringkern-Transformatoren für allgemeine Anwendung, URL Texas Instruments, Texas Instruments. The RS-485 Design Guide, URL 21 af 23

24 The jquery Foundation, The jquery Foundation. JQuery. The jquery Foundation, URL Vishay Siliconix, Vishay Siliconix. IRF9Z24, URL YIFA Electronica. YIFA Electronica. YFS201. URL Zonge International, Zonge International. Optical, structural, electrical and magnetic properties of ore minerals reference URL 22 af 23

25 Ordliste AVS Automatisk vandingssystem. CentralControl er systemets centrale computer. Database gemmer brugerens indstillinger samt log. Doseringsventil åbner og lukker for tilførslen af Gødningsmix til en bestemt Sensor Ø. Fieldsensor er en samlet generisk beskrivelse af måleinstrumenter, der kan tilsluttes en Sensor Ø. FlexPMS (Flexible Plant Management System) er den software, som binder brugergrænsefladen med den fysiske verdens. Flowmåler måler mængden af væske som løber gennem denne. Gromedie er det stof floran er plantet i, dette kan fx være muld. Gui er den grafiske brugergrænseflade. Gødningsmix er en blanding af vand og gødning med en bestemt ph-værdi. Kar er en beholder, der kan indeholde Gødningsmix. KarController styrer tilgangen af vand, gødning og ph-væske samt de sensor ø er der er tilkoblet denne. KarGruppe er et Kar med tilhørende KarController og Sensor Ø er. Management url adressen hvorpå guiinterfacet befinder sig. PC computer med Windows 7+ styresystem, samt Google Chrome som browser. Plante består af flora og gromedie. RSConverter et elektronisk print, som kan konvertere mellem UART 232 og RS485. Sensor Ø består af en Sensor Ø Control, en række Fieldsensorer, som måler fra et begrænset området, og en Doseringsventil. Sensor Ø Controller er controlleren i en Sensor Ø, som opsamler data fra sensorerne og kan styre Doseringsventilen. Ventilstyring en ventil, der kan åbnes og lukkes vha. et 5V-signal. Ventilen er tilsluttet 12V. 23 af 23