KUNGLIGA TEKNISKA HÖGSKOLAN Laboration i datateknik Felsökning och programmering av LEGO NXT robot Daniel Willén 2012 09 06 dwill@kth.se Introduktionskurs i datateknik II1310
Sammanfattning Syftet med rapporten var att skaffa förståelse för hur arbetsgången vid ingenjörsarbete går till och kunna lösa problem genom att tillämpa en av metoderna som används vid ingenjörsarbete, nämligen att implementera och verifiera. Laborationen gick ut på att pröva på en sedvanlig uppgift att programmera en robot så att den skulle bete sig på ett angivet sätt. Vid laborationen skrevs kod till roboten och sedan testades och verifierades flera gånger. Uppgiften var alltså anpassad till syftet och lyckades bra att förmedla sitt budskap i slutändan och gav dessutom nyttig övning för liknande uppgifter i framtiden. Man behöver onekligen kunna arbeta på ett effektivt sätt, kunna planera och ha förmåga att för att uppnå bästa resultat och detta visade sig vid genomförandet av laborationen. ICT skolan Kungliga Tekniska Högskolan Sida 2 av 9
Innehållsförteckning 1. Inledning... 4 1.1 Bakgrund... 4 1.2 Syfte och målsättning... 4 2. Genomförande... 4 3. Resultat... 6 4. Analys... 6 5. Diskussion... 7 Referenser... 7 Bilagor... 8 ICT skolan Kungliga Tekniska Högskolan Sida 3 av 9
1. Inledning Rapporten handlar om en laboration som går ut på att programmera en LEGO robot i ett språk som heter NXC. Laborationen och rapporten är till för att utveckla våra kunskaper inom programmering och för att skaffa förståelse för hur arbetsgången vid ingenjörsarbete går till och hur man kan dra paralleller till det verkliga arbetslivet. 1.1 Bakgrund Att jobba med problemlösning, idéframtagning och design med andra människor förekommer väldigt ofta i verkligheten när man jobbar som ingenjör. Men hur arbetar en ingenjör egentligen och hur löses problem? För att ta reda på det utfördes en laboration inom programmering i form av pararbete. Programmeringen är ett viktigt verktyg för de vid ICT skolan måste kunna. Det är viktigt att förstå hur kod fungerar och hur pass stora fel som kan uppstå om man gör ett litet misstag. Allmänt för ingenjörer gäller även att arbetet följer flera faser, i detta fall handlar laborationen mycket om metoden att implementera och verifiera, att tillämpa sina kunskaper inom programmering och verifiera om man har kommit fram till en lösning som fungerar bra och eventuellt bygga vidare på det genom att pröva sig fram och göra ändringar i programkoden. 1.2 Syfte och målsättning Laborationens syfte är att kunna använda sig av de kunskaper i programmering som man lärt sig och tillämpa dessa för att förstå hur enklare program samverkar med något i verkligheten i detta fall en LEGO Mindstorms robot. Målet är att lösa ett enklare logiskt problem genom att noggrant undersöka koden, i detta fall att redigera programkod och flasha roboten så att den kör som den ska genom verifiering. Det globala syftet var att introducera hur arbetsgången går till vid ingenjörsarbete. Rapportens syfte är att träna på rapportskrivning för att kunna beskriva laborationsmomenten i kursen på ett ingenjörsmässigt sätt. 2. Genomförande Laborationen genomfördes först med en förberedelse. Jag och min labbkamrat läste genom Lab PM via Bilda (bilda.kth.se) för att få förståelse om vad laborationen gick ut på, hur den skulle genomföras, vad man behövde veta innan man satte igång och till sist vilka mål man behövde uppnå. Detta ledde givetvis till att man fick bland annat läsa en guide, en så kallad tutorial med information om hur man programmerar sin LEGO NXT robot med NXC språket som skulle användas vid laborationen. Ett moment i förberedelsen var också att ladda ner programmet BricxCC via kursmaterialen som är programmet man använder för att redigera koden och flasha roboten. Vi fick även installera drivrutiner till roboten för att kunna koppla in den till vår PC som vi skulle ha med oss ICT skolan Kungliga Tekniska Högskolan Sida 4 av 9
till laborationen. All material vi behövde hittade vi under kursmaterial. Exempelvis fanns där en.pdf fil som visade programkoden för roboten. Vi granskade denna kod som och analyserade den en stund för att förstå hur roboten skulle agera och vad koden gjorde så att vi skulle vara förberedda inför laborationen. På kursmaterial fanns en monteringsspecifikation som.png fil som vi tittade på för att få förståelse för hur roboten skulle vara kopplad. Under själva laborationen fick vi reda på uppgiften, att programkoden skulle ändras på så att roboten skulle följa en bit svart tejp dragen kurvigt på golvet. Det första vi gjorde var att koppla in roboten i datorn och starta BricxCC. Vi flashade in linefollower.nxc filen, koden för roboten, som vi hade med oss från kursmaterial på roboten och startade sedan den för att undersöka beteendet koden beskrev. Som förväntat så gjorde inte alls vad den skulle och vi gick in och började ändra kod och testa gång på gång tills vi fick önskat resultat. Vi ändrade givetvis inte bara kod på måfå utan programmering gick till att vi analyserade vad roboten gjorde fel och försökte hitta en möjlig lösning på problemet bland annat genom att utesluta vissa delar av koden samt kolla om alla värden för de olika variablerna såg bra ut. Vi resonerade fram och tänkte logiskt för varje rad kod som vi läste för att försäkra oss om det var rätt eller fel. En av oss satt och skrev koden, och den andre kollade om det skrevs in rätt. Vi försökte utnyttja allt det vi hade lärt oss på föreläsningarna inför laborationen så att den skulle gå så smidigt som möjligt. Vi fokuserade på att lösa endast ett problem i taget och aldrig fler. Första problemet var att roboten skulle skriva ut våra namn på skärmen när den var färdig och detta precis som många andra problem med roboten utfördes genom att vi läste all relevant kod som kunde tänkas påverka roboten, tolka den och komma fram till en slutsats om vad som orsakar problemet. Efter vi hade fixat så att den visar våra namn fortsatte vi med att lösa styrningen. Vi delade upp de större och mera abstrakta problemen i mindre problem genom att resonera fram tillvägagångssättet. Vi tänkte på hur roboten bör bete sig och hur den ska göra för att till exempel följa linjen. Vi kom fram till att den bör köra av tejpen av sig själv för att sedan åka tillbaka på tejpen efter att den inser att den åkt av. Mer konkret beskrev vi lösningen att motor B skulle få högre kraft än A så att roboten svänger tillbaka in på tejpen varpå den ställer tillbaka motor B på samma nivå som tidigare efter att ljussensorn känner efter att det finns tejp. Värden mellan konstanterna Top och bottom threshold beskrev de värden som senorn läser när roboten är på tejpen. Med våra detaljerade beskrivningar på problemen hjälpte oss att kunna programmera effektivt eftersom vi visste exakt vad vi var ute efter och vad som skulle göras. Vi tog små kliv och ändrade lite i taget tills det blev bra och sparade flera versioner så att vi alltid kunde gå tillbaka om något gick alltför snett. Vi var ute efter att få precision så därför sänkte vi även hastigheten på roboten genom att ändra en konstant som beskriver hastighet i de första raderna av koden. Vi försökte göra lösningen så enkel som möjlig och hastigheten var någon som möjligtvis kunde optimeras mot slutet av uppgiften och möjligen gjorde det svårare för oss att veta om styrningen fungerade korrekt. Eftersom vi tog så pass små kliv var vi tvungna att köra roboten minst kanske 20 gånger innan den var i det optimala läget eftersom vi var osäkra på vad som var det bästa. ICT skolan Kungliga Tekniska Högskolan Sida 5 av 9
3. Resultat Resultatet i tabellen nedan visar den nya koden och det radnummer den originala koden stod på samt en kort kommentar om varför ändringen gjordes t.ex. Kommentarsblad för laborationsuppgift i ll1310 Introduktionskurs i datateknik: Radnummer Ny Kod Kommentar 35 Adem, Marin, Danny Namnen sätts som strängar i groupmembers[] array 34 String names[] Alla instanser av groupmembers döptes om till names ty de alla syftade på samma array och de måsta ha samma namn. 58 ( ) ( ) 45..LCD_line2_(8i) Man vill hoppa ner 8 pixlar per loop och inte, +16 som det blev i originalkoden när i sattes till värdet 1. 114 //dance() Vi kommenterade bort dance() eftersom den funktionen gjorde att roboten snurrade runt, den behövdes ej. 68 SensorRaw(IN_3) Sensorn var inkopplad i port 3 och ej port 1. 92 onfwd(out_b, SpeedSlow) Motorn B måste köras saktare än motor A så att roboten svänger. 4. Analys Laborationen gick i stort sett väldigt bra. Vi hade inga problem med att genomföra laborationen på det sätt som vi gjorde och vi fick inblick över hur ingenjörer arbetar, även om laborationen var på en mycket mera grundläggande nivå. Det som gick bra var vårt sätt att analysera problemen och hur vi förenklade dessa så mycket som möjligt. Det som gick sämre var att vi missade att sensorn hade fel siffra i koden vilket medförde att vi programmerade styrningen rätt med fick ändå fel resultat vilket ledde till förlorad tid. I stort sett all kod var viktig att förstå, men speciellt var lightintensity viktigt. Om vi fick ändra på något så skulle det vara att ha bättre dokumentation under labben för att kunna beskriva genomförandet på ett detaljerat sätt. Kommentarsbladet blev ofullständigt av anledningen att det var dålig organisering. Vi var för upptagna med att lösa uppgiften och liten vikt lades på dokumentering. Det fanns även flera funktioner som låg bakom robotens beteende. Främst funktionen followline() som, som det låter, gjorde att roboten följde linjen. OnFwd(a,b) var en till viktig funktion som beskrev vilken motor (a) skulle köras och med vilken fart i procent (b). Konstanterna hjälpte oss att inte hålla på koda med siffror utan istället läsa koden och tolka den som det står. Kommentarerna i koden hjälpte även oss att förstå vad koden gjorde eftersom det inte var vi som hade skrivit den. Vi lärde oss alltså att det är viktigt att skriva kod på ett rent sätt för man är sällan själv och arbetar. Om koden vi fick inte var kommenterad eller indragen eller liknande med konstiga namn på variabler hade ICT skolan Kungliga Tekniska Högskolan Sida 6 av 9
laborationen tagit betydligt längre tid att lösa. Vissa delar av koden var väldigt svåra att upptäcka eftersom de var så pass små och väckte inga misstankar som exempelvis på rad 68. Koden i stora drag innehöll många fel av olika svårighetsgrader. 5. Diskussion Syftet med laborationen var att låta oss tillämpa våra kunskaper inom programmering för att lösa ett problem och för att visa det sätt ingenjörer arbetar på, bland annat genom implementering och verifiering. Det var enligt mig ett lagom nyttigt exempel på just den fasen, dock så tror jag att det är betydligt mera komplext på högre nivåer där fler människor är inblandade och projekten är större. Laborationen var helt enkelt en liten del av det hela men ändå bra eftersom den visade grunderna för problemlösning och gav inblick om hur det är att komma fram till slutprodukten genom att göra ändringar i kod och testa om programmet gör som man vill att den gör. Några av de ändringar man hittar i analysen var enkla att lista ut men trots allt ändå krävde verifiering. Rad 45 kändes som en väldigt konstig rad kod i början och det var väldigt oklart hur personen som skrev koden tänkte. Det visade dock att det alltid går att göra missar och få allt att se rätt ut och visade även viktigheten av att arbeta i par när man programmerar. Tillvägagångssättet på laborationen gick bra eftersom vi hade tydliga mål på hur vi skulle lösa vårt problem. Vi löste problemet genom att använda oss av det vi lärt oss om programmering och alltså har laborationen uppfyllt ett av de mål som var satta. Det jag har tagit med mig till framtida studier är hur viktig planeringen är innan man sätter igång ett projekt och hur processen går till när man ska hitta en lösning på ett problem och alltså har laborationen även lyckats med sitt globala syfte att introducera hur arbetsgången går till vid ingenjörsarbete. Likaväl är dokumenteringen under själva arbetsgången viktig för att andra och du själv ska kunna förstå vad du egentligen gjorde och varför. Det jag också lärt mig är att man lätt kan göra fel genom att man gjort rätt hela tiden. Att det inte alltid är något som man tror som ligger bakom problemet. Jag lärde mig att förstå hur roboten följer linjen i detalj och hur roboten tänker med hjälp av programmeringen då jag aldrig programmerat något liknande tidigare. Jag har aldrig tidigare hållit på med att programmera fysiska delar så det gav mig inspiration eftersom det var betydligt roligare att se sin kod i verkligheten. Programvaran som man använde för att redigera koden och flasha roboten var mycket enkel att begripa och inte alls svår, långsam eller liknande. Koden var också relativt enkel att förstå jämfört med andra språk och då den var så pass nybörjarvänlig var den också rolig att arbeta med. Referenser https://bilda.kth.se/courseid/8498/content.do?id=19150198 (Labb PM) https://bilda.kth.se/courseid/8498/content.do?id=19121762 (Kursmaterial) ICT skolan Kungliga Tekniska Högskolan Sida 7 av 9
https://www.kth.se/social/home/private/ (Dagbok) Bilagor ICT skolan Kungliga Tekniska Högskolan Sida 8 av 9
ICT skolan Kungliga Tekniska Högskolan Sida 9 av 9