Die Aufgabe gliedert sich in vier Teile (separate Abgaben, siehe Kalender). Parallel zum Entwurf Feature-getrieben losimplementieren! Jede Woche wird im/nach dem Meeting bewertet, dazu gibt es Bewertungspunkte (-/O/+/++). Checkt eure Abgaben ein und zeigt sie auf dem Mittwochstreffen (z.B. auf dem Steuerungs-Notebook).

Entwurf (A2.1)

• Strategie-Entwurf: wie sieht euer Ansatz aus? Beschreibt dies textuell (1BP)
• Diagramm(e) – Klassendiagramm ist nicht das günstigste, es bieten sich zusätzlich Komponenten- oder Zustandsdiagramme an. Das Klassendiagramm soll verwendete Klassen aus der Bibliothek ebenfalls referenzieren. (1BP)
• Falls Nebenläufigkeit erforderlich (Warum?): Sequenzdiagramm (1BP)
• Erklärungen zu den Diagrammen (1BP)

Abgabe in einem gängigen Format, textuell und/oder mit Diagrammen, z.B. als PDF, im CVS!

Implementierung (A2.2-2.4, 3 Wochen)

Realisiert jede Woche mindestens vier Features, hier Vorschläge:

Feature-Liste

• Kiste umfahren um zu schieben
• Ampel Grün anfordern
• Fahren bis zur Ampellinie und auf Grün warten
• Fahren durch die Mitte wenn Grün (Reicht die Zeit?)
• Kiste durch die Mitte schieben
• Spielfeld beachten
• Außenrum fahren OHNE Kiste (um zurück zu fahren)
• Außenrum Kiste schieben
• Gegner beobachten, Kollision vermeiden
• Gegner Strategie vorhersagen
• Entscheiden, welcher Weg (außen rum oder über die Kreuzung) günstiger ist
• Statt goto() mit drehen/vorwärts in geschickten Kurven fahren (schneller)

Zu jeden kapselbaren Feature ein Test schreiben! Pro realisierbares Feature wird je 1 BP vergeben, für den dazugehörigen Test auch 1BP. Jede Woche werden maximal vier Features bewertet (man kann vorarbeiten…)

Programmierhinweise:

• Wem die Simulation aufgrund der Geschwindigkeitsbeschränkungen zu langsam sind -> SimulationThread.setSpeedupFactor() setzen.
• Es muss zu Beginn ein FIPS.waitForData() aufgerufen werden – dies dient im ‘Real’-Spiel zur Synchronisierung der Steuerrechner, damit beide gleichzeitig beginnen!
• SimulationNavAdapter.setPosition() ist natürlich nur einmal an Anfang erlaubt.

Bewertungshinweise:

• Prüft die Werte die an rotate/turn/travel()-Kommandos an die Bibliothek übergeben werden: 0 und Double/Float NaN/Infinity führen zu unvorhersehbarem Verhalten des realen Roboters.
• CPU-auslastende while(…) {}-Schleifen und vermeidbare Thread.sleep()-Aufrufe sind böse – verwendet gescheite asynchrone Mechanismen oder Threadsynchronisierung.
• CVS vs. SVN: Wenn euer Projekt im GForge-Projekt bleibt, verwende ich das cvsstats um die 1500 Zeilen abzuchecken. Das ist gutmütiger als ein cvs|svn annotate, da es auch überschriebene/gelöschte Zeilen weiterzählt.

Spiel ‘Kisten Schieben’ / BoxMoveGame

Ziel des Spiels ist es, Kisten mit einem ferngesteuerten Lego Mindstorms Roboter-Fahrzeug vom Startfeld ins Zielfeld zu schieben. Wer zuerst alle Kisten vom Start zum Ziel geschoben hat, hat gewonnen. Die Kisten sind CD-Boxen, mit einem Fiducial beklebt. Das Fahrzeug ist ebenfalls mit einem Fiducial beklebt. So kann es sich selbst, die Kisten und andere Fahrzeuge über FIPS (FujabaIndoorPositioningSystem) Positionsdaten erkennen. Jedes Fahrzeug hat ein Start- und ein Zielfeld. Das Start- und Zielfeld sind mit einer Geraden verbunden, die über eine Ampelkreuzung führt. Weiterhin existiert ein längerer ampelloser Umgehungsweg. Es spielen zwei Fahrzeuge gegeneinander, die jeweiligen Geradenverbindungen zwischen Start- und Zielfeld sind orthogonal zueinander angeordnet. Der Umgehungsweg besteht aus einem Kreis, den alle Fahrzeuge gemeinsam benutzen. Dort darf nur im Uhrzeigersinn gefahren werden, der Kreisverkehr hat Vorfahrt. Das Spielfeld wird momentan durch folgende grafischen Zeichenkommandos beschrieben:

 int xoff = 59;
 int yoff = 13;
 g2.translate(xoff, yoff);
 g2.setColor(Color.BLACK);
 g2.fillOval(0, 0, 300, 300);
 g2.setColor(Color.WHITE);
 g2.fillOval(40, 40, 220, 220);
 g2.setColor(Color.BLACK);
 g2.fillRect(130, 40, 40, 220);
 g2.fillRect(40, 130, 220, 40);
 g2.setColor(Color.RED);
 g2.drawRect(120, 120, 60, 60);
 g2.setColor(Color.BLUE);
 g2.drawRect(40, 130, 40, 40);
 g2.drawString("Sv", 80, 150);
 g2.drawString("Sh", 150, 80);
 g2.drawRect(130, 40, 40, 40);
 g2.setColor(Color.GREEN);
 g2.drawRect(220, 130, 40, 40);
 g2.drawRect(130, 220, 40, 40);

(Einheit in cm)

Hier das Spielfeld als Screenshot aus dem Simulator:

Die Ampel der Kreuzung in der Mitte arbeitet folgendermaßen: Es gibt die Zustände ‘horizontal Grün/vertikal Rot (PH)’, ‘horizontal Rot/vertikal Grün (PV)’, ‘beide Richtungen Rot (AR)’. AR ist der Startzustand, d.h. nach Systemstart ist mindestens 7,5s für alle Rot. Zwischen zwei Grünphasen (PH oder PV) folgt immer eine AR-Phase. Die Ampel wird nur auf Aufforderung grün: dazu ist ein requestHorizontal() bzw. requestVertical()-Aufruf abzusetzen. Die erste Anforderung wird zuerst bedient. Fordern beide Seiten, auch mehrmals, Grün an, wird immer abwechselnd geschaltet (mit AR dazwischen). Die Folge PH->AR->PH tritt also nur auf, wenn horizontal Grün angefordert wird und für Vertikal keine Anforderungen eingehen. Alle, also auch mehrfache Anforderungen für eine Grün-Richtung werden beim Wechsel von AR zu dieser Grünphase gelöscht. Die eingegangenen Anforderungen werden zu Beginn nach Ablauf der Minimalzeit in (changed 17.5.10) der AR-Phase ausgewertet (d.h. man hat die ganze Grün-Phase und die AR-Phase Zeit, wieder Grün anzufordern…). Die Komplett-Rot-Zeit (Zustand AR) beträgt mindestens 7,5s (mehr wenn keine Anforderung anliegt). Ist die Ampel im AR-Zustand und es liegen keine Anforderungen an, wird nach Ablauf der minimalen Komplett-Rot-Zeit sofort auf Grün geschaltet, sobald eine Anforderung eintrifft. Die Grün-Zeit (Durchfahrzeit, von PH/PV) beträgt ebenfalls 7,5s.

Regeln zum Ablauf

• Anzahl der Kisten pro Fahrzeug = 4, d.h. das Spiel ist zuende wenn ein Fahrzeug 4 Kisten ins Zielfeld geschoben hat.
• Roboter starten an der Position (80,150) bzw. (150,80) (etwa da wo Sh/Sv im Bild steht) mit Ausrichtung nach ‘aussen’.
• Es befindet sich immer nur eine Kiste im Startfeld. Sobald eine Kiste aus dem Startfeld geschoben wurde, wird die nächste hineingelegt.
• Kisten die ins Zielfeld geschoben werden, werden sofort herausgenommen.
• Kisten dürfen auf dem Spielfeld liegen gelassen werden. Sie werden nach 60s ohne Bewegung wieder herausgenommen bzw ins Startfeld gelegt. (added 17.5.10)
• Es müssen die ‘eigenen’ Kisten in das Zielfeld geschoben werden.

Fahrregeln

• Man darf bei Rot die Ampelzone (Quadrat von 60cm Kantenlänge) in der Mitte nicht befahren, und muss auch innerhalb der Grün-Dauer wieder heraus fahren. Entscheidend ist hier die FIPS-Position, nicht die Außenmaße. Eine Kiste darf bei Rot ebenfalls nicht in die Ampelzone geschoben werden.
• Man darf kein anderes Fahrzeug rammen. Bei einem Fahrzeug, dass mit der Gabel eine Kiste schiebt, gilt die Kiste als Teil des Fahrzeugs.
• Man darf die Strecke (Schwarz) nicht verlassen. Entscheidend ist hier die FIPS-Position, nicht die Außenmaße.
• Man darf die gerade Fahrstrecke des Gegners nicht befahren (Ausnahme: Kreuzungszone).
• Im äußeren Kreis darf nur im Uhrzeigersinn gefahren werden
• Wer im äußeren Kreis fährt, hat Vorfahrt vor einem einfahrenden Fahrzeug (removed 17.5.10)
• Wird eine Kiste (versehentlich) so geschoben, dass das Fahrzeug sie nicht wieder aufnehmen kann, ohne die Strecke zu verlassen, wird die Kiste herausgenommen bzw. ins Startfeld gelegt.
• Bewegt sich ein Fahrzeug an beliebiger Stelle für 30s nicht, wird es auf sein Startfeld(!) gesetzt (added 17.5.10)

Bei Regelverletzung wird das Fahrzeug auf das eigene Zielfeld(!) gesetzt (Ausnahme bei Kollision: ein Fahrzeug, dass zum Kollisionszeitpunkt stand, nicht, nur der Kollisionsverursacher). Falls es eine Kiste geschoben hat, wird diese herausgenommen bzw. ins Startfeld gelegt.

Sonstige Beschränkungen:

• maxMoveSpeed = 22,25 (cm/s), entspricht 50rpm
• maxTurnspeed 170°/s

Diese Aufgabe dient zur Vorbereitung des Um-die-Wette-Kisten-schieben-Spiels auf dem Kreuz-Spielfeld mit Ampel. Es wird in dieser Aufgabe ohne konkretes Spielfeld, d.h. ohne Straßen, Ampeln etc. gespielt, die ganze Fläche ist für einen Roboter freigegeben.

Die Aufgabe 1 ist unterteilt in folgende Teilaufgaben:

1. Schreiben Sie einen JUnit-Test für folgendes Szenario (Simulation ohne GUI): Eine Kiste wird an die Position (50, 150) gesetzt. Der Roboter startet in der Spielfeldmitte. Die Kiste ist nun parallel zur X-Achse 300 Einheiten weit zu schieben. Die Endpositionen werden vom JUnit-Test geprüft. Überlegen Sie, welche Schnittstelle ihre Robotersteuerung haben wird (evtl. leere Klassen anlegen, Test muss nicht erfolgreich sein).
2. Beschreiben Sie (handschriftlich) einen Algorithmus zum Finden der richtigen Position und Ausrichtung des Roboters zum Kisten schieben.
3. Implementieren Sie die Robotersteuerung zum Kisten-Schieben. Beachten Sie, dass der Roboter die Kiste jederzeit verlieren kann – es muss dann neu angesteuert/aufgesetzt werden.
4. Implementieren Sie eine Demo (Simulation mit GUI)! Die Kiste soll mit der Maus bewegt werden können!
5. Zusatzteil: Implementieren Sie eine Selbst-Kalibration des Roboters: Radgröße und Abstand sollen automatisch erkannt werden.

Abgabe Teilaufgabe 1 bis Mittwoch 5.5. 12:00 Uhr, Rest bis Mittwoch 12.5. 12:00 Uhr, Abgabe im mindss10-CVS-Repository unter frei wählbarem Modulnamen (z.B. BoxMoveGame_<Initialien>)

Erforderlich zum Bestehen sind mindestens 1500 Zeilen Produktiv- und 500 Zeilen Test-Code.

Dies ist eine Gruppenarbeit, es werden allerdings individuelle Noten ermittelt. Im Code wird dafür die CVS Annotation verwendet, andere Artefakte bitte manuell markieren!

Die Note wird durch Einzelbewertungen in den folgenden Kategorien gebildet:

• 15% Entwurfsdokumente
• 40% Implementierung
• 20% Tests
• 10% aktive Mitarbeit beim ‘Ausprobieren’
• 15% Endabgabe

Hallo,

Bitte tragt hier bis Di abend ein, wann ihr Donnerstags könnt und wann nicht. Falls keine Einigung möglich ist, können wir auch auf Mittwochs Treffen ausweichen.

Grüße, Ruben

1. Auschecken von: :pserver:anonymous@cvs.gforge.cs.uni-kassel.de:/cvsroot/legonxtlib, und zwar die Module FujabaNxtLib und pccomms-0.85
2. Einlesen: Klasse CatMiceScenarioDemo starten, SimulationViewer2D starten…
3. Eigenes Projekt anlegen, Name: “Einarbeitung_<Initialenkürzel…>”, und die Klasse FollowLineRobot reinkopieren (evtl. umbenennen, anderes Paket etc…) und eine Robotersteuerung implementieren, siehe unten. Die Programmieraufgabe kann zu zweit gelöst werden, einfach beide Kürzel dann verwenden. Allerdings muss es jeder erklären können 🙂
4. Auf https://gforge.cs.uni-kassel.de/projects/mindss10/ registrieren (request to join) und das Einarbeitungs-Projekt bis nächsten Donnerstag 12:00 Uhr einchecken!
5. Auf die Fragen weiter unten mündlich vorbereiten, besprechen wir nächsten Donnerstag

Beschreibung Robotersteuerung:

Der Roboter soll der schwarzen Linie folgen. Dazu benutzt er seine beiden Lichtsensoren, die den Boden scannen. Jeder Sensor liefert einen Wert nahe 0 bei schwarzem Untergrund und bis zu 100 bei weißem Untergrund. Im Initialzustand steht der Roboter auf der Linie, beide Sensoren sehen schwarzen Untergrund. Der Roboter soll fortwährend dem Linenverlauf folgen und die Linie nur möglichst kurzzeitig verlassen.

Fragen

1. Beschreiben Sie, was ihr Roboter tut wenn er auf die weiße Fläche gesetzt wird.
2. Wie lässt sich die Linie finden? Beschreiben Sie einen möglichen Algorithmus. Was passiert beim erreichen der Linie?
3. Lässt sich Linenverfolgung auch mit einem Sensor durchführen? Wie?
4. Wie lassen sich die Sensoren im Simulator weiter nach vorne verschieben (Codestelle suchen!)?

Die Vorbesprechung findet am 22.4. 14:00 im Raum 1340 (Seminarraum SE) statt.