Eenvoudige implementatie van handelsreizigersprobleem

[Clock]

Goedenavond,

Voor een studieopdracht moet ik een robotje programmeren wat zo efficient mogelijk kan orderpicken in een magazijn. Dit magazijn heeft een bekende layout, en kent een aantal obstakels (stellingen ed). Er zijn een tiental punten waar de robot langs moet rijden om orders te verzamelen, en logischerwijs willen we de route die de robot rijdt zo efficient mogelijk maken. Overigens eindigt de robot op dezelfde plek als die begint.

We moeten dus een eenvoudig algoritme maken wat de kortste route berekent. Dit probleem is ook wel bekend als het traveling salesman en het handelsreizigersprobleem. Hier zijn een aantal complexe oplossingen voor gevonden, maar én de programmeercapaciteiten om die te implementeren ontbreken, én de hardware van de robot gaat dit niet trekken.

Ik ben dus op zoek naar een eenvoudige implementatie voor dit probleem. Ik hoop dat iemand mij hier een zet in de goede richting kan geven.

Alvast bedankt!

[Rigi]

Toevallig al langs wikipedia (engels) geweest? Flinke lijst referenties en notes om je op weg te helpen naast een lap tekst over oplossingen en heuristieken.

Maar ja, een NP-hard probleem gaat toch wel wat rekenkracht / tijd duren om op te lossen, daar is het tenslotte NP-hard voor.

[ Voor 24% gewijzigd door Rigi op 19-09-2007 22:16 ]

[ThunderNet]

Heeft de robot een constante connectie met een "server" ? Want dan zou je eventueel de berekeningen op een krachtige machine kunnen maken. En een route meegeven aan de robot.

[Confusion]

Tien punten kan je op 10! manieren bezoeken en dat zijn er zo weinig dat je ze gemakkelijk allemaal even uit kunt rekenen en vergelijken. Kortom, ik zou het gewoon brute force doen.

[ThunderNet]

Confusion schreef op woensdag 19 september 2007 @ 22:22:
Tien punten kan je op 10! manieren bezoeken en dat zijn er zo weinig dat je ze gemakkelijk allemaal even uit kunt rekenen en vergelijken. Kortom, ik zou het gewoon brute force doen.

Ik denk dat er meer mogelijkheden zijn.
Per gang heb je natuurlijk meerdere producten.
Stel alle producten liggen aan het einde van de gangen (allemaal aan zelfde kant). Dan is het meeste efficiente om steeds een stukje de gang in te gaan, en dan weer terug, en dan naar de volgende gang. En niet door alle 10 gangen volledig door te lopen, maar dus slechts een gedeelte.

Maar dit hangt van meerdere factoren af natuurlijk

[Clock]

Confusion schreef op woensdag 19 september 2007 @ 22:22:
Tien punten kan je op 10! manieren bezoeken en dat zijn er zo weinig dat je ze gemakkelijk allemaal even uit kunt rekenen en vergelijken. Kortom, ik zou het gewoon brute force doen.

Mjah, ik had het even uitgerekent. Het zijn er rond de 3,2 miljoen. Maar om dat uit te rekenen op een 50 MHz procje duurt een behoorlijke tijd. Dan kan ik de robot net zo goed het hele magazijn laten rondcrossen. Brute force is dus geen optie, helaas

Ik denk dat er meer mogelijkheden zijn.
Per gang heb je natuurlijk meerdere producten.
Stel alle producten liggen aan het einde van de gangen (allemaal aan zelfde kant). Dan is het meeste efficiente om steeds een stukje de gang in te gaan, en dan weer terug, en dan naar de volgende gang. En niet door alle 10 gangen volledig door te lopen, maar dus slechts een gedeelte.

Maar dit hangt van meerdere factoren af natuurlijk

Dit zal idd wat invloed hebben op het aantal mogelijkheden, maar het blijven gewoon te veel om te berekenen. Dan staat de robot eerst 10 min te rekenen voordat ie aan zijn tocht begint.

ThunderNet schreef op woensdag 19 september 2007 @ 22:19:
Heeft de robot een constante connectie met een "server" ? Want dan zou je eventueel de berekeningen op een krachtige machine kunnen maken. En een route meegeven aan de robot.

Nope, hij moet het helemaal in zijn eentje klaren. Hij krijgt een tiental punten in een array;'tje gegoten, en dan moet hij zichzelf redden.

[ Voor 51% gewijzigd door Clock op 19-09-2007 22:43 ]

[DrClaw]

50 khz is nog steeds 50 miljoen hertz. 50 miljoen kloktikken per seconde. 3.6 miljoen mogelijkheden ? nou ja, je kan je algoritme zo profilen dat het aantal klokcycles geminimaliseerd wordt, en sowieso gaat het geen 10 minuten duren. dan ben je .5 seconden per mogelijk pad aan het rekenen en da's denk ik onzin.

en verder: er staan bestaande obstakels in het veld, toch ? ik zou zeggen, bouw een 10x10 matrix op, met daarin de afstand van punt A naar punt B (en dat hoeven dus geen rechte lijnen te zijn maar kunnen ook polygoondingen zijn bv).
en begin dan gewoon in je startpunt, en bepaal greedy een pad langs alle punten. is eigenlijk best eitje. beetje A*.

[Clock]

DrClaw schreef op woensdag 19 september 2007 @ 22:54:
50 khz is nog steeds 50 miljoen hertz. 50 miljoen kloktikken per seconde. 3.6 miljoen mogelijkheden ? nou ja, je kan je algoritme zo profilen dat het aantal klokcycles geminimaliseerd wordt, en sowieso gaat het geen 10 minuten duren. dan ben je .5 seconden per mogelijk pad aan het rekenen en da's denk ik onzin.

en verder: er staan bestaande obstakels in het veld, toch ? ik zou zeggen, bouw een 10x10 matrix op, met daarin de afstand van punt A naar punt B (en dat hoeven dus geen rechte lijnen te zijn maar kunnen ook polygoondingen zijn bv).
en begin dan gewoon in je startpunt, en bepaal greedy een pad langs alle punten. is eigenlijk best eitje. beetje A*.

Maar ik bereken in 1 kloktik geen route over een matrix van 8*24 (zo hebben we het magazijn ingedeeld). Daar zullen aanzienlijk meer stappen voor nodig zijn.

De obstakels zijn bekend ja. Ga je er dan vanuit dat je vanuit punt A de kortste afstand naar een volgend punt(zeg B ) neemt? En vanuit punt B de kortste afstand tot het volgende punt (zeg C)? Maar hoe kom je dan weer effecient terug op je begintpunt?

[DrClaw]

je hoeft toch niet elke keer de afstand van A tot B uit te rekenen ? dat doe je 1x, in een matrix van 10x10 .. het kan zelfs in een halve matrix, als mem efficiency belangrijk is.

en dan is het bepalen van de volgende afstand gewoon een lookup geworden, die je als je het slim doet gewoon 10x een pointertje door een array schuiven is.

[Clock]

DrClaw schreef op woensdag 19 september 2007 @ 23:33:
je hoeft toch niet elke keer de afstand van A tot B uit te rekenen ? dat doe je 1x, in een matrix van 10x10 .. het kan zelfs in een halve matrix, als mem efficiency belangrijk is.

en dan is het bepalen van de volgende afstand gewoon een lookup geworden, die je als je het slim doet gewoon 10x een pointertje door een array schuiven is.

Maar dat moet de robot zelf doen, dus dan kan het net zo goed terwijl die aan het rijden is. Het is niet mogelijk (toegestaan), om dat zelf op een pc oid uit te rekenen en dan in te voeren als route. De robot krijgt een array met 10 x en y waarden (van het raster van 8*24), en moet dan zelf een goede route vinden/maken.

Ik wil dus weten welke stappen ik moet nemen (programmeren), om tot een redelijk efficiente/korte route te komen.
Is dat steeds de kortste afstand tot het volgende punt bepalen? Of een cirkel rondom het magazijn waarna je voor elk pakketje 'naar binnen' rijdt? De oplossingen van wikipedia's ed zijn vaak dermate gecompliceerd en wiskundig dat ze in ons geval niet haalbaar zijn.

[Marcj]

Als je al hebt berekend wat de kortste route is van elk punt naar elk ander punt (wat niet zo moeilijk zou moeten zijn) kun je het als volgt aanpakken:

Je begint met het berekenen van een sub-optimale oplossing, simpelweg door vanaf het laatste punt de dichtstbijzijnde volgende (nog niet bereikte) punt te bepalen. Als je dit hebt gedaan kun je de route gaan optimaliseren, voor daarvoor het volgende net zolang uit totdat er geen betere te vinden is:

- Bepaal een punt P die je wilt gaan optimaliseren (we gaan ze allemaal bijlangs, maar probeer eerst degene met de langte routes eraan vast)
- Zoek of naar dit punt op de huidige route geen betere route te vinden is:
Stel dat P nu gekoppeld is aan punten S en T met routes van lengte 6 en 8. De afstand tussen S en T is 5. Nu zoeken we dus twee andere punten waarmee het omrijden via P niet meer dan (6 + 8 - 5 =) 9 extra kost, bijvoorbeeld S' en T' liggen op een afstand 3 van elkaar, maar S' naar P is 5 en P naar T' is 6. Nu is de nieuwe route (6 + 8 + 3) - (5 + 5 + 6) = 1 korter geworden.

Probeer deze stap zo vaak mogelijk uit te voeren (voor 10 punten zal dat niet al te veel zijn) en je zou een redelijk optimale route moeten krijgen met niet zoveel rekenwerk

Misschien wat pseudocode:

code:

Route getRoute(Point[] ps, Point start) {
  route = {start}
  last = start
  while not empty(ps) {
    Point shortest = nil
    dist shortestDist = MAX_VALUE
    for each P in ps {
      if dist(last, P) < shortestDist {
        shortest = P
        shortestDist = dist(last, P)
      }
    }
    last = shortest
    route.add(last)
  }
  // Nu hebben we een route

  loop: while true {
    sortedPoints = sortByDistFromNeighbours(route)
    for each P in sortedPoints {
      S = route.getPrev(P)
      T = route.getNext(P)
      diff = dist(S, P) + dist(P, T) - dist(S, P)
      for each S' in route {
        T' = route.getNext(S')
        if dist(S', P) + dist(T', P) - dist(S', T') < diff {
          route.remove(P)
          route.insertAfter(S', P)
          goto loop
        }
      }
    }
  }
  return route
}

[joepP]

Een heel simpel stappenplan, wat ook op een relatief trage processor tot goede oplossingen moet leiden in korte tijd:

1) Maak een lijst van alle punten die je moet bezoeken.
2) Bereken de afstand van alle punten tot elkaar, en stop dat in de afstandsmatrix.
3) Voer het Lin-Kernighan algoritme uit.

Het algoritme in stap 3 is zeer snel, geeft zeer goede resultaten, en is eenvoudig te implementeren. Ik denk dat je met wat zoeken op google zelf wel wat implementaties moet kunnen vinden.

[MicroWhale]

Ervan uitgaand dat je robot op elk willekeurig moment het beste pad bewandelt, betekent dit dat je eigenlijk het nieuwe pad moet invoegen in het beste pad om een nieuw beste pad te krijgen.

[Confusion]

Clock schreef op woensdag 19 september 2007 @ 22:29:
Mjah, ik had het even uitgerekent. Het zijn er rond de 3,2 miljoen. Maar om dat uit te rekenen op een 50 MHz procje duurt een behoorlijke tijd. Dan kan ik de robot net zo goed het hele magazijn laten rondcrossen. Brute force is dus geen optie, helaas

Hoeveel tijd mag het kosten? 3.2 miljoen keer 10 afstanden uit een matrix halen, optellen en vergelijken met de laatst gevonden waarde kost nou ook weer niet de wereld aan tijd, zelfs niet op een 50 MHz processor.

Je kan ook het dichtstbijzijnde punt als beginpunt kiezen en de overige mogelijkheden (nog maar 320000) laten uitrekenen terwijl de robot daar naartoe rijdt.

Clock schreef op woensdag 19 september 2007 @ 23:44:
Is dat steeds de kortste afstand tot het volgende punt bepalen?

Lijkt mij een prima algoritme om aan de opdracht te voldoen.

[ Voor 25% gewijzigd door Confusion op 20-09-2007 10:49 ]

[Clock]

joepP schreef op donderdag 20 september 2007 @ 10:19:
Een heel simpel stappenplan, wat ook op een relatief trage processor tot goede oplossingen moet leiden in korte tijd:

1) Maak een lijst van alle punten die je moet bezoeken.
2) Bereken de afstand van alle punten tot elkaar, en stop dat in de afstandsmatrix.
3) Voer het Lin-Kernighan algoritme uit.

Het algoritme in stap 3 is zeer snel, geeft zeer goede resultaten, en is eenvoudig te implementeren. Ik denk dat je met wat zoeken op google zelf wel wat implementaties moet kunnen vinden.

Aah, nuttig! Alleen ik kan vrij weinig implementaties vinden. En deze zijn dan vaak ook zo rond de 4000 regels code, wat teveel van het goede is voor ons. En als ik de beschrijving van het algoritme zo zie lijkt het alsof het wel een beetje overkill is. Dit is meer geschreven om de meest optimale route voor 200+ punten te vinden lijkt het.

[Clock]

Confusion schreef op donderdag 20 september 2007 @ 10:46:
[...]

Hoeveel tijd mag het kosten? 3.2 miljoen keer 10 afstanden uit een matrix halen, optellen en vergelijken met de laatst gevonden waarde kost nou ook weer niet de wereld aan tijd, zelfs niet op een 50 MHz processor.

Je kan ook het dichtstbijzijnde punt als beginpunt kiezen en de overige mogelijkheden (nog maar 320000) laten uitrekenen terwijl de robot daar naartoe rijdt.


[...]

Lijkt mij een prima algoritme om aan de opdracht te voldoen.

Ik heb een klein foutje gemaakt. Deze specs zijn van de nieuwe hardware. De hardware die wij gebruiken is een stuk trager. Het gaat dan om een 8bits 16mhz processor en 32kb aan geheugen.

Hierop is het naar mijn inziens behoorlijk onmogelijk om 3,2 miljoen mogelijkheden te checken en een uitgebreide afstandsmatrix te genereren.

En uiteindelijk is hetgene wat telt de tijd die de robot nodig heeft om zijn taken te voltooien. Dus hoe minder tijd hij kwijt is hoe beter.

[ Voor 7% gewijzigd door Clock op 20-09-2007 19:04 ]

[Refro]

Je zou ook een compleet andere aanpak kunnen kiezen en de punten gewoon semi random (niet de meeste optimale oplossing zoeken) af kunnen rijden. Dit kan afhankelijk van de situatie sneller gaan omdat je alle rekentijd van te voren bespaart en gewoon begint te rijden. Onderweg kun je dan bepalen wat het beste volgende punt is om heen te gaan.

Dit is qua rijtijd niet optimaal maar omdat je direct kunt beginnen met rijden kan het positief uitpakken (bijkomend voordeel is dat je snel iets hebt om te laten zien).

Wij hebben ooit een robot moeten bouwen die zijn weg uit een doolhof zocht en simpel de linkermuur blijven volgen werkte op de 8mHz hardware maar marginaal slechter als allerlei ingewikkelde oplos technieken die veel processortijd kosten.

[Confusion]

Clock schreef op donderdag 20 september 2007 @ 19:03:
Hierop is het naar mijn inziens behoorlijk onmogelijk om 3,2 miljoen mogelijkheden te checken en een uitgebreide afstandsmatrix te genereren.

Een 10x10 matrix met afstanden lijkt me niet uitgebreid? Sowieso is dat de basis van alle algoritmes: je moet eerst uitrekenen wat naburige punten zijn en die in je geheugen houden.

De berekening is een eenvoudige optelling en de oplossing is een volgorde van 10 coordinaten, waarvan je er telkens slechts 1 hoeft te onthouden: de kortste. Geheugengebruik is het probleem niet bij brute force. Maargoed, het is natuurlijk geen interessante oplossing en eentje die volstrekt niet schaalt . Interessanter is bijvoorbeeld het algoritme van Marcj implementeren, waarbij punten die je hebt gehad natuurlijk afvallen.

[BestTested!]

Ik zal ook eens een gooi doen naar een eenvoudig algoritme (Geinspireerd door MarcJ)

Genereerd een distance-matrix. Deze 10x10 matrix bevat de afstanden tussen de op te halen pakketjes. Deze afstanden kan je 'snel' berekenen met een eenvoudig A* (manhattan distance als heuristic?).

Genereer een waarschijnlijk suboptimale oplossing door steeds tussen de pakketjes de dichtsbijzijnde volgende lokatie te kiezen. Je krijgt nu een sequence a-b-c-d-e-...-j. De totale afstand van deze route is natuurlijk de som van de onderlinge afstanden.

Deze eerste oplossing heeft het probleem dat hij in een lokaal optimum zit. Alle eenvoudige permutaties (2 lokaties omwisselen) resulteren in een slechter pad. Maar wanneer we meer van deze eenvoudige permutaties achter mekaar uitvoeren kunnen we uit dit lokaal optimum ontsnappen.

Doen we bijvoorbeeld max 10 permutaties achter mekaar, dan zal het pad eerst in lengte toenemen, maar daarna misschien wel weer afnemen (misschien ook niet). Hebben we na 10 keer nog geen beter pad gevonden. Dan beginnen we opnieuw met het eerste optimale pad. Vinden we wel een beter pad, dan onthouden we deze en voeren we hier voortaan de permutaties op uit.

Dit algorithme heeft als nadeel dat er zeer vaak hetzelfde pad berekend zal worden. Je kan alle ruimte dat je nog over hebt gebruiken om een hashlist te vullen. Je hoeft immers alleen maar de 10x10 afstanden te onthouden (eigenlijk maar ((NxN - N) / 2)) en het beste pad. Deze lijst bevat dan als key het pad en als value de lengte. Door lookups te doen in deze hashlist kan je het algorithme sneller maken.

Dit algoritme eindigt niet, maar je kan ophouden na een bepaalde tijd of wanneer je tevreden bent met je oplossing.

Dus in het kort:

1. Genereer distance-matrix
2. Bereken begin-pad. (waarschijnlijk suboptimaal)
3. Voer 1 permutaties uit op het tot-nu-toe beste pad
4. Haal lengte van dit pad uit de hashlist, of bereken lengte (en sla lengte op in hashlist)
5. Is het pad beter? Sla dit pad op als het tot-nu-toe-beste pad. Ga naar 3 (reset counter?)
6. n permutaties gehad? Ga naar stap 3
7. Voer 1 permutatie uit op het gepermuteerde pad.
8. Ga naar stap 4

Eventueel kan je nog een of andere heuristic gebruiken om te bepalen waar je je permutatie uitvoert. Dus in plaats van een uniforme random verdeling gebruik je een verdeling die afhankelijk is van je heuristic.

[Niemand_Anders]

Volgens mij is de efficientste route de snelste. Als de rest van de robots eerst 5 minuten stil staat om hun route te berekenen, kun je misschien beter gewoon de punten 1 voor 1 afgaan? Of is hier efficienste definineerd als kortste?

Tijdens mij elektro studie heb ik ook eens een opdracht gekregen om via een PLC een magazijn robot (meer op afstand bedienbare heftruck) te bedienen. Ook daar ging het erom wie het efficienst 5 blokjes kon verplaatsen. Omdat ik die week mijn aandacht bij andere zaken had, was mijn voorbereiding niet zo goed. Ook ik kreeg 5 start en eind punten (x,y,z - gang 2, stelling 4, plank 2) en moesten dus 5 blokjes verplaatsen. Het enigste wat ik had gedaan was sorteren op gangpad (van zowel de start als eind bestemming). Dus je verplaatst een item van gangpad 1 naar gangpad 2, dan moet het volgende start item zich ook in gangpad 2 bevinden. Ik ben toen 30 minuten bezig geweest met het schrijven van het (Hitatchi) PLC programma. Andere studenten hadden allerlei vage (complexe) procedures geschreven waardoor uiteindelijk op het moment dat hun heftruck ging rijden, mijn heftruck al klaar was. Een student (Maarten) heeft het zelfs voor elkaar gekregen om zijn heftruck na het starten van het PLC programma 45 minuten stil te laten staan. Hij had uiteindelijk wel de korste weg gevonden. Mijn runtime was 274 seconden. Maarten zijn runtime was 231 seconden. Maar mijn totale tijd was 321 seconden, Maarten zat net over de 3000 seconden. De leraar had ons beide uitgeroepen tot 'winnaar' omdat in de opdracht efficient (tijd/afstand) niet gedefineerd was. In de praktijk zal efficients echter altijd in tijd gemeten worden (immers hoe sneller je in totaal iets doet, hoe meer je kan doen).

Mijn advies: Als efficient niet gedefineerd is, ga dan gewoon direct naar de opgegeven punten, want dan verlies je geen tijd. Is efficient echter omschreven als de kortste afstand, dan ontkomt je niet aan complexe berekeningen.

p.s. Ik weet verder vrij weinig van robots. De volgende opdracht was het programmeren van een freesmachine en die week daarop van een verkeers kruising.

[MicroWhale]

MrWilliams schreef op donderdag 20 september 2007 @ 10:31:
Ervan uitgaand dat je robot op elk willekeurig moment het beste pad bewandelt, betekent dit dat je eigenlijk het nieuwe pad moet invoegen in het beste pad om een nieuw beste pad te krijgen.

er reageert niemand op dus ik licht het even toe:

Is er een pad?
- Nee, reken het pad uit naar de bestemming en zet dit als beste pad.
- Ja,
voor het eerste punt op het beste pad:
- reken het beste pad uit vanaf daar.
- trek vanaf eerste punt al het "dubbel pad" van de route af
- stel dit in als voorlopig nieuw beste pad

voor alle vervolgpunten na de nieuwe splitsing:
a reken het beste pad vanaf daar (als het pad minder efficient word, ga dan naar d)
b trek al het "dubbel pad" van de route af
c is het pad efficiënter stel dit in als voorlopig nieuw beste pad
d ga naar het volgende punt (evt na nieuwe splitsing) en ga naar a

imo niet al teveel rekenwerk als je al een graaf hebt.
In geval van geen pad: 1x pad berekenen
in geval van pad: maximaal aantal keer rekenen = aantal punten op huidig beste pad.

Dit laatste zal vrijwel niet gebeuren, omdat doorgaans veel overlap is in kleinere grafen. Dit betekent dat je vaak een inefficiëntere route bewandelt (en dus skipt) of punten overslaat (dubbel pad).

[ Voor 17% gewijzigd door MicroWhale op 27-09-2007 14:31 ]

[Terror]

Zomaar ideetje. Heel gretig. Bepaal afstand tot orders. (10 getallen). Ga naar dichtsbijzijnde. Bepaal afstand tot overgebleven orders. Ga naar dichtsbijzijnde. Voordeel. Je kan gelijk aan de slag.

[Verwijderd]

De oplossing van Terror vind ik tochwel goed (best first search) in jouw situatie (dit minimaliseert tijd en ruimtecomplexiteit), maar er zijn enkele situaties waarin er echt geen optimaal pad zal gevonden worden. Een mogelijkheid die ik zou voorstellen is een aantal populaties te generen dmv van een genetisch algoritme en daar het beste resultaat uit te halen. Er zijn veel voorbeelden te vinden van genetische algoritmen voor het traveling salesman probleem. Veel succes!

[Clock]

Excuses voor de wel heel late reply, maar ik had het bijzonder bijzonder druk

Het is helemaal gelukt met de robot, en het dingetje heeft de snelste tijd neergezet, en heeft daarmee 17 groepjes achter zich gelaten Ik heb het idee van Terror uitgewerkt, omdat dit in combinatie met de gebruikte hardware en de moeilijkheidsgraad, mij de beste oplossing leek.

Eerst heb ik een aantal routines gemaakt waarmee ik de robot kon besturen (links, rechts, omdraaien, 1 blok naar voren, etc). Daarna heb ik die functies zo uitgebreidt dat de robot ten alle tijden 'wist' op welke coordinaten in het raster het zich bevond. Dit was nog redelijk gemakkelijk te maken.

Vervolgens heb ik een grote routine geschreven die aangeroepen kon worden met een willekeurige X en Y coordinaat. Deze functie zorgde er vervolgens voor dat de robot naar die positie zou rijden, rekening houdend met de magazijnstellingen ed. Het testen en testen en nogmaals testen zodat dit feilloos werkte kostte een hoop tijd.

Toen dat allemaal werkte was het tijd voor het algoritme, welke bijzonder snel geschreven was. Met een loopje liep ik alle 10 de punten door, en berekende in 3 stappen per punt welke het dichtste bij de robot was (natuurlijk rekening houdend met de stellingen). Het dichstbijzijnde punt was zo binnen 3 a 4 seconden gevonden (en deze tijd werd korter naarmate er meer punten als 'gepickt' konden worden gelabeld). Vervolgens was het nog een kwestie van het aanroepen van de goto(x,y) functie.

De 10 punten op een raster van 27*8 (5 bij 2 meter oid) konden door de robot in 2,5 min worden verzameld. Bedankt voor de hulp allemaal!

[Verwijderd]

Dat wordt weer een Technische Bedrijfskunde student aan de RuG die de IT richting gaat doen, of niet? Dit komt me allemaal erg bekend voor

Zullen we het hyves gehalte proberen rond 0 te houden en inhoudelijk en ontopic te reageren?

[ Voor 26% gewijzigd door RobIII op 05-11-2007 12:28 ]