I detta kapitel behandlas diskussionen för de olika delarna i projektet som metoden där kamerahuset skulle konstrueras, valet av de olika komponenterna, mjukvaran som skulle tas fram samt resultaten och felkällorna.
6.1 HÅRDVARA
Eftersom det inte fanns någon färdig modell på hur kamerahuset skulle se utan bara vissa riktlinjer så som diametern på aluminiumcylindern som skulle svarvas samt hur den skulle fästas i mätriggen fick mycket fantasi användas vid konstruktionen av den. Eftersom kamerahuset skulle svarvas ut ur aluminiumblocket tog de väldigt lång tid att få ut kamerahusen. Ett kamerahus tog 10 timmar att svarva till locket och bottendelen och eftersom 8 stycken kamerahus skulle tillverkas var det en tidsåtgång på två stycken arbetsveckor. Om dessa kamerahus skall i framtiden produceras i stor skala till Absolicons drivlinor kan en ny konstruktion på dessa kamerahus bli aktuell som skulle minska tillverkningstiden för dessa. Anledningen att denna metod valdes var för att få fram snygga och robusta kamerahus som skulle ge en wow-faktor.
Kamerahuset var ursprungligen dimensionerat för 5V då det är spänningen som både datorn och LED-belysningen drivs på. Sedan uppdagades de att kablarna till kamerahuset från OCCU skulle vara 25 meter långa och spänningsfallet i de kablarna blir alltför stora och komponenterna skulle inte få tillräckligt med spänning, även om tjocklocken på kablarna skulle öka så skulle alldeles för tjocka och dyra kablar behöva användas och är inte ekonomiskt försvarbart samt att de inte skulle få plats i kabelstegen på mätriggen. Istället valde jag att ändra spänningen till 24 V vilket är industristandard och lägga till en ytterligare komponent i kamerahuset. En likströmsspänningsomvandlare som omvandlar spänningen till 5 V.
Den första omvandlaren som valdes var väldigt problematisk då den inte var isolerad och tänkt att sitta fastmonterad på ett kretskort. Detta fungerade mindre bra då omvandlaren låg direkt mot kamerahusets aluminiumbotten. Därför valdes en ny modell på omvandlare som var isolerad. Ett annat problem som kunde ha uppstått var värmealstringen av de elektriska komponenterna i kamerahuset då de är en stängd miljö utan luftflöde genom den. Vid för hög temperatur kan elektroniken sluta fungera korrekt. Eftersom aluminium har utmärkta egenskaper för transport av värme blir detta inget problem. För att ytterligare minska värmealstringen fästs omvandlaren mot kamerahusets botten som får agera kylfläns.
LED-belysningen var det som var absolut mest problem med. Den var väldigt känslig och lödningen av denna kunde enkelt skada kretsarna på LED-belysningen vilket resulterade i att den inte fungerade alls, sporadiskt eller med olika färgdefekter. Lödningen var svår att genomföra då de var små kontaktytor att löda fast kabeln på. Dessutom är LED-belysningen placerad mot aluminium i locket. För att förhindra kortslutning tejpades undersidan av LED-belysningen med kapton tejp som är isolerande. Det som skulle ha ändrats på här var att utrymmet för LED-belysningen skulle ha dimensionerats större samt att ledbelysningen inte skulle ha legat mot ett material som leder ström. Ett annat val som skulle kunna ha gjorts var att byta ut LED-belysningen mot ett som passar bättre i industriell miljö men då stor tid hade lagt på att lägga till det i programmeringen samt tiden inte räckte till fick jag göra de bästa av LED-belysningen jag hade. Flera av dessa komponenter fick kasseras av skada som uppkom vid lödning eller när strömmen slogs på till kamerahuset.
Kameran som sitter på kameramodulen som används i kamerahuset vilar på en kudde som gör att kameran kan vinklas lite åt olika håll och de kan skilja några millimeter mellan kamerorna. För att kunna kompensera för detta används en kalibreringsbalk som kamerorna får titta på och mjukvarumässigt förskjuter bilden så att den ska vara helt ortogonal mot tråget. Detta är viktigt då antaganden och de man utgått från i teorin är baserat på detta och en sned kamera
är en officiell Raspberry Pi kameramodul och de redan fanns många fördefinierade funktioner för att manipulera kameran används denna eftersom de skulle ta alldeles för mycket tid att programmera egna funktioner för dessa.
I det stora hela har konstruktionen och monteringen av kamerahuset varit lyckad och slutprodukten blev estetiskt tilltalande.
6.2 MJUKVARA
Anledningen till programspråket Python valdes är för min egen erfarenhet i det samt att det är ett för-installerat programspråk på Raspberry Pi. Dessutom så var arbetet påbörjat i Python när tesen testades i lab-miljö.
För att försäkra sig om att huvudprogrammet alltid körs så används scriptet watchpanda.sh genom att titta på de aktiva processer som finns. Dock är detta inte hundra procent tillförlitligt och det har observerats att ett nytt program har startats fast det redan fanns ett aktivt program. Detta gör att båda programmen kraschar då de använder samma ID för att ansluta sig till brokern i centraldatorn. Det är dock sällan att det händer men för att förhindra detta skulle en ny design i programmet behövas eller hur de aktiva processerna tittas på.
Eftersom LED-belysningen inte är anpassad för att köras på en Raspberry Pi och att varje LED lampa styrs individuellt så måste olika väntetider läggas in för att få LED-belysningen att fungera som tänkt. För att inte dessa väntetider ska påverka kantdetektionen och hastigheten som kameran som tar kort fick de läggas på en separat programtråd kallad ”thread” där dessa körs parallellt och väntetiderna inte påverkar resten av programmet. Nackdelen med att använda denna LED-belysning som inte är avsedd för raspberry pi är att man måste köra programmet som super user (sudo) vilket gör att man kan ändra systemfiler i datorn och risken för krascher ökar då en del av programmet skapar filer. Det man skulle kunna ha gjort annorlunda är att lägga LED-belysningen i ett separat program och kört de som super user och anslutit de till brokern i centraldatorn.
Kantdetektionen i programmet är relativt känsligt då det identifierar de största konturerna i bilden. Receiverröret är tänkt att alltid vara den största konturen som blir då det är ett svart rör som reflekteras genom hela solfångaren. Om andra större konturer hittas kommer detta leda till att kantdetektionen ta den konturen istället för det reflekterade röret och beräkningen för plåtens normalvinkel i denna punkt kommer bli helt fel. Därför är det viktigt att minimera störningar så mycket som möjligt för de som programmet kan uppfatta som en kontur. En annan sak som kantdetekteringen i programmet är känslig för är ljusstyrkan i tråget på solfångaren. Är ljuset för starkt i tråget så blir reflektionen för ljus och de reflekterade kanterna på receiverröret blir förskjutna eller inte syns alls. Detta kommer ge missvisande resultat för beräkningen av plåtens normalvinkel. Är ljuset för mörkt i tråget kommer konturerna inte synas vilket leder till att ingen kantdetektion kommer ske vilket också resulterar i ingen beräkning för dessa punkter. Det är därför av största vikt att se till att ljusförhållanden i tråget är goda men inte för starka. Det som skulle kunna ha gjorts annorlunda här är själva kantdetekteringen. Istället för att leta efter de största konturerna så skulle programmet letat efter den största rektangel som finns i varje bild och ta positionen för de långa sidorna på den som skulle motsvaras av de reflekterande kanterna på receiverröret.
I det stora hela fungerar kantdetekteringen bra om det inte finns störningar som reflekteras i tråget samt att testningen visar att programmen är stabila med ytterst få mindre buggar.
6.3 RESULTAT
Resultatet från det första testet gick bra då kopplingarna hade gjorts korrekt förutom det att den första omvandlaren strulade och därför byttes till en ny modell. Även LED-belysningen var problematisk då som det beskrivs i diskussionen i hårdvaran att lödningen av denna var problematisk men de upptäcktes inte förren i detta test då all hårdvara skulle testas. Testet var ganska enkelt men viktigt att säkerhetsställa att kamerahusets olika delar skulle fungera korrekt och detta test upprepades till alla åtta kamerahus hade fullgod funktion.
Resultatet från det andra testet visade hur bra programmet kunde följa den mall som satts upp för hur programmet skulle köras på en riktig solfångare. Det var också ett stabilitetstest som visade hur programmet klarade upprepningar utan att krascha. Det var en del buggar som visade sig på de tidigare testen som behövde ändras så att programmet klarade att följa test-schemat som hade skapats. Även ändringar i test-schemat behövde göras för att säkerhetsställa att bland annat mätdatat som skickades kom fram inom angiven tid.
Resultatet från de tredje testet visade att programmet var bra på att detektera kanter från det reflekterade receiverröret. I nästan hela tråget kunde kanterna på receiverröret detekteras. Det finns vissa försvårande ställen i tråget på kantdetektionen och dessa är längst upp och ned i tråget längs kortsidan där en svart lim-kant finns. Denna syns i reflektionen och stör kantdetektion på dessa ställen. Även längs kanterna på långsidan finns en svart limsträng som försvårar kantdetektionen där då denna stör. Ett sista ställe som försvårar är mitten då en metallist ligger tvärgående över tråget. Det som störde mest var dock reflektioner från taket och en vit duk fick läggas över mätriggen för att inte mätningen skulle bli alldeles felaktig. Ramen som höll upp duken orsakade lite störningar men små i jämförelse med att vara utan duk. Detta gjorde så att det blev för mörkt inne i mätriggen och mycket tid fick läggas på att sätta upp belysning som inte störde mätningen. I figurerna 33 – 36 samt figurerna 38 – 41 ser man ett område i botten på tråget på solfången där inte någon kantdetektion finns och vad detta beror på vet jag inte. Det kan vara störningar utifrån som orsakade detta eller att kameran som inte fungerande som den skulle men svårt att säga säkert. Det är önskvärt att få detektion i hela tråget och detta är något som jobbas med genom att förfina programvaran samt uppsättning av ett skydd mot störningar runt tråget i mätriggen.
Resultatet för det fjärde testet visar en bra indikation på att systemet fungerar som tänkt då både lasern och mätroboten visar samma sak och stöds av teorin i kapitel tre. Det som kunde göras mer exakt är testet med laser på fler solfångare och minska avståndet mellan varje mätning. Men detta är väldigt tidskrävande och tidsbrist gjorde att endast en solfångare tittades på. Samma fel som i föregående test fanns och även en vit duk användes i detta test för att minska störningarna på reflektionen i tråget. Det gula bandet som kan ses i figurerna 38 – 41. i testet är en miss i kommunikationen mellan centraldatorn och kamerahuset då fler bilder per sekund togs av den kameran men det påverkar inte resultat något mer än att de finns fler mätvärden i dessa kvadrater, då färhållandet mellan träff och miss i tråget förblir detsamma.
6.4 FELKÄLLOR
Felkällor i systemet kan bero på fel i kameran på grund av en dåligt producerad kamera eller smuts som kan ha hamnat i linsen vilket kan försvåra kantdetektionen. Genom att rengöra linsen innan mätning kan detta förhindras. Fler felkällor under mätning kan vara taket över mätriggen som gör att tråget på solfångaren reflekterar annat än receiverröret vilket påverkar beräkningen utifrån den detekterade punkten. Annan felkälla kan vara den mänskliga faktorn då mätning av lasern skulle ske att man var på exakt rätt ställe och lasern inte var vinkelrätt mot tråget. Den mänskliga faktorn på alla moment kan också vara en bidragande felkälla. Denna har försökt minimeras genom att arbeta noggrant och metodiskt.