Benutzer-Werkzeuge
projektews1415:frankroboy
Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen gezeigt.
| Nächste Überarbeitung | Vorhergehende Überarbeitung | ||
|
projektews1415:frankroboy [2015/03/30 13:45] c.jaedicke angelegt |
projektews1415:frankroboy [2016/01/21 12:45] (aktuell) |
||
|---|---|---|---|
| Zeile 1: | Zeile 1: | ||
| - | |||
| ====== Projektdokumentation ====== | ====== Projektdokumentation ====== | ||
| - | <note> | ||
| - | Kommentar zur 2. Korrektur+ Notengebung: | ||
| - | |||
| - | Ihr habt einen sehr ordentlichen ersten Ansatz eingereicht, dann aber leider auf unsere Korrekturvorschläge nicht weiter reagiert. | ||
| - | |||
| - | Die eingereichte Fassung deckt alle geforderten Bereich ab und hat die geforderte Grundstruktur. An einigen Stellen wurden Informationen vermischt, die zu getrennten Abschnitten gehört hätten. Die vorhandenen Zeichnungen sind gut oder sehr gut, es fehlt jedoch insbesondere eine Skizze, in der die Winkelbeziehungen zwischen Ball, Roboter und Tor erklärt werden. Die Erklärung des Algorithmus zur Farbmarkerfindung geht in die richtige Richtung, ist aber noch an vielen Stellen nicht exakt genug. Insbesondere fehlen Formeln und deren Herleitung völlig - darum werdet ihr euch in einer ingenieurswissenschaftlichen Laufbahn auch in Zukunft nicht drücken können... | ||
| - | |||
| - | Die Angaben im Fazit können so nicht stehen bleiben, ohne dass das zu deren Ermittlung verwendete experimentelle Protokoll und die so gewonnenen Daten angegeben werden. Das ist unverzichtbare Basis wissenschaftlichen Arbeitens. Der Verdacht, dass es sich bei den Zahlen um nicht belegbare Schätzungen nach Bauchgefühl (am Rande einer wissenschaftliche Fälschung) handelt, wiegt schwer und verhindert eine "gute" Bewertung. | ||
| - | |||
| - | Befriedigend mit guten Tendenzen (9/15) | ||
| - | |||
| - | Felix Bonowski | ||
| - | |||
| - | </note> | ||
| \\ | \\ | ||
| Hermann Pöhler, Eric Beier, Maximilian Schulz | Hermann Pöhler, Eric Beier, Maximilian Schulz | ||
| Zeile 48: | Zeile 33: | ||
| Frank Robory ist ein Roboter, der das Finden eines Balles mittels einer Kamera sowie das Ansteuern und Schießen (bzw. Schieben) von jenem ermöglicht. Zielstellung ist es, den Ball in das Tor des Gegenübers zu befördern. \\ Roboter bewegt sich auf einem rechteckigen Feld, welches durch Holzbalken abgetrennt ist und ca. 180cm x 250cm misst.\\ Eine Holzplatte dient als Grundplattform. An ihr sind zwei ansteuerbare, motorisierte Räder sowie eine Mauskugel, welche als Stütze dient, befestigt. Die Grundplatte ist bis auf die Vorderseite rund. An dieser befindet sich eine ebene Fläche, um den Ball zu schieben. Die Deckplatte ist mit 2 verschiedenfarbigen Punkten versehen. Durch eine über dem Spielfeld angebrachte Kamera ist es so möglich den Roboter, seine Fahrtrichtung sowie den Spielball zu lokalisieren. Durch Anwendung von Winkelbeziehungen und linearer Algebra errechnet er so den Weg zum Ball und bewegt ihn. Die von der Bildverarbeitung errechneten Informationen werden mithilfe von W-LAN an den Roboter übermittelt. Weiterhin sind auf der Grundplattte ein Arduino Mega, welcher die zentrale Steuerungseinheit des Roboters darstellt sowie ein AKKU, der die Motoren und Arduino mit Strom versorgt, befestigt. | Frank Robory ist ein Roboter, der das Finden eines Balles mittels einer Kamera sowie das Ansteuern und Schießen (bzw. Schieben) von jenem ermöglicht. Zielstellung ist es, den Ball in das Tor des Gegenübers zu befördern. \\ Roboter bewegt sich auf einem rechteckigen Feld, welches durch Holzbalken abgetrennt ist und ca. 180cm x 250cm misst.\\ Eine Holzplatte dient als Grundplattform. An ihr sind zwei ansteuerbare, motorisierte Räder sowie eine Mauskugel, welche als Stütze dient, befestigt. Die Grundplatte ist bis auf die Vorderseite rund. An dieser befindet sich eine ebene Fläche, um den Ball zu schieben. Die Deckplatte ist mit 2 verschiedenfarbigen Punkten versehen. Durch eine über dem Spielfeld angebrachte Kamera ist es so möglich den Roboter, seine Fahrtrichtung sowie den Spielball zu lokalisieren. Durch Anwendung von Winkelbeziehungen und linearer Algebra errechnet er so den Weg zum Ball und bewegt ihn. Die von der Bildverarbeitung errechneten Informationen werden mithilfe von W-LAN an den Roboter übermittelt. Weiterhin sind auf der Grundplattte ein Arduino Mega, welcher die zentrale Steuerungseinheit des Roboters darstellt sowie ein AKKU, der die Motoren und Arduino mit Strom versorgt, befestigt. | ||
| \\ | \\ | ||
| - | <note tip>Felix: Die geforderte Einführung in die Themenstellung ist enthalten und geht so grundsätzlich OK. Das Lesen fällt jedoch leichter, wenn ihr in diesem einführenden Abschnitt erst einmal das Grundkonzepts (Was ist alles beteiligt, was soll es tun, wo fließen Informationen) grob umreißt, ohne Maße und allzuviele technische Details zu nennen. Eine genauere Beschreibung des Aufbaus des Roboters und technische Daten zu den Bauteilen könnte dann in einem eigenen Abschnitt erfolgen.</note> | ||
| Konkurrenzprojekt: [[projektewise2014:soccerbot:start|SoccerBot]] | Konkurrenzprojekt: [[projektewise2014:soccerbot:start|SoccerBot]] | ||
| \\ | \\ | ||
| Zeile 58: | Zeile 42: | ||
| Zwei Kameras sind in einer Höhe von 190cm an einem Stativ aus einem vorherigen Projekt befestigt, wodurch ein Sichtfeld von 180cm x 250cm auf dem Boden entsteht. Die Kameras sind die Playstation–Eye von der Firma Sony, welche zum Sortiment der Playstation 3 gehören. Jede Kamera ist durch ein langes Kabel mit einem Computer verbunden. Das Sichtfeld der beiden Kameras ist die Begrenzung des Spielfeldes. Durch eine Holzbarriere aus 2,5cm starken Holzleisten wird der Ball daran gehindert bei einem Spiel das Kamerasichtfeld zu verlassen. Ein Teppich dient als Untergrund, auf dem der Roboter sich bewegt und durch seine Beschaffenheit die Fahrtüchtigkeit der Räder nicht einschränkt. Die graue Farbe des Teppichs stört die Farberkennung der Kamera nicht, da seine RGB-Werte keine Ähnlichkeit zu der Farbe des Balles und den Farben auf dem Roboter besitzt. | Zwei Kameras sind in einer Höhe von 190cm an einem Stativ aus einem vorherigen Projekt befestigt, wodurch ein Sichtfeld von 180cm x 250cm auf dem Boden entsteht. Die Kameras sind die Playstation–Eye von der Firma Sony, welche zum Sortiment der Playstation 3 gehören. Jede Kamera ist durch ein langes Kabel mit einem Computer verbunden. Das Sichtfeld der beiden Kameras ist die Begrenzung des Spielfeldes. Durch eine Holzbarriere aus 2,5cm starken Holzleisten wird der Ball daran gehindert bei einem Spiel das Kamerasichtfeld zu verlassen. Ein Teppich dient als Untergrund, auf dem der Roboter sich bewegt und durch seine Beschaffenheit die Fahrtüchtigkeit der Räder nicht einschränkt. Die graue Farbe des Teppichs stört die Farberkennung der Kamera nicht, da seine RGB-Werte keine Ähnlichkeit zu der Farbe des Balles und den Farben auf dem Roboter besitzt. | ||
| - | <note tip>Prinzipiell wichtige Angaben, die aber alle eher etwas mit der Bilderkennung als mit dem Spielfeld ansich zu tun haben. Die Tatsache, dass eine Kamera das Feld von oben betrachtet und ihre Daten für die Lokalisierung von Roboter und Ball verwendet werden, gehört eher in die "Beschreibung des Gesamtsystems" als hierher. Kleine sprachliche Ungenauigkeit: die PS3Eye "gehört" nicht "zum Sortiment" der PS3, sonder wird als Zubehört zur PS3 verkauft. | + | |
| - | Das Tor erwähnt ihr mit keinem Satz, welches jedoch zum Spielfeld gehört. | + | |
| - | </note> | + | |
| === Roboter === | === Roboter === | ||
| Zeile 78: | Zeile 60: | ||
| \\ | \\ | ||
| {{ :projektewise2014:frankroboy:aufbau2.1.jpg?nolink |}} | {{ :projektewise2014:frankroboy:aufbau2.1.jpg?nolink |}} | ||
| - | <note tip>Gute Bilder! An dieser Stelle würde ein Text über die Funktion der Verwendeten Bauteile, Maße etc. passen. Was macht z.B. eigentlich dieses Motomama-Board?</note> | ||
| \\ | \\ | ||
| === b) Materialien === | === b) Materialien === | ||
| Zeile 110: | Zeile 91: | ||
| \\ | \\ | ||
| ===== Bildverarbeitung ===== | ===== Bildverarbeitung ===== | ||
| - | <note>Bei einem Komplexen Thema wie diesem bietet es sich an, erst einmal die Problematik mit 1-3 Sätzen zu erklären und dann eine detaillierte Beschreibung der einzelnen Schritte (mit Formeln und Skizzen) folgen zu lassen. Richtig gut ist die Beschreibung dann, wenn ein durchschnittliche begabter Leser, der euer Projekt nicht kennt, versteht, was da so ungefähr passiert und ein wirklich interessierter Leser den Text als ein Kochrezept verwenden kann, um euer Verfahren //**exakt**// so wie ihr es erfunden habt, nachzubauen ("Reproduzierbar").</note> | ||
| Die Kamera untersucht dank des erarbeiteten Processing – Programms nacheinander jeden aufgenommen Pixel. | Die Kamera untersucht dank des erarbeiteten Processing – Programms nacheinander jeden aufgenommen Pixel. | ||
| - | <note>Wie erfolgt diese Untersuchung genau?</note> | ||
| Um Fehler zu minimieren, wird der Mittelwert der gefundenen Werte verwendet. | Um Fehler zu minimieren, wird der Mittelwert der gefundenen Werte verwendet. | ||
| - | <note>Wann ist ein Wert ein "gefundener"? Was wird gemittelt? Farben? Positionen?</note> | ||
| Eingespeicherte Farbwerte können so erkannt und visuell markiert werden. | Eingespeicherte Farbwerte können so erkannt und visuell markiert werden. | ||
| - | <note>Wie werden Farbwerte denn gespeichert? Was für Farbwerte speichert ihr und wozu?</note> | ||
| Da durch die Lichteinwirkung und die unkonstante Aufnahme der Kamera jedoch nur in den seltesten Fällen exakt die gewünschten RGB - Werte erreicht werden, sind Toleranzen für jene im Programm implementiert. | Da durch die Lichteinwirkung und die unkonstante Aufnahme der Kamera jedoch nur in den seltesten Fällen exakt die gewünschten RGB - Werte erreicht werden, sind Toleranzen für jene im Programm implementiert. | ||
| - | <note> | ||
| - | Sprache: | ||
| - | * "unkonstant" ist etwas ungenau - was ändert sich da? | ||
| - | * Das Gleiche gilt für die für "Lichteinwirkung": Verändern sich die Farben, wenn sie kontinuierlich der Sonne ausgesetzt sind (dafür wäre das der richtige Begriff), oder verändern sich die gemessenen RGB-Werte, wenn sich die Lichtverhältnisse im Raum verändern? | ||
| - | |||
| - | </note> | ||
| Sie sind in einem 3D - Koordinatensystem als Kugel um den Idealfarbwert dargestellt (siehe Abbildung). Dank einer eingebauten mousePressed – Funktion können auf dem Bildschirm zudem beliebige Pixel angeklickt und ihre Farbwerte ausgegeben werden. So ist es möglich die zu erkennenden Farben bei verschiedenen Lichtverhältnissen zu kalibrieren. | Sie sind in einem 3D - Koordinatensystem als Kugel um den Idealfarbwert dargestellt (siehe Abbildung). Dank einer eingebauten mousePressed – Funktion können auf dem Bildschirm zudem beliebige Pixel angeklickt und ihre Farbwerte ausgegeben werden. So ist es möglich die zu erkennenden Farben bei verschiedenen Lichtverhältnissen zu kalibrieren. | ||
| \\ | \\ | ||
| Zeile 140: | Zeile 111: | ||
| \\ | \\ | ||
| Jeweils zwischen dem Farbpunkt des Balles und dem Mittelpunkt des Roboters sowie zwischen den zwei robotereigenen Farbpunkten werden nun Vektoren aufgespannt. So ist es möglich die Route vom Roboter zum Ball mit der reellen Fahrtrichtung abzugleichen. | Jeweils zwischen dem Farbpunkt des Balles und dem Mittelpunkt des Roboters sowie zwischen den zwei robotereigenen Farbpunkten werden nun Vektoren aufgespannt. So ist es möglich die Route vom Roboter zum Ball mit der reellen Fahrtrichtung abzugleichen. | ||
| - | <note>Idealerweise wäre hier eine Skizze, in der die beiden Vektoren sowie der Winkel eingezeichnet sind.</note> | ||
| | | ||
| ===== Fahrfunktion ===== | ===== Fahrfunktion ===== | ||
| Um die Abweichung zwischen idealem und tatsächlichen Fahrweg zu errechnen, wird die atan2 – Funktion benutzt. Diese errechnet den Winkel zwischen den zwei, von der Bildverarbeitung erstellten, Vektoren. Weiterhin gibt sie durch das Vorzeichen des Ergebnisses an, ob sich der Ball links oder rechts vom Roboter befindet. | Um die Abweichung zwischen idealem und tatsächlichen Fahrweg zu errechnen, wird die atan2 – Funktion benutzt. Diese errechnet den Winkel zwischen den zwei, von der Bildverarbeitung erstellten, Vektoren. Weiterhin gibt sie durch das Vorzeichen des Ergebnisses an, ob sich der Ball links oder rechts vom Roboter befindet. | ||
| - | <note>Hier sollten eine Sikzze die Lage der Punkte und Vektoren verdeutlichen. In der Skizze sollten die Variablen eingezeichnet sein, die in einer Formel verwedet werden, um einen Winkel auszurechnen. Die Formel könnt ihr entweder direkt in die Skizze oder in den Text schreiben.</note> | ||
| \\ | \\ | ||
| Zunächst war geplant, den Roboter um sich selbst drehen zu lassen, bis alle drei Punkte auf einer Gerade waren und ihn dann Fahren zu lassen. Jedoch stellte sich heraus, dass diese Methode nicht nur langsam, sondern auch sehr fehleranfällig war. Da die Farberkennung nicht immer perfekt funktioniert (Erkannte Werte schwanken) erkannte das Programm oft nicht, dass der Roboter in perfekter Position war und ließ ihn so mehrere Male um 360° drehen. | Zunächst war geplant, den Roboter um sich selbst drehen zu lassen, bis alle drei Punkte auf einer Gerade waren und ihn dann Fahren zu lassen. Jedoch stellte sich heraus, dass diese Methode nicht nur langsam, sondern auch sehr fehleranfällig war. Da die Farberkennung nicht immer perfekt funktioniert (Erkannte Werte schwanken) erkannte das Programm oft nicht, dass der Roboter in perfekter Position war und ließ ihn so mehrere Male um 360° drehen. | ||
| - | <note>Gute Beschreibung!</note> | ||
| \\ | \\ | ||
| Stattdessen werden nun die Winkel in Geschwindigkeiten umgerechnet, die als Parameter an die Motoren übergeben werden. Im Diagramm dargestellt sind die Geschwindigkeiten, welche die Räder je nach gemessenem Winkel annehmen. Je größer der Winkel zu Idealroute ausfällt, desto schneller bewegt sich das Rad, welches zum Ausgleich benötigt wird. Parallel wird das gegenüberliegende Rad proportinial zum winkel langsamer. | Stattdessen werden nun die Winkel in Geschwindigkeiten umgerechnet, die als Parameter an die Motoren übergeben werden. Im Diagramm dargestellt sind die Geschwindigkeiten, welche die Räder je nach gemessenem Winkel annehmen. Je größer der Winkel zu Idealroute ausfällt, desto schneller bewegt sich das Rad, welches zum Ausgleich benötigt wird. Parallel wird das gegenüberliegende Rad proportinial zum winkel langsamer. | ||
| {{ :projektewise2014:frankroboy:geschwindigkeitsdiagramm.jpg |}} | {{ :projektewise2014:frankroboy:geschwindigkeitsdiagramm.jpg |}} | ||
| - | |||
| - | <note>Das Bild ist sehr schön! Damit es so richtig vollständig ist, fehtl aber noch eine Formel, die den Funktionszusammenhang aus Winkel und "Gasgeben" beschreibt, eine Begründung, warum die Werte gerade genau so gewählt wurden, und ein Hinweis darauf, was passiert, wenn der Roboter am Ball angekommen ist.</note> | ||
| - | |||
| ===== Datenübertragung ===== | ===== Datenübertragung ===== | ||
| Zeile 161: | Zeile 126: | ||
| {{ :projektewise2014:frankroboy:5595561403175750003.jpg?nolink&200|}}Um die Daten von dem Processingprogramm des Computers zu dem Roboter, welcher mit einem Arduinoprogramm läuft zu übermitteln, benutzen wir W-LAN. Auf dem Roboter ist das Wifly-Modul (RN-XV, rechts) durch das MotoMama Board mit dem Arduino verbunden. Die Datenübertragung vom Wifly -Modul zum Arduino erfolgt über die Pins, beziehungsweise die Eingänge der beiden Geräte. Das Wifly-Modul ermöglicht es dem Arduino, über einen Router mit dem Computer und somit auch mit Processing zu kommunizeren. Beide Geräte müssen mit dem Router verbunden sein. Durch den Austausch von der IP-Adresse und einem dazugehörigen Passwortes sind die beiden Geräte gekoppelt. Die Koppelung ermöglicht es Nachrichten von Processing zu Arduino zu übermitteln. Die Bildverarbeitung liefert entsprechend der errechneten Geschwindigkeiten verschiedene Nachrichten,welche die Parameter an den Arduino Mega übergeben. Diese Nachrichten werden mit Hilfe des Wifly-Moduls vom Arduino empfangen. Abhängig von der empfangenen Nachricht führt der Arduino bestimmte Funktionen aus. | {{ :projektewise2014:frankroboy:5595561403175750003.jpg?nolink&200|}}Um die Daten von dem Processingprogramm des Computers zu dem Roboter, welcher mit einem Arduinoprogramm läuft zu übermitteln, benutzen wir W-LAN. Auf dem Roboter ist das Wifly-Modul (RN-XV, rechts) durch das MotoMama Board mit dem Arduino verbunden. Die Datenübertragung vom Wifly -Modul zum Arduino erfolgt über die Pins, beziehungsweise die Eingänge der beiden Geräte. Das Wifly-Modul ermöglicht es dem Arduino, über einen Router mit dem Computer und somit auch mit Processing zu kommunizeren. Beide Geräte müssen mit dem Router verbunden sein. Durch den Austausch von der IP-Adresse und einem dazugehörigen Passwortes sind die beiden Geräte gekoppelt. Die Koppelung ermöglicht es Nachrichten von Processing zu Arduino zu übermitteln. Die Bildverarbeitung liefert entsprechend der errechneten Geschwindigkeiten verschiedene Nachrichten,welche die Parameter an den Arduino Mega übergeben. Diese Nachrichten werden mit Hilfe des Wifly-Moduls vom Arduino empfangen. Abhängig von der empfangenen Nachricht führt der Arduino bestimmte Funktionen aus. | ||
| - | <note>Ihr habt die Verbingung zwischen Arduino und Wifly gut erklärt. Unklar beibt noch welche Art von Daten ihr übertragt und wie ihr das tut (Library).</note> | ||
| ===== Pinliste Arduino ===== | ===== Pinliste Arduino ===== | ||
| Zeile 189: | Zeile 153: | ||
| ===== Endergebnis ===== | ===== Endergebnis ===== | ||
| - | Zur Zeit der Erstellung dieser Dokumentation findet und schiebt der Roboter in ca. 40% den Ball. Das Tor trifft er mit einer Wahrscheinlichkeit von etwa 15% noch recht selten. <note>Solche Zahlen sind genau das, was wir wollen - sie sollten allerdings irgendwie belegt sein - z.B. durch eine Dokumentierte Zählung mit ebenso dokumentierten Ausgangsbedingungen. Falls euch das zuviel ist, müsst ihr angeben, dass diese Zahlen ein subjektives Gefühl sind, und keine Messung stattgefunden hat - das ist natürlich nicht ganz so super, aber auf jeden Fall besser, als wenn der Verdacht im Raum bestehen bleibt, ihr hättet sie euch einfach ausgedacht ohne irgendwas zu belegen (das wäre dann Betrug...)</note> | + | Zur Zeit der Erstellung dieser Dokumentation findet und schiebt der Roboter in ca. 40% den Ball. Das Tor trifft er mit einer Wahrscheinlichkeit von etwa 15% noch recht selten. |
| \\ | \\ | ||
| Die Motoren des Roboters lassen sich wie gewünscht ansteuern und lenken Frank Robory so in die gewünschte Richtung. Das Hinterrad (Mauskugel) weist leichte Abnutzungserscheinungen auf, die die Bewegung allerdings nicht einschränken. | Die Motoren des Roboters lassen sich wie gewünscht ansteuern und lenken Frank Robory so in die gewünschte Richtung. Das Hinterrad (Mauskugel) weist leichte Abnutzungserscheinungen auf, die die Bewegung allerdings nicht einschränken. | ||
| Zeile 196: | Zeile 160: | ||
| \\ | \\ | ||
| Das Problem, welches zur hohen Fehlerquote des Roboters führt und ihn somit oft im Kreis fahren lässt, ist die Farberkennung. Oft werden die zu findenen Farben nur teilweise oder gar nicht erkannt. Auslöser dafür ist die schwankende Helligkeit auf dem Spielfeld, welche die Farberkennung den real konstanten Farben, je nach Lage auf dem Spielfeld, teilweise drastisch abweichende RGB-Werte zuweisen lässt. | Das Problem, welches zur hohen Fehlerquote des Roboters führt und ihn somit oft im Kreis fahren lässt, ist die Farberkennung. Oft werden die zu findenen Farben nur teilweise oder gar nicht erkannt. Auslöser dafür ist die schwankende Helligkeit auf dem Spielfeld, welche die Farberkennung den real konstanten Farben, je nach Lage auf dem Spielfeld, teilweise drastisch abweichende RGB-Werte zuweisen lässt. | ||
| - | <note>Eine sehr plausible Vermutung - Idealerweise sollte auch so etwas irgendwie belegt sein - z.B. indem ihr dem Roboter an ein paar verschiedenen Stellen hinstellt und die Farben auf seinen Markern messt und die Ergebnisse in einer Tabelle darstellt.</note> | ||
| \\ | \\ | ||
| Weiterhin bleibt Frank Robory oft an de Abgrenzung des Spielfelds hängen, was durch eine nicht implementierte Funktion zur Vermeidung der Spielfeldränder zu erklären ist. | Weiterhin bleibt Frank Robory oft an de Abgrenzung des Spielfelds hängen, was durch eine nicht implementierte Funktion zur Vermeidung der Spielfeldränder zu erklären ist. | ||
| \\ | \\ | ||
| - | <note> Inhaltlich ist der Abschluss vorbildlich, allerdings fehlen Belege für die genannten Zahlen.</note> | ||
| ==== Torerfolg ==== | ==== Torerfolg ==== | ||
| Zeile 217: | Zeile 179: | ||
| Auch das Vermeiden der Banden oder eine Verteidigungsfunktion sind denkbar. So könnte sich Robory nicht mehr am Spielfeld aufhängen und im Tor positionieren, wenn der Ball im hinteren Teil der eigenen Hälfte liegt. | Auch das Vermeiden der Banden oder eine Verteidigungsfunktion sind denkbar. So könnte sich Robory nicht mehr am Spielfeld aufhängen und im Tor positionieren, wenn der Ball im hinteren Teil der eigenen Hälfte liegt. | ||
| - | |||
| - | <note>In eurer Dokumentation bleibt unklar, was eure Strategie zum Ball schießen ist. Im Moment fahrt ihr nur auf den Ball, was noch keinen Torschuss zulässt. Das sollte ein wenig Mathematik in die Doku bringen, die bis jetzt eher unangetastet bleibt, die ihr aber sicher verwendet habt.</note> | ||
| ===== Links ===== | ===== Links ===== | ||
| Zeile 226: | Zeile 186: | ||
| {{:projektewise2014:frankroboy:code-robory.zip|}} | {{:projektewise2014:frankroboy:code-robory.zip|}} | ||
| \\ | \\ | ||
| - | <note>Der Code ist Teilweise noch unkommentiert und hat noch debug-Ausgaben.</note> | ||
| \\ | \\ | ||
| Libaries und Programme zur Benutzung von Kamera und Co.: | Libaries und Programme zur Benutzung von Kamera und Co.: | ||
| {{:projektewise2014:frankroboy:libaries.zip|}} | {{:projektewise2014:frankroboy:libaries.zip|}} | ||
projektews1415/frankroboy.1427715929.txt.gz · Zuletzt geändert: 2016/01/21 12:45 (Externe Bearbeitung)
Seiten-Werkzeuge
