Projekt-Steckbrief: Roboter

Projekt-Steckbrief: Roboter-Labyrinth
Variante optical echo mit der Kinect
In diesem Projekt soll ein „hybrides“ Strategiespiel entwickelt werden. Hybrid bedeutet dabei, dass
das Spiel aus Software- und Hardwarekomponenten besteht. Die Hardwarekomponenten sind in
diesem Fall kleine RaspberryPi-basierte Roboter, die mit Java programmiert werden können. Diese
Roboter sollen mit virtuellen Robotern in einem Labyrinth einen Wettkampf austragen. Durch die
Projektion eines Bilds auf ein echtes Spielfeld wird für die Zuschauer das Zusammenspiel von echten
und virtuellen Robotern deutlich (s. Abbildung).
Ein Beamer projiziert virtuelle Roboter und zusätzliche Spielinformationen auf den Grundriss eines
Labyrinths, auf dem auch echte Roboter fahren können
Die Spielidee ist recht simpel: Das Labyrinth besteht aus Feldern auf denen Rohstoffe wachsen. Diese
können von Robotern geerntet werden, die daraufhin Punkte erhalten. Die Rohstoffe auf
abgeernteten Feldern wachsen mit der Zeit nach. Die Roboter (echt und virtuell) müssen autonom
einer möglichst cleveren Strategie folgen, um möglichst viele Punkte zu erhalten. Zusammenstöße
zischen Robotern dürfen nicht vorkommen oder sollten mit Punktabzug sanktioniert werden. Falls
eine Abstimmung unter den Gruppen, die diese Aufgabe erhalten, funktioniert, kann am Ende des
Softwareprojekts ein Wettkampf stattfinden, bei dem der schlauste Roboter ermittelt wird.
Das Softwareprodukt hat vier Teile:
Spiel-Server und Dateiformate
Auf dem Spiel-Server wird der Zustand eines Spiels verwaltet. Dazu gehören das Labyrinth, die
Positionen von Robotern, deren Punktstände und die Position und Sättigung von Rohstofffeldern. Ein
Spiel wird auf Basis einer Level-Datei geladen. In einer Level-Datei muss der Grundriss des Labyrinths
beschrieben werden können, sowie Startpunkte von Robotern. Ein Server muss in der Lage sein
beliebige Level zu laden, solange diese bestimmten festzulegenden Randbedingungen genügen. Nach
SWP-1516_Projekt-Roboter-Labyrinth.docx
1
dem Start des Spiels durch einen Anwender sendet der Server ein Startsignal an die Roboter. Diese
setzen sich dann in Bewegung und informieren den Server über Positionsänderungen, wenn sie von
einem auf ein anderes Spielfeld fahren. Roboter dürfen natürlich nur auf gültigen Wegen im
Labyrinth fahren. Fahren die Roboter über ein Spielfeld mit einem Rohstoffvorrat, so wird dieser auf
null gesetzt und ein entsprechender Punktgewinn wird dem Roboter gutgeschrieben. Über die Zeit
wachsen die Rohstoffe bis zu einer gewissen Obergrenze pro Feld nach. Der Anwender soll das Spiel
zu jeder Zeit stoppen können. Dann sollen die erreichten Punkte der Roboter angezeigt werden. In
der Level-Datei oder einer gesonderten Parameter-Datei soll spezifiziert werden können, wie stark
die Rohstoffe mit der Zeit nachwachsen. Auch sollte es möglich sein, eine Höchstgeschwindigkeit für
Roboter festzulegen, sodass für ein faires Spiel eingestellt werden kann, dass virtuelle Roboter nicht
beliebig viel schneller als echte Roboter fahren können
Die grobe Architektur der Anwendung
Pi2Go-Roboter
Pi2Go-Roboter sind einfache Roboter auf Basis eines RaspberryPi, der mit Java programmiert werden
kann. Ein Pi2Go-Roboter sollte Linien in einem Labyrith folgen können oder auf andere Art
sicherstellen, dass er nur vorgegebenen Wegen folgt. Ein Roboter sollte feststellen können, dass er
sich von einem Spielfeld auf das nächste bewegt hat und dieses dem Server mitteilen. Ein Roboter
sollte eine clevere Strategie implementieren um möglichst schnell viele Rohstoffe zu ernten und
Zusammenstöße zu vermeiden. Jeder Roboter erhält vom Server auch die Positionsänderungen der
anderen Roboter und kann sich so ein eigenes Bild vom Spielzustand machen.
Virtueller Roboter
Virtuelle Roboter sollen die gleiche Funktionalität wie die Pi2Go-Roboter haben, nur sollten sie reine
Software-Agenten sein. Sie müssen sich zudem an die Höchstgeschwindigkeit (s.o.) halten.
Visualisierung und Spielfeld
Der Zustand des Spiels muss visuell darstellt werden können. Die Ausgabe sollte zum einen auf einem
Beamer erfolgen, der das Spielfeld auf ein echtes Spielfeld projiziert. Das echte Spielfeld könnte z.B.
aus Linien bestehen, dem die Pi2Go-Roboter folgen. Der dynamische Anteil des Spiels, z.B. Position
der Roboter und Sättigung der Rohstofffelder, sollte aber geeignet visualisiert werden. Das echte
Spielfeld und das projizierte Bild sollten sich dabei möglichst gut überlagern. Zusätzlich zum Spielfeld
selbst sollten auch die Punktstände der einzelnen Roboter angezeigt werden können. Des Weiteren
SWP-1516_Projekt-Roboter-Labyrinth.docx
2
sollte eine alternative oder zusätzliche Ausgabe der Visualisierung auf einem normalen Bildschirm
möglich sein, sodass das Spiel auch ohne Beamer und echtes Spielfeld präsentiert und getestet
werden kann.
Profil des Projekts
- Kunde: Joel Greenyer
- Es sollen möglichst wiederverwendbare Komponenten mit klarer, gut dokumentierter API
entstehen.
- Die Implementierung der Komponenten erfolgt mit Java.
- Jede Gruppe bekommt einen Pi2Go-Roboter zum Testen.
- Wir stellen nur einen Beamer für alle Gruppen zur Verfügung. Beim Testen der Projektion
sollten sich die Gruppen also abstimmen. Auch sollten sich die Gruppen abstimmen über die
Abmessungen eines Labyrith-Levels und ggf. sogar über den Entwurf eines Levels.
- Ein Labyrinth-Level für die Pi2Go-Roboter sollte transportfähig sein (z.B. auf einem großen
Papierbogen, ggf. kann ein Linienmuster geplottet werden)
- Server und Roboter (virtuell und echt) sollten über MQTT kommunizieren.
- Im Programmcode sind nur englische Bezeichner und Kommentare erlaubt.
- Qualitätskriterien:
o Es soll ein möglichst ansprechender Eindruck entstehen
o Ein Spiel sollte möglichst lange ohne Unterbrechung und menschliches Einwirken auf
die Roboter funktionieren
o Spielfeld, Visualisierung, Level und Spielparameter sollten so aufeinander
abgestimmt werden dass ein möglichst faires Spiel zwischen Pi2Go-Robotern und
virtuellen Robotern möglich ist.
SWP-1516_Projekt-Roboter-Labyrinth.docx
3

Download Report