Hansa-Café
Aus Hansa-Wiki
| Hansa-Café | |
|---|---|
| |
| Daten: | |
| Name: | Hansa-Café |
| Entwickler: | Dimitri Aschenbrenner, Christopher Binder, Tzu-Nen Tzeng |
| Status: | alpha |
| Kategorie: | Kellner-Roboter |
| Sprache: | Deutsch (de) |
Unser Ziel ist es, einen Roboter zu bauen, der in einem Café Gäste bedient. Für die Einfachheit soll der Roboter auf einem langen Tisch mithilfe des Lichtsensors auf einer gekennzeichneten Bahn fahren um den Gast, der zuvor durch einen Mikrofon an seinem Platz den Roboter gerufen hat, zu bedienen. Hinter einer Sichtblockade soll der Koch/Bäcker/Konditor die Bestellung des Gastes auf die Tragefläche des Roboters stellen, damit der Roboter die Bestellung zum Gast bringt.
Insgesamt haben wir es also mit drei Arbeitsschritten zu tun: Die Programmierung des Dialogs mit DialogOS, die Einbindung der Befehle an den Roboter und das Entwerfen und Bauen eines geeigneten Roboters.
Inhaltsverzeichnis |
Dialog
Das Dialog haben wir uns recht einfach vorgestellt: Der Gast kommt und setzt sich, spricht in ein Mikrofon und der Roboter kommt zu ihm und startet einen Gespräch mit dem Gast. Dann bestellt der Gast, und der Roboter holt die Bestellung (die wir heimlich auf sein Tablett stellen).
Doch leider ist es doch nicht so simpel, wie wir uns wünschen, denn schon am Anfang tauchen folgende Fragen auf: Wie bestellt der Gast? Woher weißt er, was im Angebot ist? Soll der Roboter eine Karte bringen oder soll er alles auflisten?
Wir haben uns am Ende entschieden, dass der Roboter fragt, ob man seine Bestellung schon weiß (z.B. bei Stammkunden) oder ob er alles auflisten soll. Für diese Entscheidung mussten wir unser Angebot kürzen, damit der Roboter nicht stundenlang redet.
Dann kommt die zweite Frage: Was passiert, wenn der Gast mehr als eine Bestellung macht (z.B. Kaffee + Kuchen)? In diesem Fall müsste der Roboter sich mehrere Antworten merken können, außerdem müsste das Tablett groß genug sein und gleichzeitig muss der Roboter die schwere Last auch tragen können. Zur Lösung dieses komplizierten Problems merkt sich die Person, die versteckt die Bestellung des Gastes auf den Roboter stellt, die Bestellung. So müssen wir zwar menschliche Unterstützung einsetzen, das Problem wird dadurch aber schnell gelöst.
Auch bei der Frage, wie am Ende gezahlt wird, entschieden wir uns dafür, dass eine Kasse extra dafür eingerichtet wird und die durch einen Mensch geführt wird.
Allgemein haben wir Schwierigkeiten mit verschiedenen Situationen und mit den Antworten des Gastes, denn es kann z.B. sein, dass der Gast einfach so geht, ohne vorher zu bezahlen, oder dass der Gast nach Sachen fragt, die nicht im Sortiment sind. Um so etwas zu programmieren ist zwar möglich, wäre aber sehr aufwendig.
Für die verschiedenen Antwortmöglichkeiten wollten wir auch mit Grammatiken arbeiten, jedoch hat uns das viel Zeit gekostet, da wir lange Zeit nicht feststellen konnten, wo wir unsere Fehler gemacht haben. Zum Glück hat uns Roxy von der Wegeleitsystem-Gruppe am Ende gezeigt, wie sie das Problem gelöst haben.
Für die Stimme der Sprachausgabe haben wir uns aufgrund unserer Zeichnung des Kellners (männlich) für Reiner entschieden, auch wenn Steffi deutlich natürlicher klingt.
Am Ende unserer Arbeit mit DialogOS ist folgendes herausgekommen:
Erst jetzt bemerken wir, wie wichtig es ist, Ordnung in der Struktur zu halten, denn vorher konnte man nämlich nichts erkennen und wir waren oft selber von unserem eigens programmierten Dialog verwirrt. Kaum vorstellbar ist auch noch die Tatsache, dass wir den Inhalt von den Graphen "Bestellung" und "Lieferung" auch im Hauptfenster hatten, das war schrecklich... Deswegen haben wir die Graphen auch mit Sorgfalt eingerichtet:
und
Programmierung mit NXT
Die NXT-Programmierung beschränkt sich nur darauf, dass der Roboter den Weg zwischen der „Küche“ und dem Gast absolviert. Dies erwies sich als gar nicht so einfach wie es scheint.
Am Anfang wollten wir, dass der Roboter mit dem Ultraschallsensor den Gast ortet. Nach der Programmierung stellen wir jedoch fest, dass die Wegfindung nicht verlässlich ist, außerdem „rutscht“ der Roboter dem Gast immer näher, obwohl er vorher vor ihm stehen geblieben ist. Der Ultraschallsensor arbeitet anscheinend nicht 100%ig genau.
Um das Problem zu umgehen wollen wir auf den Lichtsensor umsteigen. Die Idee ist es, dass der Roboter einen schwarzen Streifen folgt und auf dieser Weise zum Gast findet.
Nach einer langen Recherche ist es uns endlich gelungen, den Lichtsensor zu aktivieren. Damit der Roboter einen Weg folgen soll, ist es leichter, zwei Lichtsensoren zu verwenden, um bei der Registrierung des einen Lichtsensors eines weißen Untergrunds den Roboter in die entgegengesetzte Richtung zu lenken.
Nachdem wir den Roboter fertig gebaut haben, haben wir endlich angefangen, uns ernsthaft mit der NXT-Programmierung zu beschäftigen. Wir haben viele verschiedene Ansätze probiert, die aber nicht klappten. Das größte Problem von uns war, dass wir die zwei Lichtsensoren nicht gleichzeitig ansteuern konnten. Später hat uns Herr Debacher einen guten Ansatz nach Muster eines Baumdiagramms gezeigt, was auch klappt...bis auf eines: wir können das Programm nicht beenden.
Nachdem wir die Variablen ausgelassen haben und in den Klammern des while-Klausels "true" einsetzten, klappte das Ganze, jedoch gibt es praktisch keine Stopp-Bedingung. Erst als wir Herrn Debacher um Rat gefragt haben, konnten wir das Problem feststellen: Es lag hauptsächlich daran, dass wir unserer Variable keinen Datentyp zugewiesen haben. Nach der Eingabe eines "int" vor der Variablen, funktionierte das Ganze.
Konstruktion eines passenden Roboters
Wir sind erst hierher angekommen, als wir schon nicht mehr viel Zeit hatten und die Programmierung kann ohne den Roboter nicht angefangen werden, Zeitdruck für uns also.
Wir haben uns insgesamt viele Gedanken über den Roboter gemacht. Zunächst wollten wir ein Tablett vor dem Roboter anbringen, was durch den geringen Platz, der diese Methode bietet und durch die schlechte Gewichtslagerung verworfen wurde. Wir sind zum Schluss gekommen, dass die Tragefläche auf dem „Rücken“ des Roboters sein muss. Um die Stabilität zu gewährleisten muss der Roboter flach und breit gebaut sein. Als Fortbewegungsmethode schien uns der Einsatz von Kettenband sinnvoll zu sein.
Am Ende haben wir einen panzerähnlichen Roboter gebaut mit einem Bild eines Kellners hinten am Rumpf, damit der Gast weißt, mit wem er es zu tun hat (siehe Bild).
Das einzige, aber auch große, Problem bei der Realisierung ist, dass der Roboter zu flach geworden ist und seine Ketten zu weit auseinander liegen, sodass er schon bei leichtem Druck auf seine Tragefläche nach unten sackt und sein Brick den Boden berührt. Aber der kommende Praxistest wird uns noch zeigen, wie sich das Problem auswirkt.
Zwischenergebnis
Wir haben geschafft:
- einen Dialog aufzubauen
- Grammatiken einzufügen
- einen passenden Roboter zu bauen
- den Roboter nach einem Kellner zu gestalten
- ein NXT-Programm für die Wegfindung des Roboters zu schreiben
- die Funktionalität der Roboter-Wegfindung zu testen (mit Erfolg)
Wir haben (noch) nicht geschafft:
- das ganze System auszuprobieren
- den Roboter so umzubauen, dass man an die An- und Ausschaltknöpfe kommt
- dass der Roboter auf dem Weg den Gast unterhält
- dass der Roboter sich die Bestellung merkt
Wir haben verworfen:
- den Ultraschallsensor für das Orten des Gastes einzusetzen
- dass der Roboter rückwärts fährt, wenn er zurück zur "Kuche" fährt (aufgrund seiner Konstruktion muss er sich stattdessen umdrehen)
- ein umfangreicheres Angebot anzubieten
- den Roboter unabhängig von menschlicher Hilfe zu machen
- dass der Roboter mehrere Gäste gleichzeitig bedient
- dass der Roboter die Bestellung des Gastes auf den Tisch stellt
