Dieses Semester gibts zwei Szenarien, eine ist von der Android-Gruppe, die andere von der Mindstorms-Gruppe umzusetzen:
Android-Pacman:
Schachbrettmuster:
(Processing Code)
int gap = 50; // 600 / 13; // 800 / 17
int bw = gap * 3;
void setup() {
size(800, 600);
noLoop();
}
void draw() {
background(255);
fill(0);
for (int x = 0; x <= 800 ; x += (gap + bw))
{
for (int y = 0; y <= 600 ; y += (gap + bw))
{
rect(x + gap, y + gap, bw, bw);
}
}
}
Das erste Projekttreffen findet morgen (also Freitag den 28.10.2010) im Labor des Fachgebiets statt.
Folgende Webseiten haben wir gesichtet:
Die zwei Lego-related Papiere:
Überlegt euch bis nächsten Mittwoch 13 Uhr (Treffen!) was euch interessiert – wir planen dann genauer.
Die Projekt Vorstellung findet morgen, also am 27.10., 14 Uhr in Raum 1340 statt.
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).
Abgabe in einem gängigen Format, textuell und/oder mit Diagrammen, z.B. als PDF, im CVS!
Realisiert jede Woche mindestens vier Features, hier Vorschläge:
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…)
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.
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.
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:
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:
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