Kapittel 1. Innledning - Institutt for teknisk kybernetikk - NTNU

Forslag til Utforming for Eurobot 2002 

Kapittel 1. Innledning 

Roboten ”Floke” er bygd av medlemmer fra Eksperter i Team, gruppe 2 i landsbyen 

”Kreative løsninger med innebygd styringsdatateknikk” våren 2001, ved institutt for 

Teknisk Kybernetikk, NTNU. Roboten løser oppgavene som beskrevet i rapporten 

”Floke, NTNU’s bidrag til Eurobot 2001”. 

Nye regler gjelder for neste års konkurranse i Paris, dvs ”Eurobot 2002”. Denne 

prosjektoppgaven vil analysere roboten, diskutere forskjellige forandringer som må 

gjøres og foreta en konklusjon basert på disse vurderingene. 

Kapittel 2, Robotbeskrivelse, gir en oversikt over hvordan roboten er satt sammen i dag. 

Det blir gitt en innføring i hvilke sensorsystem som brukes, hvordan roboten fysisk er satt 

sammen, dvs alt av kort, sammenkoblinger, plasseringer og tilkoblinger. 

Kapittel 3, Miljøbeskrivelse, tar for seg det domenet roboten er ment å fungere i. Dette er 

i henhold til reglene for konkurransen i 2002. De komplette reglene finnes i vedlegg A, 

og dette kapitlet gir en kortfattet innblikk i disse, slik at leseren raskt får en oversikt over 

hvordan konkurransen vil bli gjennomført. 

Kapittel 4, Roboten, Vil det bli beskrevet hvilke regler og restriksjoner som gjelder for 

den deltakende roboten. Disse reglene må følges i design og utvikling av hardware, 

software og mekanisk utforming. 

Kapittel 5, Drøfting av forskjellige løsninger, inneholder en oppsummering av de 

viktigste forskjellene i reglene for 2002 kontra 2001. Her finner vi også tips og råd fra 

forrige gruppes erfaring med konkurransen, roboten og fremgangsmåte. 

Dessuten vil det bli beskrevet forslag til hvordan roboten kan bli designet, strategi, 

fremgangsmåte og en vurdering av forskjellige mekaniske innretninger. 

Kapittel 6, AI, vil foreta en analyse av robotens kunstige intelligens. I hvor stor grad skal 

man forandre eksisterende kode, hva kan brukes om igjen, og hva må skiftes ut? Det blir 

gitt en oversikt over strukturen på forskjellige metodekall i AI-tråden, og en vurdering av 

de eksisterende filene, som er skrevet i programmeringsspråket C. 

Kapittel 7, Diskusjon og konklusjon, oppsummerer de forskjellige løsningene, ser på 

fordeler og ulemper, som resulterer i en anbefalt fremgangsmåte for modifisering av 

roboten. 

Kapittel 8, Videre arbeid, gir tips og råd til realisering av nevnte konkluderte 

fremgangsmåte. 

Bakerst i vedlegg A finnes de komplette reglene for konkurransen, utgitt av ANSTJ. Det 

anbefales at disse studeres nøye før man går i gang med ombygging og realisering av ny 

robot. 

Frode Vik Bredesen, Institutt for Teknisk Kybernetikk 

Norges Teknisk-Naturvitenskaplige Universitet 

1


Kapittel 2. Robotbeskrivelse 

Her vil det bli gitt en oversikt om hvordan roboten fungerer i dag. Alle opplysninger er 

hentet fra rapporten som ble skrevet i forbindelse med vårens konkurranse i Paris, av 

medlemmene i Eksperter i Team. inngående beskrivelser av utstyr/kort og liknende som 

sees som lite relevant i forbindelse med reglene i Eurobot 2002 er utelatt. Ønskes mere 

informasjon om dette, oppfordres leseren til å lese rapporten fra Eksperter i Team. 

Roboten har et chassis av aluminium. To motorer driver seks hjul, alle med framdrift. 

Styringssystemet for motoren blir tatt hånd om av et mikrokontrollerkort. En vanlig 

mainstream-PC med operativsystemet Windows 2000, som tar seg av høynivåstyringa. 

Roboten har (foreløpig) disse ulike sensorsystem for navigering over spillebrettet: 

Figur 1. To versjoner av roboten. Den første er en versjon fra 2001, den andre er NTNU’s bidrag fra 2000 

Type Modalitet Utstyr 

Eksteroseptiv Syn Webkamera for 

sylinderdeteksjon 

Proprioseptiv Distanse Encodere for hjulrotasjon 

Proprioseptiv Vinkel Gyro for rotasjonsmåling 

Tabell 1. Eksisterende sensorsystem 

Disse encoderne og gyroen sender data til mikrokontrollerkortet, som regner ut robotens 

posisjon, og sender dette til PC’en. Denne kombinerer dette med kamerainput og tar 

beslutninger for hva roboten skal foreta seg. PC’en sender deretter kommandoer til 

mikrokontrollerkortet, som regulerer motorene. 

Per i dag er roboten utstyrt med skyvearm for utplassering av flagg på lave sylindere, og 

en heis til en stor sylinder. 



2


2.1 Kort, sammenkobling og plassering 

Roboten består av to hoveddeler; topp og bunn. Bunnen inkluderer hjul, batterier, motor 

og encodere. Det brukes to stk. 12 V batterier (datablad) i serie som dermed forsyner 

roboten med 24 V, 3 ampere. Disse batteriene er hovedstrømsforskyningen til roboten, og 

brukes nesten av alle deler av roboten som trenger strøm. Det er 3 hjul på hver side som 

blir drevet av en motor hver. Motorene er av type Maxon DC motor, 90 W og er koblet til 

hjulet i midten på hver side. (datablad). Hjulene er koblet sammen slik at det blir 

fremdrift på alle hjulene. Det er en encoder til hver motor. Disse teller antall 

omdreininger på motorakslingen, og sender denne informasjonen til 

mikrokontrollerkortet. 

Sammenkoblinger mellom topp og bunn av roboten er spenning fra batteriene til powerkortet, 

spenning fra servoforsterkerne til fremdriftsmotorene og informasjon fra 

encoderne til mikrokontrollerkortet. For å få tilgang til bunnen av roboten, løsner man to 

fester, ett framme og ett bak, og vippe toppen framover. 

På denne måten er det enkelt å bytte batterier. 

Toppen består for øyeblikket av flere deler. Den har en PC og et mikrokontrollerkort fra 

Barco Kongsberg, en flaggplantningsmekanisme med skyvearmskort og flaggheisen. I 

tillegg har den et tilkoplingspanel, to servoforsterkere, et power-kort, nødstopp, startsnor, 

styringskort for flaggdropping, webkamera og gyro. 

Figuren under viser plasseringen til de forskjellige delene på roboten. 

2.2 Tilkoblinger 

VGA-monitor, tastatur, mus, nettverk og ekstern spenningskilde kan koples til 

tilkoplingspanelet på siden av roboten. panelet har også en 10A sikring og AV/PÅ bryter 

for batteri-spenning, som ikke har noen innvirkning på den evt spenningskilda. PC’en vil 

altså starte opp ved tilkopling av 24V DC, uavhengig av hvilken posisjon bryteren står i. 

(vedlegg for koplingsskjema). 

Servoforsterkerne leverer spenning til fremdriftsmotorene som er plassert i bunnen av 

roboten. Det er en forsterker til hver motor. De får spenning fra power-kortet, og 

styringssignal fra Barco-kortet. 

Power-kortet får 24V DC fra enten batteriene eller fra en ekstern spenningskilde. Kortet 

bruker to DC/DC-konvertere (vedlegg) for å gjøre denne spenningen om til 5 og 12 V 

DC. De forskjellige enhetene på roboten kan da hente den riktige spenningen fra dette 

kortet. 

Nødstopp er påbudt for robotene i Eurobot-konkurransen, som må være godt synlig. 

Nødstoppen på roboten resetter Mikrokontrollerkortet, slik at dette må aktiveres pånytt 

for å fungere. Dermed vil ved bruk av denne nødstoppknappen føre til at roboten stopper 

opp, samtidig slik at PC’en holdes operativ. Dette for å unngå lang oppstartstid. 



3


Det er også påbudt med en startsnor, eller en annen startmekanisme. Robotens startsnor 

kopler 5V til en analoginngang på mikrokontrollerkortet ved hjelp av en ”pull-up” 

motstand. Selve startsnora er bare en enkel ”jumper” som kutter banen inn til kortet når 

snoren dras ut. Programmet sjekker denne inngangen kontinuerlig og starter roboten først 

når spenningen på inngangen er sunket under et visst nivå. 

Web-kameraet er koblet direkte inn på PC’en via Universal Serial Bus (USB). Kameraet 

er festet i toppen av roboten i front og ”ser” skrått fremover. Det brukes til å navigere inn 

mot sylindere, hvor roboten i henhold til konkurransen fra 2001 skulle sette ut flagg. 

2.2.1 PC 

En komplett PC er ”hjernen” til roboten. Den består av et NOVA-600 EBX Pentium 

hovedkort, og en AMD K6-2 300 MHz prosessor. Den har 128 MB RAM, og en harddisk 

av typen IBM Travelstar på 4.86 GB. 

Hovedkortet er en veldig kompakt industri-PC. Den har integrert grafikk- og 

nettverkskort. Det er også utstyrt med alle I/O-muligheter som en vanlig PC. Det vil si 

både seriell, parallell og USB-porter. Det har floppy-disk interface, og Ultra DMA/33 

IDE interface for tilkobling av harddisk. Det støtter prosessorhastigheter opp til 300MHz. 

Operativsystemet som kjøres er Windows 2000. Dette gjør det enkelt å benytte USBkameraer 

og å programmere på et høyt nivå. Bortsett fra dette har operativsystemet 

mindre betydning. 

Prosessoren på PC’en er følsom for overoppheting dersom det blir dårlig luftsirkulasjon. 

På roboten står prosessoren med vifte nesten helt inntil beskyttelsesdekselet, og det var 

derfor nødvendig å lage en del luftehull. I tillegg har harddisken til roboten et punkt som 

ikke må dekkes til. Dette er viktig å ta hensyn til når denne skal festes. Punktet er godt 

merket. Brukermanual (vedlegg). 

2.2.2 Mikrokontrollerkort 

Dette kortet som nå står i er laget av Barco Kongsberg, og som har programvare derfra 

også. I årets robot vil det derimot bli portet VxVorks til kortet. 

2.3 Sensorer 

2.3.1 Encoder 

Generelt er encodere sensorer som oversetter mekanisk bevegelse som for eksempel 

hastighet og akselerasjon til elektriske signaler. Det finnes to typer encodere, absolutte og 

inkrementelle. Forskjellen mellom disse er at absolutt-encoderne har unike verdier for 

eksempelvis hver posisjon I motsetning til de inkrementelle encoderne, der hver 



4


forandring i posisjonen vil gi en inkrementering i verdi i forhold til forrige verdi, og må 

derfor leses ved oppstart av roboten. På det nåværende tidspunkt benytter roboten to 

inkrementelle encodere, en for hver motor på høyre og venstre side. For hver hele 

rotasjon sendes det ut in indeks-puls, som markerer en enkelt posisjon, og opptrer på en 

egen kanal fra encoderen. 

2.3.2 Gyro 

Et gyroskop viser stillingsforandring, her med hensyn på vinkel i horisontalplanet. Den 

består av et lite svinghjul opphengt på en aksel. Den fungerer slik at hvis roboten blir 

forsøkt dyttet bort fra kjøreretningen vil den kunne justere seg tilbake til riktig retning 

igjen. 

Figur 2. Skisse av gyro 

Gyroens aksel må stå vinkelrett på den rotasjonsretningen som man vil registrere. En ytre 

kraft virker på akselen og denne vil bevege seg loddrett på kraften, eller på tvers av 

trykkretningen. Gyroen må i tillegg ha en referansespenning, i dette tilfellet 2,5 volt, der 

en rotasjon til høyre eller venstre vil medføre at spenningen stiger eller synker. 

Spenningsområdet ut fra gyroen er fra 0 til 5 volt, driftsspenning 12 volt. Gyroen er ellers 

ganske ømfintlig for kollisjoner og støt, og vil gå i metning ved hurtig rotasjon, for 

eksempel hvis roboten snur seg for raskt. Maksimal rotasjon er 90 grader. 

2.3.3 Kamera 

Roboten benytter et webkamera for å kunne identifisere mål. Det har blitt laget algoritmer 

for å gjenkjenne diverse mål, spesielt noen sylindere som skulle finnes i forrige Eurobotkonkurranse. 

Disse baserer seg på form og farge-gjenkjenning. 



5


Figur 3. Webkameraet som brukes i roboten 

Kameraet er ømfintlig for varierende lysforhold og det er montert på et polariserende 

filter for å filtrere vekk refleksjoner og hindre at kameraet går i metning. 



6


Kapittel 3. Miljøbeskrivelse 

Dette kapittelet dreier seg om hva roboten skal gjøre, hvordan og hva konkurransen, 

Eurobot 2002 går ut på. 

Konkurransen har tittelen ”Flying Billiards”, og går i korte trekk ut på at to roboter, som 

starter på hver sin side av et spillebrett, skal plukke opp baller spredt tilfeldig 

rundtomkring på bordet for så å legge disse oppi kurvene lokalisert i hvert hjørne. 

3.1 Spillebrettet 

Brettet er et rektangulært treplate som måler 300cm x 210cm og malt grønt. Det har to 

startsoner i hver ende, konstruert av to rektangulære treplater som måler 60cm x 60cm og 

malt i samme grønnfarge. De fire kurvene er lokalisert i hvert sitt hjørne. Ei kantliste av 

tre omringer spillebrettet med 7cm høyde og 2.2cm vidde, og er også malt grønt. Den 

strekker seg 15cm nedover under spillebrettet. Kantlistene er montert 

fullstendig på siden av brettet, slik at de dermed er utenfor de nevnte brett-dimensjonene. 

Fullstendig beskrivelse av bordet finnes i appendiks A i vedlegg A 

Figur 4. Spillebrettet 



7


Hvite linjer deler opp spillebrettet i et rutenett, og avstanden mellom hver linje er 30cm. 

Det blir da med rask hoderegning 10 linjer på tvers og 7 på langs av spillerfeltet. Linjene 

som går på tvers er 3cm vide, og de som går på langs er 2cm vide. 

3.2 Beacons 

Beacons er mottakere og/eller sendere som spillerne kan sette ut på bestemte plasser. Det 

er 10 steder man kan utplassere disse, altså 5 til hver spiller. Før hver match kan spillerne 

plassere ut sine beacons på 50cm høye stolper, som står på hver sin kortside av 

spillebrettet. I følge reglene kan man montere disse på andre siden av sin egen startsone, 

dvs dine over motstanderens kortside, og hans over din startsone. 

Figur 5. Beacons 

Platåene oppå disse er 8cm x 8cm og dekket med den harde delen av en borrelås. Det er 

derfor intuitivt at de beacons’ene man vil plassere ut har den myke siden av en borrelås 

montert på undersiden. Detaljer finnes i appendiks A i vedlegg A. 

3.3 Ballene 

Tolv baller er ved start spredt utover spillebrettet, åtte er røde og fire er svarte. ”Billiardballen” 

er representert av en 14cm i diameter, og er egentlig rytmisk sportsgymnastikkballer, 

som egentlig er 16cm i diameter, men som blir tappet for luft til de når størrelsen 

14cm i diameter. Merket brukt av arrangørene er ”Togu”, som sikkert er lett å få tak i 

Frankrike, men som vi nok må lete litt ekstra etter her i Norge. Ballene veier 300g hver 

(+/- 2%). 



8


3.4 Kurvene 

De fire kurvene er proposjonert til å inneholde omkring 4 baller hver. Kurvene har et 

system slik at det går an å ”stjele” en ball fra kurven, en etter en. Kurvene har sin åpning 

25cm over bordhøyde, og selve kurven er åpen i bunnen slik at en og en ball ligger under 

Figur 6. En av de fire kurvene 

kurven i kontakt med nettet, men nede på bordet. Vel og merke så er kurvene designet 

slik at man kan kaste ballene oppi dem. 

Bare sluttstatusen til kurvene bestemmer poengberegningen, dvs baller som blir lagt oppi 

en kurv, og deretter fjernet, vil ikke telle som poeng på denne kurven. Ballene må være i 

fysisk kontakt med kurvene for at poeng skal tilkjennes. 



9


Kapittel 4. Roboten 

Først og fremst må roboten være fullstendig automatisk styrt (utelukker all bruk av 

sendere), ha med seg sin egen energikilde, aktuatorer og kontrollsystem. 

4.1 Restriksjoner 

Endel restriksjoner er det (selvfølgelig) også på robotene: 

- Roboten kan ikke med overlegg hive ballene vekk fra spillebrettet. 

- I løpet av matchen kan ikke noe form for utstyr befinne seg over lengre tid i området 

for operasjon av beacons, dvs over 50cm. 

- En robot må ikke designes for å skade motstanderens robot med vilje (Altså ingen 

robot-wars!!!!) eller spillebrettet. Den kan heller ikke ha f.eks. skarpe objekter som 

ved et uhell kan ødelegge brettet eller den andre roboten. 

- Man kan heller ikke med vilje hindre den andre roboten, eller bruke objekter eller 

grafikk som etterligner spillebrettet for å lure den andre roboten. 

- Ingen pyrotekniske eller korroderende produkter samt levende objekter er tillatt. 

- Generelt vil roboten bli pælma på hauet ut av konkurransen hvis arrangørene finner ut 

at roboten er for farlig for omgivelsene til å bli brukt. 

4.2 Obligatorisk utstyr 

Et startsystem må være enkelt å aksessere og utløst av en minst 50cm lang wire. Wiren 

må aktivere kun et elektrisk utstyr. Denne wiren må ikke forbli på roboten etter start, men 

må røskes av i startøyeblikket for å sette i gang roboten. En tydelig AV-knapp må være 

påmontert, som det er nå i form av en nødstopp. 

4.3 Spesifikasjon av roboten og beacons’ene 

- Den vertikale projeksjonen av roboten må ikke overstige 130cm (dvs den korteste 

vegen å gå rundt skyggen av roboten under vertikalt lys. Formen på denne 

projeksjonen kan varieres gjennom matchen, forbeholdt at den holder seg innenfor 

omkretsen på 130cm. 

- Roboten må ikke være høyere enn 40cm. 

- Ballene som er plukket opp av roboten er ikke med i disse dimensjonene, men for å 

ikke forhindre motstanderens beacon, må disse ballene ikke løftes mere enn 50 cm 

opp (over lengre tid). 

- Beacon’ens størrelse må ikke overgå de 8cm lange sidene på support-stengene. 

- Roboten må lages av internt avhengige elementer. 

- Generelt vil en robot som tolkes som en trussel for sikkerheten mot de andre 

robotene, deltakerne, tilskuerne og whatever bli vist bort. 

Mere spesifiserte regler finnes i vedlegg A 



10


Kapittel 5. Drøfting av forskjellige løsninger 

5.1 Regler for 2002 kontra 2001 

Den største forskjellen bortsett fra åpenbart andre spilleregler og annet spillebrett er at det 

ikke lenger er lov til å bruke såkalte MSP’s (Moving or Stationary Portion). Dette betyr at 

det ikke vil være lov med små ”terrorroboter” som hopper ut fra hovedenheten ved start i 

den hensikt for å sperre motstanderen eller utføre oppgaver i henhold til spillet. Dette 

tolkes som et forsøk fra arrangørene på å legge vekt på at robotene skal være så 

intelligente som mulig, i steden for ”hack and slash”-teknikk som favoriserer raske 

”dumme” småroboter som bare har en oppgave. Dette vil være en stor fordel for NTNU’s 

bidrag til konkurransen, siden det er nettopp AI og ikke terror bidraget har blitt lagt vekt 

på. 

5.2 Tips og råd fra forrige gruppes erfaringer med konkurransen 

5.2.1 Roboten 

Roboten er utstyrt med gummihjul og encodere for å måle hjulrotasjon. Disse encoderne 

sender beskjed til mikrokontrollerkortet som sender beskjed videre til robotens AI for 

bestemmelse av posisjon. Erfaringer har vist at dette systemet for beregning av posisjon 

ikke er veldig nøyaktig. Grunnen til dette er at hvis roboten f.eks. spinner, vil ikke dette 

bli detektert som annet enn framdrift, og robotens posisjon vil dermed bli feil. Jo tidligere 

dette skjer, jo større og større vil feilen bli etterhvert som roboten navigerer seg frem på 

brettet. En kollisjon vil også føre til at roboten kommer ut av posisjon, og dette affekterer 

ikke bare encoderne, men også gyroen som måler forandring i vinkel. Ved normal 

dreining av roboten vil gyroen detektere forandringen i vinkel, men ved et forholdsvis 

kraftig støt vil dette ikke registreres grunnet gyroens fysiske begrensninger. Som sagt 

tidligere ligger gyroens begrensninger på 90 grader. 

Opprinnelig skulle robotens posisjon også beregnes mere nøyaktig av et ultralydsystem, 

som ved hjelp av signaler fra sendere montert på beacons’ene krysspeile avstanden til 

disse og dermed oppnå nøyaktig posisjon. Siden dette systemet ikke fungerte ved 

ferdigstilling av roboten, ble denne løsningen forkastet. Det stilles dessuten spørsmål om 

denne løsninga ville fungert på konkurransen i Frankrike. Personer som medlemmene i 

Eksperter i Team snakket med på konkurransen påsto at et slikt system ville bli kraftig 

forstyrret av støy fra publikum, utstyr og annet kaos som pågikk når konkurransen var i 

gang. Det vil derfor bli sett på som urealistisk å få et slikt system til å fungere annet enn 

ved ideelle forhold. Andre måter å bruke beacons’ene på vil heller bli vurdert. 



11


Figur 7. Beacons og sylindre med fargekode for navigering 

I NTNU’s bidrag til konkurransen ble det brukt anretninger med fargekoder som var 

plassert på beacons’ene, og ved hjelp av webkameraet kunne roboten navigere seg fram 

til disse. Dette vil være en bedre løsning også for bidraget til 2002. 

5.2.2 Mikrokontrollerkortet 

Mikrokontrollerkortet har programvare fra Barco Kongsberg, og er designet for å operere 

en maskin for å plotte store prosjekter på arkstørrelser opp til A0. Kompilator ble utlånt 

fra Barco Kongsberg, og var ikke særlig optimalt å ha med å gjøre. Det var liten eller 

ingen muligheter for feilsøk med dekoderen, og roboten måtte rett og slett kompileres og 

deretter kjøres for feilsøk. Dette kortet vil nå få sin programvare erstattet med VxVorks, 

slik at feilsøk blir betydelig lettere. 

5.2.3 Kameraet 

Kamerasynet var veldig ømfintlig for varierende lysforhold. Spesielt gjaldt dette for 

deteksjon av de orange sylinderne som var dekt med et hvitt lag på toppen. Det var denne 

hvite ovalen kameraet skulle se etter, men siden lysforholdene varierte veldig fra 

konkurranse til konkurranse måtte kameraet kalibreres for hver gang, uten kanskje å vite 

helt hvordan det skulle bli. Lysforholdene varierte sterkt mye på grunn av om 

konkurransen ble filmet av kameraer eller ikke. Kraftige lys montert på tv-kameraene 

bidro til at kameraet gikk i metning og så kun hvitt, og dermed var ute av stand til å finne 



12


sylinderne. Dette var dermed en ekstra utfordring for roboten som fra før av kunne være 

uta av posisjon. 

5.2.4 Andre ting 

Det finnes per i dag ingen anretning for deteksjon av kollisjon, f.eks. i form av 

mikrobrytere i front eller rundt roboten. Det kunne ha vært en fordel med dette i og med 

at mikrokontrollerkortet kunne ha sendt et avbruddssignal til motorene sånn at de stoppet 

slik at encoderne ikke akkumulerte så mye feil i posisjonsberegningen. Implementasjon 

av dette kunne også få roboten til å snu hvis den kjørte på en permanent hindring, få den 

til å rygge litt, og snu. 



13


5.3 Forslag til adferd for oppgaveløsning 

Det er flere muligheter for å løse denne oppgaven. Noen virker mer eller mindre 

gjennomførbare enn andre, bla må kostnad taes i betraktning, men det er viktig å se på 

flere sider av saken, slik at man ikke blir for ensporet på bare ei løsning. På grunn av 

ballenes størrelse (14 cm i diameter) og vekt (300g) vil en noe diskutert ”støvsuger”- 

metode være uaktuell. Det var tenkt at roboten ved start skulle gå et fast mønster over 

spillebrettet, der den skulle suge opp ballene den støtte på gjennom en åpning i front. 

Etter denne oppsamlingen kunne en intern rutine som inkluderte f.eks. et kamera 

detektere fargen på ballene (rød eller svart), for deretter å kjøre til tilhørende kurv og 

legge dem oppi. Denne løsninga vil kreve en forholdsvis kraftig oppsugingsmekanisme, 

som vil sette store krav til dens motor, og dermed også størrelse. Vertikal projeksjon av 

roboten kan som kjent ikke overstige 130 cm, og høyden på max 40 cm. Å finne en 

såpass kompakt og kraftig støvsuger, og samtidig ta i betraktning av at roboten også skal 

bestå av bevegelsesmotorer, mikrokontrollerkort, hovedkort, kamera osv, vil bli 

tilnærmet umulig. 

En annen mulighet som også har vært tenkt på er at roboten ved start folder ut to armer 

som strekker seg til sidene av spillebrettet, for deretter å burne framover for å samle opp 

ballene, som blir liggende på ei rett linje forover med en arm på hver side. Ved å løfte 

disse armene opp, kan man kjøre til en kurv, for så å sette igang et samlebånd som ligger 

lansetter armene og lempe ballene i kurvene, omtrent som man transporterer folk opp ei 

rulletrapp, eller frakter malm opp i en smelteovn. Denne løsninga overskrider også 

reglene om vertikal projeksjon, altså at omkretsen rundt roboten bli for stor, dvs over 130 

cm. 



14


Figur 8. Forkastet løsning 

Det ligger derfor an til at roboten må plukke opp disse en etter en ved hjelp av ei 

gripearm, og deretter samle disse opp og/eller kjøre bort til rette kurv med denne ene eller 

flere baller. 

5.3.1 Oppsamling av baller 

Den første ballen roboten vil møte er en rød, som alltid vil ligge ved utgangen av 

startfeltet. Siden man vet nøyaktig hvor denne ballen ligger, kan den plukkes opp relativt 

enkelt. Ballen kan plukkes opp av ei enkelt klo montert på robotens front. Det er to 

strategier herfra: 

- kjøre bort til motstanderens kurver og droppe den der 



15


- samle opp flere baller før man cruiser bort til de rette kurvene 

Å plukke opp en etter en kan bli en tidkrevende affære. Å satse på å finne flere baller 

burde være en bedre løsning. Her ser jeg for meg en metode der ballene blir ved hjelp av 

ei klo løftet opp og lagt ned i et rør kuttet av på langs, slik at det ser ut som en half-pipe 

eller ei takrenne som heller skrått ned mot eller på siden av roboten, slik at ballene ligger 

på rekke og rad nedover langs denne renna. Det som er viktig på denne tegninga er 

prinsippet med kloa og renna. Designen ellers blir nok litt for fantasifull for praktisk 

bruk, og tar ikke spesielle plasshensyn. 

5.3.2 Avlevering av baller 

Figur 9. Forslag til robot sett fra siden 

I hvert tilfelle der roboten plukker opp en ball, må det registreres hvilken farge denne 

ballen har, og hvilken plassering den vil ha i renna. Hvis denne renna bli full, eller at ei 

viss tidsgrense går ut for ballsøk på spillebrettet, vil hovedoppgaven for roboten veksle 

fra ballsøk til kurvsøk, slik at den beveger seg mot kurvene for å avlevere ballene. Ved å 

bekke ned den andre enden av renna rundt en aksling plassert på midten av denne, vil 

ballene rulle fram og ligge fremst i renna. Roboten ”vet” da hvilken rekkefølge disse 

ballene ligger i, og kan deretter kjøre frem til rett kurv. La oss si at roboten har plukket 

opp baller slik at de ligger i denne rekkefølgen: svart-rød-rød-svart-rød. (Den første 

ballen som ble plukket opp er den røde som lå ved startposisjonen, og vil da ligge 

bakerst). Siden den ballen som ble sist plukket opp er svart, vil roboten ta retning mot en 

av sine egne kurver, ta den første ballen i renna ved hjelp av kloa, og droppe den i 

kurven. Posisjonen til ballene vil da være rød-rød-svart-rød. Deretter vil den kjøre til 

motstanderens kurver, for så å droppe av disse der. Så snur den, for å dumpe den siste 



16


svarte ballen, og returnerer nok engang til motstanderens kurver for å slippe av den siste 

røde ballen. 

Figur 10. Forslag til robot sett forfra 

Det er også videreføre denne ideen videre. Etter at ballene er oppsamlet i renna og 

vinkelen snudd, kan roboten spare tid f.eks. ved først å avlevere alle de svarte ballene den 

har plukket opp i renna ved sine egne kurver. Det stilles dermed krav til at kloa kan 

bevege seg langs renna og plukke opp baller med bestemte farger. La oss anta den samme 

ballposisjonen i renna: svart-rød-rød-svart-rød, og at den kjører til sine egne kurver først. 

Kloa plukker opp den fremste svarte ballen, og hiver den oppi kurven. De andre ballene 

ruller da framover og inntar en ny posisjon i forhold til den gamle. Roboten må da selv 

oppdatere denne posisjonen. Den nye rekkefølgen blir da: rød-rød-svart-rød. Kloa må da 

plukke opp ball i posisjon nr 3 for å finne den svarte ballen, for så å dumpe denne i 

kurven. Posisjonene til ballene vil da være rød-rød-rød, og deretter kan roboten kjøre bort 

til en kurv på motstanderens side, og kvitte seg med resten, i og med at de alle er røde. 

En enda større videreutvikling kan være å ha ei renne på hver side av roboten, en for røde 

og en for svarte baller. Det vil dermed bli overflødig med en rutine som har kontroll på 

hvilken farge som ligger fremst osv. Denne løsninga stiller imidlertid sterke plasskrav, og 

blir om mulig ikke gjennomførbar. 



17


Figur 11. Nærbilde av kloa med infrarødt deteksjossystem 

Renna (eller rennene) kan også utstyres med en egen avleveringsmekanisme, som skyver 

ballene ut av renna ved egen hjelp, slik at kloa bare har den oppgaven å samle opp baller. 

Dette vil forenkle designen av selve kloa. Har man to renner vil strategien bli å kjøre 

fram til en kurv, for så å tømme den korresponderende renna i kurven. Ved å skyve 

ballene ut av renna, vil disse falle ned i kurven, og roboten kan kjøre mot neste kurv 

igjen, gjøre det samme med disse ballene, for så å skifte oppgave til å søke etter baller på 

spillebrettet igjen. 

5.3.3 Sensorer 

Et veldig vitalt punkt ved hele spillet, er å finne fram på brettet, finne ballene og kurvene. 

Til dette kan det brukes flere forskjellige sensorer. Nedenfor følger ei liste over mulige 

typer sensorer, hva de kan brukes til, og hvor aktuelle de er. 

Type Modalitet Utstyr Anvendelsesområde Aktuell 

Eksteroseptiv Syn Webkamera Deteksjon av baller og kurver Ja 

Eksteroseptiv Berøring Følere, ”bumper switches” Deteksjon av kollisjon Ja 

Proprioseptiv Distanse Encodere Registrering av hjulrotasjon Ja 

Eksteroseptiv Distanse Optisk mus Registrering av bevegelse Ja 



18


Proprioseptiv Vinkel Gyro Registrering av horisontal Ja 

rotasjon 

Eksteroseptiv Posisjon Ultralyd plassert på Krysspeiling av ultralydsignaler Nei 

beacons’ene, mottaker på 

roboten 

Eksteroseptiv Deteksjon Infrarød sensor Deteksjon av ball i kloa Ja 

Eksteroseptiv Posisjon Strekkoder på beacons’ene, 

webkamera på roboten 

Krysspeiling av strekkoder Ja 

Tabell 2. Forslag til sensortyper 

Siden ballene er tilfeldig spredt rundtomkring på brettet (bortsett fra en rød), blir det 

vanskelig å lage en forhåndsbestemt rutine som optimaliserer ruta som skal følges. 

Kameraet vil da innta en viktig posisjon for å finne ballene og kurvene. Det er viktig å ta 

hensyn til flere faktorer sånn som lysforhold, kameravinkel, og posisjon, slik at man vet 

om kurven man leter etter er ens egen eller motstanderens. 

For å forhindre at roboten ”stanger” inn mot en sidekant, kan følere plasseres i fronten og 

på bakparten. Kjører roboten i sidekanten, vil disse ”bumper swith’ene” utløses slik at 

roboten kan rygge litt, og snu seg bort fra kanten. Det vil da bli å betrakte som en 

avbruddsrutine. 

Encoderne er viktige for å måle distansen som er kjørt. Disse gir direkte informasjon om 

hvor roboten befinner seg på brettet, medmindre en kollisjon har skjedd, eller at hjulene 

spinner, isåfall er det viktig å kunne benytte seg av annet lokaliseringsutstyr. 

Optisk mus har gjennomgått en rekke forbedringer i det siste. Den inneholder ingen 

trackball, og registrerer bevegelse ved direkte avlesning fra underlagets tekstur. 

Figur 12. Optisk mus fra Apinex.Com 

I motsetning til encoderne vil musa ikke lure sitt eget styringssystem ved en evt kollisjon, 

da den måler forflytning direkte på underlaget og ikke hjulrotasjon, og gjør dermed 

roboten mere robust ved slike tilfeller. Det samme gjelder ved spinn. Den kan monteres 

under roboten like over underlaget, og har den fordel i forhold til tradisjonelle muser at 

den ikke har mekaniske bevegelige deler som kan slites ut og gi unøyaktig resultat. Den 

er også forholdsvis billig. 



19


Gyroen som måler rotasjon av roboten kontrollerer hvor mye roboten har snudd og om 

den er på vei i rett retning basert på målinger fra encoderne og styringssignal. 

Figur 13. Eksempel på gyro Gyrostar fra Murata 

Det har vært prøvd å implementere et system for å krysspeile posisjonen til roboten på 

spillebrettet ved hjelp av beacon-supports’ene. Men fra tidligere erfaring fra forrige 

gruppe virket ikke dette spesielt aktuelt, på grunn av all mulig støy under konkurransen i 

Frankrike. Det er derimot mulig å benytte en annen form for krysspeiling ved å feste 

anretninger på beacons’ene som er påmontert strekkoder. 

Figur 14. Krysspeiling ved hjelp av beacons 

Disse strekkodene kan leses av enten en vanlig strekkodeleser eller kameraet som er 

festet i front av roboten. Denne muligheten bør kikkes på nøye da roboten enkelt kan 

komme ut av posisjon ved kollisjon og støt, for ikke snakke om at den kan spinne, og 



20


dermed lure sine egne encodere. Posisjonen kan oppdateres ved slike hendelser, og selv 

om det kan ta tid, er det sterkt å foretrekke foran å bomme totalt på det man var på vei til. 

Denne løsninga ble som nevnt brukt av teamet fra NTNU ved konkurransen i 2000. 



21


Kapittel 6. AI 

Hvordan roboten skal oppføre seg blir avgjort på høyeste nivå av robotens kunstige 

intelligens. AI’en skal fungere slik at den kontinuerlig vurderer hvilken oppgave som det 

vil lønne seg å prioritere. Skal det plukkes opp baller, eller legge fra seg baller? Hvor står 

vi på spillebrettet? Hvilken kurv er det kortest vei til?. Må vi kjøre en omvei? Er det en 

rød eller svart ball vi har foran oss? De fleste av disse problemene må løses fra avstand, 

dvs roboten må bruke kamerasynet til å finne frem og vurdere avstander osv. 

6.1 Gjenbruk av kode 

Koden som eksisterer på roboten per i dag er skrevet i programmeringsspråket C. Siden 

koden legger stor vekt på målsøking, er det stor sannsynlighet for at mesteparten kan 

brukes på nytt, med mer eller mindre modifisering. AI’en kjører i en egen tråd som 

startes i programmet for kjøring av roboten. Det sendes kommandoer til 

mikrokontrolleren for å svinge, kjøre og sette ut flagg (som var hovedmålet for 

robotfunksjonen). Tilbake kommer det posisjon beregnet fra encoderavlesning. 

Posisjoneringen er med andre ord ikke den del av den kunstige intelligensen. 

Figur 15. Nåværende AI-tråd 

6.2 AI-trådens virkemåte 

Figuren over viser hvordan roboten fungerer nå. En metode som må byttes ut er helt klart 

robot_set_flag(), ettersom det er snakk om å plukke opp baller denne gangen. Inn må to 

nye metoder, en for henting av baller, og en for avlevering av baller. Metoden 

command_goto_star kan skrives om for å finne fram til baller og kurver, og dermed lage 



22


to instanser av denne. Strukturen på hvordan metodene kalles kan uten tvil gjenbrukes, 

det er bare hva metodene gjør og hvilke attributter og parametre de behandler som må 

forandres på. 

En ny oversikt over hvordan strukturen følger AI-tråden kan bli på følgende måte. 

Figur 16. Forslag til ny AI-tråd 

Vi ser at command_goto_star() er byttet ut med en ny metode som heter 

command_goto_goal(), som kan brukes til målsøking av både baller og kurver med 

forskjellige parametre. Den andre metoden som er erstattet, robot_set_flag(), blir 

etterfulgt av to nye metoder for å ta opp/avlevere ballene. Disse kan f.eks. være 

grab_ball() og release_ball(). Det kan diskuteres om disse metodene kan slås sammen til 

én, som selvfølgelig er mulig. Disse er likevel oppført som to ulike metoder for å 

fremheve funksjonaliteten til AI-tråden. 

De forskjellige filene som er implementert kan til stor grad benyttes igjen, og vil bli 

beskrevet under. 

6.2.1 ai.c 

Hovedtråden for kunstig intelligens er implementert i denne fila (altså diagrammene 

ovenfor). Denne tråden går kontinuerlig og kaller task_control() funksjonen slik at 

oppgaver blir vurdert og utført til enhver tid. 

6.2.2 command.c 

”robot.h” inneholder prototypene for de primitive kommandoene som sendes til 

mikrokontrolleren, disse er implementert i v01_robot.cpp. Laveste nivå for kommandoer 

er altså ikke implementert i command.c. Den er derimot kommandoer på et litt høyere 



23


nivå. Det finnes kommandoer som får roboten til å gå til et bestemt punkt. Funksjoner 

med suffiks_block returnerer ikke før roboten fysisk har utført en kommando. For 

eksempel vil funksjonen command_drive_block(dist, time) ikke returnere før roboten har 

kjørt dist millimeter eller etter time millisekunder, dersom ikke roboten har stoppet til da. 

6.2.3 debug.c 

Som navnet tilsier er denne fila ment for debugging. Den har en loggefunksjon som 

fungerer på samme måte som printf. Men som skriver en linje til fil for hvert kall. Fila 

blir lukket etter hvert kall, slik at ingen data skal gå tapt ved kræsj. 

6.2.4 geometry.c 

Inneholder geometri-funksjoner til bruk blant annet ved vei-finning og bildegjenkjenning. 

Disse funksjonene er svært generelle og vil kunne brukes i andre sammenhenger. En del 

er enkle vektorfunksjoner som lengde og skalarprodukt. Men det er også enkelte mer 

spesialiserte funksjoner som for eksempel geom_point_line_distance(Point a, Point b, 

Point c) som er svært nyttig for å finne ut om roboten kolliderer med noe (en annen robot, 

en kant) som står i punkt c dersom roboten skal gå fra a til b. 

6.2.5 table.c 

Kode som er direkte knyttet til spillebrettet ligger i denne fila. Algoritme for veifinning er 

også implementert her. Algoritmen som den eksisterer prøver å finne en brukbar vei 

mellom to vilkårlige punkter. Steg én i algoritmen er å forsøke den rette veien mellom de 

to punktene Dersom dette ikke er mulig, finner algoritmen ett brukbart passeringspunkt 

som ligger på midtnormalen på linja mellom start- og sluttpunktet. Algoritmen kjøres så 

rekursivt på de to halvdelene av veien inntil en maksimumsgrense for rekursjonen. Veien 

blir tilslutt forbedret ved å fjerne unødvendige svinger. 

6.2.6 tasking.c 

Funksjoner i denne fila skal være med å avgjøre hvilken oppgave som til enhver tid skal 

prioriteres. Task_control() kalles jevnlig fra hoved-AI-tråden og denne funksjonen sørger 

for å velge rett task. 

Hver task har implementert to funksjoner i denne fila. Den ene funksjonen er en 

prioritetssjekk som beregner poengsum ut i fra avstand fra robot til et mål, tid anvendt for 

å finne målet og parametre som kan settes fra brukergrensesnittet. Den andre funksjonen 

er funksjonen som kjøres når en oppgave har blitt valgt. Denne funksjonen skal sende 

riktige kommandoer for å styre roboten fram til målet. Funksjonen skal returnere 

umiddelbart for ikke å henge AI-tråden. 



24


6.2.7 win_thread.c 

Inneholder windowsspesifikke funksjoner for bruk av tråder. 



25


Kapittel 7. Diskusjon 

Denne prosjektoppgaven har gått igjennom robotens eksisterende virkemåte, oppbygging 

og funksjonalitet. Det er vurdert å bygge om roboten slik at den kan ved hjelp av ei klo 

kan løfte opp ballene fra spillebrettet, samle dem opp i ei renne, for så å avlevere dem i 

kurvene plassert i spillebrettets hjørner. 

Spørsmålet er om det skal være ei eller to renner, avhengig av fargene på ballene. 

Fordelen med å dele opp i to renner er at man ved adkomst til en kurv kan tømme hele 

renna med baller som har den rette fargen til den korresponderende kurven. Problemet 

med dette er plasshensyn, og pga størrelsen på ballene (14 cm i diameter), i forhold til 

robotens begrensninger i høyde og omkrets. Denne løsninga krever et forholdsvis 

kompakt design, som tillater oppsamling på denne måten. 

Ved bruk av ei renne sparer man plass, og får sannsynligvis plass til flere baller. Da må 

det implementeres en rutine, som holder styr på rekkefølgen på ballene i renna. 

Inneholder renna f.eks. en svart ball plassert mellom flere røde, kan det føre til 

uøkonomisk kjøring mellom kurvene for å få tømt den. 

Bruk av sensorer er også et viktig spørsmål. Mange sensorer kan gi et større ”bilde” av 

hvordan verden ser ut rundt roboten. Men også for mange sensorer kan føre til ”overkill”, 

dvs en kombinasjon av mange sensorinput krever et komplekst styringssystem som må 

prioritere mellom disse. Å satse på færre sensorer gir et mindre komplekst 

styringssystem, og vil gi bedre oversikt når man skal debugge dette. Det vil også bli 

enklere å lage effektive veivalg, altså en plan for hvordan roboten skal komme seg fra A 

til B. 

AI’en er hjernen til roboten, og det hjelper ikke hvor mange ”smarte” mekaniske 

innretninger og sensorer man har hvis roboten ikke kan samordne disse funksjonene og 

navigere over spillebrettet. Men det er likevel en stor fordel å ha bestemt seg for og ha på 

plass de funksjoner og innretninger som man har tenkt å bruke før en går løs på AI-delen. 

Som kjent eksisterer det allerede et omfattende AI-system implementert i C. Denne 

koden kan være tung å sette seg inn i, som kan føre til forvirring spesielt der denne koden 

er dårlig kommentert. Dette er et arbeid som tar tid, og tidligere forfattere kan det bli 

nødvendig å få tak i, for å oppklare utydeligheter. Alternativet er å begynne helt på nytt, 

og skrive koden sjøl. Man har derfor frihet til å implementere AI-systemet i et valgfritt 

programmeringsspråk, uten å være bundet til det som allerede eksisterer. På den måten 

har man full kontroll på metodekall og liknende fra første tastetrykk. 

På den annen side har koden blitt skrevet og testet av to tidligere bidrag, nemlig teamene 

bak NTNU’s bidrag både i 2000 og 2001. Den har blitt testet og kjørt mot andre roboter, 

som vi mangler muligheter til her. Det vil da være svært nytting å studere disse 

løsningene som er brukt, spesielt siden veiplanlegging og målsøkingsalgoritmene er svært 

like med de nye reglenes utfordringer. Koden er som nevnt skrevet i C, som er et 

programmeringsspråk mye brukt i forbindelse med sanntidsprogrammering. Erfaring fra 

forrige års team viser at de også i stor grad kunne benytte koden fra tidligere år. 



26


Kapittel 8. Konklusjon 

Roboten bør bygges og mekaniske innretninger bør være på plass før programmeringen 

av roboten starter. Av plasshensyn bør roboten bygges med ei renne som har plass til 

ballene, og ei klo som løfter ballene opp i renna og som også kan brukes til å løfte dem 

bort fra dem, og i kurvene. 

Bruk av sensorer er viktig, og til det anbefales det bruk av kamerasyn for deteksjon av 

fargekoding på beacons’ene. For registrering av kjørt distanse og posisjon anbefales 

optisk mus, som i forhold til encodere ikke gir feil verdi med hensyn til kjørt distanse ved 

hjulspinn, som f.eks. kan inntreffe ved kollisjon. Det anbefales altså at man bytter ut de 

eksisterende encoderne, og erstatter dette med ei optisk mus. For måling av vinkel spiller 

gyroen en viktig rolle, og bør tas med. Disse tre sensorene i kombinasjon vil avgrense en 

”sensorjungel”, og vil gjøre det lettere å implementere styringssystemet. 

På grunn av godt testet kode for AI systemet som allerede er implementert på roboten, vil 

jeg anbefale at denne koden brukes som basis for løsning på styringssystemet. En del av 

koden må modifiseres og skiftes ut, og dette gjelder spesielt metodene som skal benytte 

robotens mekaniske anretninger. Metoden for å sette ut flagg må fjernes, og nye metoder 

for avhenting og avlevering av baller må settes inn istedet for denne. Metoden for 

prioritetssjekk må også forandres. De delene av koden som tar for seg veivalg og 

ruteplanlegging kan til stor grad brukes igjen uforandret. 



27


Kapittel 9. Videre arbeid 

Denne oppgaven med å bygge om roboten kommer til å bli tidskrevende for ikke å 

snakke om økonomisk krevende. Det anbefales at den (eller de) som setter i gang med det 

praktiske arbeidet har god tid, tilgang til midler og et verksted i ryggen som kan være 

med på å teste ut forskjellige løsninger, spesielt når det gjelder de elektromekaniske 

komponentene. En god kommunikasjon med verkstedet er viktig for å lykkes. Spesielt 

gjelder dette hvis man har dårlige kunnskaper innenfor bygging. 

Det anbefales sterkt at de mekaniske løsningene mhp utforming, kortplassering og utstyr 

gjøres først, før man starter på AI-delen. Tidligere erfaringer har vist at fysiske 

forandringer på roboten sent i implementeringsfasen kan være katastrofalt i 

programmeringshensyn, og mye må kanskje gjøres om igjen. Ved å følge dette rådet kan 

man spare seg mange grå hår. 

Av samme grunn er det viktig å ha kontroll på det økonomiske før man starter, slik at 

men vet hvor mye ressurser man kan regne med å bruke i utviklinga. 



28


Litteratur 

[Murphy, 2000] Robin R. Murphy (2000). INTRODUCTION TO AI ROBOTICS. The 

MIT Press, Cambridge, Massachusetts, London, England. 

[Adams, 1995] Dogulas Adams (1995). HITCHHIKERS GUIDE TO THE GALAXY – A 

TRILOGY IN FIVE PRARTS. Heiminger, London. 

[Scicluna et al., 2001] Christophe Scicluna alias Mulder (presenter in English and 

French)), Gerhard Plavec (Austrian volunteer), Gilles Beaufils alias Le Gillou (trophy 

builder), Grégory Bastian alias Greg (working at the ANSTJ responsible for Eurobot), 

Jean-Philippe Fieldes alias JP (special correspondant in England), 

Magali Reyter alias Gali (chief translator !), Patrick Quéméré alias Pat (our doctor :-) 

Soudabeh Serre alias Soudi (member of the Fribotte team in 1999), Véronique Raoul 

(Deputy Head - ANSTJ). 

http://www.anstj.org/robot/concours/eurobot/rules/rules_en.html. 

[Jensen et al., 2001] Lars Christian Jensen, Lasse Løvstakken, Øyvind Borgan, Trond 

Haukom og Alf Egil Edvardsen (2001) FLOKE, NTNU’S BIDRAG TIL EUROBOT 2001. 

NTNU, Institutt for Teknisk Kybernetikk, Trondheim. 

[Tveide et al., 2000] Tallak Tveide, Henrik Schumann-Olsen, Yngve Ytterdal, Vemund 

Raggestad, John Reidar Mathisen, Vegard Evjen Hovstein, Trond Auestad. (2000) TEAM 

EUROBOT 2000. http://www.itk.ntnu.no/misc/eurobot0/ 



29


Index 



30

Kapittel 1. Innledning - Institutt for teknisk kybernetikk - NTNU

Create successful ePaper yourself

Delete template?

Save as template?