Maandag 27 juni 2005:

Vandaag hebben wij ons project opgedeeld in een aantal subtaken en we hebben ons in de eerste subtaak verdiept.

Dit zijn enkele subtaken die wij onderscheiden hebben:

• Eigenschappen en verschillen van het materiaal bestuderen, bv. afmetingen.
  
• Representeren van de Jenga-wereld en basisoperaties definiëren.
  
• Basisoperaties oppakken, neerzetten, sorteren daadwerkelijk uitvoeren.
  
• Definiëren/herkennen van onstabiele states.
  
• Een heuristiek voor Jenga.
  
• Gebruik van gereedschap voor moeilijke operaties.
  
• Een spelletje Jenga spelen.

Dinsdag 28 juni 2005:

Representeren van de Jenga-wereld en basisoperaties definiëren:
Vandaag zijn we bezig geweest met het schrijven van een programma in Java. We hebben voor Java gekozen omdat we dan konden afkijken bij de programma's die we voor de vorige opdrachten moesten maken. En we kunnen nu bepaalde code hergebruiken. In dit Java programma hebben we een representatie van de Jenga wereld en een aantal basisoperaties geïmplementeerd. We hebben er voor gekozen om de toren in de beginstand in 18 verdiepingen en 3 blokken per verdieping te verdelen. De 3 blokken hebben we per verdieping in een object verdieping gestopt. Dit object hebben we speciaal gemaakt voor deze opdracht en heeft drie boolean-velden. Die boolean-velden kan je apart opvragen. Deze 18 verdiepingen hebben we op hun beurt weer een een Vector opgeslagen. We hebben hier voor een Vector gekozen om dat de lengte moet kunnen varieren. We hebben enkele basisoperaties geïmplementeerd voor het manipuleren van deze datastructuur: het opzetten van de beginsituatie, het verwijderen van een willkeurig blokje en het bovenop de toren plaatsen van een blokje. Verder hebben we nog een probleem ondekt. Hoe kan de robotarm ooit bij een blokje in de achterste rijen komen? Die hoek kan de robotarm nooit maken zonder de toren om te gooien.

Woensdag 29 juni 2005:

Een heuristiek voor Jenga:
Ook hebben we een programma in Java geschreven voor de heuristiek. Dit programma berekend hoeveel plekken er leeg zijn per kolom. Elke verdieping heeft 3 blokjes en ieder blokje kan je opdelen in 3 plekken. Per verdieping heb je dan 9 plekken en die geven we de nummers 1 t/m 9. Een kolom is alle plekken met bijvoorbeeld het nummer 1. Vervolgens kijkt hij in welke kolommen de meeste plekken leeg zijn.
Een blokje kan op 6 verschillende posities in de toren liggen. 3 posities zijn verticaal en 3 horizentaal. Per positie wordt berekend hoeveel plekken er in de 3 kolommen die hij overbrugd, leeg zijn. Het programma kiest dan willekeurig een blokje met de positie die de minste lege plekken heeft.

Basisoperaties oppakken, neerzetten, sorteren daadwerkelijk uitvoeren:
Vandaag hebben we aan het path planning programma gewerkt. Ook dit programma hebben we in Java geïmplementeerd om dezelfde reden als bij de andere programma's. Het implementeren van dit programma is niet zo heel moeilijk, het probleem is om de robotarm de goede hoeken te geven. We zijn begonnen met het voor elkaar krijgen dat de robotarm de makkelijkste zet kan doen. Dat is de zet van het blokje 3 in verdiepping 6 naar boven op de toren. De robotarm kan makkelijk bij de blokje met nummer 3 in de even verdiepingen omdat hij dan de makkelijkste hoeken moet hebben. Alle andere blokjes geven verschillende soorten problemen. Vooral de hoek van de gripper (de "hand" van de robotarm) doet het niet goed. Maar daar gaan we nog veel over nadenken.

Hier een aantal aannames die wij tijdens dit project doen.

Donderdag 30 juni 2005:

Deze dag is niet echt motiverend. Het probleem met de hoeken lukt maar niet. Het andere programma's, die met de representatie, de heuristiek en de basisoperaties wordt wel steeds mooier en beter. De computer weet wanneer welke blokje weg worden gehaald en welke hij daarna het beste kan kiezen. Dat gaat allemaal heel goed. Maar die inverse kinematica. Dat gaat minder goed. Er worden goede coordinaten berekend voor de pols en de hoek van de gripper gaat nu ook goed. Maar doordat de gripper lang is, zitten de "vingers" niet op de goede coordinaten. Kijk maar op deze foto. Hier zet hij het blokje nog niet goed neer.

We hebben net onze programma's uitgeprobeerd op de robotarm. En hij heeft hem maar 300 keer omgegooid. Bijna niks ging goed. Maar we weten nu wel van een aantal dingen wat er fout ging en hoe we dat moeten verbeteren. Sommige dingen kan je in de simulator niet goed zien en die moet je dus even in het echt proberen. Op de volgende foto zie je een andere situatie die niet echt de bedoeling is. Maar de gripper is wel sterk.

Nu we een aantal dingen hebben verbeterd en nog een keer onze programma's hebben uitgeprobeerd op de robotarm, gaat het al een stuk beter. We hebben het alleen wel opgegeven dat de robotarm ooit bij alle blokjes zou kunnen komen. Dat kan hij gewoon echt niet. Er is geen plek op de tafel te vinden zodat de robotarm overal bij kan. Deze aanname hebben we ook toegevoegd aan onze al eerder gedane aannames. We hebben wel een oplossing bedacht. Je zou de toren op een bord, die computer aangestuurd kan draaien, kunnen zetten. Maar dat kan nu niet meer. We hoeven nu dus ook niet meer de toren ook zo centraal mogelijk op de tafel te zetten en hij staat nu dus rechts van de robotarm en behoorlijk naar voren, zodat de robotarm wel heel goed bij twee kanten van de toren kan. Hij kan de blokjes ook goed op iederen positie bovenop de toren leggen. Kijk maar op de volgende foto.

Conclusie:

Onze conclusie is dat de robotarm andere dingen wel en niet kon dan wij van te voren dachten. Wij hadden verwacht dat hij vooral veel moeite zou hebben met het uit de toren halen van een blokje. Maar dat ging juist heel goed. Het probleem was de grootte van de configuratie ruimte van de robotarm. Hij kan gewoon niet overal bij en hij kan niet alle hoeken maken. En dat is best jammer.