Hier werden die Unterschiede zwischen zwei Versionen gezeigt.
Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung | ||
projektewise17:haligali:doku:h_doku [2018/03/08 17:56] zerbian [Tabelle] |
projektewise17:haligali:doku:h_doku [2018/03/16 16:07] (aktuell) d.golovko |
||
---|---|---|---|
Zeile 10: | Zeile 10: | ||
===Kartenausgabe=== | ===Kartenausgabe=== | ||
- | {{ :projektewise17:haligali:doku:kartenausgabe.png?300|Seitenansicht}} | + | <figure label>{{:projektewise17:haligali:doku:kartenausgabe.png?500|Seitenansicht}}<caption>Abbildung 1: Seitenansicht</caption></figure> |
Unser Anspruch war, dass der Roboter ziemlich zuverlässig einzelne Karten ausgeben kann. Unsere Konstruktion besteht somit aus einer Kartenablage, in der die Karten liegen, einem Steppermoter, der über ein gummiertes Rad von unten die unterste Karte des Stapels nach vorne schiebt und einer Rampe, auf der die auszugebende Karte dann herrunterrutscht. | Unser Anspruch war, dass der Roboter ziemlich zuverlässig einzelne Karten ausgeben kann. Unsere Konstruktion besteht somit aus einer Kartenablage, in der die Karten liegen, einem Steppermoter, der über ein gummiertes Rad von unten die unterste Karte des Stapels nach vorne schiebt und einer Rampe, auf der die auszugebende Karte dann herrunterrutscht. | ||
- | {{ :projektewise17:haligali:doku:kartenausgabe_front.png?200|Frontansicht}} | + | <figure label>{{:projektewise17:haligali:doku:kartenausgabe_front.png?500|Frontansicht}}<caption>Abbildung 2: Frontansicht</caption></figure> |
Damit wir sicherstellen konnten, dass auch nur eine Karte pro Ausgabe auch ausgegeben wird haben wir eine Art Wand noch vor den Kartenstapel eingezogen, welche von der Höhe so eingestellt war, dass nur eine Karten darunter durch passt. Da wir nicht genau bestimmen konnten, wie weit sich das Rad drehen muss, damit nur eine Karte ausgeben wird, haben wir noch eine Rückwärtsbewegung des Rades hinzugefügt, dass wenn die nächste Karte aus versehen schon mit nach vorne geschoben wird, sie wieder zurück geschoben wird. | Damit wir sicherstellen konnten, dass auch nur eine Karte pro Ausgabe auch ausgegeben wird haben wir eine Art Wand noch vor den Kartenstapel eingezogen, welche von der Höhe so eingestellt war, dass nur eine Karten darunter durch passt. Da wir nicht genau bestimmen konnten, wie weit sich das Rad drehen muss, damit nur eine Karte ausgeben wird, haben wir noch eine Rückwärtsbewegung des Rades hinzugefügt, dass wenn die nächste Karte aus versehen schon mit nach vorne geschoben wird, sie wieder zurück geschoben wird. | ||
===Klingelstation=== | ===Klingelstation=== | ||
- | {{ :projektewise17:haligali:doku:klinegl.png?200|}} | + | <figure label>{{:projektewise17:haligali:doku:klinegl.png?500|}}<caption>Abbildung 3: Klingelstation</caption></figure> |
- | <note important>Diese Abbildung ist zu klein: die Beschriftungen sind nicht mehr lesbar. \\ | ||
- | |||
- | Jede Abbildung soll eine Nummer und Unterschrift bekommen, z.B. "Abb. 3: Klingel". \\ | ||
- | |||
- | Ihr braucht zusätzlich eine Abbildung, wo das gesamte Roboter zu sehen ist. Es ist z.B. nicht klar, das die Klingel und der Inhalt der 1. Abbildung nebeneinander stehen, und der Kameraarm ist hier nicht sichtbar. | ||
- | </note> | ||
Nach einigen Überlegungen,wie die Klingel von dem Roboter betätigt werden soll,kamen wir auf den Entschluss,den Roboter nicht anhand einer "Hand" klingeln zu lassen,also von oben,sondern von unten mithilfe eines Hubmagneten. Dieser stößt den Schwingungskörper der Klingel an wodurch diese klingelt. Der große Vorteil davon ist,dass der Mensch als Gegenspieler ohne Einschränkung auf die klingel schlagen kann. Mensch und Maschine stehen sich nicht unnütz im Weg. Da nun der Mensch zwar anhand des Geräusches wahrnehmen kann, ob der Roboter geklingelt hat und der Roboter nicht diese Fähigkeit besitzt, mussten wir uns eine Lösung dafür überlegen. | Nach einigen Überlegungen,wie die Klingel von dem Roboter betätigt werden soll,kamen wir auf den Entschluss,den Roboter nicht anhand einer "Hand" klingeln zu lassen,also von oben,sondern von unten mithilfe eines Hubmagneten. Dieser stößt den Schwingungskörper der Klingel an wodurch diese klingelt. Der große Vorteil davon ist,dass der Mensch als Gegenspieler ohne Einschränkung auf die klingel schlagen kann. Mensch und Maschine stehen sich nicht unnütz im Weg. Da nun der Mensch zwar anhand des Geräusches wahrnehmen kann, ob der Roboter geklingelt hat und der Roboter nicht diese Fähigkeit besitzt, mussten wir uns eine Lösung dafür überlegen. | ||
Zeile 31: | Zeile 25: | ||
===Kameraarm=== | ===Kameraarm=== | ||
- | Da oben bereits die Kartenausgabe erklärt und die Funktion der Klingel erläutert wurde, stellt sich nun die Frage wie der Roboter in der Lage sein sein soll die Karten richtig zu erkennen. | + | Damit unser Roboter die Farben der Karten erkennen benutzen wir eine Kamera. Diese sollte nun in der Lage sein die ausgegebenen Karten des Roboters und des Menschen zu erkennen. Aufgrunddessen haben wir uns dazu entschieden sie am Ende der Rampe zu platzieren. Sie musste reichlich Fläche aufnehmen können, weshalb wir eine Vorrichtung gebaut haben, an der die Kamera kopfüber in ca. 20 cm Höhe befestigt wurde. Sie erfässt dadurch die Karten beider Spieler. |
- | Dass wir eine Kamera dafür benötigen und diese Farben erkennen soll ,ist nach dem Spielprinzip von Halli-Galli selbsterklärend. Unsere Kamera sollte nun in der Lage sein die ausgegebenen Karten des Roboters und des Menschen zu erkennen. Aufgrunddessen haben wir uns dazu entschieden sie am Ende der Rampe zu platzieren. Sie musste reichlich Fläche aufnehmen können, weshalb wir eine Vorrichtung gebaut haben, an der die Kamera kopfüber in ca. 20 cm Höhe befestigt wurde. Sie erfässt dadurch die Karten beider Spieler. | + | |
- | + | ||
- | <note important>Diesen Absatz würde ich umformulieren: "Da oben bereits die Kartenausgabe erklärt und die Funktion der Klingel erläutert wurde" muss man hier nicht nochmal erklären, und "Dass wir eine Kamera dafür benötigen, ... ist nach dem Spielprinzip von Halli-Galli selbsterklärend" -- glaube ich nicht (hätte theoretisch z.B. ein Farbsensor oder ein Spektrometer sein können). \\ | + | |
- | + | ||
- | Besser z.B. so: "Damit der Roboter die ausgegebenen Karten anhand ihrer Farbe richtig erkennen kann, verwenden wir eine Kamera. Die Kamera soll die ausgegebenen Karten des Roboters und des Menschen..." \\ | + | |
- | + | ||
- | Der Kameraarm und die Licher sind auf der 1. Abbildung leider nicht zu sehen. Entweder braucht ihr hier eine andere Abbildung (am besten sowohl mit dem Kameraarm als auch mit dem Rest des Roboters, damit klar wird, wo der Roboterarm ist), oder ihr ändert die Abb. 1, oder ihr fügt eine Abbildung mit einer Gesamtansicht des Roboters hinzu. | + | |
- | + | ||
- | </note> | + | |
Damit es zu weniger Lichtproblemen kommt, die bei der Programmierung der Farberkennung bemerkbar wurden, haben wir neben der Kamera Lichter befestigt die den aufgenommenen Bereich so gut wie möglich beleuchten. Zu der Funktion der Farberkennung kommen wir gleich. | Damit es zu weniger Lichtproblemen kommt, die bei der Programmierung der Farberkennung bemerkbar wurden, haben wir neben der Kamera Lichter befestigt die den aufgenommenen Bereich so gut wie möglich beleuchten. Zu der Funktion der Farberkennung kommen wir gleich. | ||
Zeile 49: | Zeile 34: | ||
Der Arduino kommuniziert per USB über die serielle Schnittstelle mit dem Computer und empfängt Nachrichten, wann er eine Karten ausgeben oder die Klingel betätigen soll und sendet eine Nachricht, wenn die Klingel gedrückt wurde. Nähere Erklärung [[projektewise17:haligali:doku:c_doku|hier]]. | Der Arduino kommuniziert per USB über die serielle Schnittstelle mit dem Computer und empfängt Nachrichten, wann er eine Karten ausgeben oder die Klingel betätigen soll und sendet eine Nachricht, wenn die Klingel gedrückt wurde. Nähere Erklärung [[projektewise17:haligali:doku:c_doku|hier]]. | ||
===Schaltplan=== | ===Schaltplan=== | ||
- | {{ :projektewise17:haligali:doku:wireing.png?500|}}{{:projektewise17:haligali:doku:wirering_board.png?500 |}} | + | <figure label>{{:projektewise17:haligali:doku:wireing.png?500|}}<caption>Abbildung 4: Schaltplan</caption></figure> |
+ | <figure label>{{:projektewise17:haligali:doku:wirering_board.png?500|}}<caption>Abbildung 5: Steckbrettansicht</caption></figure> | ||
===Materialiste=== | ===Materialiste=== | ||
Zeile 81: | Zeile 67: | ||
| Jumper-Kabel | 12 | | | Jumper-Kabel | 12 | | ||
+ | ===Pinbelegungstabelle=== | ||
+ | ^ Arduino Pin ^ Funktion ^ | ||
+ | |2 |Glocke (interrupt-Pin)| | ||
+ | |3 |Stepper (DIR)| | ||
+ | |4 |Stepper (STEP)| | ||
+ | |6 |Hubmagnet| | ||
- | <note important>Fügt bitte noch eine Pinbelegungstabelle hinzu. </note> | ||
+ | ===Arduino Processing Kommunikation=== | ||
+ | Auf dem Arduino läuft ein Programm, welches immer wieder die empfangenden Bytes über der seriellen Schnittstelle überprüft. Je nach Nachricht wird eine Karten ausgegeben, die Glocke geläutet oder nichts getan. | ||
+ | <code c> | ||
+ | void loop() { | ||
+ | //serielle Schnittstelle abfragen | ||
+ | if (Serial.available() > 0) { | ||
+ | //eingehende Bytes abfangen | ||
+ | int incoming = Serial.read(); | ||
+ | | ||
+ | //Fallunterscheidung | ||
+ | switch (incoming) { | ||
+ | case '0': | ||
+ | | ||
+ | //Hier folgt dann die Kartenausgabe | ||
+ | | ||
+ | case '1': | ||
+ | | ||
+ | //Hier erfolgt dann das Glockenklingeln | ||
+ | | ||
+ | } | ||
+ | } | ||
+ | } | ||
+ | </code> | ||
+ | Damit aber der Arduino auch senden kann, wenn die Glockgeläutet wird und der Stromkreis sehr kurz einmal geschlossen wird, hat der Arduino eine **Interrupt Routine**, die dafür sorgt, dass zu jedem Zeitpunkt die Nachricht gesendet werden kann((Wenn man im normalen //loop// versuchen würde immer abzufragen, ob der Stromkreis geschlossen ist, dann passiert es, dass der Arduino in dem Moment, wo die Stromkreis kurz geschlossen ist gerade etwas anderes macht und das Schließen somit garnicht bemerkt.)). | ||
+ | <code c> | ||
+ | void setup() { | ||
+ | | ||
+ | //Funktion "interrupt_routine" an einen Interrupt Pin "binden" | ||
+ | attachInterrupt(0, interrupt_routine, FALLING); | ||
+ | } | ||
+ | void interrupt_routine() { | ||
+ | | ||
+ | //Senden von Nachricht, wenn die Glockgeklingelt wurde | ||
+ | Serial.write('2'); | ||
+ | } | ||
+ | </code> | ||
Zeile 184: | Zeile 211: | ||
<note tip>Um die Zusammenhänge der einzelnen Klassen besser darzustellen wäre hier wohl ein UML angebracht, jedoch wurde dieses noch nicht erstellt.</note> | <note tip>Um die Zusammenhänge der einzelnen Klassen besser darzustellen wäre hier wohl ein UML angebracht, jedoch wurde dieses noch nicht erstellt.</note> | ||
- | {{ :projektewise17:haligali:doku:onscreen.jpeg?200|Bildauswertung}} | + | <figure label>{{:projektewise17:haligali:doku:onscreen.jpeg?500|Bildauswertung}}<caption>Abbildung 6: Bildauswertung((Hier sieht man aber auch, |
+ | dass die Bildauswertung noch nicht optimiert wurde.))</caption></figure> | ||
Somit kann man also jedem festgelegten Bereich eine Farbe zuordnen. Danach müssen nur noch die Anzahl der jeweiligen Farbfelder bestimmt werden, und schon kann gesagt werden, ob die Gewinnbedingung nach den Spielregeln eintrifft. | Somit kann man also jedem festgelegten Bereich eine Farbe zuordnen. Danach müssen nur noch die Anzahl der jeweiligen Farbfelder bestimmt werden, und schon kann gesagt werden, ob die Gewinnbedingung nach den Spielregeln eintrifft. | ||
Zeile 190: | Zeile 218: | ||
Unser Halli-Galli Roboter ist in der Lage die Grundlagen des Spiels zu erledigen (Kartenausgabe -> Kartenerkennung -> Klingel ). Allerdings ist es noch nicht möglich ein richtiges Spiel gegen ihn zu spielen, weil er noch nicht erkennen kann ob sein Gegner eine neue Karte gelegt hat und folglich nicht weiß wann er am Zug ist. Jedoch haben wir ein sehr gut strukturiertes Framework geschaffen, welches auch sehr gut geeignet wäre für Gruppen in folgenden Projektlaboren weitergeführt zu werden. | Unser Halli-Galli Roboter ist in der Lage die Grundlagen des Spiels zu erledigen (Kartenausgabe -> Kartenerkennung -> Klingel ). Allerdings ist es noch nicht möglich ein richtiges Spiel gegen ihn zu spielen, weil er noch nicht erkennen kann ob sein Gegner eine neue Karte gelegt hat und folglich nicht weiß wann er am Zug ist. Jedoch haben wir ein sehr gut strukturiertes Framework geschaffen, welches auch sehr gut geeignet wäre für Gruppen in folgenden Projektlaboren weitergeführt zu werden. | ||
- | Er ist außerdem noch Verbesserungswürdig: Der Roboter weiß z.B. nicht wie viele Karten er noch übrig hat, was allerdings nicht notwendig ist zu können, da der Mensch das überprüfen kann. Deshalb ist es oben nicht aufgelistet. Ein weiterer Punkt wäre, dass er in der Lage sein könnte ..?.. | ||
- | |||
- | <note important>Hier kommt noch was?</note> | ||
====Code und Rohdaten==== | ====Code und Rohdaten==== | ||
- | Gesamter Code und noch weitere Erklärungen: [[projektewise17:haligali:doku:c_doku|Code und Rohdaten]] | + | Gesamter Code: [[projektewise17:haligali:doku:c_doku|Code und Rohdaten]] |
+ | <note important>**Bewertung der Dokumentation** | ||
- | <note important>Ich möchte, dass alles auf eine Seite kommt. Z.B. so: \\ | + | Gute Dokumentation, die alle Aspekte des Projektes erläutert, mit Abbildungen in guter Qualität verdeutlicht und in einer angenehm zu lesenden Sprache geschrieben ist. Es wäre gut gewesen, beim Kapitel “Processing Programm” nicht den ganzen Code zu kopieren (es wird auf die Code-Zeilen kein Bezug im Text genommen), sondern mit Worten oder Diagrammen die Funktion der Box-Klasse zu erläutern und die Zusammenhänge zwischen den einzelnen Klassen zu zeigen. Ein Ausblick wäre noch gut gewesen. |
- | * Der Kapitel "Processing Programm" kommt in den Kapitel "Bildverarbeitung". Ich glaube, ihr könntet anhand der Java-Klassen (z.B. ''Box'') auch besser erklären, wie ihr die Karte in mehrere Bereiche unterteilt habt und dort den Medianwert ermittelt habt. Das ist ein großer Beitrag von euch, ist aber ein wenig in der Doku untergegangen. | + | Ergebnis: 18 Punkte von 20. </note> |
- | * Aus dem Kapitel "Arduino Programm" macht ihr einen Kapitel "Kommunikation zwischen dem PC und Arduino". | + | |
- | * Was übrig bleibt (z.B. die .zip-Datei) kommt in den Kapitel "Code und Rohdaten". | + | |
- | Der Text von der Titelseite kann in die Einführung eingegliedert sein. | + | <note important>**Bewertung der Projektarbeit** |
- | </note> | + | |
+ | Auslegung und Teamarbeit: 10 Punkte von 10\\ | ||
+ | + Geplantes ist sauber gemacht, konsequente Entwicklung der Projektidee und Arbeit dran. Funktioniert! \\ | ||
+ | |||
+ | Mechanik / Gestell: 9 Punkte von 10 \\ | ||
+ | + Interessante Ideen mit dem gummierten Rad und der Rampe\\ | ||
+ | |||
+ | Elektronik: 9 Punkte von 10 \\ | ||
+ | + Ordentliche Farbkodierung, stabil und übersichtlich verkabelt, Mosfet verwendet, Idee mit dem Kontakt beim Klingeln der Glöcke\\ | ||
+ | |||
+ | Code: 10 Punkte von 10\\ | ||
+ | + Arbeit mit Processing und Kommunikation mit Arduino\\ | ||
+ | + Kommunikation zwischen Arduino und Processing\\ | ||
+ | + Verwendung von Klassen und Enums\\ | ||
+ | - Es gibt Variablen, deren Namen ohne guten Grund nur aus einer Buchstabe bestehen (k in main, k und m in Box). \\ | ||
+ | |||
+ | Insgesamt: 37 Punkte | ||
+ | |||
+ | </note> | ||
- | <note important>Zusammenfassung: generell sieht es gut aus. Lässt nicht die einzelnen Aspekte (z.B. Farberkennung, der Java-Code, Kommunikation mit Arduino) untertauchen, denn ihr habt gute Arbeit geleistet. Eine Abbildung mit einem Überblick über das Gesamtsystem würde zur Verständlichkeit beitragen. An manchen Stellen müsst ihr noch korrekturlesen. </note> |