Laborationsrapport av robotprogrammering

Transkript

1 KUNGLIGA TEKNISKA HÖGSKOLAN Laborationsrapport av robotprogrammering Programmering av LEGO MINDSTORMS robot Rikard Bjärlind E-post: Introduktionskurs i datateknik (H12) II1310

2 Sammanfattning Denna laborationsrapport handlar om laborationstillfället där programmering av LEGO MINDSTORMS robotar gjordes. I rapporten finns genomförandet av laborationen och resultaten med samt åsikter och analyser som speglar vad skribenten tyckte och tänkte om tillfället. Ett program skulle under laborationen skrivas som fick tidigare omnämnd robot att följa en svart tejp-linje på marken. Detta gjordes genom att korrigera en redan färdigskriven kod som laborationsdeltagarna fick ta del av. Kungliga Tekniska Högskolan, Skolan för informations- och kommunikationsteknik Sida 2 av 8

3 Innehållsförteckning Sammanfattning Inledning Bakgrund Syfte och målsättning Genomförande Resultat Analys Diskussion... 7 Referenser... 7 Bilagor... 8 Kungliga Tekniska Högskolan, Skolan för informations- och kommunikationsteknik Sida 3 av 8

4 1. Inledning Rapporteringen görs på den laboration som utfördes inom kursen Introduktion till datateknik (HT 12). I rapporten kommer genomförande och resultat av laborationen redovisas tillsammans med en djupare analys och diskussion. Även bakgrund och syfte kommer att inkluderas där frågor som varför behöver man kunna detta? kommer behandlas samt vilka mål som skulle uppnås med laborationen. Under laborationen fick deltagarna programmera en lego-robot att följa en linje. Detta gjordes genom att korrigera en redan färdig kod. 1.1 Bakgrund Varför vi utförde laborationen i en förberedande kurs har en bakgrund i att deltagarna fick prova på att arbeta som ingenjörer. Ingenjörsarbete innefattar ofta problemlösning, idéframtagning och att utföra tester i olika former. Allt detta fick laborationsdeltagarna göra till viss del. När den givna koden felsöktes krävdes både problemlösning och idéframtagning då deltagarna var tvungna att förstå koden för att sedan kunna korrigera felen i den. Sedan utfördes tester för att redogöra om de ändringar i koden som gjorts var användbara. 1.2 Syfte och målsättning Syftet med laborationen var att felsöka och korrigera ett program som fanns tillgänglig för nedladdning. Programmet skulle sedan köras av en robot vars mål var att följa en svart tejp-linje samt att skriva ut namnen på de som laborerat med roboten. Detta skulle utföras genom att ersätta den felaktiga koden som stod skriven i programmet med en korrekt kod som fick roboten att agera enligt laborationens instruktioner. 2. Genomförande Laborationen gick till som så att deltagarna delade upp sig i grupper om två personer. Varje grupp fick en "LEGO Mindstorms" robot att arbeta med. I gruppen som är aktuell för denna rapport ingick deltagarna Rikard Bjärlind, skribent av rapporten, och Markus Brolin. Denna grupp inledde laborationen med att ladda ner och installera drivrutiner till roboten från internet 1, därefter laddade gruppen ner "BricxCC"samt programmet "linefollower.nxc". Detta gjordes från kursens hemsida i Bilda under fliken Kursmaterial. "BricxCC" var programmeringsmiljön som användes under laborationen och "linefollower.nxc" var programmet som skulle korrigeras. Språket som användes var NXC (Not exactly C). Ett språk som följer samma syntax som "C" men har inbyggda funktioner som lämpar sig för maskinnära programmering. Innan programmeringsarbetet inleddes gjordes en testrunda med roboten. Den följde inte linjen så som den skulle. När koden korrigerades tillämpades parprogrammering. Två personer samarbetar med kodskrivning, den ena skriver koden samtidigt som den andre granskar den. Efter bestämd tid byter personerna plats för att på så sätt komplettera varandra. Denna metod användes under laborationen och det tidsintervall som användes var 20 minuter per person. 1 Kungliga Tekniska Högskolan, Skolan för informations- och kommunikationsteknik Sida 4 av 8

5 Arbetsprocessen var uppdelad i tre olika steg. Först planerades och diskuterades eventuella förändringar av koden. Därefter utfördes dessa förändringar av koden och det tredje steget gick ut på att praktiskt testa om förändringarna var korrekta. Om så var fallet fortsatte arbetet med planering av nästa moment. Om förändringarna dessvärre inte korrigerade problemet återgick gruppen till planerings momentet för samma steg istället för att gå vidare. Samtidigt som förändringar gjordes i koden fylldes en tabell i så att gruppen tydligt kunde se vilka förändringar som gjorts och var i koden de utförts. Denna tabell finns bifogad under Resultat. När målet var uppfyllt och programmet fungerade utan komplikationer, följde roboten linjen och skrev ut gruppmedlemmarnas namn innan programmet avslutades. Gruppen fortsatte då med att skriva ett digitalt dagboksinlägg som publicerades på "KTH Social" 2. Därefter återlämnades roboten till hanledaren 3 och laborationen var därmed avslutad. 3. Resultat Resultatet av laborationen var att roboten följde kanten av den svarta tejp-linjen på golvet enda tills att ena eller båda trycksensorerna aktiverades. När detta inträffade stannade roboten och skrev då ut dessa tre rader på displayen: "Gruppmedlemmar: Markus Rikard" Raderna visades i 20 sekunder på displayen innan roboten avslutade programmet. 2 Se Bilagor 3 Se Referenser Kungliga Tekniska Högskolan, Skolan för informations- och kommunikationsteknik Sida 5 av 8

6 Tabell över ändringar i koden i programmet "linefollower.nxc". Radnummer Ny kod Kommentarer av förändringar i koden 35 "Markus, Rikard" Här skrevs namnen på gruppmedlemmarna som skulle visas på displayen när roboten avslutade programmet. 45 Ersatte: (8*i-16) med: (8*i) Raderna på robotens display hade siffervärden i koden. Den gamla koden: (8*i-16), gjorde att namnen skrevs ut 2 rader högre upp än vad som bestämdes. Angavs då ett namn på rad 1 skrevs det ut på rad -1 (som ej existerar) på robotens display. Den nya koden åtgärdade problemet. 68 Ersatte "SensorRaw(IN_1)" med "SensorRaw(IN_3) I det här stycket beskrivs hur ljussensorn ska fungera. Koden fungerade dock inte eftersom fel sensor var angiven. IN_1 var en trycksensor och var därför tvungen att ersättas mot sensor IN_3 som var ljussensorn. 84 Ersatte "SpeedSlow" med SpeedFast 92 Ersatte "SpeedFast" med "Speed Slow" Koden beskriver hur roboten ska agera om den ser strecket. Om roboten ser strecket ska båda motorerna snurra lika snabbt. Om den inte längre ser strecket svänger den in mot strecket igen eftersom koden då säger att ena motorn ska snurra långsammare. Denna ändring berör motor A. Här sker samma sak som ovan fast istället har berörs motor B. 4. Analys Anledningen till att roboten följde just ena kanten av linjen på golvet bestämdes i koden. Det som avgjorde detta hade att göra med att roboten alltid skulle svänga in mot linjen. Beroende på hur svängarna var utskrivna i koden höll sig roboten längs ena eller andra kanten av tejpen. readlightsensor(); if(lightintensity < TopThreshold) { OnFwd(OUT_A, SpeedFast); } else { } OnFwd(OUT_A, SpeedSlow); if(lightintensity > BotThreshold) { OnFwd(OUT_B, SpeedFast); } else { OnFwd(OUT_B, Speedslow); Kungliga Tekniska Högskolan, Skolan för informations- och kommunikationsteknik Sida 6 av 8

7 I koden ovan beskrivs hur roboten ska följa linjen. Tejpen består av ett ljusintervall och så länge ljussensorn ser detta intervall åker den rakt fram, båda motorerna snurrar lika fort. Hamnar robotens ljussensor utanför intervallet svänger roboten in mot linjen igen. Den gör detta genom att ha olika hastighet på motorerna. Om man i koden ovan skulle byta plats på motor A och motor B skulle roboten följa andra kanten av linjen. Den gör detta för att åtgärden av att roboten har hamnat utanför linjen görs på samma sätt fast spegelvänt. 5. Diskussion Laborationen genomfördes ej helt utan att problem uppstod. När fel uppstod och orsakerna till dessa troddes vara inom ett visst område i koden var det ofta så att bara just den delen av programmet granskades. Efter lång tids utredande kunde en insikt att en annan del av koden faktiskt kunde vara den bakomliggande orsaken. Problemet var då i form av att fokus kunde ligga väldigt länge på fel ställe eftersom det fanns mistankar mot just det området. Istället för granska flera orsaker hände det därför ibland att bara ett granskades. Och om detta område inte var det som berörde felet kunde mycket tid passera innan den insikten kom. Detta har alltså fått mig som skribent till rapporten, att inse att man måste vidga sina vyer och inte vara rädd för nytänkande. Man ska inte snöa in sig på vissa områden utan man ska försöka se problemet på flera sätt. Denna insikt kommer antagligen att vara till stor nytta i arbetslivet då det är viktigt att kunna presentera resultat och progressivitet. Programvaran NXC är för mig inte helt främmande då jag programmerat lite i C tidigare. Det är ett effektivt språk men som inte skulle ta skada av att vara lite tydligare. Istället för att skriva ut ord som then, or och and används symboler. Detta tycker jag gör det svårare att "läsa" koden med ord i huvudet. Tillvägagångssättet under laborationen var bra, effektivt och väl genomtänkt med tank på parprogrammeringen. Fler idéer och synsätt granskar koden och det är då enklare att identifiera eventuella problem som dyker upp. Dessutom är det roligare att kunna dela upplevelsen med någon annan istället för att sitta helt själv vilket jag tror att man ändå kommer göra i framtiden. Referenser Handledare för laboration: Isabella Mosquera Hollström, lärare KTH Bilda, II1310 Introduktionskurs i datateknik (H12), Innehåll, Programmering Labb-PM LEGO, LEGO MINDSTORMS: Support: Files - Drivers - Fantom driver (PC & MAC), Kungliga Tekniska Högskolan, Skolan för informations- och kommunikationsteknik Sida 7 av 8

8 Bilagor Detta är en skärmdump av dagboksinlägget på "KTH Social" som skrevs i slutet av laborationen. Kungliga Tekniska Högskolan, Skolan för informations- och kommunikationsteknik Sida 8 av 8