Goda råd till nästa års kursdeltagare i KMM, från oss som läst den…
• Använd git istället för en "Gruppmapp" så man har tidligt versionshantering osv.
Om ni planerar möte och någon är sen, ska han/hon bjuda på fika till gruppen.
Gör så enkla lösningar som möjligt.
•
•
•
Om möjligt, undvik avbrott och gör en så enkel buss som möjligt.
Lyssna inte så mycket på gamla studenters råd, man lär sig av att göra fel.
Tänk ut en plan på hur lasersensorn ska användas. Är det korta avstånd som ska mätas är
IRsensorer mer exakta.
● Dela upp stora aktiviteter i mindre aktiviteter.
● Testa kommunikationen genom att skicka/ta emot fler värden en ett. Det är då många fel
uppstår (t. ex. fördröjning).
● Skriv inte för mycket kod som ni inte DIREKT kan testa. Ni kommer ångra er.
● Fastna inte på småsaker som att försöka få alla sensorer att vara helt perfekta. I slutet kan
ni istället gå tillbaka och förbättra dessa så bra ni behöver för er lösning.
● Gör bra och ordentliga virningar så att ni slipper vira om något/leta efter möjliga
virningar som stör ut andra signaler.
Även om det kan vara lockande att jobba den senare delen av dygnet när det är lite
tommare i muxen kan det vara en nackdel då handledarna slutar tidigare.
● Titta ofta tillbaka över dokumenten från det tidiga stadiet i kursen för att kontrollera
om er implementering stämmer överens med dessa. Framför allt kan det vara bra att
ha uppsikt över sina krav.
● Var inte trångsynta, utan lyssna och ta vara på varandra.
Se upp med debuggern – den kan skapa mer problem än vad den löser.
Lär dig git.
Följ planeringen.
Ultraljud är inte pålitligt för labyrintrobotar.
• Tänk noggrant på vilka pinnar på processorerna som har specialfunktioner så som A/Domvandling
och avbrottspinnar etc. Annars kommer ni få vira om som vi.
• I2C är onödigt svårt.
• Bussen är svår, börja tidigt med den.
• Planera utrymmen på korten.
• En LCD-display är bra att ha för att debugga.
• Gör det enkelt att visa data från styrmodulen för att kunna debugga.
Vissa problem, till exempel att sensorvärden flimrar, är svåra att upptäcka innan hela roboten är monterad.
Försök sätta ihop roboten så tidigt så möjligt.
● Arbeta inte runt problem utan försök förstå dem och lös dem på riktigt.
● Våga sätta er in i varandras kod.
Par-programmering rekommenderas, då det är svårt att sitta fler än två vid en dator
och samtidigt arbeta effektivt. Det blir även bättre utbyte om man sitter två istället för
en. Det ger också fördelen att om en person är borta någon dag kommer det alltid
finnas åtminstone en person som har bra koll på den senaste versionen av koden utan
att andra i gruppen behöver spendera tid på att sätta sig in i den.
Ha möten då alla är samlade för att kunna ta beslut.
Använd versionshantering för att underlätta utvecklingen och det är en bra idé att
använda sig av test-branches.
Använd kodstandard för en mer enhetlig kod samt att det blir enkelt för
gruppmedlemmarna att sätta sig in i kod de inte skrivit.
Tidsplaneringen är viktig att uppdatera vecka för vecka och att hela gruppen samtalar
om hur tiderna har distribuerats mellan gruppmedlemmarna. Så att det inte blir att
halva gruppen når sina timmar medans andra halvan inte gör det.
Kommunikation inom gruppen är jätteviktig.
Dela upp aktiviteterna så att gruppmedlemmarna får arbeta med saker de tycker är
kul. Det är mycket timmar som ska läggas så det underlättar att sitta helger eller sena
kvällar om man får jobba med saker som är kul och intressant.
Vid presentation, välj ut tre personer som presenterar produkten annars blir det rörigt
för åhörarna.
Skriv ordentligt med testdokumentation och i den referera till commit-idn för att
enkelt kunna hitta kod som testats i efterhand.
Det är bra att gruppmedlemmarna fick blandade aktiviteter för det leder till att alla
har koll på all kod. Under presentationen så såg vi andra grupper som hade arbetat
modulvis och det ledde till svårigheter i integreringen av modulerna.
Redan under underfasen påbörja dokumentationen, så att gruppmedlemmar kan
skriva när de har tid eller väntar på en ny aktivitet. När gruppmedlemmarna jobbar
med en specifik del så går det oftast även lättare att skriva om den direkt än att vänta
flera dagar eller veckor.
Vid osäkerhet vid tolkning av krav, kontakta beställaren direkt och tydliggör kraven.
Var noga med förarbetet! Det är där standarden för projektet sätts.
Se till att ha god kommunikation inom gruppen för att samarbetet ska fungera så bra som möjligt. Det är därför
viktigt att avsätta tillräckligt med tid för möten.
Tänk både en och två gånger innan ni väljer I2C framför SPI eller UART!
Gör ett eget kretskort. Det är betydligt bättre på alla sätt jämfört med att vira. Det spar tid i längden!
Tydlig, genomgående struktur utan avvikelser på egna initiativ.
● Utnyttja handledaren tidigt och ofta.
● Uppdatera planeringen varje vecka.
● Jobba strukturerat under felsökning.
● Under felsökning, jobba nerifrån och upp (från hårdvara till mjukvara) så att hårdvarufel hittas tidigt.
Var 6 personer i gruppen. Det är inte på något sätt värt arbetet som blir om man är en mindre grupp.
Använd parprogrammering på allt! Även hårdvaran!
Sitt inte ensam och felsök för länge. Prata inom gruppen! Hjälp varandra!
Använd C++ för att programmera UI. Undvik Java. Undvik terminalgränssnitt
Jobba så agilt ni kan! Testa funktioner och metoder var för sig och testa varje nytt moment så
eventuella fel enkelt hittas och åtgärdas!
● Versionshantera på ett sätt så ni enkelt kan gå tillbaka till en version där ni vet med er att metod “x”
funkade om systemet slutat att fungera efter flera små ändringar.
● Sätt de olika modulerna på varsina kort i början, så att flera kan arbeta parallellt. Var inte rädda för
att behöva vira om sladdar senare, det lönar sig i slutändan!
● Skriv ett gruppkontrakt, även om det känns som att det är “common sense” i hur man uppför sig.
● Undvik att sitta hemma själv och jobba! Alla i gruppen ska ha möjlighet att sätta sig in i och förstå
det arbete var och en har gjort samt den kod som har skrivits. Se till att alla har tillgång till all kod,
alltid!
● Var inte rädda för att prata med andra grupper, hjälp varandra och kom med inspiration!
Vi har under projektet hittat några saker som vi gärna delar med oss av.
Använd:
_ Versionshantering,
_ Branches,
_ Pull Requests,
_ Code Reviews,
_ Låst och stabil master,
_ Issue Tracking,
Beagleboard: Använd Python eller något annat högnivåspråk på en Beagleboard eller
Raspberry Pi. Det lönar sig.
Små gränssnitt mellan moduler: Satsa på att ha så små och så få gränssnitt mellan
moduler som möjligt, både hårdvarumässigt och mjukvarumässigt. Ta reda på vad minsta
möjliga gränssnitt är och använd det.
Skriv generell kod: Skriv koden så generell som möjligt. Den kanske blir svårare att
skriva, men den blir kortare, bättre och lättare att anpassa.
Dokumentationskommentarer: Skriv någon slags dokumentationskommentar för varje
funktion. Andra förstår snabbare vad funktionen gör, man själv upptäcker dåliga idéer
och man kan låta ett automatiserat dokumentationsverktyg generera dokumentation för
all kod.
Skriv snygg kod från början. Det är bättre att börja med snygg kod som blir sämre
och sämre än att börja med dålig kod och säga “Jag skriver om det sen.”
Använd matten Finns det formler för det man gör? Använd dem. Använd linjär algebra,
använd formlerna för PID-reglering. Uppfinn inte hjulet på nytt.
Innan ni gör tidsplanering, tänk verkligen igenom hur mycket tid ni tror att varje delmoment kommer att ta
inkluderat testning. Detta hjälpte oss en hel del.
2. Använd UART såvida mer avancerad kommunikation mellan processorerna inte behövs. Det
underlättade för oss och man sparade en massa tid.
3. Använd likadana processorer. Det gör det lättare att programmera och hjälpa varandra inom gruppen.
4. Testa allt, jämt och ständigt.
5. Kolla alltid hårdvarans funktionalitet innan ni sätter fast den, se till så att den fungerar korrekt.
6. Sätt processorerna på olika kort i början. Detta kommer underlätta och alla kan jobba samtidigt.
7. Gör en noggrann och utförlig designspecifikation. Vi fick mycket hjälp av vår och ju mer tid man lägger
på designspecifikationen desto mindre tid måste man lägga senare i projektet för att kolla upp olika saker.
Många oklarheter blir tydliga om man gör den noggrant.
