Goda råd till de som ska utföra ett liknande projekt (från KMM 2016)

Transkript

1 Goda råd till de som ska utföra ett liknande projekt (från KMM 2016) Snöa inte er på lösningar som kanske fungerar, eller som ni bara vill få fungera. Var realistiska och våga byt lösning om den det verkar ta för lång tid. Var inte rädda för digitala protokoll, även om det blir många olika protokoll för olika sensorer. Börja integrationstesta tidigt, där upptäcker man många problem som man inte trodde att man hade. Använd Wifi istället för blåtand om möjligt, underlättar både utveckling och användarbarhet. Se till att använda bra kommunikationskanaler från första början. Var inte rädda för mer avancerad versionshantering, se det här som ett utmärkt tillfälle att lära sig. Best practices i ett lite större projekt. Dela upp enheter på olika virkort, underlättar i början när man kan jobb på flera enheter samtidigt. Undvik onödig hårdvaruprogrammering (VHDL) då det är väldigt svårt att felsöka och det tar lång tid att få komponenten att fungera.

2 Kontrollera UART-anslutningens baudrate om kommunikation inte fungerar, se till att UARTregistrets värde för inställd baudrate motsvarar den för processorns klockfrekvens. Kontrollera klockfrekvensen. Undvik att använda _delay_ms() / _delay_us() när det inte behövs. En kort _delay_ms() mellan överföringar kan lösa problem då bytes försvinner. Bluetooth-modulen kan överbelastas med inkommande data och stängs då av. Detta märks då bluetooth-modulen tappar anslutningen. Att inte skicka data så ofta kan lösa detta. Se till att läsa banspecifikationen noggrant. Testa kontinuerligt sensorenheten och verifiera att sensorerna fortfarande fungerar. Filtrera IR-sensorns, och LIDAR-sensorns värden då de är känsliga för brus. Filtrera mer än du tror du behöver, och sedan ytterligare lite till! IR-sensorerna kan störa ut varandra. Montera vertikalt och skärma av. Var försiktig med JTAG-programmerarna, de är känsliga och flatkabeln kan börja glappa. Testa systemet och modulerna ofta. Testa mellan

3 implementationerna, och testa enheterna för sig. En utförlig och välformulerad designspecifikation spar mycket tid i konstruktionsfasen. På de enheter som inte har någon display eller motorer anslutna, koppla in lysdioder som kan användas för felsökning och test. Oscilloskopet är ditt bästa arbetsverktyg på bänken! Gör ordentliga virningar. Klocksignalen kan inducera störningar i kommunikationsledningarna mellan enheterna. C++ är ett bra val för att programmera användargränssnittet. Biblioteket Qt ger mycket gratis, som t.ex. grafiska fönster, men också gränssnitt för datorns seriella portar. I2C är tidskrävande att få igång. Använd hellre andra kommunikationsvägar om möjligt t.ex. PWM för LIDARsensorn. Läs dokumentation och datablad noggrant. Kommunicera mera! Det Är svårt att lägga för mycket tid på just kommunikation. Se till att alla vet var som händer i alla delar av projektet, varje dag!

4 Planera upp en vettig struktur och hierarki inom gruppen istället för att hålla hierarkin mestadels platt med en huvudansvarig och resten utvecklare. Använd versionshantering för både kod och dokumentation. Att kunna backa till ett tidigare skede av projektet är otroligt tacksamt när man stöter på problem. Gå sakta fram i projektet och överskatta tidsåtgången. Saker tar längre tid än man tänkt från början, särskilt när man arbetar med hårdvara och nya tekniker. Se till att saker fungerar med tillräckligt hög pålitlighet innan ni går vidare. Att behöva backa tillbaka flera veckor för att en grundläggande funktion inte fungerar som den ska i en viss situation tar mycket tid. Samtidigt som det bidrar till en stabilare robot är det sjukt våghalsigt att ha krav på formen roboten ska klara 3 av 3 körningar". Lös problem i arbetsflödet direkt! Finns det något som gör att ni ofta lägger onödigt mycket tid eller som påverkar gruppens samarbete lönar det sig att skjuta upp allt annat för att behandla det här problemet direkt. Att skjuta på problemet gör bara att det tar upp ännu mer tid! Skriv väldefinierade aktiviteter, med tydliga definitioner av vad det innebär att aktiviteten är avslutad.

5 Ha bra och tydliga milstolpar, det är bättre att inte uppnå dessa till exakt den dagen ni har bestämt än att inte riktigt kunna veta när den är uppnådd. Börja med kommunikation mellan enheterna och få det att funka tidigt. Det är viktigt vid felsökning. Tänk efter noggrant hur reglering ska gå till och vilka typer av sensorer som kommer behövas för detta. Gör detta tidigt! Gör inte som vi och börja med reglering en vecka före leveransen. Versionshantering är viktigt. Använd Git eller SVN! I2C är krångligt och tog upp alldeles för mycket tid för oss. Det kan vara lämpligt att använda något bibliotek istället för att implementera allt själv. En fördel med I2C för exempelvis Lidar Lite är att mätvärdena man får är mycket mer tillförlitliga än om vi hade kört med exempelvis PWM. Se till att samtliga gruppmedlemmar har samma ambitionsnivå. Ha ett sätt att ta reda på hur långt ni har åkt som inte beror på batteriets spänning. Använd någon typ av sensor för att mäta lagd sträcka. Underskatta inte det här. Ta tag i saker i god tid. Om ni märker att något ni har tänkt er inte fungerar bör ni inte spendera veckor på att arbeta runt problemet utan istället ta ett steg tillbaka och fundera på om ni kan lösa det på ett bättre sätt. Löda är mycket bättre än att vira. Gör ett kretskort om ni kan.

6 Använd ett versionshanteringssystem och lär er att använda det ordentligt. Använd versionshantering samt integrera ihop kod ofta. Sätt från starten höga krav på kod som ska versionshanteras i gemensamma grenar samt följer en gemensam kodstandard. Vid felsökning bör processen startas från båda mjukvarusidan och hårdvarusidan. Det vill säga testa del för del, för att snabbt kunna utesluta fungerande delar. Planera in regelbundna möten för att diskutera kommande arbete samt avklarat arbete. Så alla i gruppen får en uppfattning av framgångar och motgångar. Om problem uppstår i projektgruppen, ta det direkt och gå inte och älta problem så att det blir en dålig stämning i gruppen. Planera tidigt hur ni vill att hårdvaran ska vara placerad samt vilken hårdvara som ska finnas på kortet då detta gör att ni slipper dra upp flertalet sladdar och vira om varje gång ni inser att en modul behöver läggas till. Se till att vira bra från början, så ni slipper vira om hela tiden. Dokumentera vilka portar ni använder och hur de ska kopplas. Gör inte saker onödigt komplicerade, starta med lätta saker och utöka funktionaliteten. UART är bra!

7 Bluetooth kommunikation med till exempel Raspberry pi är mycket användbart för felsökning. Använd c++ istället för c, klasser och dylikt är användbart. Att få bra sensorvärden kan vara mycket svårt så se till att vara noggranna när ni kalibrerar dem, felaktiga sensorvärden gör den autonoma navigeringen otroligt frustrerande Fundera på att använda inverterad kinematik till rörelser, de blir betydligt mycket finare (sexbening). Sätt gränser på servona så de inte slår i chassit och går sönder (sexbening). Använd PWM på LIDAR-sensorn, om ni endast ska mäta avstånd med den. Ha så korta och snyggt virade kablar som möjligt i digitala bussar. Skriv modulär kod som är enkel att modifiera. Lägg mycket tid i början av projektet så att ni slipper lägga ner väldigt mycket tid i slutet. Gör simulatorer.