Prosessen for Brusdispenser

Maskin:

Som sagt tidligere skal vi altså lage en, enkelt sagt, brusdispenser.

Designmessig for min del (Maskin) kan dette både være enkelt og utfordrende.

For å starte med “skallet”. Formen på selve apparatet. Jeg har, med meg selv, gått gjennom de viktige punktene utseende, funksjonalitet og produserbarhet. I mitt hodet vil jeg at dette skulle vært et apparat med diverse versjoner som kan stå på en kjøkkenbenk hvor som helst. Den trenger heller ikke stå ut veldig i forhold til noe annet. Det skal være “rene” linjer og kunne blendes inn slik at det ser ut som en del av kjøkkenet.

Men hva er “rene linjer” og hvordan blendes det inn i et kjøkken? Jo, jeg tok turen inn i mitt eget kjøkken, min mors kjøkken, venners kjøkken og selvfølgelig kikket hva som blir solgt. Noe man så i repetisjon var rektangulære/kvadratiske former. Kjøleskap, komfyr, toastjern, skuffer, skap, brødrister (til en viss grad) til og med mange espressomaskiner.

Dermed ble det kvadratiskt/rektangulært form! I tillegg til at dette designet skal passe inn i et kjøkken, vil det designmessig (altså mens jeg tegner) gi meg mange fordeler. Det er rette linjer, enkle skjøter og om jeg skulle trengt å endre på noe i ettertid så vil dette sørge for å minimalisere arbeid og tid. Det er ikke masse buer med diametere, vinkler osv. Det er for det meste 90 grader og ferdig med det.

(Det er sjeldent, men å ha en slik form var min første tanke, og jeg valgte dette som et utgangspunkt jeg skal holde meg til.)

 

Men hvordan vil det bli å produsere? Hvilke metoder skal man bruke? Er det fordelaktig med en rektangulær/kvadratisk form i forhold til produksjon?

 

Produksjon i markedet

Først og fremst, vet vi at symmetri forenkler så og si alt!

Både tegnemessig (SW) og produksjonsmessig. Men, skal vi støpe denne formen? Kutte plater og skru eller lime? Bøye metall? For all del, skjære/frese? Vel, det siste er vel bare å glemme. Masse bortkastet materiale og arbeidstid. Men så har vi støpe, bøye og skru/lime! Her begynte jeg å tenke litt. Mange apparater har ofte litt avrundede hjørner. Kanskje er flatene litt buet også. Det kompliserer jo produksjonen litt i forhold til å kutte plater og skru/lime på plass. Hvorfor ikke ha et produkt man kan gjøre både og da?! Som sagt i tidligere innlegg er dette et produkt som kan leveres i diverse størrelser og versjoner! Vi kan ha den enkleste versjonen (som vi selv har laget nå) med et kammer for væske, diverse mengder som kan serveres, og enklere og billigere design. Men kanskje en annen versjon har flere kammer og egen funksjon for f.eks. saftblanding og selvrens? Kanskje den kan måle glasset med sensorer og den kan være stemmestyrt? En kan ha mulighet til å koble til vannkran og kanskje en isbitmaskin, evt kjøler. Designmessig kan man kanskje forme eller støpe denne i en litt mer “fancy” form. Altså, man betaler da for både funksjoner og design (for de som vil ha ting som står ut). Mulighetene er endeløse!

 

I markedet ville jeg ha laget produktet av enten hardplast eller aluminium. Jeg, personlig ville valgt å støpe deler for så å lime eller skru delene sammen. Et godt eksempel å bruke i forhold til vårt produkt er espressomaskiner. Billigere versjoner er ofte av plastisk, mens de litt dyrere er av rustfritt stål eller aluminium (i blandt en blanding). Veldig mange har ofte et snitt langs midten. Altså, man støper to halvdeler og skrur de sammen. Resten av delene er enten skjært ut eller støpt, og deretter limt sammen.

Mtp at vi har en såpass enkle mål og form, mener jeg at en nesten kan støpe hele formen og skru/lime på deler som trengs, evt halve formen og skru sammen som nevnt tidligere. Skjæring av plater, skruing og pussing er selvfølgelig et godt alternativ. Jeg er dessverre ikke hundre prosent sikker på nøyaktig kostnader for de forskjellige metodene (i forhold til dette produktet) eller arbeidstid mtp forskjellige materialer, men jeg vet at dette er de to alternativene som ville bli brukt.

Målet er at produksjonen skal kunne gå kjapt nok til å nesten kunne vært satt på samlebånd (eller faktisk vært på samlebånd). En forventer jo at den billigste vil bli kjøpt mest, ihvertfall i begynnelsen. Jo kjappere og mer effektiv produksjon, jo mer fortjeneste vil man ha.

 

Vår egen produksjon

 

For vår del derimot, har vi litt flere begrensninger. Derfor gikk vi for grunnmodellen.

Hvilke muligheter har vi da for denne maskinen?

Fordeler med dette produktet er jo blant annet at den skal være stillestående på en benk. Det er veldig lite krav til styrker, hardheter o.l. Vi kan fokusere på design og enkle løsninger.

så, laserkutter eller 3D-printer er helt innenfor. CNC maskin er også et tilbud vi har, men logikken sier vel det meste om hvorfor dette ikke er valgt. For selve skallet var valget klart, laserkutter. Først og fremst kunne ikke 3D-printeren printe så store størrelser, 30cmx30cm. Hvorfor gikk vi da for en så stor størrelse? Først og fremst for å ha enkel tilgang til inventaret. En skal enkelt kunne ta inn kammeret. Det er også en god del elektronikk som vi gjerne vil ha god plass til og en ryddig, og enkel tilgang til hvis noe måtte byttes. Det også planlagt å ha en led-skjerm på dispenseren som vil også kreve en del plass. Uansett, kjappeste og enkleste produksjonsmetode her ble laserkutteren. Alle vegger er tross alt flate med kun utstikkere (spor til feste) eller utskjæringer (hvor utstikkerne skal plasseres inni). Alt kunne sees på en enkel 2D-tegning og det er rett og slett bare å kjøre på.
Altså, først har jeg tegnet alle delene. Deretter setter jeg alt sammen i en assembly.
Slik vil jeg se at delene faktisk passer sammen. De må deretter legges inn som en 2D
tegning. Dette føres videre inn i et program som er laget for laserkutteren. Når vi da har
lagt dette inn, kan vi starte kuttingen.

Under er 2D tegning av høyre sideplate. Mtp måten produktet er bygget opp vil det meste
av tegninger være veldig lik denne, men med litt diverse mål på snitt som er tatt ut.

 

Jeg nevnte tidligere spor til feste (kan se det på tegningene ovenfor). For at jeg skal kunne lime dette på plass helt rett er jeg avhengig av å ha noe “å gå etter”. Dermed kan jeg påføre lim i disse utstikkerne og innhulingene og langs kantene. Slik vet jeg at sammensettingen vil bli rett fra starten av og eliminerer utfordringer med skjevheter i ettertid.

bl.a. pga dette skal jeg skjære ut i kryssfiner ettersom dette er enklere å håndtere og noen små lister for topplokket ville ikke klart seg gjennom skjæring som pleksiglass pga tykkelsen.

Jeg kan basere sammensetningen på kun trelim.
Når det først er snakk om materialet valgte jeg for å gå for 3mm kryssfiner. Det var, som sagt, veldig få krav om styrker, men med 3mm så tåler den å bli bært rundt og flyttet på uten å i fra hverandre og sprekke opp med en gang. Tykkere kryssfiner vil da egentlig bli unødvendig kostbart.

 

Så det var ingen utfordringer med design? Firkantet, kammer og elektronikk? Jo det er her det startet. Hvordan skal vi fordele elektronikk og væske? Hvordan skal glasset stå? Skal det man dytte den på innsiden av veggene? Skal den stå halvveis inn eller helt utenpå? Blir det sensorer som skal måle glasset eller vil det være knapper, kanskje touch skjerm? Ved disse valgene ble jeg egentlig satt tilbake ettersom jeg måtte vente på klarsignal fra elektrosiden. Ideene var der, men jeg hadde egne mål å ta hånd om i mellomtiden, og muligheter jeg måtte holde åpne i forhold til elektrobitene. Min første tanke var å ha kammeret nærmest fronten, føre kablene langs siden og ha elektronikken bak i et eget rom. Utfordringen var med alt av kabler, arduino osv som ville bli kronglete å føre rundt. Ikke minst risikoen for at væske skal havne inn i mellom elektronikken. Kast..

Neste var det motsatte. Ha elektronikken fremst og kammeret bak. Problemet var da væske sammen med elektronikk. Altså faren for dette. Jeg må sørge for at væske og elektronikk ikke må krysse hverandre! Jeg tenker at jeg kanskje skal vente litt på at elektrodelen skal bli mer klar så vil ideene og løsningene komme.

 

Foreløpig er jeg ihvertfall bestemt på at glasset skulle måtte plasseres i midten pga symmetri (I dette tilfellet for øyet).

Som sagt var det ikke helt klart hva av teknologi som skulle implementeres og jeg måtte nøye meg med å tegne ned ideer uten å kunne bestemme meg 100% for noe.

 

Etter hvert fikk jeg beskjed om en touch-skjerm som skulle prøves å implementeres. Jeg skjønte fort at “symmetrien” med glasset på midten måtte forkastes. Dette ettersom jeg ikke ville fått god nok plass til skjermen, ihvertfall ikke uten at det ble veldig rotete og tett. Derfor bestemte jeg meg for å gå med glasset på en side og skjerm, evt knapper o.l. på andre siden. Prøve da å få til plasseringer som vil gjøre dette, om ikke helt symmetrisk, så ihvertfall ryddig.

Dermed ble glassplasseringen satt på høyre side (falt naturlig for min egen del). Jeg kuttet til skjermen til å være ca på høyde med området væsken kommer ut (bunn av skjermen med bunn av utgang), med hull til evt. knapper under skjermen symmetrisk om “midtlinjen” fra den.

Denne ideen førte kjapt til en optimal løsning for innsiden. Ettersom glasset var på høyre siden, var det naturlig og enklest å plassere kammer og vannpumpe rett bak den. Elektronikken kunne (og burde forsåvidt) ligge bak skjermen. Dermed kunne jeg bare legge inn en skillevegg, og væske og slange trengte ikke å krysse stien til elektronikken!

Problemet mitt var jo at jeg egentlig ikke visste helt hvilke utstyr som skulle inn i den, slik at jeg kunne ikke hundre prosent bestemme meg for akkurat dette og lage for mange planer og tegninger for fordeling inne i boksen. Uansett, så la jeg et krav i forhold til plassen de har å gå på for sitt utstyr.

 

Nå hadde det kommet beskjed om noe nytt som skulle implementeres. Dette var en vektsensor med en litt merkelig form for oppbygging (ihvertfall i mitt hode). Jeg var avhengig av en plate i bunn den skulle skrus i, samt en plate skrudd ovenfra som kammeret skulle ligge på. Dette var forsåvidt ikke vanskeligere enn å lage to plater som skulle ligge under kammeret. Hvor den nederste platen hadde en opphøyning slik at skruehodene under ikke ville gjøre den ustabil.

 

Så langt kom jeg til nå. Det var fortsatt usikkerhet med evt andre sensorer, samtidig som det var problemer med å få touch-skjermen til å fungere.

I mellomtiden kunne jeg prøve å komme på en ide for “plattformen” glasset skal sette på og “gjennomføringen” øverst. Først og fremst, etter mye tenking, prøving, tegning osv kom jeg frem til at glasset måtte stå på utsiden av dispenseren. Som nevnt, produksjonsprosessen måtte være enkel. Om den skulle stå delvis innenfor dispenseren (disse forslagene gikk mest på utseende i seg selv) måtte en begynne å kutte til flere plater, en vil ha flere ledd å ta hensyn til, flere utfordringer innvendig o.l. Er det uansett ikke enklere å ha glasset på utsiden? bedre plass for hendene, lettere å sette på plass, vaske osv. For meg var fordelene mange for dette forslaget. Derfor var det mest praktiske valget å ha en helvegg foran og evt kjøre gjennomføring og “stativ” til glasset på utsiden. Ser man på bl.a. flere espressomaskiner er det heller ikke en veldig unormal løsning. Man sparer seg selv og produksjonen for flere utfordringer, steg og kroner enn nødvendig.

 

Men, selv om dette skulle være et simpelt design som skal kunne produseres kjapt måtte man fortsatt få en følelse for kvalitet. Jeg ville ha litt mykere kanter der glasset kunne treffe, både får at ikke absolutt alt skulle være “skarpe” kanter. Dette skal tross alt stikke ut fra dispenseren. I tillegg er ikke alle like forsiktige tross alt. Allerede her eliminerte jeg muligheten for bruk for laserkutting. I virkeligheten kunne jo disse produktene bli støpt, men den muligheten har ikke vi. Så, nå var det på tide å prøve seg på 3D-printing! Det virker, og høres enkelt ut, og selv om man har en stor grad av frihet, har man også noen begrensninger. Spesielt når det skulle være en produksjonsprosess som skulle ta minst mulig tid.

 

Vi vet at den må tåle å få noen mindre smell, plastikken (PLA) som brukes tåler ok mengde juling om jeg har det tykt nok. Jeg trenger ikke skru i det ettersom jeg bare kan lage spor og evt lime. PLA er tross alt såpass porøst at å lage gjenger og skru dette vil fort både sprekke det og begynne å smelte det pga varme ved skruing. Men husk, ikke for tykt, da tar det lenger tid igjen! Jeg har valgt alt av vegger o.l. i 3 mm plater. 3 mm plastikk vil tåle det lille støtet et glass vil påføre, en regner med at folk ikke kaster et glass rundt omkring. Det er tynt nok til at det ikke vil ta en evighet å printe og en har forenklet design og tankeprosess med å ha alt i samme tykkelse. Om jeg plutselig fant ut jeg kunne laserkutte så slipper jeg også å endre for mye av designet. 3 mm ble det. Delen under glasset ville jeg skulle ha et “rom” hvor overflødig væske kunne renne ned i. Jeg må da ha en del av det hult. Men samtidig kan jeg ikke ha det hult helt opp (Da kan jo glasset dette inn, bli skeiv og velve osv.). Jeg prøvde å lage slik at jeg kunne ha en form for “sil” eller rist implementert i delen. Problemet var at uansett, var sjansen for at jeg måtte ha en form under printingen stor. Noe som gikk i mot mitt mål med å gjøre produksjonsprosessen så enkelt som mulig. Det enkleste jeg kunne gjøre var å lage en rist som en egen part. Noe som var lurest i etterkant da man kan fjerne den for å lettere skylle dette lillet kammeret. Nå slapp jeg også ha i en form da det rett og slett var en hul “firkant”. Det ble også laget en vegg inn mot dispenseren siden dette måtte være tett. Noe som hjelper strukturmessig under printing (for å slippe en støtteform).

“Gjennomføringen” over der slangen kommer ut er rett og slett nesten en replika av bunnen, med unntak av at den var helt hul utenom delen som peker ned mot glasset hvor det kun var et lite hull for slangen. Nok støtte for å slippe å ha noen form!

For å gi en forklaring om det var uklart. Selve delene er et rektangel med en avrundet kant.

 

Nå i ettertid da jeg skrev ut så jeg at jeg hadde gjort en middelmådig viktig feil. Jeg hadde laget gjennomføringen (delen øverst) for tynn i SW slik at den ble kun 1mm i tykkelsen. heldigvis er det lite som skal røre den delen i bruk slik at det ikke er stor fare for den. Om jeg hadde hatt tid og mulighet, ville jeg rettet på det og laget den litt tykkere (Altså jeg er klar over feilen jeg gjorde). Samtidig ble delen som glasset står på litt i tykkeste laget fordi jeg skulle ha muligheten til å legge på rista uten at den datt gjennom. Igjen, en feil jeg er klar over og som hadde vært endret om jeg hadde mulighet til å lage den. (Pga usikkerhet med utstyr o.l. måtte jeg vente ganske lenge før jeg kunne skrive/kutte ut alle delene slik at vi slapp å gjøre prosessen gang på gang og sløse penger på materialer)

 

Altså, nå er vi nesten klar med alt utvendig. Vi mangler fortsatt informasjon om evt skjerm, knapper og sensorer og generelt hvilke komponenter som skal være med

Vi har et “nestensvar”. Noe som tilsier at det blir resultat pga tid. En hadde fortsatt ikke klart å få til funksjonen for touch-skjermen, og det blir bestemt å kjøre en mindre og enklere skjerm med to knapper under for å velge mengde væske.

Målene ble tegnet inn og kuttet i SW. Det var nå litt mer bevisst hvor mye elektronikk (kabler osv) som skulle være tilstede. Jeg lagde en enkel skillevegg med litt mer plass på høyre side (ved kammeret og pumpa) enn på venstre. Høyden gikk halvveis opp slik at en skulle ha muligheten til å fikse og sette sammen i dispenseren. I et virkelig produkt hadde man også laget et lokk for å dekke til dette. Noe som var unødvendig i vårt tilfelle mtp at det må sees og vurderes, samt jobbes med under prosessen.

Mulighetene for at kammeret velver er stor om en må flytte på dispenseren, noe som fører til risiko for blanding av vann og elektronikk (det er jo fraskilt, men best å være på den sikre siden!)! En enkel og god løsning var å lage ei plate hvor det var skjært ut plass til kammeret. Denne fester jeg i sideveggen og skilleplaten i midten, som var plassert litt lavere enn toppen av kammeret.

 

Når det kommer til væskekammeret, skjærte jeg ut plater og lagde et kammer? Nei. Først og fremst er det lim; kjemikalier i drikkevann er ikke en risiko jeg er villig til å ta. Å skru sammen noe, evt 3D printe (Porøst og dermed vil det med tiden sige væske gjennom), for så å male et vanntettende belegg gir foreløpig for mye arbeid i forhold til kravet jeg har satt meg selv. Derfor tenkte jeg, “Hva hadde man gjort om man skulle produsert dette i markedet”? Jo, en hadde enten støpt dette eller formet kammeret. Derfor, pga muligheter på skolen, valgte jeg å bruke en form for matboks med lokk hjemmefra som kammer. Dette er tross alt en prototype. Det viktige er at man kan forstå hva man skal frem til og hvordan det burde gjøres i en “virkelig” produksjon.

 

Ved det jeg forteller her så virker det som om det ikke var en stor utfordring og masse prøving og feiling. På en måte er det litt sannhet. Først og fremst, er vi kun en maskin og en elektrostudent. Mulighetene vi har for å implementere masse teknologi er veldig begrenset. Derfor var det ikke ekstremt mange krav til maskindelen i forhold til implementering av teknologi. Samtidig hjalp valget med å ha enkel form veldig mye. Evt småendringer krevde ikke at jeg måtte endre på en hel masse andre detaljer.

 

Mitt mål var å se det som et produkt jeg skulle sende ut i butikkene umiddelbart. Jeg ville se hva som skulle til å for å minke tid på produksjon, design og kostnader. Dette blant annet ved å bruke informasjon jeg har lært tidligere. Først og fremst, symmetri. Nummer to, jo færre kompliserte former, jo enklere å designe og tegne. Spesielt dette gjorde alt lettere for meg. Ved å ha rette former og mye like mål, var det enkelt å implementere både deler som skillevegg, og endre på design og plassering som f.eks. posisjon for glass, oppdeling mellom elektronikk og væskebeholder osv. Om det skulle vært implementert flere deler og mer teknologi ville dette også vært relativt enkelt. Det er god plass innvendig, og på veggene. Utfordringen min var å kunne komme med ideer som kunne passe diverse løsninger uten å vite hvilke løsninger som trengs. Altså, ettersom det tok tid å finne ut av hvilke komponenter som skulle inn og hva slags funksjoner vi ville ha, måtte jeg ha muligheten til å endre mål o.l. enkelt. Jeg visste det ville bli trangt med tid for min del, men jeg måtte bare gjøre det beste ut fra situasjonen.

Fra det tidspunktet jeg ikke fikk gjort mer, til tidspunktet jeg fikk nok informasjon til å lage mer gikk det mye tid. Mye tid som kunne bli brukt riktig om man hadde noen pekepinn. Uansett følt jeg at jeg lærte en god lekse. Planlegging er viktig først og fremst, alle ideer bør tegnes ned eller dokumenteres. Enkle design sparer deg for masse tid, penger og, ikke minst, stress. Samtidig kan det fortsatt se pent ut. Hadde jeg hatt litt flere muligheter, materialer osv på skolen hadde jeg nok kanskje prøvd å forme aluminium eller lignende. Jeg kunne også godt tenkt meg å hatt en liten kjøler og evt prøvd å finne muligheter å spare så mye energi som mulig ved å f.eks. å funnet materialer, evt foring, som kunne holdt den kjølige luften så lenge som mulig. Mtp at jeg er maskinstudent og ikke elektro, var det lite jeg hadde å si der, men det er en ide jeg har sittet og tenkt for meg selv. Uansett, til syvende og sist er jeg fornøyd med valgene jeg har tatt. Jeg har sett hva som gjør en produksjon effektiv, og dermed skjønt hva som kan gjøre det stikk motsatte. Jeg kunne uansett ønske vi var en full gruppe slik at vi kunne implementert mer. Hatt flere maskinstudenter slik at en kunne hatt iterasjoner sammen og lært flere muligheter. Jeg føler det hadde vært lettere å komme på fler ideer og løsninger om vi hadde hatt et par hoder til, både maskin og andre linjer. Noe jeg føler ville gjort dette mer spennende og dynamisk. Jeg har også da i ettertid nå sett noen deler jeg kunne gjort annerledes (Mulig det kunne vært oppdaget før om vi var flere øyne og hjerner) og til en viss grad forenklet byggingen. Blant annet laget flere posisjonsområder (utstikker o.l.), kanskje kunne jeg hatt et annet design på gjennomføringen og støtten for glasset. Uansett har jeg prøvd å gjøre det beste ut av situasjonen og vil si meg relativt fornøyd mtp tiden diverse prosesser tok.  

Elektrodel:

Jeg og Justin har dannet en liten gruppe og på grunn av at vi allerede er noen uker bak de andre, måtte vi velge noe kjapt og valget falt som sagt på brusdispenser. En elektro og en maskinstudent i en gruppe sier seg selv at det ville bli veldig mye individuelt arbeid. Her er det viktig for oss å kunne dele tanker og mål angående hvordan vi vil utføre oppgaven.  vi har satt oss ned og snakket om de ulike funksjoner vi ønsker å implementere og hvordan vi skal designe produktet. Siden det ikke var noen data studenter i gruppa, måtte programmerings delen være noe av det jeg kjente til fra før, Arduino. Jeg  startet tidlig med å programmere, og jeg valgte først å bruke tid for å styre hvor mye væske som skal renne ut i glasset. Det skjønte jeg ganske tidlig etter en prat med Joackim og Dag at det ikke ville fungere optimalt med tanke på nøyaktighet med tanke på at det vil forekomme ustabilt med strøm gjennom arduino og vannpumpa. Jeg valgte etter litt research og med tanke på hva jeg har lett tilgjengelig, å ta i bruk en vektsensor. 

jeg brukte her litt tid på å kalibrere og få implementere vektsensorene inn i resten av arduino koden. den har en egen library som jeg syns var veldig forståelig etter å ha lest litt om den.  Jeg og Justin ville også ha det litt ”fancy” så vi ville prøve å se om vi fikk til å bruke en touchskjerm. Etter en del research på nettet, og etter å ha spurt lærerne litt så fant jeg ut at vi måtte droppe den da skjermen vi fikk ikke ville fungerte selv på ferdigskrevne koder.  så valget falt på LCD-skjerm, en måned før alt skulle være ferdig.  Det ble til slutt en veldig enkel design med enkel koding, hvor vi fokuserte på at produktet klarte å gjøre sitt viktigste funksjon så nøyaktig som mulig, dispensere brus.

siste dagen gikk på å sjekke om alt funker om det var noe mer vi kunne gjøre, samt å implementere elektronikken med selve ”boksen” og sist men ikke minst lage video.

 

 

Når alt er sagt, må det sies at i starten var ideene mange. Vi vurderte stemmestyring, muligheter for å blande for eksempel saft for både mindre glass og mugger, ha et kjølesystem og kanskje muligheten for å koble til vannkran og ha en selvrenssystem. Å ha et lite “samlebånd” man kunne legge glass på, som deretter dyttet glass på plass når man skulle ha noe å drikke, var også en ide vi hadde. Mulighetene er tross alt MANGE med dette produktet. Dessverre hadde vi ikke kapasitet til å klare dette med bare oss to (noe vi skjønte veldig kjapt). Men med en større variasjon av trinn og antall personer er disse ideene absolutt ikke umulig. Vi håper kanskje neste års elever vil plukke dette opp og fullføre våre ideer.

Arduino kode Gruppe 10 DrinkMe

Sluttprosjekt Smart Drone

Oppsumering

  •  Utstyrsliste
    • 4 fire bladers propellere
    • 4 Multistar Elite DC motorer
    • 4 Electronic Speed Controller
    • 4 Ultra Sonic sensorer
    • Gyro – MPU 6050
    • 9 Volts batteri
    • 3C 11.1V batteri
    • Arduino Uno
    • Isopor

Produktet vi ønsket å skape skulle være et produkt med flest mulig bruksområder. Vi ville at det skulle kunne brukes i mange forskjellige situasjoner og av flest mulig. Derfor startet vi dette prosjektet med drøfting og diskusjon om hvordan vi ville utforme et produkt som dekket alle våre ønsker, og hva det skulle være. Gruppen gikk sammen til foreleserne og presenterte sine forslag slik at vi sammen med dem kunne være enige om et produkt som inkluderer våre ønsker og samtidig inneholde faglige krav. Produktet vi endte med å sette som utgangspunkt var en drone, med flere bruksområder og sensorer til å kunne reagere på omgivelser. Hovedmålet vårt var å bygge en drone som ville overstyre og kontrollere unna dersom en av sensorene oppdager hindringer.

En smart-drone burde være utstyrt med sensorer som kan beregne retningsbaner til objekter rundt, og kunne styre unna potensielle sammenstøt. En annen praktisk bruksmåte for å kunne bistå ved nødsituasjonen kan blant annet være at den kan styres ut til en person i nød, for eksempel fly ut med en redningsvest til en person i vannet. Droner kan være en fornuftig investering for privatpersoner som ønsker kameravinkler som vanligvis ville være uoppnåelig. På en slik måte kan man forvente at det i fremtiden vil bli plassert smarte droner over for eksempel sentrum i byer på standby for å ta imot oppdrag. Alt dette er forslag og bruksmåte vi så for oss.

 

Forventninger

Gruppens forventninger var å bygge en funksjonell drone med sensorer som kan overstyre brukeren til å unngå sammenstøt. Vi satt sammen en gruppe med fem håpefulle studenter, bestående av tre data-, en elektro-, og en maskinstudent. Med tverrfaglig kompetanse har gruppen tilrettelagt et solid grunnlag for at prosjektet skal være gjennomførbart. Ingen i gruppen har noen forkunnskaper om drone, gyrostabilisering eller avstandsmålere, derfor ser vi for oss et stort læringsutbytte ved gjennomføring. Gruppen forventer etter samtale med foreleserne at skole skal stille med flesteparten av nødvendige deler og komponenter, men er forbrett på å måtte kjøpe enkelte spesialtilpassede deler.

Studentene hadde delvis tidligere bekjentskap slik at forventningene til tverrfaglig samarbeid burde gå problemfritt. Vi regnet med å gjøre demokratiske beslutninger for å hele tiden holde gruppen samlet, og tilfredsstille flesteparten.

 

Fremgangsmåte

Som nevnt tidligere startet vi med å diskutere hvilket fagområde vi skulle basere oss på, og hva slags kunder produktet ville talt til. Da vi hadde bestemt oss og fikk klarert med foreleser at det dekket faglige krav, samlet vi oss for å diskutere hvordan designet skulle være. Vi ønsket å lage dronen spesiell og med unike trekk. Det gikk mye tid til søk på nettet etter andre droner med litt uvanlig design og research etter viktig og relevant informasjon for å bygge en drone. Ettersom vår bakgrunn med arduino besto av et relativt lavt kunnskapsnivå og tilnærmet null forståelse tok det i starten mye tid å tilvende seg språket. Underveis testet vi alltid hver eneste komponent og kartla rammeverket for vårt bruk. Dersom deler ikke opprettholdt ønsket standard eller manglet funksjoner, hadde vi en strukturert oversikt med mangler og forbedringspotensialet.

Da vi hadde bestemt oss for en drone med et isoporskall, gikk vi på isoporjakt. Etter å omsider ha skaffet isopor, startet vi med oppmåling, kutting, filing og spraymaling. Vi klarte til slutt å omforme isoporen til et skall vi var fornøyd med og som kunne brukes.

Kodene til en sammensatt drone kartla vi til å være tre hoveddeler:
–          Kommunikasjon fra styringsenhet til dronen
–          Måling av avstand til omgivelser med Ultra Sonic Sensor
–          Gyrostabilisering

Vi delte de tre hoveddelene til hver av datastudentene som utgangspunkt, slik at vi hadde en ansvarlig for hver av delene. Maskinstudenten startet på sine gitte arbeidskrav, mens elektrostudenten tok ansvar for å finne ut og beregne motorstørrelse, batteristørrelse og hvilken type rotorblader som er best egnet til vårt produkt. Da vi kodet i Arduino merket vi raskt at det letteste var å samarbeide slik at vi fant småfeil i kodene på raskest måte. Derfor ble vi stort sett gjennom hele prosjektet alltid jobbende i grupper, og fikk raskt tilrettelagt og ordnet opp i kodefeil. Likevel, tar «prøve og feile» teknikken lang tid, og mangfoldige timer ble nedlagt i denne prosessen. En av de første problemene vi hadde var at funksjonen vi prøvde på ikke fungerte med Arduino Mega, men fungerer med Arduino Uno. Det har vært slike feil som har vært prosjektet største tidstyv.

Mot slutten av prosjektet og da andre eksamener var unnagjort for flesteparten av oss ble det en siste innspurt. Vi gikk nå inn i en intensiv uke på skolen fra morgen til kveld. Vi hadde ikke kommet så langt vi skulle ha ønsket, men så fremdeles at målet kunne nåes. Lange dager, mange uforståelige feil og slitsomme kvelder har gitt oss svar og solide resultat på flere av hoveddelene, men så ikke ut til å gi oss ett sluttprodukt vi så for oss i starten. De siste ukene var det virkelig viktig at vi klarte utnytte informasjon og kunnskapen vi hadde tilegnet oss fra starten for å få ferdigstilt produktet. Vi har under hele prosjektet vært flinke til å poste hyppig oppdateringer på prosjektet for å fortelle leserne hva vi har gjort og hva vi arbeider med.

Dronen er oppbygd av fire motorer der hver av dem har sin egne Electronic Speed Controller (ESC). Det er ESCen som kommuniserer med motoren og holder orden på at motoren kjører på turtallet den har fått beskjed om. Alle motorene er originalt koblet til lik normalfart. Denne farten skal i utgangspunktet være styrt av en telefon som sender bluetooth signaler. Som vist på figur 1, inneholder dronen flere målere. Hver måler er kodet slik at dersom avstanden målt i centimetere er mindre enn en valgt varslingsavstand, vil de to nærliggende ESCene sende signaler til sin motor om at farten må økes for å styre unna hindringen. Dersom farten allerede er tilnærmet maks vil dronen gi beskjed om å senke turtallet på de to motorene på motsatte side. For eksempel, dronen kjører med en rolig fart når Ultra Sonic sensor M2 bemerker at måleren har gitt gjentatt varsler om en hindring. Da vil den sende melding til ESC2 og ESC3 at turtallet må økes for å trekke seg tilbake vekk fra hindringen. I motsetning, vil den i høy fart senke de to motstående motorenes turtall, altså ESC1 og ESC4.

Smart drone produksjon

Vi valgte å gå for laserkutting da vi skulle velge produksjonsmetode. Dette ble gjort fordi det er en kjapp og enkel måte å produsere noe på, og som gir oss resultatet raskt. Det at vi fort kan gå fra skisse til modell var noe som også bidro i avgjørelsen. Dessuten er det kun rammen som skal produseres med den valgte metoden, og ettersom at rammen har såpass simpel form vil laserkutting være mer enn nok. I tillegg er laserkutting en billig produksjonsmetode, sammenliknet med de andre metodene.

Når det kom til materialvalg hadde vi kun to krav. At det var sterkt nok, og hadde relativt lav vekt. Kryssfiner oppfyller begge disse krave. Selvsagt er det flere materialer som oppfyller begge disse kravene i enda større grad, men disse alternativene er vesentlig dyrere enn kryssfiner. Dessuten oppfyller kryssfiner kravene mer enn nok

 

Samarbeid

Ettersom at flesteparten av gruppens medlemmer hadde tidligere bekjentskap, visste vi i stor grad hva vi gikk til i dette prosjektet. Alle hadde også likt ambisjonsnivå noe som gjorde at hele prosjektet gikk enklere.

Vi etablerte fort hvilke dager vi skulle jobbe med prosjektet på, og satte opp en kumulativ timeplan. Gjennom hele prosjektet har vi klart å holde oss til denne planen, noe vi er veldig fornøyd med.

 

Det at medlemmene kommer fra forskjellige linjer er noe som har hjulpet oss enormt. Da en drone er et komplekst prosjekt som krever kunnskaper innenfor mange forskjellige disipliner har det ganget oss enormt at vi kommer fra forskjellige fagfelt.

Dersom det har oppstått uenigheter gjennom prosjekt har vi behandlet gruppen som et demokrati og hatt avstemning.

 

Konklusjon

Som nevnt tidligere, hadde vi forventninger om å få dronen til å fly, samt inneha de ønskede funksjonene. Gjennom prosjektet har vi innsett at dette er et relativt hårete mål. Prosjektet krevde mange flere timer enn hva vi først så for oss. Likevel, valgte vi å holde oss etter planen vi trodde inneholdt mer enn nok arbeidsdager, slik at det ikke gikk ut over de andre fagene som gir like mange studie poeng. Å implementere de ønskede funksjonene i dronen var vanskeligere enn forventet, og skapte mange tårefulle kvelder foran pc-skjermen. Gjennom prosjektet var det mange feil og misforståelser slik at koden ikke fungerte. Vi strevde med Electronic Speed Controller som mange ganger fikk oss til å se ut som spørsmålstegn. De var avhengige av å først få innsendt en lav verdi som tilsvarte at motorene skulle klargjøres, deretter sende en høy verdi som kunne starte rotorene. Vi har hatt ett par avstandsmålere som ikke fungerte, men likevel ikke har skapt store problemer da vi fort løste det med å bytte til en av de flere tilgjengelige sensorer vi hadde. For å potensielt kunne ha styrt dronen brukte vi ferdiglagde applikasjoner og en Bluetooth-mottaker vi koblet til arduinobrettet. Slik kunne vi enkelt lese av hvilke verdier vi sendte fra mobilen. En slik verdi var ikke problematisk å bruke til å styre en forhåndsinnstilt retning.

Ut fra våre forkunnskaper er samtlige av gruppens medlemmer fornøyde med det vi har prestert. Å bygge en drone var vanskeligere enn det noen av oss hadde forestilt oss, men føler vi har taklet oppgaven bra. Sluttproduktet ble ikke som ønsket, men vi har mestret prosjektets tre hoveddelene uten å ha fullført sammensetting.

Vi har hatt et enormt læringsutbytte av dette prosjektet. Det at vi har jobbet med medstudenter fra andre linjer og vist interesse i hverandres arbeid, har gjort at vi har fått lære mye nytt av hverandres fagfelt og gitt en bredere forståelse på sammenhenger mellom fagene. Gruppen føler at mye av det vi har lært er meget relevant med hensyn på arbeidslivet senere, i motsetning til for eksempel l’Hopitals regel.

Koder & film:

https://www.dropbox.com/s/cwktbptgslxycqw/Smart%20Drone.zip?dl=0

https://www.dropbox.com/s/34330ml1apjjmsv/25035209_1831786363498829_168588814_o.jpg?dl=0

https://www.dropbox.com/s/1ve50v8u2vjdfjs/Motor___ultrasonic.ino?dl=0

Group 6 Grand finale

Hello world,

we’ve been looking forward to this day a long time. We’re finally finished. The car assemblet and tested and it works, the documentation is finished, presentation is written, and different work requirements are delivered.

The process has been long and difficult but here we are at the end. In the report you will find every detail of our thought process in form of different documents, such as meeting reports, Brainstorming reports, Programming progression and so on. Here is direct link to google drive:

https://drive.google.com/open?id=1epZGs6IguNm7zj3AbfeQIysZCLc7Bno8

Group 6

Au revoir!

Week 49

Smart Systems code

Demo video:

 

Obtaining access to blood vessels can be difficult. Near-infrared light might be a option since subsurface blood vessels can be visualized in high contrast due to less absorption and scattering in tissue compared to visible light. Instead of using a camera with ingaas detectors, we use a near-infrared sensitivity inexpensive silicon-based detectors. Human perception is limited to the visible spectral range that is defined by the luminous efficiency functions to range between wavelengths of 380 nm and 780 nm. In contrast Si-based sensors in cameras have sensitivities extending to about 1100 nm.  Two types of scattering typically exist in the visiblelight and nearinfrared spectral range:

The more intense form of light scattering is Rayleigh scattering, this happens when only the electron clouds are distorted. This is considered an elastic process as no appreciable energy exchange occurs, if energy transfer occurs the process becomes inelastic and is named Raman scattering. This is in general a weak process involving approximately one in every 10^6–10^8 scattered photons.

The first step in developing our analytical method was find and to select the most appropriate analytical technique. This choice will depend primarily on the aspects of the technique such as:

  • The principle of analysis
  • Error sources
  • Limitations or aspects applied during the analysis process

Blood vessels that are used for peripheral venous and arterial access are typically located up to a few millimeters below the skin surface. The blood vessels are embedded in a layer of subcutaneous adipose tissue, at a depth of 1 mm to several millimeters. On top the epidermis 0.1 mm is situated, followed by the dermis 1 mm. The main chromophores in epidermis, dermis and subcutaneous adipose tissue are melanin, blood (mostly hemoglobin, fibrinogen and ALB), proteins and water. In the visible part of the spectrum, melanin and hemoglobin are highly absorptive, counteracting deep tissue penetration. In the NIR part of the spectrum (700–1400 nm), there is much less absorption by melanin and hemoglobin. However above 900 nm absorption of water is increasing, again preventing deep tissue penetration.

It is important that the light generated by the LED is safe for the eye during normal use. Since NIR light is not visible, and therefore a blinking reflex is absent, this also includes longer exposure times. The light generated by the LED is absorbed and can possibly heat the skin.

RAW image processing

There are several available baseline correction methods of the RAW images from the camera approaches with different solutions such as wavelength shifting,  first and secondorder derivatives, frequencydomain filtering and simple curve sifting of the broadband variation with a polynomial.

Partial least squares regression is a commonly used quantitative multivariate statistical tool that allows for the analysis of data with strong correlations and with noise to model a response variable when there are a large number of predictor variables[1]. Partial least squares regression can also handle data sets with more variables than samples. In analysis of biological samples, usually the most important spectral signatures are the fingerprinting peaks in the images that represent the biochemical region of the image. Binary bar-codes calculated from signs of second derivatives can be used to further remove the redundant information in the intensity fluctuation due to all the sources of intensity, this can be unexpected reflections in the image. We also lock at different methods to remove outlier images, image outlier diagnosis is a very important step to identify system faults in building reliable image sample set. Proper procedures for elimination of outliers are valuable tools for improving the quality of spectral fitting from averagedpixels. Another pre-processing method we looked at is normalization, which intensity values are rescaled for consistency. Normalizationis frequently used as a pre-processing step in preparing reference images for a qualitative identification library[2].

[1] Randall D. Tobias, SAS Institute Inc., Cary, NC,  An Introduction to Partial Least Squares Regression

[2] Bocklitz, T., A. Walter, et al. (2011). How to pre-process Raman spectra for reliable and

stable models? Analytica Chimica Acta 704, 47-56.

 

We started by trying to use the wiringpi library in python to control the movement of the servos, we soon found a few problems by doing it this way. We got a lot of gitters on the servos, so they would start twitching and move at very irregular speeds. One time it might move 300 steps and the next time it would move 150. We needed way better precision and reliability for the Angstanjagende Robot Naald.

After a little research I figured that the process that was creating the output signal from the raspberry pi were getting interrupted by other processes from the os and other applications on the raspberry pi. And since the servos are dependent on getting the correct length pulse at the correct time to move in the correct direction, this made the servo sometimes move backwards for a few steps when it was supposed to go forwards and the other way around. To fix this I increased the priority of the program to max (nice -20) and isolated the program to run on a single core or the raspberry pi, not allowing any other processes to use that core while the program was running (taskset -c 3). 

 

 

 

 

 

 

Checking the cpu usage while testing the python program.

Since the raspberry pi has a quadcore processor and there were no other heavy programs running the raspberry pi didn’t have any problems running on core 1, 2 and 3 for regular processes and core 4 for the raspberry pi program. This gave us a much more stable result. The precision was still not good enough because the servo control on wiringpi library for python didn’t allow controlling exactly how many steps the servo moved, so it was controlled by time instead. The sleep function in python was only precise down to milliseconds and to move the servo forwards it needed pulses of 1,3ms and backwards it needed 1,7ms.

Sample timing diagram for a centered servo.

The Parallax Continuous Rotation Servo is controlled through pulse width modulation. Rotational speed and direction are determined by the duration of a high pulse, in the 1.3 -1.7 ms range. In order for smooth rotation, the servo needs a 20 ms pause between pulses.

Clockwise direction.

As the length of the pulse decreases from 1.5 ms, the servo will gradually rotate faster in the clockwise direction.

Counter-clockwise direction

As the length of the pulse increases from 1.5 ms, the servo will gradually rotate faster in the counter-clockwise direction. We measured the pulse width and time between each pulse and found that the time between each servo was a lot sorter then what it was supposed to with ca 4ms between each pulse rather than the recommended 20ms.

Clockwise pulse width of 1,5ms

Counter clockwise pulse width: 1,16ms

We experienced issues with the servo motor as we noticed that it did not respond to our program commands. We decided to use an oscilloskop from the program: Digilent WaveForm, to take measurements to see the output from the raspberry Pi. Then we noticed that the pulse width was incorrect.

Because of this we threw away the idea of using python and made a new script in c, since c is a lower level language. This gives us a lot more control by manually setting the output pins for the raspberry pi. C also has the usleep function that can sleep in microseconds instead. Making it possible to give the servo the correct pulses and control the exact number of steps a servo moves. To decide how far the servo was going to move in the x and y axis we have a x and y coordinate that we get from the matlab script that analyze the picture.

When we tested the servos on the Angstanjagende Robot Naald we saw that the servos moved further backwards than forwards when it was set to move the exactly same distance forwards and backwards. We measured the offset per centimeter in each direction and added it to the x and y axis.  Now the servo moves the exact same distance forwards and backwards, so it always end up on the same spot as it started after running the entire program.

Now that the servos were moving the way they should we made a bash script to make the different scripts run in the correct order (smartSystems.sh). First taking a picture with the camera attached to the raspberry pi, then running the matlab script to analyze the picture and figure out the coordinates and then running the servo control program to move the servos and make the mark where the blood vessel in the arm is. We also made the bashscript run at startup, so we don’t need the keyboard, screen and mouse connected to the raspberry pi just the power. There were a few different ways of setting up the autostart. We figured writing the startup.sh script in the /home/pi/ folder together with the smartSystems.sh script and adding the shortcut.desktop script to the /home/pi/.config/autostart folder. This makes the smartSystems.sh script run as soon as the rest of the raspberry pi has started up, and is the solution that worked the best for us.

We wanted to check the pulse width again with the scope, and we verified that the correct pulse width was within servo specifications, as explained before.

Centered servo, pulse width: 1,5ms

Clockwise direction, pulse width: 1,3 ms

Counter-clockwise direction, pulse width: 1,7ms

 

 

07.12.2017 Gruppe 1

Vi starter der vi avsluttet gårsdagen. Motorproblemene vedvarer og vi begynner å bli rådville. På den positive siden har vi nå fått orden på hastighetskontrollen. Vi har nå mulighet til å kontrollere hastigheten ved hjelp av Serial Monitor eller potmeter. Vi har også jobbet mye med gyroen i dag, med relativt stor suksess. Gyroen fungerer som den skal, der den gir signal om at den skal stabilisere seg og motorene klarer å utføre dette relativt bra. Kanskje ikke like fort som ønskelig, men fortsatt brukbart. Hovedproblemet er at ved bruk over lengre tid vil koordinatene giroen gir ikke stemme overens med de faktiske koordinatene. Det vil si at det er en liten feilmargin hver gang den er i bevegelse, og etter hvert blir den sammenlagte feilmarginen så stor at dronen ville styrtet.

Med tanke på motorene har vi nå kommet til en dårlig, men fungerende løsning. Løsningen går ut på at vi kjører de sviktende motorene på et høyere turtall enn de andre. Noe som gjør at de tar igjen det turtallet de evt. hadde tapt pga. for lite strøm.

Smart Home

14. November 2017

Anders har brukt de siste to ukene på å lære seg SolidWorks slik at vi kunne lage modell av huset og få det kuttet slik som vi ønsker. Vi har valgt å bruke kryssfinèr til huset. Anders og Espen brukte store deler av dagen på å få modellen kuttet til (Det var mange andre grupper som skulle bruke laser kutteren denne dagen), mens Christian og Jan Helge fortsatte arbeidet med databasen og serveren. Når Anders og Espen kom tilbake med modellen, ble den satt sammen og vi kontrollerte at 7-segmentene og led fikk plass i områdene de var laget for. Alt passet perfekt!

 

21. November 2017

Vi har gjort en helomvending i forhold til prosjektet!

“Ønskelisten” over funksjoner til huset er ganske stor, men vi ikke har tilgang på alle disse delene. Derfor vurderer vi å konvertere prosjektet fra Arduino til Unity3d.

Databasen og serveren vil fortsatt bli brukt på samme måte, men vi ønsker heller at vi skal lage prosjektet i en spillmotor, slik at brukeren kan bruke prosjektet som et spill.

Vi er foreløpig usikre på hvordan vi skal få vår database til å kommunisere med Unity og motsatt, men vi ser etter noen kjappe google søk at dette lar seg gjøre. Vi gjør endringer på to-do listen slik at vi får med Unity biten.

Resten av dagen blir brukt til å legge en plan på hvordan vi skal gå fram for å få til alle løsningene vi ønsker.

28. November 2017

Hele denne uken blir brukt til eksamensforberedelser i Datamaskinarkitektur og VHDL.

 

1.Desember 2017

Vi samlet oss etter vi var ferdige med eksamen og satt i gang med SmartHome prosjektet.

Kommunikasjonen mellom Unity og det vi allerede hadde laget viste seg å være en utfordring. Det ble brukt flere timer før vi klarte å få de til å prate sammen. Jan Helge har tatt på seg jobben med å bruke udemy.com til å lære seg Blender, slik at vi kan få en skikkelig modell av huset. Vi vurderte innledningsvis å bruke ferdige assets fra Unity assets store, men ingen av asset pakkene som lå ute falt helt i smak hos oss. Vi valgte derfor at Jan Helge skulle lage vårt helt eget hus fra grunn av.


4. Desember 2017

Helgen er blitt brukt til å få kommunikasjonen mellom Unity og databasen til å fungere slik den skal.

Vi har satt ønsket temperatur i huset, og ut ifra hvor kaldt det er ute og når på døgnet det er (Hvorvidt solen er oppe eller ikke), så kan man se at temperaturen endrer seg underveis i huset. Det er også lagt inn slik at lysstyrken inne i huset endrer seg ettersom solen er oppe eller ikke.

Det oppsto problemer når vi avsluttet tråden som knyttet unity og databasen sammen. På grunn av måten Unity er satt opp, så ville ikke tråden avsluttes og vi fikk derfor opp feilmelding siden vi forsøkte å starte en ny tråd. Det tok lang tid før vi klarte å løse problemet.

Problemstillingen om hvordan vi skal få overstyrt forhåndssatte innstillinger dukker opp og vi velger derfor å endre litt på tabellene i databasen slik at vi kan ta høyde for dette. Vi legger også til noen ekstra tabeller slik at bruker kan overstyre systemet ved spesielle anledninger (filmmodus, festmodus og lignende).

Den oppdaterte listen over tabellene er som vist under:

Schedule table:

  • ID, BeginHours, BeginMinutes, EndHours, EndMinutes, WeekdayMask, Description, CreationTime, InactivationTime

Zone table:

  • ID, Name, Description

ScheduleValue table

  • ID, TargetValueID, ScheduleID

ParameterType table:

  • ID, Name

CurrentValue table:

  • ID, ZoneID, ParameterTypeID, CurrentValue

Warning table:

  • ID, Notified, Confirmed, Text, Severity, Time

Mode table:

  • ID, Name, Active

ModeValue table:

  • ID, TargetValueID, ModeID

TargetValue table:

  • ID, Value, ParameterTypeID, ZoneID

 

Er det mange Schedules som er slettet som har samme sone og verdi?

  • Hvis samme bruker endrer verdier på samme sone og samme utstyr ofte (f.eks endrer lysstyrken i stuen flere ganger iløpet av en uke), vil vi at systemet skal kunne gi bruker et varsel om bruker ønsker å gjøre denne endringen permanent i den aktive schedulen.

Mode er bestemte endringer i verdier som overstyrer schedule (filmmodus, festmodus, etc)

  • Dette vil overstyre forhåndssatt profil og vil ikke endres før bruker skrur av gjeldende modus

Bruker temp Schedule for å overstyre

  • Når bruker endrer noen av verdiene (lys, temperatur osv) så vil det bli opprettet en temporary schedule som vil overstyre den originale. Bruker vil få mulighet til å sette hvilken tid disse endringene skal gjelde til. Når tiden på temporary schedule er gått ut og ingen endringer er gjort på nytt (bruker får mulighet til å forlenge tiden hvis ønskelig) så går systemet tilbake til schedule som er fastsatt for gjeldende tidsrom.

Smarte brytere / smarte klienter som kan overstyre ting (Hvis vi får tid)

smart bryter:

  • Hvis mannen i huset ønsker å lese på sengen, men kun ha på leselys på sin side. Mannen trykker på en bryter på sin side av sengen og stiller inn ønsket tid. Dette vil da overstyre den fastsatte profilen på det spesifikke lyset i perioden han velger. Når tiden er gått ut så går systemet tilbake igjen til profilen som den opprinnelig skulle hatt på det tidspunktet.

 

5. Desember 2017

Jan Helge har gjort ferdig modellen av huset (Skallet) og han vil bruke resten av dagen på å gjøre de siste endringene slik at huset er ferdig.

 

Resten av gruppen fokuserer på det gjenstående i prosjektet.

Vi gjør Unity klar til filmen som skal lages. Dette gjør vi ved at vi programmerer en patrol-tilstand på playeren vår, slik at han går etter bestemte waypoints av seg selv. Vi gjør dette for at videoen skal kunne bli best mulig og at vi skal få vist de forskjellige funksjonene i huset.

Vi støtte på problemer når vi testet huset i Unity. Problemet oppsto når vi skulle bevege spilleren opp og ned trappen i huset. Vi satt spawn punktet til karakteren i toppen av trappen og satt waypointene i første etasje slik at han ble tvunget til å bruke trappen for å komme seg rundt. Dette gikk ikke. Karakteren ble stående på toppen og stange i trappen. Etter noe tid glitchet han seg gjennom en vegg og kom på mirakuløst vis ned i første etasje og beveget seg slik han skulle.

Etter litt research så fant vi ut at høyden på trappetrinnene var årsaken til problemet. Dette resulterte i at gangbart området i trappen var nesten ikke eksisterende, noe som resulterte i at karakterene ikke tolket trappen som et område han kunne bevege seg på. Etter justering av dette, så fungerte det utmerket.

6. Desember 2017

Modellen av huset (endret variant) overfører vi til Unity og bruker Unity til å legge textures på overflater for å få et mer naturlig utseende på huset. Dette kunne blitt gjort i Blender også, men det er veldig tidkrevende og vi har rett og slett ikke mulighet til å bruke så lang tid på det.

Vi fortsetter arbeidet med databasen da dette ble mer utfordrende enn vi trodde. Animasjoner i huset er lagt til. Figuren kan nå gå gjennom hele huset, i begge etasjer og ut og inn dører (De åpner og lukker seg).

7. Desember 2017

Siste innspurt for å gjøre ferdig prosjektet i dag. Vi jobber fortsatt med kommunikasjonen mellom databasen og unity. Vi har fått til at varmen reguleres, men det har bydd på utfordringer når vi skal introdusere moduser som skal kontrollere flere funksjoner i Unity. Vi gjør siste endringer som må til for å få laget filmen, slik at den blir klar til i morgen.

Til filmen må det lages noen elementer som vi ønsker å bruke. Dette er billboards, vei som går opp til huset o.l.

Husmodellen har nå inventar som gjør det mer realistisk.

 

Websiden

Forside

Slik ser forsiden på websiden ut. Her hentes alle moduser som brukeren har laget fra databasen og listes opp ettersom de er aktive nå eller ikke. Brukeren kan trykke på Deactivate/Activate for å deaktivere/aktivere modusen. Hvis brukeren trykker på Activate for mode 2 skjer dette:

Nederst på siden er den schedulen som er aktive nå. Denne har blitt hentet fra databasen. Tanken er at scheduler er tidsinnstilt og kan være standardinnstillingene brukeren vil ha på huset sitt. Moduser aktiveres/deaktiveres etter brukerens behov og overstyrer scheduler.

På toppen av alle sidene er det en navigasjonsbar som bruker kan bruke til å gå til en av de fire hovedsidene: Home, Modes, Schedules og Zones

Brukeren kan sette opp soner, og velge innstillinger per sone.

Zone siden

Zone siden henter alle sonene brukeren har laget fra databasen og lister dem opp. Her kan brukeren lage nye soner, ved å trykke på Create New Zone. Da lastes denne siden inn:

Her kan bruker lage en ny sone ved å fylle inn navn på sonen og en beskrivelse av hva eller hvor sonene er. Sonen vil bli lagt til i databasen når brukeren trykker på Create.

I listen over soner kan bruker trykke på Edit for en sone, da vil denne siden lastes inn:

Denne siden henter sonen brukeren vil endre fra databasen og laster informasjonen om den inn i feltene. Brukeren kan da se hva verdiene er nå, og kan eventuelt endre dem. Når brukeren trykker på Save vil endringene lagres i databasen.

I listen over soner kan brukeren trykke på Delete for en sone, da vil denne siden lastes inn:

Denne siden henter sonen brukeren vil slette fra databasen. Siden spør om brukeren er sikker på at de vil slette denne sonen, og laster inn informasjon om sonen slik at brukeren kan være sikker på at de trykte på riktig sone og får en sjanse til å ombestemme seg. Når brukeren trykker på Delete, slettes sonen fra databasen.

Schedule siden

Schedule siden henter alle schedulene brukeren har laget fra databasen og lister dem opp. Her kan brukeren lage nye scheduler, ved å trykke på Create New Schedule. Da lastes denne siden inn:

Her kan bruker lage en ny schedule ved å fylle inn beskrivelse av schedulen, start- og stopptid, og hvilke dager schedulen skal være aktiv. Bruker fylle også inn hvilke verdier hver utstyrstype skal ha i hver sone. Hvis bruker vil at schedulen skal sette temperaturen i stua på 15 grader om natten, men 20 grader på soverommet, setter bruker start- og stopptid til nattetider og skriver inn 15 under Livingroom sonen og temperatur, og 20 under Bedroom sonen og temperatur. Schedulen vil bli lagt til i databasen når brukeren trykker på Create.

Denne siden henter alle sonene og alle utstyrstypene fra databasen og lister opp alle utstyrstypene per sone.

I listen over scheduler kan bruker trykke på Edit for en schedule, da vil denne siden lastes inn:

Denne siden henter schedulen brukeren vil endre fra databasen og laster informasjonen om den inn i feltene. Brukeren kan da se hva verdiene er nå, og kan eventuelt endre dem. Når brukeren trykker på Save vil endringene lagres i databasen.

I listen over scheduler kan brukeren trykke på Delete for en schedule, da vil denne siden lastes inn:

Denne siden henter schedulen brukeren vil slette. Siden spør om brukeren er sikker på at de vil slette denne schedulen, og laster inn informasjon om schedulen fra databasen slik at brukeren kan være sikker på at de trykte på riktig schedule og får en sjanse til å ombestemme seg. Hvis brukeren trykker på Delete, slettes schedulen fra databasen.

Mode siden

Modus siden henter alle modusene brukeren har laget fra databasen og lister dem opp. Her kan brukeren lage nye moduser, ved å trykke på Create New Mode. Da lastes denne siden inn:

Her kan bruker lage en ny modus ved å fylle inn navn på modusen og om modusen skal begynne som aktiv. Bruker fyller også inn hvilke verdier hver utstyrstype skal ha i hver sone. Hvis bruker vil at modusen skal slå av alle lys i huset når den er aktiv, skriver bruker inn 0 på alle lys utstyrstypene. Modusen vil bli lagt til i databasen når brukeren trykker på Create.

På denne siden hentes alle sonene og alle utstyrstypene fra databasen og lister opp alle utstyrstypene per sone.

I listen over moduser kan bruker trykke på Edit for en modus, da vil denne siden lastes inn:

Denne siden henter modusen brukeren vil endre fra databasen og laster informasjonen om den inn i feltene. Brukeren kan da se hva verdiene er nå, og kan eventuelt endre dem. Når brukeren trykker på Save vil endringene lagres i databasen.

I listen over moduser kan brukeren trykke på Delete for en modus, da vil denne siden lastes inn:

Denne siden henter modusen brukeren vil slette fra databasen. Siden spør om brukeren er sikker på at de vil slette denne modusen, og laster inn informasjon om modusen fra databasen slik at brukeren kan være sikker på at de trykte på riktig modus og får en sjanse til å ombestemme seg. Hvis brukeren trykker på Delete, slettes modusen fra databasen.

Databasen

Databasen inneholder 7 tabeller: Zones, Schedules, ScheduleValues, Modes, ModeValues, TargetValues og ParameterType.

TargetValues lagrer verdiene brukeren vil at hver sone skal ha per parameter type. Disse linkes opp mot scheduler og moduser via ScheduleValues og ModeValues, slik at flere schedules og/eller flere moduser kan ha samme verdier i sammen sone for samme parameter type uten å måtte dobbeltlagre data.

Når bruker legger til en ny/endrer en schedule eller modus, sørger websiden for at TargetValues som ikke er i bruk av noen scheduler eller moduser slettes; sjekker om det finnes en TargetValue som allerede har en av verdiene schedulen eller modusen skal ha og linker den til schedulen eller modusen ved å lage en ScheduleValue eller ModeValue mellom dem; lager nye TargetValues med en assosiert ScheduleValue eller ModeValue; og fjerner ScheduleValues eller ModeValues mellom schedulen/modusen og en TargetValue den ikke skal ha lenger, men hvor TargetValuen hører til andre scheduler eller moduser så den ikke kan slettes.

Brukeren kan ikke legge til parameterTyper. I parameterType tabellen ligger alle typer utstyr som vårt smarthus støtter.

Unity

Vi bruker Unity3D til å simulere et smarthus. Vi simulerer varme og tid med dag/natt syklus. Vi har implementert temperaturstyring og lysstyring.

Vi har laget soner som korrespondere med sonene vi har lagt til i databasen. Smarthuset mottar en verdi for en sone fra databasen, og prøver å oppnå den verdien i den sonen ved å manipulere utstyret i den sonen.

En sone kan inneholde ovner. Når sonen får en temperaturverdi prøver den å oppnå den temperaturen ved å skru på ovnene hvis temperaturen er lavere enn den ønskede temperaturen eller skru ovnene av hvis temperaturen er høyere enn den ønskede. Dette gjør sonen kontinuerlig slik at sonen holder seg på den ønskede temperaturen.

Som en del av temperatur simuleringen vil soner som ligger ved siden av hverandre gi varme til hverandre, og de vil også få varme fra miljøet utenfor huset.

En sone kan inneholde lamper. Når sonen får en lysverdi setter den alle lysene til å ha den styrken (0 til 100%).

Hver sone har sensorer som merker om det er en person i sonen. Når det er en person i sonen setter sonen alle lysene til den ønskede verdien. Når det ikke er en person i sonen, dimmes lyset til halvparten av den ønskede verdien.

Vi simulerer tid, med en klokke som tikker. Sola følger denne klokka, og står opp kl 6, er høyest på himmelen kl 12 og går ned kl 18 hver dag. På morgen tilfører sola lite varme, midt på dagen tilfører den mest varme, på ettermiddagen tilfører den lite varme, og om natten tilfører den ingen varme.

Vi simulerer tid på året i forhold til temperatur. I juni er det varmt ute, og i desember er det kaldt.

 

Smart Home (Gruppe 9)

Vi er gruppe 9 som består av 4 data studenter ved Høgskolen i Sørøst Norge, campus Kongsberg.

Gruppen består av: Espen Rønningen, Christian Scott, Anders Kristiansen og Jan Helge Slettebø.

 

OPPGAVEN

Smart systems-prosjektet går ut på å designe et system som skal operere i sanntid og ikke ved at kun bruker skal sende inputs. Systemet skal ta sine egne avgjørelser.

Oppgaven som var gitt var helt åpen, så studentene sto fritt til å velge selv hva de ønsket å jobbe med innenfor de gitte rammene, beskrevet over.

 

22.August 2017

Dette er første dag med faget, og foreleserne gav en kort introduksjon med krav og forventninger. De gikk raskt gjennom tidligere prosjekter og gav en indikasjon på hva som var fordeler/ulemper ved at tidligere studenter hadde gjort valgene de gjorde med sine prosjekter. Studentene delte seg inn i grupper og samlet seg for å legge en slagplan for resten av semesteret. Vi avtalte at vi skulle bruke tiden fram til neste møte ved å komme med ønsker til hva vi skulle lage.

 

29 august 2017

Vi samlet oss på grupperom for å diskutere mulige løsninger på oppgaven.

Forslagene som gruppemedlemmene hadde var:

  • Selvspillende sjakk
  • Search and rescue drone
  • Smarthus
  • Fjernstyrt rygging av henger

Selvspillende sjakk:

Forslaget var at man kunne spille sjakk mot andre spillere som ikke var i samme bygg, eller brukte samme sjakkbrett.

Tanken var at en person kunne sitte med sitt sjakkbrett hos seg, utføre trekk og at disse trekkene ville bli utført på sjakkbrettet til den andre spilleren.

Search and rescue drone:

Vi ønsket å lage en drone som ved hjelp av IR kunne finne personer som var savnet, tatt av snøskred o.l. Tanken var at vi skulle lage en drone som man kunne sende opp i vanskelig terreng, som søkte med IR signaler (IR mottaker ble sydd inn i jakker o.l). Når dronen kom direkte over signalet, så skulle kraftige lys bli satt på, slik at redningsmannskapet lett kunne finne den/de savnede personen/personene.

Smarthus:

Ideen var at vi skulle lage et hus og bruke en arduino som kontrollerte forskjellige funksjoner i huset (ved hjelp av en database og et webinterface).

Fjernstyrt rygging av henger:

Man har en bil med henger som er koblet til en fjernkontroll. På kontrollen så har man to modus: en modus for bil og en modus for henger. Når man velger bil så styrer man bilen på vanlig måte. Velger man derimot henger, så styrer man hengeren dit den skal, men i realiteten så er det bilen man styrer. Bilen tar høyde for hvilken retning den må dreie hjulene for å få hengeren til å svinge den retningen den skal.

Vi tok en avstemning og valget falt på smarthus.

5. september 2017

Etter forrige ukes avstemning så satt vi igang med å planlegge hva vi ønsket at smarthuset skulle inneholde.

Under brainstormingen var dette forslagene til utstyr som vi kunne kontrollere:

  • Lys
  • Alarm
  • Temperatur
  • Lås
  • Dyr – katteluke, mating, vann
  • Plante pass
  • Doorbell (vid/bilde)
  • Markiser/persienner/temperaturregulering/solskjerming/vind
  • “You’ve got mail” postkasse
  • Værstasjon
  • Garasjeåpner
  • Brannalarm
  • Slå av inaktive ting
  • Alarmklokke
  • Detektere hvor folk/dyr er?
  • Julelys-show
  • Butler/Jarvis

Vi ble også enige om at vi skulle utvikle en App som kunne styre huset, hvis tiden strakk til.

Christian tok kontakt med Joakim, for å få oppgaven godkjent, noe den ble.

12. September 2017

Christian anbefalte resten av gruppen å ta et kurs på Asp.Net, for dette ville hjelpe oss i forbindelse med oppsett av databasen og websiden. Det ble satt av 2 uker til dette da det var et ganske omfattende kurs.

19. September 2017

Vi fortsetter med gjennomgang av ASP.net. Vi har brukt microsoft sine tutorials til dette og Udemy.com.

Vi lagde i tillegg en foreløpig utstyrsliste over hva vi trodde vi kom til å trenge:

  • 5 hvite led
  • 1 LDR
  • 1 RFID leser + chip
  • 1 IR mottaker + kontroll
  • 1 arduino
  • 1 nettverks shield + wifi?/bluetooth?
  • 1  4 x 7-segmenter
  • 4 temperatursensor
  • 1 pir detektor
  • 1 mikrofon / lyd sensor
  • 1 kamera
  • 1 buzzer

Stue:

  • Bord
  • Sofa
  • TV

Kjøkken:

  • Bord
  • Stoler
  • benk?

Bad:

  • Do
  • Vask
  • dusj/badekar?

Soverom:

  • Seng
  • skap?
  1. September 2017

Dagen ble brukt til å lage en To-do liste slik at vi fikk en anelse om tidsbruk og hvilke deler av prosjektet vi måtte prioritere. Listen ble som følger:

To-Do liste:

  • Sjekke størrelse på lekemøbler
  • Kanskje 3D printe
  • Spør admin om laserkutting og 3D printing
  • laserkutte hus/bygge hus av papp
  • Lage server
  • lage nettside
  • sette sammen arduinoen med I/O

Lys

  • 0%-100% (0-255)
  • tid
  • beholde lysstyrke i rommet

Temperatur

  • tidsstyring
  • manuell styring
  • display current temp

Ringeklokke

  • sende varsel
    • maks en i minuttet (kan stilles på)
  • lage lyd

PIR

  • sende varsel
    • alle lys blinker i minst ett minutt
    • lager lyd
  • aktiv eller ikke?

Babycall

  • sende varsel ved lyd

Magnetbryter

  • sende varsel
    • alle lys blinker i minst ett minutt
    • lager lyd
  • aktiv eller ikke?

Vi lagde også et par scenarioer slik at alt ble satt i kontekst.

Scenarioer:

Pål kommer først hjem. Han bruker RFID for å låse opp døra og lyset i stua og kjøkkenet slås på og alarmen slås av. Han går inn og merker at temperaturen går opp til ønsket nivå (vanlig hjem modus) (alternativt: han sendte melding før han kom hjem slik at temperaturen allerede var god).

Pål er sistemann som forlater huset, han skrur på alarmen og døra låser seg selv etter han har gått ut. Lyset og temperaturen demper seg til forhåndsinnstilt nivå (ingen hjemme modus).

3. oktober 2017

Vi planlegger hvordan tabellene skal se ut i databasen og hvordan de er avhengige av hverandre.

Den foreløpig listen over tabellene er som følger:

 

Profile table:

  • ID, Name, ScheduleID, Description,

Schedule table:

  • ID, Starttime, Stoptime, WeekdayMask, Description

Zone table:

  • ID, Name, Description

ZoneValues table:

  • ID, ZoneID, ProfileID, ParamterTypeID, Preset

Equipment table:

  • ID, ZoneID, Description, EquipmentType

EquipmentType table:

  • ID, Name, In/Out, ParameterTypeID

EquipmentValues table:

  • ID, EquipmentID, MinValue

Dependency table:

  • ID, EquipmentID[EquipmentType.In/Out = In], EquipmentID[EquipmentType.In/Out = Out]

ParameterType table:

  • ID, Name

Preset table:

  • ID, ParameterTypeID, Name, MinValue

Resten av dagen ble brukt til å sette opp et forslag til hvordan vi så for oss at de forskjellige ferdig satte profilene kunne se ut:

Profile:

  • p0, s1, Night time at home (weekdays)
  • p1, s2, Night time at home (weekend)

Schedule: (WeekdayMask refers to starttime)

  • s0, 00:00, 23:59, 127, Default time
  • s1, 23:00, 07:00, b1111001, Night time
  • s2, 00:00, 07:00, b0000011, Night time

Zone:

  • z0, Livingroom
  • z1, Entrance
  • z2, Bedroom

ZoneValues:

  • zv0, z0, p0, pt0, pr4
  • zv1, z0, p0, pt1, pr5
  • zv2, z2, p0, pt0, pr1
  • zv3, z1, p0, pt0, pr4
  • zv4, z1, p0, pt1, pr5

ParameterType:

  • pt0, Temperature
  • pt1, Lights
  • pt2, Access

Preset:

  • pr0, pt0, Comfort, 22
  • pr1, pt0, Sleeping, 16
  • pr2, pt1, Comfort, 80
  • pr3, pt1, Reading, 100
  • pr4, pt0, Empty, 18
  • pr5, pt1, Empty, 0
  • pr6, pt2, Open, 1
  • pr7, pt2, Locked, 2
  • pr8, pt2, Secured, 3

10. Oktober 2017

Begynner arbeidet med databasen og serveren. Vi planlegger at dette skal vi bruke god tid på slik at den blir stabil og akkurat slik vi ønsker. Ønsket er at det skal være enkelt å legge til/fjerne funksjoner uten å måtte endre kode strukturen i databasen.

Smart Mirror – Arduino: Update on the code

//////////////////Relay//////////////////////////////////
const int relay = 5;
int relayVal;
//\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
//////////////////loadCell///////////////////////////////
#include “HX711.h”
#define zero_factor 555230
#define DOUT 3 //gelb / yellow
#define CLK 2 //orange
float calibration_factor = ((200000 * 0.00045359237) + 52400);
HX711 scale(DOUT, CLK);

float valueReadLoadCell;
float valueLimit;
//\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
//////////////////Servo//////////////////////////////////
#include <Servo.h>
Servo myservo360; // continious rotation servo
Servo myservo180; // 180 servo
int direction;
int pos3 = 0;
//int pos1 = 110;
const int servPin360 = 9;
int speed = 94; // number < 90: movement clockwise; number > 90: movement counterclockwise; the actual number controles the speed of rotation
const int servPin180 = 8;
//\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
////////////////Button///////////////////////////////////
const int butPin = 12;
int butVal;
//\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
///////////////Raspberry/////////////////////////////////
char receivedChar; //
boolean newData = false;
//\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
long firstMeasure = 0;
long secondMeasure;
long interval = 7000;

unsigned long previousMillis = 0;

//_________________________________________________________________________________________
//——————————————-SETUP—————————————–

void setup() {
pinMode(butPin, INPUT);
pinMode(relay, OUTPUT);

Serial.begin(9600);

scale.set_scale(calibration_factor); // when u open the serial monitor the value should be between -0.5 and + 0.5: for setting it to 0 we will have to mount it to the box
scale.set_offset(zero_factor); // Zero out the scale using a previously known zero_factor
Serial.println(“Reading: “);
delay(5000);
valueReadLoadCell = (scale.get_units()); // get the initial value of the load cell into the variable. has to happen once in the setup otherwise the first calculation will be 0 + the interval
}

//________________________________________END of SETUP_____________________________________
//——————————————-LOOP—————————————–

void loop() {
recvInfo();
Serial.print(“Loop: “);
Serial.println(scale.get_units()); // keeps spamming the actual value of the loadCell. should be commented out if the connection is through the pi

checkButton(); // function to check if the button is pressed
if (butVal == HIGH) {
Serial.println(“called through button”);
cButton();
}
if (newData == true) { // if there is the right input data received from the raspberry PI, then start running the system
Serial.println(“called through PI”);
cPI();
}
else {
digitalWrite(relay, HIGH); // disconnect powersupply
relayVal = HIGH; // relay works inverse: HIGH = power gets disconnected from system; only the red led on relay is on
}
}
//_____________________END of LOOP_____________________________________________
//———————FUNCTIONS———————————————–
void recvInfo() { // checks if data is received from the raspberry pi
if (Serial.available() > 0) {
receivedChar = Serial.read(); // puts the value into ther variable receivedChar
if (receivedChar = ‘s’) { // if the value equals s (start)
newData = true; // set new data to true, so that the function of starting the system in the loop can get called
}
else {
newData = false; // if its not a s (start) then do nothing
}
}
}

void cButton() {
wholeSystemFunction(valueReadLoadCell, valueLimit ); // calls the function of starting the sytem started by the button
}

void cPI() {
wholeSystemFunction(valueReadLoadCell, valueLimit); // calls the function of starting the sytem started by the pi
newData = false; // after running the system, the variable has to be set to false again
delay(1000); // give time to process: found out during testing that without its more liable for mistakes
}

void wholeSystemFunction(float valueReadLoadCell, float valueLimit) {
delay(1000);
myservo360.attach(servPin360); // attach the servo that presses the toothpaste
delay(500);
digitalWrite(relay, LOW); // relay works inverse: LOW = connected to external powersupply; red and green led on relay are on
relayVal = LOW; // set the value to its start state with which the servos gets controlled

checkLoadCell(); // check the measured value on the load cell
calcNewValue(valueReadLoadCell, valueLimit); // call the function to calculate a new value

//PUSH TOOTHPASTE
if (relayVal == LOW) { // run following if the relay is on
delay(1000);
Serial.print(“In whole System Function: “);
Serial.println(valueLimit);
previousMillis = millis();
while (scale.get_units() <= valueLimit && millis() – previousMillis <= 8000) { // keep the servo running as long as the measured value, which is changing all the time, is smaller then the interval (one portion of toothpaste). stop moving if the weight is not reached within 8 seconds.
servo360(speed, valueReadLoadCell); // call function to move the servo
}
while (scale.get_units() <= valueLimit && millis() – previousMillis >= 8000) {
return;
}
myservo360.detach(); // detach the servo to stop it from twitching
delay(100);
//OPEN DOOR
myservo180.attach(servPin180); // connect the second servo
servo180(); // call the function of the second servo to open the door
myservo180.detach(); // detach the servo to stop it from twitching
}
}

int checkButton() { // gets called in the loop
butVal = digitalRead(butPin); // put the state of the button into the butVal variable
return butVal; // return the value
}

int checkLoadCell() { // function gets called in wholeSystem function
valueReadLoadCell = (scale.get_units()); // stores the value of the load cell in this variable
Serial.print(“Measured Value in loadCell Function: “);
Serial.println(valueReadLoadCell);
return valueReadLoadCell; // returns the value. this is now a fixed value, which is used in the next function
}

float calcNewValue (float & valueReadLoadCell, float & valueLimit) { //calculate a new variable depending on the measured value + a preset interval
valueLimit = valueReadLoadCell + 0.3; // this variable is very important. the load cell is very responsive, so from one go to the next the number levels in at different values. befor the measured value was compared to a fixed number but since the measured value was not stable at all that was a huge liability and the limit value had to be changed all the time. now the servo rotates on base of a not changing interval and not on a uncontrolable difference.
Serial.print(“Value calculated in calc Function: “);
Serial.println(valueLimit);
return valueLimit;
}

void servo360(int speed, float valueReadLoadCell) {
myservo180.attach(servPin180); // connect the door opener. necesserary because it always twitches open
myservo180.write(110); // set him to 110 degree, which is the closed position. could be set as a variable
delay(100); // give him time to do that
myservo180.detach(); // detach him to stop it from twitching
delay(1000); // give him time to do that
myservo360.write(speed); // start to push toothpaste
}

void servo180() {
open(); // call function to open the box
while (scale.get_units() < 15) { // do nothing as long as the weight recognised is smaller then 50 (we still need to find out which number actually makes sense through making a few measurements when the toothbrush gets put into the bracket, thats the number we need here)
Serial.println(scale.get_units());
}
while (scale.get_units() > 15) { // call function close, when toothbrush gets put into the bracket / box
close();
}
}

void open() {
delay(5000); // this delay gives the toothpaste a little bit time to settle onto the toothbrush
direction = 1; // 1 equals opening direction = clockwise
if (direction == 1) { // if it is one
for (int i = 115; i >= 30; i–) { // move the servo from its starting position to the open position at 30 degree. can be opened further but 30º is enough
myservo180.write(i); //
delay(50); // delay determines the speed of opening the door
}
}
}

int close() {
delay(5000); // this delay is very important, it should be as accurate as possible and be the average time that a person needs to put the toothbrush back into the bracket, and remove his hand, so that the door doesnt close if the hand is still in the door
direction = 0; // 0 equals closing direction = counter clockwise
if (direction == 0) { // if it is zero
for (int i = 30; i <= 115; i++) { // move the servo from its opening position to the close position to 115 degree. the closing position was determined through various tests
myservo180.write(i);
delay(50); // delay determines the speed of opening the door
}
}
return newData = false; // set newData to false, again. probably redundant
delay(5000); // give time to settle
}

 

Gruppe 1 Oppdatering

Dagen I dag bød på mange utfordringer. Alt fra motorer som ikke fungerer, til feilkoblede sensorer måtte håndteres. På dette punktet er det testingen som begrenser oss. Ettersom at vi kun har en drone, får vi ikke testet de forskjellige komponentene samtidig.

Sensorer:

Sensorene fungerer på dette punktet nesten som de skal. Det eneste problemet er at sensor nr. 3 gir oss i overkant mange feilmeldinger. Vi har prøvd å bytte selve sensoren, div ledninger, hvilken inngang den går til, og hvilken kode som styrer sensoren. Dessverre har ingen av disse tiltakene lyktes. «Jakten» på riktig løsning fortsetter i morgen.

Motorer:

Et av de større problemene vi har møtt gjennom dette prosjektet er at motorene ikke får nok strøm til å kjøre på ønsket hastighet. Det er alltid 2 eller 3 motorer som kjører som de skal, mens de resterende motorene roterte saktere eller stod stille. Dette ble midlertidig løst da vi koblet motorene til individuelle strømkilder, men dette er selvfølgelig en løsning som er uaktuel på den ferdige dronen.

Videre denne dagen jobbet vi med dokumentasjon og presentasjon. Vi begynte også på animasjonen som skal være med i filmen vår, samt startet filmingen av diverse scener som skal være med.

Godteridispenser Uke 46 (Gruppe 2H17)

Hei, her kommer en liten oppdatering på hva vi har gjort til nå.

Mekanisk:

Vi har printet ut første versjon av de viktigste mekaniske delene som skal 3D-printes. Dette har gitt oss muligheten til å sette sammen delene og teste sammen med det elektriske. Under testing kom det frem at noen av målene ikke stemmer helt, feks hullbildet til motorfestet og hullet til akslingen på impelleren. Dette fikser vi enkelt ved å bore opp hullene/lage nye hull, eller retter det opp i 3D-modellen slik at neste print blir bra.

Videre blir 3D tegningene oppdatert og alle delene printet ut.

Elektrisk:

På den elektriske delen har vi testet ut alle sensorene som skal brukes. Det viste seg at avstandsensoren som vi skal bruke til å måle mengden som er igjen i hver beholder ikke er lineær noe som kompliserer utregningene. Vi fant ut at det er best å lage en funksjon som er tilnærmet lik kurven til sensorene. Dette krevde en del prøving og feiling, men ved hjelp av matlab kom vi frem til en funksjon som er bra nok for formålet.

avstand i cm = 489 * e((10 – x) /  (8.1 + 0.4x ))

For steppermotorene har vi laget et program som mater en porsjon av gangen. Ettersom at steppermotorene er delt inn i 200 steps per runde, går det ikke opp med den impelleren vi har i dag som er delt i seks. Dermed blir posisjon forskjøvet med to steps hver runde. Dette kan løses ved å legge til to steps hver runde, men vi valgte å endre designet på impelleren slik at den er delt i fem da vi uansett skulle printe nye.

Dermed har vi kontroll på hvordan komponentene skal styres og arduinoprogrammet begynner å ta form. For å ferdigstille programmet er det mest effektivt at det mekaniske er på plass, slik at de elektriske komponentene kan festes og programmet testkjøres.

Data:

Har fått ansiktsgjenkjenningskoden til å fungere! Da vi skulle legge koden over på rasberry pi kom det frem at den trenger en egen programvare som må lastes ned for å være kompatibel. Etter forsøk med rasberry pi 2 endte vi med å måtte bruke pi 3 for å få det til å fungere. Denne er nå festet direkte på skjermen som er plassert på tilegnet stativ.

GUI – Vi har valgt Tkinter , som er et standard bibliotek for Python  for å få laget vår GUI. Det er ikke det eneste GUI -biblioteket for Python , men det er det mest populære, og virker helt ok for hva vi skal bruke det til(i forhold til design).

Videre jobber vi også med med en “smart fordeling” som skal foreslå godteri for kunden basert på kundens preferanser og tilfredshet av tidligere kjøp(i samarbeid med en database) .