Goda råd från studenterna som gjorde kandidatprojektet 2018

Transkript

1 Goda råd från studenterna som gjorde kandidatprojektet 2018 Strukturera tiden och se till att komma igång tidigt i kursen. Det är en väldigt intensiv period när sommaren närmar sig och det är inte till någons fördel att ha tunga, avgörande delar av projektet som icke avklarade när sluttampen är där. Det är även viktigt att tidigt inse att när projektet går mot sin slutfas så kommer alla delmoment kräva att man har tillgång till roboten, vilket lätt leder till att arbetet blir ineffektivt när enbart en kan den. Det är definitivt av värde att utvärdera kraven i kravspecifikationen både en och två gånger extra. Går det inte att motivera ett krav som avgörande för funktionaliteten så bör det inte tillåtas vara av prioritet ett. Detta hade underlättat enormt mycket i vårt fall där vi med facit i hand insåg att ett par av våra krav inte på något sett ledde till att projektdirektivet utfördes med bravur, utan bara skapade mer arbete. Här listas några goda råd till de som ska utföra ett liknande projekt. Fråga studenter som har gjort samma projekt från tidigare år om beslut de ångrar. Utför inte bara separata tester på funktionalitet och tro att det fungerar implementerat i resten av systemet. Helhetssystemet måste också testas när nya funktioner läggs till. Var medvetna om att stora förändringar i tidsplanen och även designen kommer göras kontinuerligt under projektets gång. Det som har planerats i förväg är inte skrivet i sten, det är skrivet i LATEX. Lös flaskhalsar genom att kolla framåt. Vad är planlagt längre fram i tiden men kan lika gärna påbörjas redan nu. Vid felsökning, tänk igenom testet noggrant. Börja med att göra det så simpelt som möjligt och koncentrerat på det som ska testas. Om det visar sig fungera kan testet successivt bli mer omfattande. Var uppmärksam på tidsåtgången. En simplare eller fulare dellösning är bättre än en ofullständig helhet. Låt aldrig en ensam person ansvara för en deluppgift. För när den personen då inte kan arbeta står utvecklingen still, trots att det egentligen finns andra som inte har något att göra. Kom ihåg att det är avancerade saker som görs i projektet. Att sätta sig in i något som någon annan har utvecklat under en tid är inte lätt, speciellt när den personen inte finns tillgänglig att fråga.

2 Koppla upp Raspberry Pi:n till andra datorer via fjärrstyrning för att felsöka under körning. Till exempel SSH. Detta hade underlättat felsökningen enormt. Många sensorer var inte lika bra som förväntat. Noggrannare undersökning av sensorerna innan man väljer hade gett bättre resultat. Till exempel Lidar v3- sensorerna var sämre än förväntat och projektet hade gått bättre med andra sensorer. Gör det inte för svårt då det finns en tidsbegränsning och det mesta är svårare att implementera än man tror. Ta backups på sd-kort. Ta er tid att bryta ner och diskutera problem. Läs dokumentationen, ger oftast bättre svar än andra källor. Använd ROS. Skriv ordentliga testprotokoll i tidigt skede av projektet för att minimera problem då olika delsystem ska integreras tillsammans. Var flexibel! Saker fungerar sällan som man tänkt sig - var därför inte rädda för att köra igång, testa och omplanera om det visar sig behövas. Desto mer av detta som kan utföras under förstudien, desto bättre blir designen. Se till att all hårdvara fungerar som det är tänkt innan man går vidare med att skriva mjukvara. Ha en kick-off, att jobba på gruppdynamiken faller gärna i glömska. Man ska jobba mycket tillsammans och en bra dynamik gör arbetet roligare och effektivare. Då konflikter och diskussioner löses lättare i en mognare grupp. Kursen tar väldigt mycket tid. Sitt gärna alla tillsammans under arbetstid 8-17 då ni inte har lektioner och föreläsningar i andra kurser. Det ger en rimlig och jämn tidsåtgång.

3 Ha roligt och passa på att lär er nya tekniker och lösningar. Lägg mer tid på designspecifikationen än projektplanen. Det är svårt att utnyttja projektplanen bra om man inte gjort designspecifikationen utförlig och bra tidigt. Överlag är designspecifikationen, enligt oss, ett viktigare dokument för arbetet än projektplanen. Dela in er kod i separata klasser och spara klasserna i separata filer redan från början. Använd testdriven utveckling. Spara kod för testning av klasserna. Gör klasserna lätta att anpassa och se gärna till att de kan köras på en separat tråd. Undvik i den mån som är möjligt globala variabler och fulhack tills att projektet är i sin slutfas. Ha långa beskrivande variabelnamn i er kod. Java-kompilatorn Eclipse sparar alla utskick på terminalen. En java-applikation som med jämna mellanrum skriver ut något på Eclipse-terminalen kan efter några minuter ta upp flera gigabyte av arbetsminne på datorn. Ta alltså bort alla utskick till Eclipse-terminalen i ert java-applikation om ni använder en sådan till ert projekt. Se till att alla semikolon finns med i era header-filer. En headerfil utan ett semikolon kan skapa väldigt kryptiska fel i c-kod som är svåra att felsöka. Få kommunikationen att fungera tidigt mellan de olika modulerna. Börja i tid! Man har inte råd att förlora ett par veckor i början. Det kommer göra det riktigt stressigt i slutet av projektet. Håll gruppen uppdaterad på vad alla arbetar med. Förhindrar att arbetet stannar upp om någon försvinner. Om möjligt, implementera så att man kan ändra PID-konstanterna under körning utan att starta om roboten. Sparar mycket tid när regleringen ska finjusteras. Drönarspecifika: Testa grejer (typ allt) i Beta Flight innan ni flyger, minskar risk för krasch betydligt Var allmänt försiktig vid tester Se till att Kill-Switch fungerar utan fördröjning till 100% Utnyttja tiden i Vision väl, då den är begränsad och ni är beroende av den

4 Prata tidigt igenom gruppen vilken ambitionsnivå alla har. Börja testa flygning så tidigt som möjligt. Kontrollera noggrant att drönaren beter sig som avsett innan den tillåts lyfta. Reglering av drönaren tar lång tid. Sätt tidigt upp fasta regler om arbetstid. Under dessa på förhand bestämda timmar bör det vara obligatoriskt för samtliga projektmedlemmar att närvara. Att lära sig mycket om den teori som kommer behövas under projektet redan i planeringsfasen ger ett bra försprång. Använd förstudierna för att lära er om ämnen ni är osäkra på och börja arbeta i god tid. Utnyttja även handledare mycket och se till att vara förberedda vid möten och sammanslutningar med beställare. Se även till att ha god kommunikation inom gruppen för att arbetet ska fungera så bra som möjligt. Kravspecifikationen bör bestå av krav som är lättförståeliga och inte går att misstolka. Det har uppstått tillfällen då gruppmedlemmarna inte förstod vad vissa krav egentligen innebar som då fick revideras tillsammans med beställaren. Undvik GIT-problem, testa koden och om tidigare fungerande kod inte fungerar en dag senare beror det troligen på att koden inte hämtats rätt från GIT eller att koden inte komplierats rätt, make clean -> make all. Implementera ett system där man rapporterar vad man har gjort under dagen och vad andra kan jobba vidare på. Behöver inte vara något komplicerat men det undviker de situationer som uppstår när man ska starta arbetsdagen men har inte en aning vad som har gjorts och vad som ska göras. Att det är tydligare vem som gör vad och hur långt de kommit. Att inte skjuta upp sådan som tycks funka ibland. Hittar man något som inte fungerar som det ska bör man

5 åtgärda det omgående. Var inte rädd för att göra en bra lösning istället för en snabb lösning. Testa kod noggrannare innan det inkorporeras i resten av systemet. Vi upptäckte massiva buggar flera veckor efter att de skrevs, och under tiden trodde vi att det var andra saker det var fel på. undvik Git-strul för guds skull. Vi förlorade många timmar på detta. Se gärna till att få åtminstone en hyfsat ordentlig förståelse för andra delar av systemet än det som täcks av ditt ansvarsområde. Skriv välskrivna förstudier och uppmuntra varandra att läsa dem. Och sist, men inte minst: KORREKTURLÄS. Att ha struktur från början spar tid i framtiden. Kommentera kod. Skriv vettiga meddelanden på Git-commits. Se till att Git-repot är snyggt, gör inte commits av saker som inte fungerar. Gör ett bra arbete med dokumenten och börja tidigt, för även om man vill sitta och koda hela dagarna blir resultatet inte så bra som det kunde varit om det stressas ihop i början. Tänk ut klasser i koden, och gör på samma sätt överallt. Det är 6 personer som alla vill göra på sitt sätt, men det ställer bara till problem när man i slutändan ändå måste länka ihop det var och en har gjort. Tänk alltid ur någon annans perspektiv: Hur hade någon som inte satt ned och skrev det här tolkat och förstått det jag precis skapade? Hade jag kunnat presentera detta för min framtida arbetsgivare? Detta projekt är det slutliga som ger en kandidatexamen, och det bör synas utåt och inåt! Var noga med hur ni definierar era krav. I början så insåg vi inte vikten av att ha korta och tydligt formulerade krav utan vi siktade nästan snarare på att täcka in mycket i varje krav och vara lite vaga. Detta visade sig vara ett misstag och hade vi gjort om projektet idag hade vi i princip enbart haft krav som kan formuleras i en mening samt är lätta att verifiera om det är uppfyllda eller inte. I början när vi som grupp ombads planera på detaljnivå exakt vilka aktiviteter som skulle göras samt hur lång tid det skulle ta så kändes det knepigt då vi inte hade någon tidigare erfarenhet av att göra liknande aktiviteter. Därför blev det svårt att göra vettiga tidsuppskattningar. Tipset vi vill ge är dock att det ändå är vettigt att tänka på detta då vi senare haft mycket nytta av att ha aktiviteter på detaljnivå utstakade. Det är viktigt att ha kul i kandidatgruppen och vi rekommenderar att ni under terminens gång med jämna mellanrum träffas och hittar på något utanför skolan, bara för att få chans att umgås och tänka på annat. Var också beredda på att detta projekt kommer ta

6 mycket tid och under långa stunder vara väldigt frustrerande, men ni kommer ta er i mål bara ni ligger i. Utnyttja den kompetens som finns hos handledarna, de kan hjälpa er väldigt mycket och leda in er på rätt spår om ni är på väg i en riktning som uppenbarligen inte kommer att ge något. Handledarna rekommenderade att mycket i roboten sköttes med hjälp av avbrottshantering och vår grupp valde att helt köra utan. Det finns för- och nackdelar med båda sätten och ni bör fundera över på vilket sätt ni generellt vill lösa problem. Gör man på det sätt som vi gjorde, dvs kör hela programmet sekventiellt då kan det vara svårt att i slutet implementera en process som kräver avbrott. Dela upp projektet i små bitar och testa väldigt ofta. Vår grupp saknade på förhand en del teknisk kompetens och det gjorde det svårt för oss att göra väldigt stora "framsteg" utan att testa ifall det funkade eller inte. När vi ser tillbaka på det är detta en av dem saker som var absolut nyttigast för oss, vi testade nästan varenda liten funktion.