Teknik

I teknikgruppen har vi hittat en strategi som funkar väldigt bra för oss, Vi har två personer som Konstant programmerar, samtidigt som vi har en från “rapportgruppen” som kommer in till oss för att lära sig programmeringskonsten av just detta program. Man kan se den personen lite som en lärling som är med oss en lektion och sedan rullar det bland alla i laget från lektion till lektion. Lärlingen hjälpte även till med att bygga olika armar och startblock till olika uppgifter.

Om man går tillbaka till oss två konstanta programmerare så var vår strategi att dela upp arbetet. Vi är två duktiga programmerare och eftersom vi inte har haft så mycket tid på oss så insåg vi snabbt att detta var den optimala strategin. Vad jag menar är att istället för att hålla på med ett uppdrag i taget så gjorde vi varsitt och sedan kombinerade dem när båda var klara. På detta sätt gjorde vi lika mycket som de flesta andra lag, fast på hälften så lång tid. Men däremot tog valde vi inte uppdrag genom att slå en tärning. Vi observerade banan, tänkte ut en “väg” för roboten och valde på så sätt en så effektiv väg som möjligt för att reducera tid. Tillexempel istället för att köra över banan och mellan uppdragen på en väg som en åtta valde vi att köra som en nolla. På detta sätt skippar vi mittendelen och följer kanterna vilket kanske till en början gjorde att vi missade lite poäng men i slutändan sparade mycket tid för att kanske ett extra uppdrag i slutet.

I vår teknikgrupp är vi två beständiga personer vilket resulterar till att vi kommer lösa problemen vi stöter på, på olika sätt.

För Taaseen så programmerar han genom försök och misslyckande för att sedan förbättra sina egna försök och lära sig utifrån det.  Han använder inga mått eftersom han tycker att på så sätt kan man se de olika scenarion som kan ske. Taaseen brukar oftast observera uppgiften ett tag, försöker komma på ett antal lösningar , efter det tänka på vilken arm som skulle behövas och uppdraget går att lösa med armen som redan sitter på roboten. När Taaseen tror att han har hittat en lösning så börjar han programmera (med gissade mått) och sedan redigera han programmet in i detalj tills han har uppnått perfektion.

För Alfred när han programmerar fungerar det lite på samma sätt, han bestämmer sig för ett uppdrag, inspekterar det och försöker komma på flera olika sätt det går att lösa uppgiften. Efter han har kommit upp med ett antal idéer så ”går” han igenom det med roboten så han får upp bilden i huvudet hur det ska fungera. Efter det börjar Alfred programmera och försöker efterlikna den bilden han målat upp så mycket som möjligt. Han väljer först ut en startpunkt eller bygger en [startplats] så att den alltid börjar på samma ställe då skillnaden mellan att lyckas eller inte handlar om millimeter åt något håll.

Vår robot använder sig av fyra motorer och inga sensorer. Dem tre första motorerna är ”basic” och nästan alla använder dem där man har två för varsitt däck och en för mittenarmen. Den fjärde däremot är våran egen idé, det är en vi la till på sidan av vår robot så den kan lösa specifika uppgifter. Anledningen till att vi la till en motor istället för att bara placera en lego del där är så att vi kan med motorn ”ta bort” handen, för att förenkla det för roboten att ta sig igenom smala områden. För våran mitt arm så ser den ut såhär (((((. I tidigt skede var tanken att göra en arm med kloform, som vi hade förra året, men den idéen skrotades ganska snart. Vi insåg att årets bana är mycket simplare och vi gjorde endast en arm för att lösa de uppgifter vi hade planerat att lösa. Med den vetskapen gjorde vi en arm gjord av två stycken plusformade bitar. Den armen lyckades med en del uppgifter men inte alla vi hade planerat så vi la till en 90 gradig bit. Denna hjälpte till för att lösa en del saker utan att förstöra något för de andra uppgifterna. Precis när vi trodde att vi var klara med armen så insåg vi att vi inte kunde lösa problemet med ”trafikstoppningen” på grund av att armen bara gled av när dem var påväg upp. Som tur var hittade vi en gummidel som vi hade använt förra året som hjälpte till då den stack fast i legobiten på ett bra sätt.

Det finns en annan anledning till att vi hade gjort en så simpel och effektiv arm. Vi tror på att man inte behöver komplicera saker utan att det är bäst att hålla det smidigt och enkelt eftersom vi inte är några karriärprogrammerare. Desto större du bygger, desto större chans att göra ett misstag och desto längre tid att programmera. Dessa misstag skulle kunna uppstå av flera olika problem såsom friktion, vikt, obalans och så vidare. Förra året hade vi en robot som kunde göra massa saker men eftersom den var så stor så fick vi problem på tävlingsdagen och det blev lite av ett fiasko, så vi har bestämt att inte göra samma misstag detta år.

Vår design är ganska lik den vi började med eftersom vi tycker det är bra att hålla den stilren och enkel för att inte ha delar som stör och kan fastna på fel ställen och uppdrag på banan. Har man en mer simpel design kan man ta tajtare kurvor, det blir mindre naturliga ”fel” som kan bero på för mycket friktion så att den inte motorn orkar utan roboten ”hoppar/hackar” sig fram. Andra anledningen till att vi gillar den simpla desgingen är för att det inte behövs mer, vi har löst största delen av uppdragen som till exempel kranuppdraget, gungan, trafikstockningen, hissen och när man ska köra ut husen med att bara sätta på en fast arm byggd av 5 legobitar.

Vår tidsplan var i början inte så välplanerad då det i början tog ett par lektioner mer än planerat för att titta igenom banan och alla uppdrag och sedan välja vart vi skulle börja med, vilka som skulle ta tid att programmera osv. Eftersom vi endast har tillgång till banan 165 minuter i veckan blir tiden rätt knapp att jobba på men det har vi löst ganska bra ändå. Som sagt det började lite kantigt men trots det flöt det på väldigt bra när vi väl kom igång med att programmera. Vi letade länge och spenderade mycket tid på varje uppdrag för att hitta det mest effektiva men ändå en metod som är säker och konstant för att lösa problemet.