De forsvundne børn – Havneområdet

Lavet af Malte Borges(mabor12), Didde Marie Hellestrup(dihel12), Samah A. Ajjawi(saajj12), Rasmus Gorm Petersen(rasmp09) & Rasmus Petersen (rpete10)

Introduktion

Dette projekt er baseret på et scenarie, der omhandler forsvundne robot-børn, som skal findes af nogle såkaldte “søger”-robotter. Til dette skulle der laves en bane med felter, der repræsenterede områder som havn, by og skov (se figur 1).

Projektet blev inddelt i fire grupper med hver deres fokusområde. Vores gruppes fokusområde i forbindelse med projektet var, at fokusere på havneområdet.

Figur 1 - Banen, eller miljøet, som robotterne skal bevæge sig i.
Figur 1 – Banen, eller miljøet, som robotterne skal bevæge sig i.

Idéen:

Denne projektgruppes fokus var at bygge en “søger”-robot ud af LEGO Mindstorms NXT, der skulle kunne køre tilfældigt rundt på banen. Vores robot fik havneområdet som sit ansvarsområde (det blå felt). Opgaven for robotten var at finde robot-børnene, der ligeledes er på banen, både i det blå og hvide område, både i det blå og hvide område. Når en af børnene blev fundet skulle vores robot kunne finde hjem til startområdet (markeret med lilla) igen.

Problemformulering

Prioriteten i dette projekt er at vi skal kunne finde løsninger på følgende problemer:

  • Få vores robot til at kunne navigere rundt på banen, den skal kunne kende forskel på kanter og de forskellige områder på banen, samt kunne vide, hvornår den er på det blå eller hvide område.
  • Flytte forhindringer i havneområdet.
  • Robotten skal kunne finde et barn og “fange” barnet, dermed forstået at robotten skal kunne kommunikere til de andre søge-robotter når et barn er fundet.
  • Efter at søge-robotterne sammen har fundet alle børne-robotterne og dermed har fuldført deres opgave, skal den kunne finde tilbage til startområdet igen.

Mål / løsning:

Ud fra ovenstående ønskede vi at bygge en robot, der skulle være i stand til at navigere på banen, lokalisere havneområdet (markeret med blåt), flytte på forhindringer (i form af tomatpuré-dåser pakket ind i karton og placeret på en lego platform) og fange robot-børnene. Dette skulle løses gennem brug af passende sensorer. Vi ville bruge en farvesensor, der pegede mod jorden, som skulle stå for at aflæse, hvilket område robotten befandt sig i – dette var dog ikke muligt, da de farvesensorer vi havde fået stillet til rådighed var defekt. Hvis robotten bevæger sig ind på et område den ikke hører til, ville den navigere væk derfra igen. Hvis robotten mødte en forhindring inde på havneområdet, skulle den være i stand til at flytte den af vejen. Når vores robot kommer i nærheden af et robot-barn, ville den ved hjælp af en infrarød sensor kunne se robot-barnet (der udsender infrarødt lys konstant), og melde til de andre robotter at et barn er blevet fundet.

Materialer

I dette afsnit vil materialerne, der er blevet brugt for at kunne opbygge robotten, blive beskrevet mere detaljeret.

LEGO Mindstorm NXT

Til dette projekt er der blevet gjort brug af LEGO Mindstorm NXT, hvilket er et såkaldt robot programmeringssæt udviklet af LEGO. Sættet indeholder en række sensorer og aktuatorer, der i efterfølgende underpunkter vil blive beskrevet. Programmeringen af NXT-bricken (se figur 2) er foregået i det C-inspireret programmeringssprog NXC – et programmeringssprog designet til programmering af LEGO Mindstorm robotter (http://bricxcc.sourceforge.net/nbc/nxcdoc/nxcapi/intro.html).

NXT Brick

NXT-bricken kan siges at være “robottens hjerne”. NXT-bricken består af en 32-bit microprocessor. Den har fire input porte (sensor porte) og tre output porte (servo motor porte). Ydermere tillader NXT-bricken trådløs kommunikation via bluetooth (http://shop.lego.com/en-CA/NXT-Intelligent-Brick-9841).

Figur 2 - Lego Mindstorm NXT brick
Figur 2 – Lego Mindstorm NXT brick

IR-seeker

I og med den vigtigste opgave for vores robot har været at finde “de forsvundne børn”, har det været nødvendigt at finde en måde, hvorpå robotten kan se børnene. Til at gøre dette har vi placeret en infrarød sensor (se figur 3) på toppen af robotten. Børnene der søges efter er blevet udstyret med infrarøde lysdioder på toppen – det er deres lys, som vores robot leder efter. Den infrarøde sensor leder i en synsvinkel på 240 grader (https://www.hitechnic.com/cgi-bin/commerce.cgi?preadd=action&key=NSK1042), på den måde vil det være muligt at se, hvor børnene er i forhold til sin egen position (Se figur 4).

Figur 3 - IR seeker
Figur 3 – IR seeker
Figur 4 - IR seeker retnings værdier
Figur 4 – IR seeker retnings værdier

Touch-sensor

For at kunne flytte objekterne i miljøet har det været nødvendigt at have en sensor, der kan registrere kontakt med disse. Til at gøre dette har vi gjort brug af en touch-sensor (se figur 5). Ved kontakt med et objekt sendes et signal fra touch-sensoren til NXT-bricken (http://shop.lego.com/en-CA/Touch-Sensor-9843).

Figur 5 - Touchsensor
Figur 5 – Touchsensor

Servomotorer

Denne robot gør brug af to servomotorer (se figur 6), tilkoblet til hvert sit hjul. Servomotorerne fungerer som aktuatorer, der modtager besked om, hvor hurtigt, hvilken retning og hvor længe de skal køre (http://shop.lego.com/en-US/Interactive-Servo-Motor-9842). Det er disse aktuatorer, der får robotten til at bevæge sig.

Figur 6 - Servo motor
Figur 6 – Servomotor

Ultrasonic sensor

Til at registrere andre robotter i miljøet foran robotten, har vi gjort brug af en ultralydssensor (se figur 7). Sensoren registrerer afstanden til det foranstående objekt, ved at sende ultralyd ud og modtage den reflekterede lyd igen (http://shop.lego.com/en-US/Ultrasonic-Sensor-9846).

Figur 7 - Ultrasonic sensor
Figur 7 – Ultrasonic sensor

Lyssensor

Til at genkende hvor på banen robotten befinder sig, har vi gjort brug af én lyssensor, placeret på undersiden af robotten (se figur 8). Lyssensoren registrerer den reflekterede lysintensitet af underlaget, på den måde skelnes mellem forskellige farver (http://shop.lego.com/en-CA/Light-Sensor-9844).

Figur 8 - Lys sensor
Figur 8 – Lyssensor

Metoder

Nedenstående er en sekventiel gennemgang af projektforløbet til dette projekt. Først vil de tanker vi havde under brainstormingsfasen blive beskrevet. Efterfølgende vil de tanker vi havde til vores robots konceptuelle design blive forklaret. Herefter vil måden, hvorpå vi har evalueret robottens funktionalitet gennem tests blive beskrevet. Til sidst vil indholdet af multiagent systemer kort bliver ridset op.

Brainstorm

Først blev det besluttet imellem grupperne, at projektet skulle have en bane med et fællesområde. På dette område skulle alle robotter kunne bevæge sig. Så var der områder, hvor kun bestemte robotter måtte bevæge sig i. Vores gruppe fik havneområdet, som vi skulle fokusere på. I løbet af brainstormingsfasen diskuterede vi, hvordan miljøet i havneområdet skulle se ud og hvilke elementer/objekter, der skulle være i området. De diskuterede elementer har blandt andet været de forhindringer havneområdet skulle indeholde. Ligeledes er det blevet diskuteret, hvordan vores endelige robot skulle se ud, hvilke sensorer den skulle have og hvordan den skulle bygges. Derudover omhandlede en stor del af brainstormingen om, hvilke opgaver robotten skulle løse.

Konceptuelt design

Vi havde en række krav til vores robots konceptuelle design: Den skulle bygges så den kunne bevæge sig forholdsvis nemt rundt på banen, af den grund skulle den ikke være for stor eller have for svært ved at dreje. Der skulle dog være plads til alle de ønskede sensorer. Den skulle være enkel at bygge. Den skulle have mulighed for at flytte på objekterne i havneområdet.

Evaluering gennem tests

Fra projektets start og til skrivende stund, har testene haft det formål først og fremmest at teste de individuelle sensorers funktionalitet baseret på den software, som vi har produceret til den respektive sensor. Derfor har vi for hver ny sensors implementering, testet og evalueret dens funktionalitet med efterfølgende forfining af softwaren, så sensoren på den måde har kunnet udfylde den funktion den måtte have.

Løbende har vi testet, hvordan implementeringen af en ny sensor har påvirket de andre sensorer samt robottens overordnede opførelse.

Vi har haft ansvaret for at udvikle én robot, der har skulle afsøge “havneområdet” for forsvundne børn. Det har ikke været muligt, grundet projektets omfang, at teste vores robots opførelse i det globale multi agent system. En samlet test af hele systemet er skemalagt til den 12/5-16 og vil bringe indsigt i, hvilke opgaver vores robot løser tilfredsstillende.

Multi agent systemers indhold

Begrebet Multi agent systemer dækker over et system bestående af flere agenter, der tilsammen skaber kollektiv intelligens. I sådanne systemer er de individuelle komponenter komplette agenter, modsat ikke autonome moduler (Pfeiffer et al., 2006 s. 214).

En agent beskrives som værende en fysisk eller virtuel enhed, der bl.a. kan reagere i et miljø, kan kommunikere med andre agenter, er drevet af et sæt individuelle mål, besidder sine egne ressourcer samt har en opførelse, der er drevet mod at opnå sine mål (Nielsen, 2008).

Til at beskrive aspekterne i et multi agent system præsenterer Yves Demazeau (Demazeau, 2002), hvad han kalder den deklarative formel. Den deklarative formel har til formål at beskrive, de konceptuelle aspekter af et multi agent system.

MAS = Agent + Environment + Interaction +Organization

Formlen illustrerer at et multi agent system består af fire aspekter:

  • Agenterne i systemet.
  • Et miljø agenterne skal operere i.
  • Et sæt mulige interaktioner agenterne imellem, herunder hvordan agenterne kommunikerer med hinanden og interagere med miljøet.
  • Mindst en organisation af disse agenter.

Resultater

Robottens opbygning

I løbet af brainstormingsfasen blev det, som nævnt, besluttet at vores gruppe skulle arbejde med havneområdet. I forlængelse heraf fandt vi frem til nogle gode ideer til, hvordan miljøet på havnen skulle se ud. Vi blev enige om at på havnen skulle der placeres nogle “containere”. Disse containere blev repræsenteret af små dåser. Dåserne blev vi enige om at pakke ind i rødt pap, da vi på den måde selv kunne bestemme, hvor høje de var. Disse containere skulle være de forhindringer, som vores robot skulle “kæmpe sig igennem” for at få fat i børnene.

Robottens fysiske opbygning er inspireret af en lego-bygge-instruktion, som blev fundet hos Hitechnic.com (se figur 10) (https://www.hitechnic.com/upload/TrikeBase_Instructions.pdf).

På figuren ses robottens indledende udseende baseret på byggeinstruktionen. Til dette projekt har der været behov for at tilføje flere sensorer, og der harder har været behov for at udbygge robotten en anelse. For eksempel stiller projektet krav til implementering af IR-seeker, dette er placeret højt over selve robotten, for således at minimere støj, sikre at signalet ikke bliver brudt af miljøets andre elementer og ikke mindst at være på højde med børnenes IR-lys.

Endvidere har robotten, på dens front, fået tilføjet en slags fangarme til at flytte objekter med. Ligeledes er der monteret en lyssensor og en tryksensor på robottens forside (se figur 9 og figur 11).

Figur 9 - Robottens elementer
Figur 9 – Robottens elementer
Figur 10 - Robottens opbygning
Figur 10 – Robottens opbygning
Figur 11 - Robottens sensorer og aktuatorer
Figur 11 – Robottens sensorer og aktuatorer

Robottens opgaver

I henhold til det overordnede system har vores robot ansvaret for,, at afdække havneområdet og løbende søge efter børne-robotterne – både i havneområdet og på det hvide fælles-område. Derfor er vores robots første opgave at finde hen til havneområdet. For at gøre dette kører den tilfældigt rundt og hvis robotten kører ind på et område, hvor den ikke må befinde sig, drejer den og kører væk fra det felt igen.

Når robotten er på havneområdet, vil den støde på forhindringer i form af, de containere der er placeret rundt omkring i området. Når robotten støder frontalt ind i en container, skubbes containeren frem, robotten bakker og kører derefter uden om forhindringen.

For at robotten skal kunne finde de forsvundne børn, er idéen at børnene skal udsende IR lys og vores robots IR seeker skal kunne opfange dette lys. Når lyset fra et barn opfanges, skal dette kommunikeres til både søge-robotter og børne-robotter. Denne opførsel er på nuværende tidspunkt ikke implementeret i vores robot.

Elementerne i multi agent systemet

Kigger man på det overordnede multi agent system, i forhold til den deklarative formel (MAS = Agent + Environment + Interaction + Organization), kan systemets elementer placeres i henhold til de konceptuelle aspekter, som disse elementer dækker. For eksempel består systemet af to typer af agenter: Børne-robotterne og Søger-robotterne. Miljøet består af den overordnede bane med dertilhørende fællesområde, individuelle områder og objekterne/forhindringerne, der er i de forskellige områder. Interaktionen imellem søger-robotterne og børne-robotterne foregår gennem det IR-signal, som børne-robotterne sender ud og som bliver opfanget af søger-robotterne. Interaktionen der sker imellem søger-robotterne foregår via den kommunikation, som foregår over bluetooth, når et barn er fundet. Organisationen af agenterne i systemet er således at alle søger-robotter har til opgave at holde styr på hvor mange børn der er fundet. Når et barn er fundet sendes der et signal via bluetooth til alle søger-robotter, disse søger-robotter har hver især en counter der tæller ned hver gang et barn er fundet – man kan sige at alle søger-robotter har en lige høj hierarkisk placering.

Kode

Softwaren der er blevet produceret til denne robot vil herunder blive beskrevet. Koden som den ser ud i skrivende stund består af én hoved-task og seks parallelle tasks. Softwaren kan hentes her.

Initialisering og definering af variabler og værdier

Først i koden defineres nogle globale værdier og variabler, som dermed kan benyttes i de forskellige tasks der køres. Blandt andet er NEAR værdien, der fortæller robotten, hvor lang afstanden som ultralydssensoren skal opfatte andre agenter på og mutex moveMutex bruges til at erhverve motorstyringen i de forskellige tasks, så kun én task kan bestemme over motorerne af gangen.

//Ultrasonic Sensor
#define NEAR 15 //cm

//IRSEEKER
#define IRSEEKER IN_1
// Convenience macro that combines TextOut and NumOut
#define TextNumOut(xPos,yPos,str,col,num)  TextOut(xPos,yPos,str); \
                                           NumOut(xPos+6*col,yPos,num);
int dir, s1, s2, s3, s4, s5, result;


//Lightsensor
int lS;
int lSreading;

//Ultrasonicsensor
int distance;

//colors
string color;

mutex moveMutex; //Contains the motor movement

Hoved task

task main()

Denne funktion definerer de forskellige sensor porte og starter de seks parallelle tasks, som udgør robottens opførsel.

task main()
{
	//Begin all the tasks
	Precedes(print_values, initialize_colors, move_forward, move_obstacle, wrong_color, avoid_obstacle);

	//Lightsensor
	SetSensorLight(IN_3); 
	
	//Ultrasonic Sensor
	SetSensorLowspeed(IN_4); 

	//Pressuresensor
	SetSensorTouch(IN_2);

	//IRSEEKER
	SetSensorLowspeed(IRSEEKER);
}

Parallelle tasks

task print_values()

Værdierne fra lys-sensor, Ultra sonic sensor og IR-seeker printes på NXT-Brick-displayets respektive linjer.

task print_values()
{
	while(true)
	{
		//Lightsensor
		lS = Sensor(IN_3);
		NumOut(0, LCD_LINE1, lS);

		//Ultrasonicsensor
		distance = SensorUS(IN_4);
		NumOut(50, LCD_LINE1, distance);

		//IRSEEKER
		ReadSensorHTIRSeeker(IRSEEKER, dir, s1, s2, s3, s4, s5);

	    TextNumOut(0, LCD_LINE3, "Dir:    ",4,dir);
	    TextNumOut(6, LCD_LINE4, "S1:     ",3,s1);
	    TextNumOut(6, LCD_LINE5, "S2:     ",3,s2);
	    TextNumOut(6, LCD_LINE6, "S3:     ",3,s3);
	    TextNumOut(6, LCD_LINE7, "S4:     ",3,s4);
	    TextNumOut(6, LCD_LINE8, "S5:     ",3,s5);

	}
}

task initialize_colors()

I denne task, defineres de forskellige farver i forhold til lyssensor værdierne, dette er gjort i en separat task for at lette opgaven med at fintune og ændre værdier løbende. Værdierne der i sidste ende blev benyttet er:

Lyssensor-værdi: 23-26, color = “BLACK”

Lyssensor.værdi: 49-52, color = “WHITE”

Lyssensor-værdi: 30-36, color = “BLUE”

Lyssensor-værdi: 37-41, color = “GREENGRAYPURPLE”

task initialize_colors()
{
	while(true)
	{
		//Define black
		if (lS > 23 && lS < 26)
		{
			color = "black";
			TextOut(0, LCD_LINE8, "BLACK             ");
		}
		//Define white
		else if (lS > 49 && lS < 52)
		{
			color = "white";
			TextOut(0, LCD_LINE8, "WHITE             ");
		}
		//Define blue
		else if (lS > 30 && lS < 36)
		{
			color = "blue";
			TextOut(0, LCD_LINE8, "BLUE             ");
		}
		//Define green, gray and purple (The purple color should, according to the task, not be a wrong color. This is the result of not having a functioning color sensor, and therefore we had to use a light sensor)
		else if (lS > 37 && lS < 41)
		{
			color = "greengraypurple";
			TextOut(0, LCD_LINE8, "GREENGRAYPURPLE");
		}
	}
}

task move_forward()

Denne funktion har til formål at styre robottens bevægelse fremad. Når denne funktion er aktiv kører begge motorer fremad med en motorkraft på 50, denne task vil overtage motorstyringen, når ingen andre tasks gør det.

task move_forward()
{
	while(true)
	{
		Acquire(moveMutex);
		//Move Forward
		OnFwd(OUT_BC,50);
		Release(moveMutex);
	}
}

task move_obstacle()

Hvis touch-sensoren bliver aktiveret (hvis der er kontakt med et objekt), kører begge motorer frem med en motorkraft på 25 i 900 ms, bakker så med en motorkraft på 25 i 1000 ms, for derefter at køre frem med den ene motor i 700 ms med en motorkraft på 50 og dermed dreje.

Med andre ord:  Skub objektet frem → bak væk fra det →  kør uden om.

task move_obstacle()
{
	while(true)
	{
		if (SENSOR_2 == 1) {
			Acquire(moveMutex);
			//Move the obstacle forward, back away and go around
			OnFwd(OUT_BC, 25);
			Wait(900);
			OnRev(OUT_BC, 25);
			Wait(1000);
      		OnFwd(OUT_B, 50);
      		Wait(700);
      		Release(moveMutex);
		}
	}
}

task wrong_color()

Hvis den læste farve fra lyssensoren er sort, grøn, lilla eller grå slukkes begge motorer, derefter bakkes der på den ene motor med kraften 50 i 600 ms. Altså drejer robotten væk fra det område som den ikke må bevæge sig ind på.

Grunden til at grøn, grå og lilla er blevet en og samme farve for robotten er at vi var nødt til at benytte en lyssensor i stedet for en farvesensor og dermed endte vores robot desværre med at opfange de samme værdier på farverne grøn, grå og lilla. I forhold grøn og grå gør det ikke den store forskel, da begge farver er forbudte områder. Men dette er medvirkende til at for at få robotten til at køre ud fra samt at finde tilbage til start området, skulle der findes en anden løsning.

task wrong_color()
{
	while(true)
	{
		if ((color == "black") || (color == "greengraypurple"))
		{
			Acquire(moveMutex);
			//Turn around
			Off(OUT_BC);
			OnRev(OUT_C,50); 
			Wait(600);
			Release(moveMutex);
		}
	}
}

task avoid_obstacle()

Når robotten bevæger sig rundt på banen og ultrasonic sensoren registrerer et objekt, (en anden robot eller forhindringer højere end containerne) bakker begge motorer i 300 ms med en motorkraft på 50.

task avoid_obstacle()
{
	while(true)
	{
		while(SensorUS(IN_4)>NEAR);
		Acquire(moveMutex);
		//Back away
		OnRev(OUT_BC,50);
		Wait(300);
		Release(moveMutex);
	}
}

Diskussion

Målet med dette projekt var, at bidrage til et større multi agent system med en autonom agent, der kunne bevæge sig tilfældigt rundt på banen, finde dens tildelte område, flytte på forhindringer i dette område, lokalisere andre agenter i miljøet via IR-lys, samt kommunikere med de andre agenter.

Vi har til at løse dette, bygget en robot, der bevæger sig øjensynligt tilfældigt rundt på banen, omend den ikke er helt tilfældig i sin kørsel. Når robotten startes op kører den lige ud, indtil den møder en anden farve underlag end det hvide. For at få robottens bevægelser til at virke mere tilfældigt, kunne vi have implementeret “random numbers”-værdier til robottens bevægelse. Det skal dog nævnes, at i følge tests er dette ikke er en nødvendighed for, at robotten løser sine opgaver. Med hensyn til at finde det tildelte havneområde løser robotten sin opgave tilfredsstillende. Robotten kan genkende farven (eller rettere lysintensiteten som farven reflekterer) på underlaget, og dermed ved den om, den er på det rigtige felt eller ej. Der er dog situationer, hvor lys-sensoren kommer til kort. Det har gennem testene vist sig, at robotten nogle gange har svært ved at genkende, især den blå farve, som værende en farve robotten må bevæge sig ind på. Dette forekommer, når robotten bevæger sig fra det hvide område til det blå område. Når lyssensoren befinder sig ca. halvvejs mellem det blå (lyssensor-værdi: 30-36) og det hvide (lyssensor-værdi: 49-52) registrerer lyssensoren en værdi, der er mellem 37 og 41, der passer med det interval, der definerer farverne grå, grøn og lilla. For at løse dette, skulle en farvesensor, der kunne registrerer farver i stedet for lysintensitet bruges. Når robotten bevæger sig over et felt i en “forbudt” farve, evner den at vende om og køre væk fra det område igen.
Når det så lykkedes robotten at finde ind på havneområdet, vil den på et tidspunkt støde ind i forhindringerne, der er placeret i dette område. Disse forhindringer (containere) har vi, som tidligere nævnt, modificeret på en måde, så de har en højde, der passer med touch-sensorens placering og samtidig kan ses af børnenes ultrasonic sensor, men ikke kan ses af vores robots ultrasonic sensor. Der er dog lidt problemer i forhold til at registrere kontakten med forhindringerne, hvis de ikke kolliderer præcist med touch-sensoren. Vi har monteret et LEGO-hjul på fronten af touch-sensoren, for at give 

den et større område at registrerer kontakt på, men der kan stadig være situationer, hvor den ikke bliver trykket helt ind. En måde at løse denne udfordring på, kunne være at lave nogle tungere forhindringer. Disse forhindringer skulle have en vægt, så de er tunge nok til at kunne registreres af sensoren, men ikke så tunge at robotten ikke kan flytte dem. Endvidere skal det nævnes, at robotten ikke kan skelne mellem kontakt med en container eller kontakt med et andet objekt i miljøet. Hvis robotten kommer i en situation, hvor den kommer i kontakt med et andet objekt, der har nogenlunde samme højde, dette skulle dog ikke være et problem i forhold til miljøets design.

Der kan være mange miljømæssige forstyrrelser, der kan spille ind på IR-målingerne. Vi ved for eksempel ikke, hvordan IR-seekeren (og robotten) vil reagere, hvis der er et barn på hver side af den. Samtidig mangler vi også, at teste om robotten kan finde ud af det, hvis der er en anden agent mellem det forsvundne barn og den selv. Endvidere vil der med stor sandsynlighed dukke en række andre uforudsete problemer op. Alt dette med IR seekeren kan dog være svært at afprøve, da vi på nuværende tidspunkt ikke har programmeret en opførsel til robotten, hvor målinger med IR seekeren har nogen effekt på noget. Afslutningsvist er det heller ikke blevet testet, hvordan kommunikationen med de andre agenter fungerer i praksis, og igen er dette heller ikke noget der på nuværende tidspunkt er en del af robottens software.

Konklusion

Vi mener, at vores projekt langt hen ad vejen løser de problemstillinger, der er blevet sat som mål for dette projekt, omend der er en række af ubesvaret spørgsmål. Robottens fysiske opbygning viser evne til at udføre de henstillede krav der indgår i projektet. Sensorerne har vist sig at være velplacerede i forhold til løsning af opgaven. Det skal dog nævnes at der er  der er visse elementer af projektet, som af diverse grunde ikke lever op til de krav vi selv havde til løsningen. Eksempelvis ville en farvesensor i stedet for lyssensoren klart have været at foretrække. Samtidig mangler vi at finde en perfekt container, der er tung nok til at blive registreret, hver gang den kommer i kontakt med touch-sensoren, men ikke er for tung til at blive flyttet af robotten. Endvidere finder vi det beklageligt, at det ikke har været muligt at teste multiagent systemet som helhed, inden udførelsen af dette blogindlæg. Havde det været muligt at lave den overordnede test forud for forfatningen af blogindlægget, ville vi kunne analysere gennem tests, hvorledes robotten lever op til de overordnede krav vi havde til dens opførelse. Vi ser derfor frem til at udføre disse tests til sidste undervisningsgang i Programmering af robotter og andre fysiske enheder.

Perspektivering

Når den overordnede test af multi agent systemet er udført, vil vi i gruppen diskutere, hvilke elementer på robotten, der kan forbedres og hvordan løsningen på forbedringerne kunne udføres. Den samlede test med robot samarbejde vil skabe uforudsete problematikker, de forskellige grupper har bygget forskellige systemer som ikke er testet sammen, og med multiagent systemer vil det være en udfordring i sig selv.

Med udgangspunkt i at systemet virker, vil børnene blive fundet.

Bibliography

Demazeau, Y. (2002) ‘From interactions to collective bahavior in agent-based systems’

Nielsen, J. (2008) ‘User Configurable Modular Robotics – Design and Use’

Pfeifer, R., Bongard, J.C., Grand, S., Brooks, R. and Iwasawa, S. (2006)How the body shapes the way we think: A new view of intelligence

Hjemmesider

http://bricxcc.sourceforge.net/nbc/nxcdoc/nxcapi/intro.html

http://shop.lego.com/en-CA/Light-Sensor-9844

http://shop.lego.com/en-CA/NXT-Intelligent-Brick-9841

http://shop.lego.com/en-CA/Touch-Sensor-9843

http://shop.lego.com/en-US/Interactive-Servo-Motor-9842

http://shop.lego.com/en-US/Ultrasonic-Sensor-9846

https://www.hitechnic.com/cgi-bin/commerce.cgi?preadd=action&key=NSK1042

 

Leave a Reply